Self regulating orders (SRO)
When it comes to improving station rating, often the focus is on changing or extending the network and tuning the signaling to the needs or adding additional trains to single stations while the orders of trains are often overlooked and plain default orders like “GoTo A, full load”, “GoTo B, unload” are only given. This article will show a set of more complex orders which offer a solution to comparatively easy network management while it “only” requires a usual efficient two-way track layout all the same.
The current PublicServer game #151, is a multi-region map where different regions are connected by ICE trains (or rather Shinkansens in this case) but the local s-bahn is subject to individual design.
Setting:
The growing cities of my region needed a decent and high-capacity s-bahn in order to transfer all the people to the ICE terminal, but on the other hand I like to keep it simple and not create a new set of orders for each single station which needs separately looking after. Also I didn’t want to build a SRNW due to its higher space consumption and the little space available, having chosen one of the smallest islands around.
Self-regulating orders (SRO)
The solution is in using conditional orders to its full extend. In the example, my main s-bahn line connects four stations (each 8 tracks wide) on a LL_RR line to the ICE terminal (UET Uetani Shinkansen):
Convoluted as they may look, the principle of these orders are simple:
Go to the stations on the tracks in their order A,B,C,D. If the vehicle is more than 90% full, return to the ICE station and subsequently go straight back to the same station without stopping elsewhere. If the vehicle isn’t full, go to the next station in the sequence. Visiting the same station where the vehicle surpassed 90% load ratio (after dropping the cargo at the drop station), proved the most efficient orders with respect to obtained station rating and the total waiting PAX at the stations.
Ceavats:
A set of these orders may need some time till the trains reach an equilibrium. This might take longer the longer the list of visited stations is. The regulation will fail, if you add way too few vehicles. In this case, the vehicles will always visit the same station, some stations might not get the coverage they need.
Regulation might also fail, if way too many trains (or vehicles) are assigned to such set of orders. Nothing bad happens though, if no congestion occurs – but efficiency is then very low and cargo will go through all stations; the vehicle number might be limited automatically by giving an additional conditional order that the vehicle goes to a depot, if it is (nearly) empty when leaving the last station in the orders list.
Variations:
- This scheme can be varied, e.g. by issuing the orders such that the next station instead of the same is visited, after a vehicle returned to the drop station. The tests showed though, that the average station rating was considerably better when the same station is visited again.
- Another solution could be to always start with station A and only go to B, C etc, when the vehicle isn’t full. The disadvantage of this approach is that the further stations tend to get less vehicle coverage and thus a worse rating.
- Setting up such string of conditional orders involves many mouse clicks and is really tiresome. In order to ease the pain on the mouse, it’s certainly possible to lower the amount of conditional orders and only do a jump after each 2nd station or so. The experience in this game showed, though, that this was of limited value and results comparatively poor.
Giving the orders
Orders are always added before the highlighted line in the orders window. For a start it’s advisable to give simple goto orders to all stations which the vehicle should potentially visit, in the order they should be visited, if all stations only have very little cargo available.
- Then add an additional order to the drop station.
- Add a conditional jump, available in the drop down menu under “goto”:
The mouse cursor will change and you now need to click onto the order where you want to make the jump to, if the condition is true. - Done that you can actually set the condition:
Select the thing you want the jump depend on:
Select the value to compare the property to
And set how to compare the property to the entered value:
Summary
These orders are certainly nothing new and they’ve been used here and there. But they could be taken to the extreme (and then they’d probably not only be self-regulating orders, but also PITA orders), and the same order list could be given for all vehicles which transport a single cargo. It’s especially useful, of course, for pax networks where vehicles seldom have full load but the optimum amount of vehicles per station varies.
Acknowledgments
Thanks also to HansNL who kind of made me look into this in more detail and play with the different possibilities of these conditional orders – and write it up. Thanks also to all other players on this PSG #151 which make this particular game into one of my nicer games again. 🙂
It is a very nice article but somehow, I would prefer programmable signals/waypoints. As that would imo, fit the network construction, I don’t like to program single trains.
I may need to point out some things I did different compared to planetmaker.
In this article the train still goes to main station every time it left the last station of the order list. It may be that the last station is a very quiet station with not so much cargo. If the train deposited it’s cargo the station before, it’s still inefficient to enter the main station.
In my local network on PSG #151 I had trains running until they are full. There is a loop, but practically there is no start or end. Trains go to deposit station when they are full.
That’s the whole deal of this conditional order system. Only deposit when it’s worth doing so.
Seems that signaling is getting even more complex. As a very old ex-suspect I think later I should devote some time again re-learning the systems.