[Patch] Departure boards, 24h clock + binary 25 (r27452)

[hthhs]

Here's something I made earlier (well, about five minutes ago):

departureboardswallclock8b3-r21039.diff

(95.71 KiB) Downloaded 117 times

If a vehicle has been sent to stop in a depot, then until it reaches the depot all its departures will be shown as cancelled. Let me know what you think!

[Eddi]

i'm not really fond of this change... what if i have a conditional order with separate timetable that hits servicing? then all timetabling should stay intact.

[hthhs]

i'm not really fond of this change... what if i have a conditional order with separate timetable that hits servicing? then all timetabling should stay intact.

Sorry, I wasn't clear enough: a vehicle will only be shown as cancelled if it has been sent to stay in a depot and not resume its orders, so trains servicing will not be affected.

[supermop]

It might also be interesting to "cancel" trains that have been told to skip the station in question by the player.

Here is an idea that I have been mulling over for a few days, but that perhaps should be added via another patch, so as to improve the chances of this patch for trunk.

stationgrid.png (17.71 KiB) Viewed 3482 times

The idea would be to use the arival and departure times to generate a graphical representation of the congestion of the station. The Y axis shows time, the amount of which could be set by the player, and each train is presented as a box bounded by its arrival and departure. The number of column would be either set by the player, automatically set so as to prevent overlapping boxes, or ideally determined by number of tracks at the station (neither practical nor possible as far as I know).

Best,

[DeletedUser6]

Thank you very much! I didn't even expect to get the idea taken seriously! I may have a go at compiling later on today.

[Dwight_K._Schrute]

Nice new features

I just tried to translate your patch into German:

MacDonald & Co., 17. Jun 2342.png (22.56 KiB) Viewed 3405 times

Works fine but I think the column for the status is quite small. Is it possible for me to change this??

[hthhs]

It might also be interesting to "cancel" trains that have been told to skip the station in question by the player.

Currently when this happens the entry just disappears from the departure board. Skipping orders also moves the timetable forward by the travel and wait times of the order that was skipped, so I think it's better to just not show the departure at all, rather than seemingly randomly changing its scheduled time. That the timetable gets moved forward also means that it's impossible to tell whether a train has been told to skip an order. It's a nice idea though!

The idea would be to use the arival and departure times to generate a graphical representation of the congestion of the station. The Y axis shows time, the amount of which could be set by the player, and each train is presented as a box bounded by its arrival and departure. The number of column would be either set by the player, automatically set so as to prevent overlapping boxes, or ideally determined by number of tracks at the station (neither practical nor possible as far as I know).

I think this is beyond the scope of what I want to put in the patch. Sorry!

Works fine but I think the column for the status is quite small. Is it possible for me to change this??

Is the German equivalent of the "Expt: ##:##" text very short? Normally the width of the status column is based on the width of this as in the English version it's the widest text that can appear in the column.

[supermop]

The idea would be to use the arival and departure times to generate a graphical representation of the congestion of the station. The Y axis shows time, the amount of which could be set by the player, and each train is presented as a box bounded by its arrival and departure. The number of column would be either set by the player, automatically set so as to prevent overlapping boxes, or ideally determined by number of tracks at the station (neither practical nor possible as far as I know).

I think this is beyond the scope of what I want to put in the patch. Sorry!

Yeah, I think it should be outside of the scope of this patch. I was positing the idea for a potential patch that could be based on this patch at a later date, as a thought experiment primarily. I think it is best to keep this patch as clean and focused as possible.

[Eddi]

Works fine but I think the column for the status is quite small. Is it possible for me to change this??

Is the German equivalent of the "Expt: ##:##" text very short? Normally the width of the status column is based on the width of this as in the English version it's the widest text that can appear in the column.

firstly, rule of thumb: on average, german words are two letters longer than english words. secondly, why don't you use GUI elements that automatically scale on text width?

