Terkhen's Personal Patch Pack

[Chillosophy]

Great collection of carefully selected patches, I love it. Keep up the good work!

[Terkhen]

Thanks for your support, Chillosophy

I have made a decision about patches that bump the savegame version. To force compatibility both with new versions of TPPP and updates to trunk, the present version will be the last one with savegame version bumping patches. This means that, as much as I like it, the patch "Conditional order: skip with certain probability" will be taken out. Also, savegames from v04 will be incompatible with v05, but after this last change you can forget about savegame incompatibilities between different TPPP versions and trunk forever. What do you think?

[Ammler]

but after this last change you can forget about savegame incompatibilities between different TPPP versions and trunk forever.

All other patches don't change the save format?

[Rubidium]

All other patches don't change the save format?

They probably don't add/remove bits of data. They just change the meaning of the data *or* they don't save what needs to be saved.

[Terkhen]

No, that's the only patch in TPPP that bumps it. I knew that I would have to test a savegame created with an Extra-large maps binary in vanilla trunk, but I posted in a hurry and didn't realized what Rubidium mentioned: there's a lot of patches in TPPP that alter the savegame format but they don't bump the savegame version (even if they should). Patches like Signals in tunnels and on bridges do changes to the savegame (adding more bits for that information). Close airports does not seem to save the "closed" state of the airport anywhere, and so on. It seems that I wanted to do the impossible for a PP unless I take out almost all patches

[planetmaker]

Well, if you accept closed airports as a temporary feature which is used only to upgrade airports, it's not that important. Surely it isn't clean, though, yes.

One thing which surely needs a savegame bump is the "more conditional orders" patch and as you stated the "big maps" patch. I'm not sure about chunnels, signals on bridges and tunnels might do without as from the description you give, it is calculated from what is there.

Such non-savegame bumping patchpack would be interesting IMO.

[Rubidium]

Close airports does not seem to save the "closed" state of the airport anywhere

So it even causes desyncs. You could take a look at MiniIN how that provided limited backward compatability for MiniIN and full backward compatability for trunk; MiniIN could only load the last 3-5 savegame versions of MiniIN, but with chaining MiniIN load-saves you could load all MiniIN saves in newer MiniIN (only once it started to have backward compatability support though).

[Terkhen]

It seems that Closed airports do save the state: as a movement block on the airport. Then it simply relies on the usual savegame functions to save the new flag. I suppose that if you move a savegame from a closed airports binary to trunk, the airport would just behave as normal. I'm going to check all patches closely, follow Rubidium advice and get back with a well examined status on each patch.

[cirdan]

Regarding the close airport patch, it does save the closed state of an airport in the savegame; it does so because the closed state is kept in a bit in the airport_flags field of a station, which gets saved. As such, there should be no savegame incompatibility or related problems (if there are, that is a bug; please report it). Hey, I do take care in the code I write.

As for loading a savegame with an airport closed in vanilla trunk, the bit should be ignored, so, yes, the airport should behave as usual. (On the other hand, the bit should be left alone, so if resaved with trunk and reloaded with the patch, the airport should be closed again.)

By the way, you're doing an awesome work with you patchpack, Terkhen. Keep it up!

[Terkhen]

I will try to, cirdan. Thank you

After careful checking of all the patches, this is what i got:

Autoload face: No incompatibilities.

Chunnels: The patch itself makes no changes to savegame structure (or any other structure). Savegames with chunnels can be loaded with vanilla trunk. The chunnels stay and work perfectly, but of course you can't build more chunnels. No incompatibilities.

Close airports: It has the exact behaviour that cirdan described. A closed airport will revert to normal behaviour when loaded by vanilla trunk, but will be closed again if loaded by a closed airports binary. Since the patch uses a bit in airport_flags, the behaviour will be the same until some new feature that needs new bits there is implemented in trunk.

Diagonal level and clear: This patch only changes how the terraform commands are done, not their results. This patch does not affect savegame compatibility at all.

Conditional order "skip with certain probability": As already stated, the patch bumps the savegame version correctly, therefore any savegame made with this patch will not be compatible with trunk.

Enhanced minimap: Only GUI changes.

Extra-large maps: No changes in savegame format. Obviously maps bigger than 2048 x 2048 will fail to load in vanilla trunk. Otherwise, savegames made with the patch are fully compatible with trunk.

Improved build station GUI: Only GUI changes and CFG changes.

More diesel smoke: Only visual changes.

More map settings: No changes in savegame format (the map is generated differently, but it is saved in the same way).

NewGRF GUI: Only GUI changes.

Query land shortcut: Only keyboard changes.

Shade windows: Only GUI and CFG changes.

Signals in tunnels and on bridges: Games saved with this patch can be loaded "without problems" in vanilla trunk. Without problems means that simply all signals placed on bridges and in tunnels will dissapear instantly, which will probably cause train crashes if there is two trains at the same bridge / tunnel. The signals will reappear if you load the game after saving it with vanilla trunk. Savegames will be compatible with trunk until the two extra bits that the patch uses are needed for some feature in trunk. Not that this compatibility is useful at all: doing a simple test I managed to crash 6 trains in less than a blink. If this was done with a real network the results would be closer to a disasters film than a transport simulation game.

