[HEX Edittor] Is this supported?

[djwessie]

Well, cause i thought it would fit here the best.

A friend of mine asked if the former HEX edittor (Would allow you to hack values like how many objects you can place in parks or how many objects you could select in the scenario edittor.) [BEWARE, THIS IS VERY DANGEROUS IN SAVEGAMES!]

Or is this tool not supported yet for OpenRCT-2?

Regards,

Wes.

[X7123M3-256]

A hex editor can be used to edit any type of binary data, SV6 files included. It's just a matter of how difficult it is. SV6 files are stored in compressed format, and this makes them hard to edit manually. That was true in vanilla as well. I have a script that will decompress the SV6 for editing and then recompress it when done which I've used in the past for hacks not supported by OpenRCT2. However, I prefer to do this sort of thing on the in-memory version of the data (which is not compressed). You can do this with a debugger, or simply by inserting some extra code after the SV6 is loaded. This approach has the advantage that you can take advantage of the existing symbols - you don't have to manually calculate the correct offset for the value you want to change, and you can easily loop over the map data if you need to do something to every tile.

2 hours ago, djwessie said:

Would allow you to hack values like how many objects you can place in parks or how many objects you could select in the scenario edittor.

A hex editor will absolutely NOT allow you to override these limits. The SV6 file allocates a fixed amount of space for the table of selected rides, and a fixed amount of space for the ride structures themselves. If you want more of them, there's nowhere to put them. These limits cannot be removed without a new file format - if you just patch out the limit, all you'll be doing is clobbering memory reserved for other things. This will corrupt your game.

Edited September 6, 2016 by X7123M3-256

[djwessie]

Well, it has worked before with serious danger you can override the limits, it's just very dangerous if you don't know what youre doing.

But thank you for the answer.

[X7123M3-256]

Seriously, it will not work, you will corrupt game data. Just because the game doesn't immediately crash doesn't mean it has worked. The behaviour is completely unpredictable because it doesn't show up until the corrupted memory is actually used. I have had all sorts of things happen as a result of exceeding these limits, from window icons drawing outside of the window to coaster cars turning into trees. There is only a fixed amount of space allocated for rides, if you try to write more than that you will be writing into memory used for something else, which will corrupt that, and then you have more problems when the code that originally used that memory writes over it again, and now whenever that ride is referenced it reads from corrupted memory. Further, only 1 byte is used to index into that array, so the extra ride would get index 0xFF, which is treated as unused (and any further rides would wrap around and start pointing at the beginning of the array instead).

And even if it appears to work, it might cease to do so with a later update. I had a ride that (unknowingly) exceeded the cars per train limit, and it appeared to work for months before the problem was discovered when it stopped working. (I then increased the cars per train limit, as it was possible to refactor the code to eliminate it entirely. That is not the case for the rides limit, a new file format is needed). The compiler will assume this type of thing just doesn't happen and doesn't have to account for the possibility - if it can determine that a buffer overflow will occur, it can literally optimize out the entire code block and that's perfectly valid behaviour, because absolutely nothing is guaranteed if you invoke undefined behaviour.