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

[sph]

That's a cool idea! I've added it to the patch on the first post of the thread with a few modifications:
- the icons are now orange, like most of the rest of the text
- the icons are shown between the time and destination, because this was easier to implement
- whether to show them or not can be set in advanced settings

Great! Though I'd prefer to keep the icon silver, that way it's a better visual separation between time and destination. All the orange makes the screen a bit too crowded and harder to interpret.

Arrivals boards would indeed be useful. I'll look into adding them this weekend if I have time.

Perhaps you could use something like {GREEN}{RIGHTARROW} for arrivals and {RED}{LEFTARROW} for departures in a mixed board. This might be handy for reducing the number of vehicles in a station (e.g. try to timetable trains to lower the odds that they "block" each other at the entrance/exit by leaving some time in between an arrival and a departure).

Let me know if I can help somewhere, although I'm not that familiar with the OpenTTD code yet.

[hthhs]

Great! Though I'd prefer to keep the icon silver, that way it's a better visual separation between time and destination. All the orange makes the screen a bit too crowded and harder to interpret.

I've added an option to display the icons in silver

I've also changed how orders with a wait time of zero are handled - now vehicles with such orders will still appear in a station's departure boards, provided the order to load from that particular station has a nonzero wait time.

With regard to showing arrivals as well as departures: it's trickier to do than I hoped it would be, as orders are stored as singly-linked lists, so I can't just traverse a vehicle's orders in reverse to find its origin.

[Logital82]

Just a simple question. I one ending station my train goes on a rail only for wait its time till his next service and not blocking the passenger staion in this time: For example:

