Train Schedules - Train goes on demand - Multiple conditional schedules

[PeteS]

I have a suggestion........

It would be nice if it was possible to have a train with multiple schedules that could be selectively triggered by station and/or factory stock levels. An "If this then..... option". To give an example of what I mean, if you had a livestock train that supplied a slaughterhouse from many farms, with each farm having its own station, with the train waiting at the slaughterhouse (not the farm) for a preset trigger level from the farm station which activated the required schedule to collect the goods from that farm. This would mean that instead of many trains waiting at low volume outlets to transport goods, I could have one train waiting for a call to collect. This could cut the number of trains collecting livestock from say, 10, to 1. And the train could run at 100% loading for the return leg of the journey.

I could see this working for all low volume products such as Wool, Livestock, Grain, Fish, etc.

This could mean that in order to satisfy demand that there are several trains used to supply one factory, and each factory/train group runs the same flexi-schedule but being sent to different collection points on demand.

Just like phoning a transport company and telling them the goods are ready to pick up and they come and collect. In real life you wouldn't have a $100,000 piece of plant standing still if you could use it somewhere else!

Thanks

Pete S.

[jayem]

I suspect that production is sufficiently consistent that the best solution would be to find the optimum number of trains and run them continuously (if it's <1 wait at the first station for a given time).

That said as a novice thinking about the programming it shouldn't be too hard to 'skip' a station based on a condition (I believe simutrans does it's route finding on the fly anyway).
Say 'if <X% goods for stop advance to stop after next stop',
      'if 'full and no goods for stop advance to stop after next stop.     
      'no goods at next stop advance to stop after next stop' (perhaps after telephones)

Which would give a bespoke effect (which could be useful for very low passenger travel in 17thC).  At a cost of a single check per station arrival.
You wouldn't want it for your main line express, but it should be pretty obvious.

With option 1 you could then use the schedule Slaughter -> Farm1 (-> Slaughter?) -> Farm2 (-> Slaughter?) which will avoid returning to the slaughter house empty handed or going to farms without picking anything up, but potentially pick up 1 from each farm.
With option 2 you could use the schedule Slaughter -> Farm1 (-> Farm2?) (-> Farm3?)...  for a similar but subtly different effect
With option3 you'd get the behaviour you wanted (but run the risk of full trains never delivering to an empty stop - the others you just get crowded stations)

You'd need some protection from looping right round, perhaps a wait for option 3, not sure what for option 1/2.

[kierongreen]

That said as a novice thinking about the programming it shouldn't be too hard to 'skip' a station based on a condition

You are correct this would not be too difficult to program technically. However variations of this idea have been suggested before and have always been denied on the basis that simutrans operates on the principle of fixed and predictable routes.

[Ters]

Players have a hard time getting "simple" things like choose singals and pre-signals right. How are they going to understand this?

Not that I haven't been wanting this feature at times, either for to tell trains carrying cargo both ways to stop and wait if both stations are empty, or to route trains to a holding area away from the busiest areas when there is no cargo to pick up.

[An_dz]

We need a good manual telling how it works, I still don't understand train signal even reading the tiki.
I understand choose signals, end choose, normal signals. But long block and pre signals are still a mystery for me.

[ӔO]

We need a good manual telling how it works, I still don't understand train signal even reading the tiki.
I understand choose signals, end choose, normal signals. But long block and pre signals are still a mystery for me.

probably best to have small demos saves or scenarios showing how it works. One slightly hard concept to understand, that's related to train signals, is the line capacity, or how many trains that are X tiles long will fit within the infrastructure and not jam.

[sdog]

signals are a topie that could be covered very well in a video tutorial. Anyone knows anyone doing those well?

[PeteS]

..... and have always been denied on the basis that simutrans operates on the principle of fixed and predictable routes.

Maybe something unpredictable would be nice 

[el_slapper]

Maybe something unpredictable would be nice 

it's already quite surprising. Even with regular, unchanging, balanced lines, the train can be full 40% one travel & 80% the next one. The simple fact that travellers choose random destinations instead of fixed ones is a huge randomizator. City growth also already alters significantly the traffic flow.

[Train-catcher]

The simple fact that travellers choose random destinations instead of fixed ones is a huge randomizator.

But the statistical characteristics of the passenger's flow is constant through a short time period. So, you can consider, that there is a defined amount of pax from A to B in the n-th year. And grows linearly every year (because of city growth).

The question is: it hard to calculate, how much static-sheduled trains I need for supplying one factory, given that these trains must be full-loaded and have no idle time. With the programmable shedules this question is not relevant. With the programmable shedules it will be easily to done full-loaded trains with no idle time. So I vote pro programmable routes!

E.g., OTTD has this feature, and you can invoke it, but you can ignore it.
OTTD's shedules are more like ASM code. You can write there something like this:

Code Select Expand


dest1;
dest2;
cond1==true? goto dest 4 //if cond1 true - go to dest4
dest3;
goto dest5; //unconditional jump
dest4;
dest5;
dest6;
...

And this code will means: "after reaching dest2, do test. If cond1 is true, then go to dest 4; else go to dest3. And after dest3 or dest4 go to dest 5 anyway."

In simutrans game it's would be nice to introduce the same feature.
To differ from OTTD, in simutrans game it can be done by setting a condition and then/else branches. And the example would be look like this:

Code Select Expand


dest1;
dest2;
if (cond1==true)
then
     dest3
else
    dest4
end
dest5
dest6
...

Of course, a player have not to write a code manualy. Must be given an opportunity in GUI for setting condition and filling branches.

[kierongreen]

Of course, a player have not to write a code manualy. Must be given an opportunity in GUI for setting condition and filling branches.

The idea of schedules (optionally) represented as a form of code is...interesting. I can't see this realistically being included in standard, however if I ever get to the end of my other projects then I might think about writing a patch for this. I'd envisage the GUI limited to simple options (i.e. same as now) with more advanced ones (multiple conditions, branching and so on) being restricted to code only. I really, really wouldn't expect anything to happen with this any time soon though!

[Ters]

My idea for something like this would be the ability to add hooks to entries in the schedule. These hooks would be called as a replacement for the checks Simutrans already perform for minimum load and maximum wait time. But in addition to saying whether the train should move on or keep waiting for more goods, these hooks would be able to tell which entry in the schedule should become the next target.

The advantages are:

   
• The schedule window will look mostly the same. Just add a button for opening a windows for editing hooks, and a way for each entry to indicate that a hook has been installed.
• The schedule itself isn't code, so no problems presenting it to non-programmers. I also expect less problems with compatibility for the schedule itself because of this.
• The hooks might use the same underlying scripting functionality as the scripted scenarios. Very complex behaviour is possible.

The disadvantages are:

   
• With the hooks not initially visible, it becomes less clear what the schedule actually works.
• Very complex behaviour is possible.