Town sign shows ratings: Only GUI changes.


In conclusion, if I remove the conditional order patch, it seems that TPPP-trunk savegame compatibility would have only a minor issue with closed airports becoming open and a more problematic issue with signals in tunnels and on bridges dissapearing. I'm probably wrong at something, though

[HackaLittleBit]

I managed to crash 6 trains in less than a blink.

in the early stages of development I did it with 500 trains , and I would like to compliment the developpers for such a stable game
It takes about 3 seconds but after that the game simply continues.
To make the game "vanilla trunk" again you (carefull) have to take away all signals on tunnel/bridge.

Regards HackaLittleBit

[hempa]

First, I'd like to thank you for a great patch pack. Most people (read all but a few) don't have the skill or patience to put together a patch pack like this and then maintain it. I like the fact that you have strict rules on what goes or not into your pack.

Been playing a bit with v03 now, and I'll pick up v04 today to see how it works. The addition of diagonal clear/level is quite interesting. I must say that I will miss the condition with probability when you remove it in v05, but if it breaks save game compatibility.. Removing it will be for the better.

Keep it up, you're doing a great job!

[Terkhen]

Version r16755-v05 of TPPP released. See this post for changes and download. The most important change is that v05 savegames are compatible with trunk, besides the savegame issues I comment in that post. This means that you wont be able to use your savegames from previous TPPP versions with TPPP V05. I have also added a few guidelines for reporting bugs and problems.

hempa: Thanks for your comments. I am going to miss the conditional order with probability too. I hope that having (almost complete) savegame compatibility with trunk will make up for the loss of that patch.

[2007Alain2007]

also with savegame compatibility the devs might like this more as well as long as all the bugs in the patchs are worked out

also patchs that have no change in save game file are theres all going to be added to this set

[Terkhen]

2007alain2007: I don't see why this decision should change the opinions of the developers on patch packs: TPPP is still a group of unfinished patches compiled together that is bug prone and makes bugs harder to find and correct. Since I don't want TPPP to interfere with development, I added some notes about bugs in TPPP: I prefer to check myself if the bug is caused by TPPP (in that case, the bug is my problem) or by some of their components (in that case, I would report the bug to the patch developer).

Also, "never include patches that alter the savegame compatibility" is obviously not the same as "include all patches that don't alter savegame compatibility". I told you this by private message some time ago: I am not going to work in a patch pack that has a huge number of incompatible patches that I don't need. You are free to pick up the TPPP diff file (or any or all of the patches at the development page) and use them to make your own custom build with your own rules about inclusion.

[Wasila]

This has probably been suggested before, but this would be the perfect patchpack with cargodist (what I'm really looking for is the extra-large-maps with cargodist, but closed airports is a nice extra).

[hempa]

Terkhen: Going to get the new patch today to see how much I really use the conditionals I'm sure i can do without, no problem. Keep it up and awesome work!

Wasila: I believe Terkhen wrote in this thread that he wouldn't incorporate any bigger patches (like cargodist). Feel free to try and apply the patch to the cargodist tree though


edit:

Big patches that add a lot of features (like cargodist, more height levels, etc) will never be included in TPPP.

That's from the first post.

[Wasila]

Thanks anyway. I've already tried patching cargodist, but it didn't work.

[Terkhen]

Wasila: Your definition of perfect seems to be "having a lot of features". If that was the only point to consider then yes, TPPP would be perfect if it had cargodist. And more height levels, timetable based separation, Improved breakdowns...

Now look at it from my point of view: Cargo distribution is not a simple patch that alters a single piece of OpenTTD behaviour. It completely remakes some key points of OpenTTD. Even if I managed to merge it with the 14 patches that are included in TPPP right now (which I doubt is even possible), do you really think that Cargo Distribution expects these patches on its way?. Some of them will conflict with cargodist (even if the mess compiles) and you will have a bugged game that does a lot of strange things. And as I already said in the introduction, I am not going to include patches that are always in need of testing to a patch pack. A lot of users would prefer the patch pack (even if the big patch is bugged and messed up), lowering a lot the quality of the tests and forcing the developer to waste his time.

About a build including only cargo distribution and extra-large maps: It should be easy, as cargo distribution probably does not touch the code that extra-large maps requires. Unless I am mistaken, it is only a matter of fixing rejects manually and it should work. Finding someone to do it for you will be harder, though.

hempa: Ironically I had no time to play with TPPP v5 besides my usual new version testing. But I expect to miss the random conditional orders specially with road vehicles, as I used them to balance traffic in long roads and near multiple drive-through stations.

[Wasila]

By perfect, I did mean those two. And I meant perfect for me . I understand what you mean, and I couldn't do any better so I'm not going to keep asking. Now I've just to find some one to fix those rejects...