[extension] "last convoy at" in fixed convoy times

[KneeOn]

Hello,


I am very happy to see that fixed departure times have found their way in to Simutrans!


While there may be some cosmetic changes or minor bugs (see https://forum.simutrans.com/index.php/topic,21294.0.html) it's a very useful feature.


My idea is as follows:
Currently one can set the frequency and the first departure. I do not know how to write programs however I assume it takes this first departure time and divides the ticks per month that remain between the first departure time and the end of the month.


I propose adding a "last departure at" time. If it isn't set, then it defaults to the end of the month.


Once a convoy has reached the destination with this set the following could happen:
Has the last departure time passed? If not, them the journey continues. This can include looping the schedule to the start or continuing its journey.
If it has passed then the convoy returns to its origin i.e. the first location in the schedule where "first departure at" is set.


As an added bonus, this could regulate services at the end of the month much as in real-life where services may not run their whole route for every journey, stopping short. Example with "show month = 1" (one month is displayed as a 24hr clock)




Station A 16 departures a month first at 0600 last at 2100
Station B EMPTY
Station C 16 departures a month last at 2200
Station D EMPTY
Station E 16 departures a month first at 0600 last at 2100
Station D EMPTY
Station C EMPTY
Station B EMPTY




Station A will send convoys between 0600-2100. That's 16 departures slots, in however many ticks 16 hours is i.e an hourly service. A convoy that wants to depart at 2130 now must wait until 0600 next month.
Station B is a normal calling point
Station C does not require regulating for the first convoys but any departure after 2200 will not run and return to Station A to wait
Station D is a normal calling point
Station E will send convoys between 0600 and 2100. If a convoy wants to leave after 2100, it returns fast and empty to Station A to wait for its first departure tirme
Station D, C, B are all empty because the regulation takes place on the outward journey. The return one, if the departure time condition has been met, runs as booked.


This has the added benefit of making stabling points and yards, station lay outs, choose signals, service management and line creation more important. It also has impacts on airports, harbours, road and tram transport.


I had posted an idea to extended about expanding the way depots are used however it gave very little gameplay return in its initial format. It was also focussed on rail transport. I believe this request would give cause to create meaningful depots.


Regardless of transport type, this is a scalable feature. If a player uses it, then they need infrastructure to match. It's a cost/profit risk/reward mechanic wholly dependant on players choices. Large airports, docks and rail yards/sidings can be used to manage a more complex and potentially profitable line by ensuring convoys run when they are truly required but with flexible minimum levels.


Players can opt to use this to make sure that a factory has time to bounce back without running empty convoys because there is no way to limit when a convoy runs once it is running other than to make it wait until n% filled and after nth of a month which risks interfering with other services and causing profit killing congestion.


Lastly, for those who play the game as a "railroad simulator" as per Prissis comments on the new feature, this would allow such players to play a true clock face game.


I'm keen to hear your thoughts!

[prissi]

I do not understand your idea. The convoi will depart exactly at the set time, even if it had been fully loaded earlier. If you set more slots, the time is the offset of the first departure, and hence the available range goes from 0...31day/number of departures per month.

When a convoi arrives at a stop, it will load until the darture times comes. Then there is an internal setting to continue loading if there are still pax waitings or depart anyway (the "UK" versus the "Japanese" loading mode).

The actual departure time greatly varies with the time setting, as there are month with three days and with the "real" day count. For the latter, the departures will be only as intended for month with 31 days and wrong for all others, since the internal counter uses the ticks per month. There is no setting with a month with 24h only.

[KneeOn]

Hi Prissi,


Setting "show month" to 1 makes the game clock appear 24hrs. The fact it doesn't change anything explains my bug report when using show month = 1.


I'll try to explain it better using the default setting:


Let's say you set a convoy to run on a daily basis between 10th and 20th of the month at 11:00.


You want this because you want to maximise profit on that route and letting the convoy run 1/3rd of the month let's goods build up 2/3rds of the month. A single full convoy is more profitable than 2 half full ones.


The issue with using the "wait until n% filled or n/1th of a month has passed" is that if your convoy uses a way with other services, congestion can build.


At the moment you could only make it run every day at 11:00 from the 10th, you can't specify that it is only to run 10th-20th by setting a date and time for no further departures to go.


My suggestion is to allow services to have a first departure time AND a last departure time each month. That way players have greater control over when in the month a convoy runs.


Is that any clearer?


Translating it in to a railroad simulator scenario, few services run 24 hours a day (certainly in the UK).


I might want to use show month = 1 so the game clock shows 1 day per month and run my service between 04:30 and 23:30 every hour but nothing between the start of the month (shown as 00:00) and 04:30 and after 23:30.

[prissi]

You can run a convoi from 10h to 20h, but would need an entry for each individual departure time.

The 24h display was indeed a bug, different routines used different bases. Should be fixed in the next nightly.

[KneeOn]

That's good news about the 24h bug, I've also read your response to the bug report - interesting things which I did not know.


I appreciate one could set individual routes for each convoy to only run once however this would become messy on the lines window. It also doesn't allow for multiple trips to run in a single day as easily.


By having a last departure at time, one could have 6 vehicles run to that one schedule with certainty no departures would happen after a set time - the alternative requires full "diagramming" of units and removing one unit would mean entire routes need rediagramming across multiple schedules.


In the example on my initial post, 8 vehicles (assuming the journey times allow this) could provide coverage from one line.


By setting individual lines means each convoy needs a diagram for two return journeys. Any changes in frequency or in times, additional or removing stops would need 8 times the work to change.


Lastly, the gameplay element - managing vehicle and stabling/depot points to hold vehicles creates a new challenge that would be optional and avoided if players don't want to use the "no departures after" feature.

[prissi]

Gameplaywise, pausing transport makes absolutely no sense, since the number of passengers or goods is independent from the ticks of months, i.e. constant at all times. Pausing 1/3 of a month will simply overcrowd all stops and will show every stop as overcrowded each month.

[KneeOn]

Is that not dependant on the pakset and what the output of factories and passenger levels are?

If that were the case why would there be any feature to have a "wait until full?"

Even if it were the case, one of the issues that rail systems have to manage is regulating services so that a slow running freight train doesn't hold up an express passenger.

If your entire system runs on a fixed departure time, either one runs services that aren't full by having regular fixed departures or one runs their freight services by waiting until n% full or every 1/nth of a month, which ever is first and lose any ability to regulate the services around the rest of the network.

This feature request gives players a chance to run services that are fuller without compromising the paths/slots they've designed for the rest of the network.


Edit:


Furthermore you have said that the fixed departure times are for "railroad simulator" players. This feature expands options for free playing or railroad simulating players.


Lastly, you said that one could run a series of schedules onna route to achieve the same outcome. While true that is labourious for a player when this feature could allow the same.otcome with an increased quality of life and is more adaptable with line changes.

[wlindley]

Because of the way the game chooses which passengers to load on a train, it certainly might be desirable to -- for example -- pause the "local" such that the "express" always arrives first, leaving open seats on the following "local" that will be filled at intermediate stops.  Or vice versa, depending on how you might have outfitted various services.  The same goes for goods: timed schedules can help override the default game mechanics to increase network utilization and efficiency (and profit). 

[prissi]

The scheduling feature does not care if a convoi is loaded or not. It will depart at the given time, not earlier.

If you use wait for loading, then then it will depart at full load. If you use scheduled time, then it will wait for the scheduled time. The generation of passengers and mail is totally independent from the pakset. It is only somewhat paused, when stops are overcrowded. The generation of goods depends of the just_in_time settings, and if the transported goods and the recieving storage are full or empty. Again, not really pakset dependent (apart from the size of the storage(s)).

If you want the overtake slow good trains, you have to force them on the sidigs and use priority signals. The scheduling feature ca be used to have more regular departures in certain lines, which can be asymetric and sometimes (like ferries occasionally) have either too much on one or the other end.

I though the main point of schedule is for the model railroader fraction, who rather wants to emulate real life timetables with Simutrans.

[KneeOn]

There are two ways the feature could be used.
1. Model railroad to run a timetable in show month =1 that is true to life in so much as between 2300(ish) and 0400(ish) there would be reduced or no services (as per the UK, other countries may vary)
2. To help in the regulation of services across a route - slow moving freight can be regulated to not run during passenger services and avoid knock on delays impacting on a timetable.
2.a to help in service recovery month to month (which I've just thought of). If the timetable is lost one month (i.e a late running service loses its monthly departure slot causing knock on delays), they can be recovered if services have a built in "last departure" option. Once this is hit services return to normal the following month because they'd go back to "first departure at" the following month and await their next month's services rather than running in perpetuity out of sync.

[prissi]

I see your point, but I am a little afraid that it would make the scheduling even more complex. Moreover, this could be achieved manually. If one really want to have schedule, then one could just repeat the schedule three time or so.

It is not completely denied, but not high on my priority list.

[KneeOn]

Prissi, thank you for considering it and for the critical analysis of the features use. I do believe in its usefulness and what it would bring but clearly having a critical look at this by others is a vital part of any feature to ensure it is robust and useful.

I cannot program - I left uni because I was so inept at it. Of course that means it will be at the mercy of others such as you. In the mean time if I have any further thoughts on how to implement the feature, its uses and other bits I will update this post