btw. german timetables tend to show the delay (e.g. "ca. 20 minutes later"), not the expected time

[Eddi]

Why don't you attatch the file here instead of uploading it somewhere else?

Likely because of forum limitation (4 MiB maximum size of attachment).

i was under the impression that got raised to more like 6MB.

[Dwight_K._Schrute]

Is the German equivalent of the "Expt: ##:##" text very short? Normally the width of the status column is based on the width of this as in the English version it's the widest text that can appear in the column.

Yes, I took "ca. ##:##". Ok.. no big thing.. So my trains have to be on time always

firstly, rule of thumb: on average, german words are two letters longer than english words. secondly, why don't you use GUI elements that automatically scale on text width?

If this patch hits trunk (and I hope it will!) there will be a lot more languages to deal with.. so there should be a more general approach to the width of the column

btw. german timetables tend to show the delay (e.g. "ca. 20 minutes later"), not the expected time

I think hthhs has been inspired by a Britsh station... so it's ok for me... it's hardly possible to make it fit for every railroad company

[ChillCore]

firstly, rule of thumb: on average, german words are two letters longer than english words. secondly, why don't you use GUI elements that automatically scale on text width?

If this patch hits trunk (and I hope it will!) there will be a lot more languages to deal with.. so there should be a more general approach to the width of the column

Yes, the approach Eddi mentioned.


In other news, I had a little test with the cancelled if sent to depot message.
Timetables are not affected so that is good.
However try this.:
1- Send a train to the depot for whatever reason, maybe you want to add some extra wagons or you have forgotten to refit properly. The gui shows cancelled and the entry dissapears from the departures board.
2- Keep the departures gui open (to see easier what happens two lines down).
3- Keep the train in the depot for a bit longer than two times its total trip travel time and release it again.
4- Delayed will be shown two times for arrivals and two times for departures as first entries until the train arrives at the station. I have not yet tried keeping my train for 5 times its travel time while only showing 10 entries but I think I know what will happen ...

More if I see someting else.

[hthhs]

why don't you use GUI elements that automatically scale on text width?

I didn't know of their existence when I first made the patch

If this patch hits trunk (and I hope it will!) there will be a lot more languages to deal with.. so there should be a more general approach to the width of the column

I've changed the patch so it now always uses the largest size of all possible statuses as the column width, which should solve the problem you're having. I forgot to say, thank you for attempting to translate it!

1- Send a train to the depot for whatever reason, maybe you want to add some extra wagons or you have forgotten to refit properly. The gui shows cancelled and the entry dissapears from the departures board.
2- Keep the departures gui open (to see easier what happens two lines down).
3- Keep the train in the depot for a bit longer than two times its total trip travel time and release it again.
4- Delayed will be shown two times for arrivals and two times for departures as first entries until the train arrives at the station. I have not yet tried keeping my train for 5 times its travel time while only showing 10 entries but I think I know what will happen ...

Oops! I'm not sure what the best thing to do about this is. The train will still be running on its original timetable that it had before going to the depot and will try to catch up to it, which explains the behaviour I think you're referring to. Perhaps a patch to change vehicle behaviour so that if its lateness is greater than its total timetable duration, then the former will be decreased by the latter?

departureboardswallclock8b4-r21054.diff

(96.64 KiB) Downloaded 103 times

[ChillCore]

Perhaps a patch to change vehicle behaviour so that if its lateness is greater than its total timetable duration, then the former will be decreased by the latter?

Would it not still be listed twice then and once incorrectly? (In case of being stopped for a little longer than twice its total travel time.)
Better would be to discard delayed orders when the vehicle is started again from the depot and just recalculate the next arrival/departure?

[hthhs]

Would it not still be listed twice then and once incorrectly? (In case of being stopped for a little longer than twice its total travel time.)
Better would be to discard delayed orders when the vehicle is started again from the depot and just recalculate the next arrival/departure?

In that case, then it would skip two rounds of the timetable. The code might look something like this:

