Karn wrote:
Is this orders concept missing any feature that somebody would like to see? Once it's done, it's gonna be set in stone for this patch. Also something from above might change during implementation due to technical limits and some part being too hc.
Disclaimer: I saw this thread some time ago, regarded the idea / patch as quite interesting, but didn´t have time to dive into it / write to this thread. But I thought a bit about orders, independent from your post. So what I write is more an idea from outside than a direct comment to your concept.
My starting point is: I play my games in a style where I specify in a quite exact manner what a train does when, i.e. I use timetables (my self written patch). Even with the added information ("not only I specify that the train should visit station X, I also specify when it is supposed to do so), I consider keeping a non-trivial train network running a quite complex task (e.g., avoid deadlocks, avoid trains block other trains for a long time).
Now, I consider shunting a really interesting feature, but in a non-trivial network, my feeling is that avoiding the situation that while shunting, different trains block each other in a unwanted way is a quite complex task, much more complex than with standard OpenTTD orders. For example, if the locomotive fetches the first three wagons of a train, moves them to a track outside the station, and couples them to a waiting train on another track, you need the following prerequesites for this:
- The track outside the station needs to be empty
- The second train must already have arrived
- The second train must have found an empty track
If for example, the locomotive is expected to move to the back of the train, you will have a similar set of prerequesites.
And my feeling is that in a non-trivial network, where things sometimes go wrong (e.g. second train got delayed, etc.), keeping things running in the light of such shunting orders (and the above examples are just the most simple ones) is quite difficult, i.e. the danger that you often have to manually fix things is quite high in my feeling. Especially, because OpenTTD stations are clearly limited with respect to the number of tracks - where in reality, you have shunting areas with a lot of parallel tracks, in OpenTTD, you are really restricted here.
So how can the order concept support you here?
An idea that came to my mind is, could it be senseful to move the concept of detailed orders from the vehicles to the stations? What I mean is something like the following:
- A station can have a set of "advanced" orders (whatever this means in detail)
- For this set of advanced orders, you define a set of entry points (tiles), where for incoming vehicles is decided wether (one of) the advanced orders is applicable.
- The advanced orders can have things like "if train is in group X, it should enter track Y if free, otherwise track Z if free, otherwise it should stay outside"
- With respect to shunting, these advanced orders can trigger a series of shunting operations for a train they take control of.
- Shunting orders also can have preconditions ("wait with doing this until condition X is met"), conditions ("if train X is here, couple the three wagons to it, otherwise move them to track Y and leave them there)
- The default orders would need less complexity (they specify only to go to that station, not what to do there in detail)
- Once a set of advanced orders is completed, it gives control back to a default order.
- If during shunting, a new train is arranged, the last advanced order might specify "assign order list X to that train, and start with the first order"
- If an entry point (see above) doesn´t take control over a train, just the usual default order is processed, no need to deal with the complexity described here
So, to conclude, when a train passes an entry tile, it is decided wether it should be subject to advanced orders. If yes, a series of advanced orders is processed, and after they give control back, the default orders will proceed.
Why I came to that idea?
- As described above, I felt that once you play with more complex shunting operations, you might need finer control about how things work in detail (e.g., which track to use?)
- But how can you keep the overview over everything in a particular station happens? Distributing shunting operations that might interfere with each other over several order lists doesn´t seem that clearly represented.
- Maybe mimic the real world concept of a traffic controller, i.e. an entity that controls everything happening in a particular region?
- And of course don´t invent anything someone who isn´t interested in such a complexity is forced to use.
As I have said, these are some more advanced ideas that came to my mind in the last days. I really don´t want to disturb your patch (and I know that it would be a lot of work to make that work), but at least I wanted to add some aspects ("how might this work in more complex networks with non-trivial shunting operations?") to the discussion.