Topic: Suggestion to make convoy spacing more simple

[manolollr]

I'm using convoy spacing with buses. It's difficult. It works most of the time, but sometimes a bus arrives only one minute late, ¡¡only one minute!!, and it must wait the whole slot time, causing an important delay in the whole line. This topic is commented in this thread:

https://forum.simutrans.com/index.php/topic,17148.msg163289.html#msg163289

You can reduce the probability of a bus arriving late by setting the frecuency a little higher, reducing a few buses per month. But with this you are causing the buses waiting unnecesarily, only to prevent an occasional bus arriving late.

I have a suggestion to make the convoy spacing more simple: instead of the current setting indicating convoys per month, I suggest to put only a setting indicating how many minutes you want your convoys separated, normally the calculated frecuency (average trip time / number of convoys).

I think it can be done with a variable in the bus/train stop, to store the time at which the last convoy leave the stop. For example, a convoy leaves the stop at time 46:35. The separation is configured at 15 minutes. Then arrives a convoy at 1:00:00, it must wait 1 minute and 35 seconds until 1:01:35.

With this system, if a convoy arrives late it doesn't wait, it departs inmediately. But it stores the departure time in the variable I've suggested, causing a delay to the rest of the line. For example, if a bus arrives 1 minute late, it causes 1 minute delay to the rest of the line, but only one minute and not 15 minutes.

I think my suggestion can work and it is more simple and more intuitive. With all my respect to the coding of the current spacing system, but in computer engineering, and in engineering in general, more simple is better.

Thank you!!

[freddyhayward]

This suggestion would completely break all overlapping schedules and all situations where the precision of the current system is needed (e.g. single-track lines). I agree with you in principle about simplicity and have often called for features and code to be simplified (see my post history), but the line scheduling system is, in my opinion, the most valuable feature in Simutrans-Extended and is what separates it from similar games. That thread also suggests a lateness tolerance feature to be specified in the schedule editor that would improve the system.

[Freahk]

This has been noted many times already.
The issue with simple minimum spacings is, that it will be impossible to handle dependencies in between lines when schedules do not relate to a fixed point in time.

On the other hand, on some lines, this might not be required and a minimum space is something you can do already anyways using good old simutrans standard "max load" and "Maximum wait time", though assuming you do not schedule at a station where your vehicles will ever be full.

Might be the "Maximum wait time" will need a little overhaul, allowing the same fine steps as the "Wait for time" feature does, not only for consistency reasons.

Anyways, there is another approach that allows for delays, but does also relate to fixed points in time.
We know when the schedule slots are.
If we know when the last vehicle departed, we can just check if the previous schedule slot was used already or not (departure at or after the time of the previous schedule slot)
If it was used, we will wait for the next schedule. If not, we assume to be late and depart immediately.
To maintain dependencies to other lines, we can set a maximum delay at which vehicles are still allowed to depart. If that time is exeeded, it will have to wait for the next slot.

[manolollr]

Thank you for your responses.

[jamespetts]

Making the scheduling system easier to use without losing functionality or breaking existing saved games where players have already set elaborate schedules using the existing systems would be desirable, but require a very large amount of coding work. Given that there are balance critical features not yet completed, this cannot be a priority for my time until they are.

If anybody else would like to work on something that would fulfil the above criteria, then this would be welcome (although even more welcome would be assistance with balance critical features).