News:

SimuTranslator
Make Simutrans speak your language.

Fixed timed schedule option

Started by gfurst, February 13, 2014, 08:52:19 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gfurst

Hey folks, I would like to propose the addition to the schedule's options, to be able to set a fixed departure time.
Very much like "convoy spacing" in experimental, though this could be implemented in a different way.
This is mainly for passenger lines to avoid convoys of getting close to each other and thus reducing its efficiency.
We can try and do it manually and even set a max_wait_time, but convoys will eventually go out of sync and this also results in lot of micromanagement.

In simutrans-experimental this is done by setting available slots that a convoy can leave per month, it will apply to a stop when the minimum load is more than 0.
Again, this could be implemented differently in standard, by setting a manual departure time,  day of the month, but the slots per month are pretty good as well.

Remembering that for this to be useful, the user would need some sort way to figuring the travel time it would normally take to complete a schedule.
Such as a way to figuring proper times for schedule to leave at the same time while minimizing time wasted at stop: average trip time divided by number of convoys in line.

This could also fit or better the new "departure times" presented in the stop's window.

Thanks for reading and please share your views on this.

Ters

The main problem is that this will block up stops, if I understood this correctly. Having vehicles waiting at a stop is the last thing I want in areas where vehicles bunching up tends to be a problem.

