Chaining sims with decisions and choices in the timetable

With regards to chaining: For the kinds of major decisions that need to be taken immediately at sim startup that certainly sounds like a reasonable idea, plus it can be useful in single play, too.

For decisions that happen later on at runtime, it'd probably still be preferable if the decision state could somehow be shared across chained simulations, so you don't have to manually specify each and every "alternative train"-type decision across the chain already right at the initial sim startup.

To prevent a decision from being taken simultaneously in multiple chained sims, there'd have to be either some sort of collision detection, or alternatively, it might perhaps make more sense to have a designated master sim responsible for taking all shared decisions across the chain, e.g. by reusing the master-slave relationship that already exists for the purpose of time synchronisation.

So whenever a decision needs to be taken, the sim will ask its designated master neighbour, which in turn might have to forward that request to its own designated master and so on until you reach the master sim at the end of the chain, which will then take the decision and broadcast the result back down the chain.

So building on the thoughts listed. Maybe in the decisions box for each decision, there's a tick box for "user definable" which will then trigger the decision to be listed in the startup screen and the user can ignore it (default) or pick the decision in the same way as any other startup option.

jc92 in post 138703 said:

So building on the thoughts listed. Maybe in the decisions box for each decision, there's a tick box for "user definable" which will then trigger the decision to be listed in the startup screen and the user can ignore it (default) or pick the decision in the same way as any other startup option.

It's not as simple as that. Unless you want the user to be able to select all seven days of a DOTW-style timetable... Hence my comment about grouping and multi-select.

Jan in post 138702 said:

For decisions that happen later on at runtime, it'd probably still be preferable if the decision state could somehow be shared across chained simulations, so you don't have to manually specify each and every "alternative train"-type decision across the chain already right at the initial sim startup.

To prevent a decision from being taken simultaneously in multiple chained sims, there'd have to be either some sort of collision detection, or alternatively, it might perhaps make more sense to have a designated master sim responsible for taking all shared decisions across the chain, e.g. by reusing the master-slave relationship that already exists for the purpose of time synchronisation.

So whenever a decision needs to be taken, the sim will ask its designated master neighbour, which in turn might have to forward that request to its own designated master and so on until you reach the master sim at the end of the chain, which will then take the decision and broadcast the result back down the chain.

While that could be done, I'm not sure that's going to be sensible in all cases. It relies on every sim in the entire chain either knowing about the specific decision name, or not caring about it and passing it on. The problem is when the identity is neither of those: it's ambiguous, or otherwise means something different in one or more sims compared to other sims.

You don't need seed groups; you can just go back to how it used to be done before decisions came along. The core code was not written to specifically ensure that this method worked so Geoff and Clive always viewed it as an at your own risk strategy. You have a group of seed trains all entering at start time and all with a TD/UID which puts them at the front of the queue alphabetically (so typically 0A00/$0A00MON, 0A00/$0A00TUE etc). You then set up MUTEX rules for all five and add weights to the trains so they all have an equal chance. The core code will read the TT alphanumerically and come to 0A00/$0A00FRI first. As you want that to have a 1 in 5 chance of running you set the entry percentage as 20%. If that does not enter because of the MUTEX rules, the core code next reads 0A00/$0A00MON. You want that to have an equal chance of running as any of the other three remaining days so you set the entry percentage as 25%. It is then rinse and repeat with 0A00/$0A00THU set at 33%, 0A00/$0A00TUE as 50% and 0A00/$0A00WED with the entry set to 100% or left unchecked.

How hard would it be to make it possible to make 1 timetable that can be read by all sims? I mean you make one file that holds the TT for an certain region. That way you eliminate the trouble of having different decision names. This also makes it easier to have the same train types and TD/uid.
The SIM only 'reads' the locations it has in the area, but it can 'read' all already used TD/uid, train types and decisions. It could even pick up the entry location and time of all trains to pre-fill the TT for the area.

postal in post 138651 said:

You don't need seed groups; you can just go back to how it used to be done before decisions came along. The core code was not written to specifically ensure that this method worked so Geoff and Clive always viewed it as an at your own risk strategy. You have a group of seed trains all entering at start time and all with a TD/UID which puts them at the front of the queue alphabetically (so typically 0A00/$0A00MON, 0A00/$0A00TUE etc). You then set up MUTEX rules for all five and add weights to the trains so they all have an equal chance. The core code will read the TT alphanumerically and come to 0A00/$0A00FRI first. As you want that to have a 1 in 5 chance of running you set the entry percentage as 20%. If that does not enter because of the MUTEX rules, the core code next reads 0A00/$0A00MON. You want that to have an equal chance of running as any of the other three remaining days so you set the entry percentage as 25%. It is then rinse and repeat with 0A00/$0A00THU set at 33%, 0A00/$0A00TUE as 50% and 0A00/$0A00WED with the entry set to 100% or left unchecked.

Hey, I added a better way (XOR, I think it's called; can't be bothered to look) where you just say "only one of $0A00* runs, chosen at random").