A - B - C - B - A - X ( - A - B - ...

The X is a station only for operating not for passengers. In the second A order there is full unload and leave empte so that passenger will not stay in train going to X. In X there is order to not load. In the departureboars the X is the final destination of the train whats doesnt look so nice. Is there a possibility to solve this?

[hthhs]

Just a simple question. I one ending station my train goes on a rail only for wait its time till his next service and not blocking the passenger staion in this time: For example:

A - B - C - B - A - X ( - A - B - ...

The X is a station only for operating not for passengers. In the second A order there is full unload and leave empte so that passenger will not stay in train going to X. In X there is order to not load. In the departureboars the X is the final destination of the train whats doesnt look so nice. Is there a possibility to solve this?

That case should definitely be handled more sensibly. I've updated the patch so the train will be shown as terminating at A. Well done for spotting this!

[welshdragon]

Any Binary? (dare I ask for a Mac one? my Windows PC is in bits at my mum's )

[hthhs]

Any Binary? (dare I ask for a Mac one? my Windows PC is in bits at my mum's )

The windows binary in the first post has been updated. I can't compile a Mac one, sorry

[sph]

I've added an option to display the icons in silver

Thanks!

With regard to showing arrivals as well as departures: it's trickier to do than I hoped it would be, as orders are stored as singly-linked lists, so I can't just traverse a vehicle's orders in reverse to find its origin.

Isn't it sufficient to use the same approach from the departure board? i.e. Search for the last destination in the order list before the current station. This would mean you'd have to loop over all orders in that list but at least you don't have to go backwards

[hthhs]

Isn't it sufficient to use the same approach from the departure board? i.e. Search for the last destination in the order list before the current station. This would mean you'd have to loop over all orders in that list but at least you don't have to go backwards

Where a departure will terminate isn't necessarily where the arrival should be listed as coming from. Regardless, we can't just use a vehicle's destination as the origin for its next arrival, as it might operate in a triangle, e.g. terminating stations being CBG -> PBO -> SVG and then repeat. The train's destination would be PBO, but we want it to be shown as arriving from SVG.

I think one solution is to go forwards through the order list keeping track of potential origins, then when we know which order to use as the origin go back to it. I'll have a stab at doing this at some point.

[sph]

Where a departure will terminate isn't necessarily where the arrival should be listed as coming from. Regardless, we can't just use a vehicle's destination as the origin for its next arrival, as it might operate in a triangle, e.g. terminating stations being CBG -> PBO -> SVG and then repeat. The train's destination would be PBO, but we want it to be shown as arriving from SVG.

Assuming we'd start with CBG:
Destination = PBO
As we didn't meet the CBG order while walking over the order list until PBO, we continue.
ArrivalFrom = Destination
Destination = SVG
As we didn't meet the CBG order while walking over the order list until SVG, we continue.
ArrivalFrom = Destination
Destination = CBG
Now on the route to CBG we fulfil the break condition (order==start) at the CBG order again, break the loop and the source station would be in the ArrivalFrom variable which is SVG. So this would require walking over the list only once.

I'll have a look at the actual code this evening, shouldn't be too hard, unless I'm missing something

[hthhs]

Assuming we'd start with CBG:
Destination = PBO
As we didn't meet the CBG order while walking over the order list until PBO, we continue.
ArrivalFrom = Destination
Destination = SVG
As we didn't meet the CBG order while walking over the order list until SVG, we continue.
ArrivalFrom = Destination
Destination = CBG
Now on the route to CBG we fulfil the break condition (order==start) at the CBG order again, break the loop and the source station would be in the ArrivalFrom variable which is SVG. So this would require walking over the list only once.

I'll have a look at the actual code this evening, shouldn't be too hard, unless I'm missing something

Suppose the full order list is:

Code: Select all

CBG
ELY
PBO (unload and leave empty)
PBO
SNO
HIT
SVG (unload and leave empty)
SVG
HIT
MEL
CBG (unload and leave empty)

Would your method have ArrivalFrom set to SVG or MEL when you come to process the second CBG order?

EDIT

I figured out a way of doing it, possibly exactly the one you were thinking of. The patch in the first post has been updated. A binary will appear shortly.

[sph]

I figured out a way of doing it, possibly exactly the one you were thinking of. The patch in the first post has been updated. A binary will appear shortly.

Nice work! I'll give it a try tomorrow and sniff around a bit in the code then

[hthhs]

The patch has been updated with a few small bugfixes.

[sph]

Small fix on line 364 in departures_gui.cpp.

Replace:

Code: Select all

			if (a->scheduled_date + (a->status == D_ARRIVED ? 0 : a->lateness) < d->scheduled_date + (d->status == D_ARRIVED ? 0 : d->lateness)) {

by

Code: Select all

			if (a->scheduled_date <= d->scheduled_date) {

Otherwise the order can be screwed up if one vehicle is delayed.

For example:
arrivals: A1 (1:00) -> A2 (2:00) -> A3 (3:00)
departures: D1 (1:30) -> D2 (2:30) -> D3 (3:30)

Suppose A1 is two hours late. The board will now look like: D1 (1:30) -> D2 (2:30) -> A1 (3:00) -> A2 (2:00) -> A3 (3:00) -> D3 (3:30). You can see the conflict between D2 and A2.

Also, I don't think there is any need to take lateness into account when sorting in the first place. If a train is late, it will show up at the time it was scheduled to arrive or leave but with the "Expected: ..." message next to it, which is the normal behaviour at our railway at least

Edit: also apply the same fix on line 192, otherwise it might open the wrong vehicle window when clicking on an order.

Edit2: Meh, it seems that there is still a sorting bug somewhere.

[hthhs]

arrivals: A1 (1:00) -> A2 (2:00) -> A3 (3:00)
departures: D1 (1:30) -> D2 (2:30) -> D3 (3:30)

Suppose A1 is two hours late. The board will now look like: D1 (1:30) -> D2 (2:30) -> A1 (3:00) -> A2 (2:00) -> A3 (3:00) -> D3 (3:30). You can see the conflict between D2 and A2.

In that case, then the computed arrivals list would have been [A2, A1, A3] or [A2, A3, A1], only

Also, I don't think there is any need to take lateness into account when sorting in the first place. If a train is late, it will show up at the time it was scheduled to arrive or leave but with the "Expected: ..." message next to it, which is the normal behaviour at our railway at least

made me realise just how annoying it can be to have departures keep swapping positions in the list, so the patch has been updated to order them by scheduled time instead of expected time.

[sph]

made me realise just how annoying it can be to have departures keep swapping positions in the list, so the patch has been updated to order them only by scheduled time.

Yeah, except there's still a little bug somewhere but I can't find what's causing it

Edit.

In that case, then the computed arrivals list would have been [A2, A1, A3] or [A2, A3, A1], only

This made me think, perhaps the arrivals should be compared with lateness included and departures should not? This might explain the bug in the picture.

[sph]

This patch fixes it. I've added a Sort method to the SmallVector class. This should also simplify some things in the departure.cpp file, though I haven't changed anything there yet.

@the developers, is there any reason why SmallVector didn't have a Sort method? The GUIList in sortlist_type.h could call that one instead then. If you're interested, I've attached a patch specifically for smallvect_type.hpp

[hthhs]

This patch fixes it. I've added a Sort method to the SmallVector class. This should also simplify some things in the departure.cpp file, though I haven't changed anything there yet.

Cool - I reckon that's probably the most sensible solution. It would have been nice if the computed lists of departures were sorted while they were computed. Oh well. Thank you!

[sph]

Cool - I reckon that's probably the most sensible solution. It would have been nice if the computed lists of departures were sorted while they were computed. Oh well. Thank you!

Yeah, it's probably possible (assuming the VehicleSortedList is actually sorted on scheduled_date) but it's going to make things more complicated while there's hardly any speed gain, sorting a list of 20-30 items every so many ticks isn't exactly a heavy operation

I've added the bus icon too now, it looks a bit nicer this way.

[bwong]

I like how this patch is developing!
Does this patch implement the clock for one day. So for one Openttd day, the 24h clock needs to get from 0:00 to 24:59:59 for that to be one day?

[Eddi]

no, the clock has nothing to do with the days. that would be ... unpractical.