The following patch does not change external behavior but re-organizes how order lists are handled internally, to make the code easier to maintain and to make advanced features tied to order lists and timetables easier to implement (that was the real reason for me to do it, as you might imagine
)So, why should you try it out, then? To help me to test it! If you like my timetable patch and would like to see some of the features suggested there, testing this, will help me implementing these features earlier. As this patch has become larger than I thought, it needs some thorough testing before I dare to suggest it for trunk. Unfortunately, the patch has to bump the savegame version as the number of orders is no longer saved but calculated on load.
If you happen to understand C++ I would also be grateful for code reviews.
Please test it with -d misc=6 option and "review vehicle's orders" advanced setting turned on, since this enables a regular check if the order lists are consistent. Move orders, remove and insert them, clone, unclone and copy them between vehicles, change the timetables, try to load older and newer games and whatever you can imagine to break it.
If you find, OpenTTD behaves differently, triggers asserts or even segmentation faults, please report here together with a savegame and a description of the steps to reproduce the problem.
Some information on the motivation for this patch and what it does:
So far, the order lists are stored only as a linked list and this list is shared (i.e. the same list) for vehicles with shared orders. There is no place to store stuff which is not related to a single order or a single vehicle. Variables that are logically tied to the order list, such as the number of orders, or the first vehicle are replicated in all vehicles at the moment, resulting in the need to update all of them, when the number of orders or the first shared vehicle changes. The same is true for removing or inserting an order at the beginning of the list, as all vehicles point to the first order directly. (To be exact, to avoid that in the latter case, hard to understand operations involving swapping orders are used.)
As, I decided to implement some more advanced features for my timetable patch, which need some more variables tied to order lists, I decided to create a new class OrderList which now manages a single order list which is still a linked list as it was before, but now the vehicles don't point to the first order directly but to the OrderList and the OrderList points to the first order of the chain and provides methods to manage the chain.