News:

SimuTranslator
Make Simutrans speak your language.

Discussion: Choose-Path-Signals and Predictability Philosophy

Started by Leartin, August 07, 2016, 12:08:00 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Leartin

One of the most common mistakes of new players is to expect Simutrans trains to be smart in there choice of route, and when they discover that trains are a bit stubborn, they misuse the choose-platform-signal to create even more of a mess. These players either become frustrated and start playing OTTD instead, or they seek answers, only to learn about the philosophy of predictability in Simutrans.

Quote from: Ters on June 08, 2016, 02:54:45 PM
Vehicles in Simutrans always finds the shortest* possible path, and sticks to it unless it discovers that the way has been physically removed or "permanently" blocked. The philosophy behind this is predictability. Trains won't suddenly go all the way around the world because all other paths were temporarily blocked, which could happen in for instance Transport Tycoon.

Quote from: prissi on September 02, 2009, 01:15:00 PM
Generally I do not like trains getting loss. The TTD routing annoyed me to a very large degree and I added the choose stuff very reluctantly. [...]
Adding the code is not the only thing. Usually it results in complains that the trains are not reading once mind. It got worse and worse. The more freedom a choose signal would introduce the more difficult its management would get.

Countrary to the Philosophy of Predictability is the idea of Choose-Path-Signals. How exactly they could work and be implemented was talked about before and could be talked about in the future, but for the sake of this discussion, they are any kind of signal which makes a train reconsider it's route based on currently reserved paths. Essentially a tool that enables overtake tracks and works in the way many new players expect Choose-Platform-Signals to work.

My question is: Can we have Choose-Path-Signals and still follow the Philosophy of Predictability?

Pretty much any time someone asked for this, it was the same TTD argument and was never really considered.
I understand that we don't want to have the same system as Transport Tycoon, where trains would just go anywhere and become confused.
However - in my opinion, a choose-path-signal can't be any less predictable than current choose-platform-signals. If you use them correctly, you know which choices the trains have, and all of them are acceptable. If you use them wrongly, unpredictable stuff might happen.
But unpredictable stuff and "lost" trains can have different reasons as well. For example, you might have placed a signal facing the wrong direction, rendering the whole track useless and force trains to move far around it. Or you forgot a single tile of overhead wire. It's mistakes that cause problems, not features.

On the other hand, choose signals would certainly add to the gameplay. Mostly seen by how often people ask for them or wonder why they are not in the game. And the best part: If it's a signal, any player can choose not to use it, and even any pakset creator can choose not to implement it. Choice is a nice thing. ;)


What do you think?

jamespetts

Generally, the Simutrans way of handling this, I think, is the better way: if I understand you correctly, the Open TTD system would be unmanageable. However, there is something to be said for choose signals working other than at stations, to choose a free path (if, and only if, the normal path is blocked) between that choose signal and the next either (1) platform; or (2) end of choose sign.

Simutrans-Experimental has recently implemented this feature in the devel-new branch.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Perhaps the best way to stop people setting up randomness that won't work, is to rename the choose signal to "platform choice signal" or "platform selection signal". Choose signals and pre-signals both have hardly meaningful names and non-intuitive behavior.

While allowing some adaptive routing of trains can be a powerful tool for experienced players, I suspect that most players asking for it don't grasp the complexities involved.

Quote from: jamespetts on August 07, 2016, 02:13:18 PM
to choose a free path (if, and only if, the normal path is blocked) between that choose signal and the next either (1) platform; or (2) end of choose sign.

What stops that from spanning the entire rail network? Even if the effect is limited, I still suspect that this is a canon that is eager to get aimed at the player's own foot. Not that signals in general won't hesitate to let the player shoot himself in the foot. Nor is routing in Simutrans 100% static even without signals.

jamespetts

Quote from: Ters on August 07, 2016, 03:42:16 PM
What stops that from spanning the entire rail network?

The MAX_CHOOSE_BLOCK_TILES preprocessor definition should do this, should it not? I cannot recall whether this comes from Standard or was added for Experimental years ago, but its effect is to set a maximum number of tiles over which the choose-signal specific path-finder will attempt to find an alternative path.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

MAX_CHOOSE_BLOCK_TILES is not set by default. What would a reasonable value be? Especially considering different pak sets might be tailored for different length trains.

River

I think it also depends on the map size at least. on bigger maps you might create more similar paths but they might be very long.

Ters

Longer path means that it takes longer to clean up the mess when a train chooses a bad route or chooses at a bad time. Even without choose signals in the mix, I always cross-connect my double tracked lines at semi-regular intervals so that I can reroute a badly routed train as fast as possible. Map size is not a factor in this.

jamespetts

You could take it out of being a preprocessor directive and make it into a simuconf.tab setting and let people experiment to find an optimal value.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

Still that would depend on map and network size. I added the tile count, when I had a dead end stations in three height levels where occassionally a train gót lost in the cellar and had to travel half the network to get back out from it. Also it may easiy happen that there is not end of choose signal on the other route when a reroute is triggered (for instance by removing a tile where that train is intended to go).

It sounds lame, but I found it almost impossible to get choose signals which are not prone to deadlocks and practically workable. (And they should be names platform choose signals; about half of the pak64 translation uses a tranlation like that, amount french, and japanese).

Ters

What exactly is the problem to solve? Is it passing the train in front of you that is waiting for something? Is it finding an alternative route between Berlin and Paris by going via Bern? Or some silver-bullet to solve every imagined, contrived or real problem? I find that the more complex the problem to solve is, the more fragile the solution will be. And giving people the solution they think they want or need, rather than solving the problem they have, can often prove fruitless.

jamespetts

The problem that this is intended to solve in Experimental is allowing, for example, a train that does not stop at a station to overtake a train that does stop at a station by using a slightly longer path through the station (a different platform, for example), or to allow a faster train to overtake a slower train on a quad-track section of line with cross-overs, or automate the use of freight loops. At present, if a train stops in a station and there is a slightly longer path through the station, a train that does not stop at the station will wait until the train that stops at the station has finished loading. If wait for load is set, this might be a long wait.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

Yes, the answer is simply to not have platforms on the trhough track or do not schedule train there for waiting. That is way easier than any other solution (but will obviously not work with the experimental backwards schedule feature, as this tackes off control of the platform).

Ters

The few times I have sent trains down a fast and a slow track, I've noticed that it takes the faster train a lot of time to overtake the slower if the faster train has to divert onto the fast track. If the slower train needs to divert (the routing penalty thing could be useful for this), it will slow down to be even lower speeds before it has cleared the common track. That can make it take even longer for the faster train to overtake, since it will be even more likely that the faster train had to stop before the split. I guess this can depend on how the various pak sets balance curve friction against engine power.