Code: Select all

while (vehicle.lateness > vehicle.timetable.duration):
    vehicle.lateness -= vehicle.timetable.duration
    vehicle.timetable.start += vehicle.timetable.duration

Actually, with it looking as simple as that I'll try to code it this afternoon and see what happens.

[ChillCore]

The simpler the better but only do it when the vehicle is stopped.

Code: Select all

while ((vehicle.lateness > vehicle.timetable.duration) && 'vehicle is stopped') {
...
}

That way if it is listed twice it indicates a major problem in the network. (eg. Network deadlock, vehicles not being able to reach their destination anymore -> disaster destroyed rails un-noticed etc.)

[hthhs]

That way if it is listed twice it indicates a major problem in the network. (eg. Network deadlock, vehicles not being able to reach their destination anymore -> disaster destroyed rails un-noticed etc.)

The patch I've attached runs the code whenever the vehicle finishes an order, so any of the scenarios you describe will do as you suggest.

vehicletimetableskip1-r21054.diff

(670 Bytes) Downloaded 117 times

...I'm quite pleased that it came to less than a kilobyte.

[Dwight_K._Schrute]

I made this post in Chill's Patchpack-thread and he asked me to post it in yours:

I have a suggestion concerning the "Ticks per minute"-setting (wallclock-patch). Why is the setting not saved with the savegame like others? I have two games... one with 89 ticks per minute and one with 74 ticks per minute. So everytime I start one game I have to check the setting if it is correct. If not timetables can get disordered...

The patch I've attached runs the code whenever the vehicle finishes an order, so any of the scenarios you describe will do as you suggest.

I really like the idea of this patch.. I tested it and saw the following problems:

Imagine a vehicle starting every two hours.. 02:00, 04:00 and so on... If you cut the delay it may happen that it starts at 3:15... and you have to change it manually anyway.

If you have maybe two vehicles with shared orders and a total duration of the timetable of 2 hours.

vehicle 1 starts at: 01:00, 3:00, 5:00,...
vehicle 2 starts at: 02:00, 4:00, 6:00,...

So imagine one of them is too late so that your patch will cut the delay. So it is possible (even if my first point is handled correctly) that both vehicles start at 4:00... and have to change manually again...

[hthhs]

I have a suggestion concerning the "Ticks per minute"-setting (wallclock-patch). Why is the setting not saved with the savegame like others? I have two games... one with 89 ticks per minute and one with 74 ticks per minute. So everytime I start one game I have to check the setting if it is correct. If not timetables can get disordered...

Good point. However I'd like each user to be able to set their own value in a multiplayer game. There is a savegamewhere value detailed on the wiki that might achieve both our wishes - I'll investigate.

Imagine a vehicle starting every two hours.. 02:00, 04:00 and so on... If you cut the delay it may happen that it starts at 3:15... and you have to change it manually anyway.

I'm not sure what you mean by this. What delay do you mean?

If you have maybe two vehicles with shared orders and a total duration of the timetable of 2 hours.

vehicle 1 starts at: 01:00, 3:00, 5:00,...
vehicle 2 starts at: 02:00, 4:00, 6:00,...

So imagine one of them is too late so that your patch will cut the delay. So it is possible (even if my first point is handled correctly) that both vehicles start at 4:00... and have to change manually again...

I don't think this can happen - vehicle 1 will only ever be timetabled to start on odd hours, and vehicle 2 will only ever be timetabled to start on even hours. If one of them is ever more than 2 hours late, then its lateness will be reduced by 2 hours (so instead of being timetabled to start at X:00, it will effectively become timetabled to start at (X+2):00). The key thing about 2 hours being that it's the total duration of the vehicles' timetables - the patch won't reduce their latenesses any amount other than multiples of this.

[Dwight_K._Schrute]

Ok. Obviously I've mad a mistake in my first try. Just have tried it again and everything has worked perfectly... So I'm glad I was wrong