(One cause of the problem is that fully loaded buses move noticably slower than unloaded buses, which isn't really the case in real life. Even if it takes a few more minutes to load/unload many passenger than few, that becomes insignificant compared to the total time of a bus route. The other cause is congestion, which would cause significant delays in real life as well, although not so many buses from the same route bunch up.)

gfurst

Quote from: Ters on February 13, 2014, 09:15:17 PM
The main problem is that this will block up stops, if I understood this correctly. Having vehicles waiting at a stop is the last thing I want in areas where vehicles bunching up tends to be a problem.
Well, not really, as you will tend to use the fixed departure time only on end stations, any station in between the schedule the convoy would just pass by.
The stop blocking is prevented with the proper use of the choose signal. (which by the way, doesn't work very well on roads)
For example, a line I had in a game.
A <-> B <-> C <-> D
A and D are final and connecting stops, thus I set the departure time on them, If I have two convoys they will be both departing at the same time, one from A and the other from D.
I current game, the convoy will tend to get closer to another, due to traffic, loading, etc. As such both convoys could be close to station A while D has a long time without the convoy attending there.
So this reduces efficiency greatly if in station A there's enough load for 1 but not 2 convoys, the first convoy could load fully but the second would be empty, meanwhile at the D station passengers are waiting.

kierongreen

Setting schedules in this way is also considerable micromanagement. Everytime you add additional convois to a route you have to change it, calculating what it should be anticipating what demand will be. When you have a complicated network with hundreds of routes all interacting with each other then trying to enforce fixed timings without proper planning is a recipe for disaster. That proper planning is a considerable exercise in itself - think how many people are employed to create train timetables in real life.

Ters

Quote from: gfurst on February 13, 2014, 09:38:55 PM
Well, not really, as you will tend to use the fixed departure time only on end stations, any station in between the schedule the convoy would just pass by.
The stop blocking is prevented with the proper use of the choose signal. (which by the way, doesn't work very well on roads)
For example, a line I had in a game.
A <-> B <-> C <-> D
A and D are final and connecting stops, thus I set the departure time on them, If I have two convoys they will be both departing at the same time, one from A and the other from D.
I current game, the convoy will tend to get closer to another, due to traffic, loading, etc. As such both convoys could be close to station A while D has a long time without the convoy attending there.
So this reduces efficiency greatly if in station A there's enough load for 1 but not 2 convoys, the first convoy could load fully but the second would be empty, meanwhile at the D station passengers are waiting.

You seem to be thinking of trains. I never have significant problems with trains bunching up. Train stations also have enough capacity to compensate. Correct convoy spacing is way more important for me for busses, and for buses I usually don't have space for stops in parallel.

kierongreen

It should also be noted that buses bunching is a real life problem...

Ters

Quote from: kierongreen on February 14, 2014, 10:02:12 AM
It should also be noted that buses bunching is a real life problem...
Not all the buses on a line, not unless there has been some serious incident.

Vladki

Quote from: kierongreen on February 14, 2014, 10:02:12 AM
It should also be noted that buses bunching is a real life problem...
What I frequently see (in real life on busy and long bus lines) is that if one bus is delayed for whatever reason, it tends to get delayed more and more, because more people accumulate on the stops. And then the second bus runs almost empty and before schedule. And then the trhird has again too many people on the stops (those who didnt catch the second bus, because it ran a bit earlier) and gets delayed, and so on...

gfurst

Quote from: Ters on February 14, 2014, 06:08:43 AM
You seem to be thinking of trains. I never have significant problems with trains bunching up. Train stations also have enough capacity to compensate. Correct convoy spacing is way more important for me for busses, and for buses I usually don't have space for stops in parallel.
Well no, I had the actual example from from two bus lines, where the first end point was a big station, and the last was a big city stop, and in between some other important stops.
One can go and make proper road terminals with choose signs but this can get rather complicated in small spaces.
Now, sequential stops are always an issue to me, for example two stops side by side equals 4 loading slots( 2 on each side of the road),  but if one convoy is in the first, no other convoy behind can get to the other slots. Because of this I think there is an issue with the choose signals not working properly, and they also don't seem to work on intersections.
The stop clogging up is a present issue that also results if you try to slow convoys down by setting a max wait time.

On the micromanagement part for scheduling, its not really true. A simple calculation can be made by knowing the average time a convoy takes to reach the other end, or entire route, and dividing that number by the number of convoys.
For example if a convoy takes 2 days to complete a route, you would be safe to have a departing time of 1 day( each day 1 convoy leaves from the stop), So you would have a convoy departing while the other is somewhere around the middle of the route.
This last part is thanks to simutrans experimental, they already implemented it, and it works.

Ters

Quote from: gfurst on February 14, 2014, 05:46:00 PM
Now, sequential stops are always an issue to me, for example two stops side by side equals 4 loading slots( 2 on each side of the road),  but if one convoy is in the first, no other convoy behind can get to the other slots. Because of this I think there is an issue with the choose signals not working properly, and they also don't seem to work on intersections.
Choose signs, and also choose signals, only work for stops in parallel. If for no other reason, then because the vehicles can't get to the second stop until the first one is clear. I only use them at freight terminals for vehicles that wait for a full load.

Quote from: gfurst on February 14, 2014, 05:46:00 PM
The stop clogging up is a present issue that also results if you try to slow convoys down by setting a max wait time.
Which is why waiting for full load, either with or without a max wait time, is only for dead-end stops on a siding. Only an ability for vehicles to bypass each other at stops can solve this, but the graphics don't really have space for it. Ships do cheat at this point, as do airplanes in flight, but do we really want more of such ugly overlapping?

Quote from: gfurst on February 14, 2014, 05:46:00 PM
On the micromanagement part for scheduling, its not really true. A simple calculation can be made by knowing the average time a convoy takes to reach the other end, or entire route, and dividing that number by the number of convoys.
I have no idea how long a convoy takes to complete a round. Nor do I have time to figure it out. Does the game know?

kierongreen

QuoteOn the micromanagement part for scheduling, its not really true. A simple calculation can be made by knowing the average time a convoy takes to reach the other end, or entire route, and dividing that number by the number of convoys.
That is micromanagement - that means you have to observe that route to see how long it takes for a vehicle to complete it. That could take a couple of real life minutes easily. Then consider that you are likely to have hundreds of bus routes in a developed game and I agree with Ters, I wouldn't have time to figure the time for a round trip.

gfurst

Quote from: kierongreen on February 14, 2014, 07:53:11 PM
That is micromanagement - that means you have to observe that route to see how long it takes for a vehicle to complete it. That could take a couple of real life minutes easily. Then consider that you are likely to have hundreds of bus routes in a developed game and I agree with Ters, I wouldn't have time to figure the time for a round trip.
Again, no! the average trip time can be one of the major data necessary for the calculation, while it would be a lot of work to gather manually can easily be shown to the user on a per-convoy basis, this can either be:
- a simple record from the last time to took to make a complete schedule trip, the arrival time minus the last arrival time = average trip time.
- a simple calculation on path, convoy speed, path limits, etc at the time certain convoy schedule is updated, this to be recorded and unchanged.

Simutrans experimental does the first way, you just to let the schedule run once. This is not micromanagement as its been tested and proved.

kierongreen

It's not a question of the calculation being particularly challenging for a player. Micromanagement can be  a simple task, but one that has to be repeated many times and therefore becomes tedious.

hreintke

LS,

I took the average trip time implementation in experimental and adapted it for use in standard.
Still work in progress, included is not yet the save in sve so calculation restarts at load of a game.

See attached patch and convoi detail screen.

Comments are welcome.

Herman

gfurst

Quote from: hreintke on February 18, 2014, 11:06:29 AM
I took the average trip time implementation in experimental and adapted it for use in standard.
Still work in progress, included is not yet the save in sve so calculation restarts at load of a game.

Very good, this is an good practical example of how this could be applied. In this case you set a a timed schedule of 25 days or more.
Its certainly less management than trying to achieve this with max wait times.

hreintke, may I ask, what this actually is? The recorded last round trip time, or the estimated trip time based on path?

Combuijs

That is the recorded last round trip time (which is also in Experimental). So at least one convoi must have made the trip otherwise you can't show anything definite.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



hreintke

GFurst,

This is the average of the last 8 completed trips, where a trip is one full cycle of the convoi's schedule.
Beware, this implementation (as it is currently in experimental), doesn't take into account the difference between real travel time and unload/load (waiting) time.
I am looking in ways to show this split.

It is recorded on the convoi level, so each convoi on a schedule has it's own value.
Maybe showing the values also in a line overview provides a better overview there.
I am checking this too.

Herman

jamespetts

Quote from: hreintke on February 18, 2014, 02:05:23 PM
GFurst,

This is the average of the last 8 completed trips, where a trip is one full cycle of the convoi's schedule.
Beware, this implementation (as it is currently in experimental), doesn't take into account the difference between real travel time and unload/load (waiting) time.
I am looking in ways to show this split.

...
Herman

This might be useful in experimental, too.
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

Fixed schedules implemented in r9996