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

[supermop]

So I typed up something earlier while at work, but it looks like it didn't show up, so here is my feedback:

After a few months of being hands off with both OTTD and the online community, I was amazed to find this implimentation here. Simple proactive efforts like this make the game delightful, and really bring character to the community that surrounds this game. I was also pleasantly surprised with progress in my favorite projects and in trunk, but this caught me completely off guard. So thanks to Ms. Ayanami for having the inspiration and initiative to realize this. I hope the project progresses gracefully toward candidacy for trunk inclusion.

This patch got me to play around with OTTD again, but so far its just been experimenting with one network, centered on a hub with mainlines extending in two directions. I have been trying to use precise scheduling and the departure board to manage congestion, and allow express and local services on the same line. To maintain an acurate idea of where an express is relative to the locals that you want it to pass, it is helpful to schedule it as "non-stop via" at all of the stations that it will skip. However, this then leads to the "via" order showing up in large face on the departure board. While this is true, I find it spoils the effect of the board GUI, as express services become significantly represented by the stations they skip, where this would be more natural for local service nominclature. The problem is that TTD's "via" order is not exactly congruous with how this language is used on literature intended for passengers.

It would be nice if "via" was only used to denote a significant stop a vehicle made along the way to its terminus, however I can think of no good way to implement this.

Consider the following arangement: a rail line between A and E with smaller towns b, c, and d, along the route. The line is served by Local trains making all stops, rapid trains stoping only ant A, c, and E, and express trains going non-stop from A to E. vX represents an order to go nonstop via X.

Code: Select all

Line:     A---b---c---d---E
Local:    A---b---c---d---E
Rapid:    A--vb---c--vd---E
Express:  A--vb--vc--vd---E

With current behavior, the Local is listed as "Station E, calling at: b, c, d, E", which is ideal. However, both the rapid and express will appear as "Station E via b," followed by the list of stops. This does little to distinguish the rapid and express from the local, let alone each other. While one can read the list of stops to make a determination, but ideally one could identify distinct services by the main listing.

My suggested behavior would be this:

Local: Station E, calling at b, c, d, E

Rapid: Station E, via c, calling at c, E

Express: Station E, calling at E

Practically, it might be better to omit the "via" alltogether, but if it is posssible to walk through the order list, and on finding a via order, count to the next revenue stopping station, listing that on the board instead could be interesting.

I have a few other ideas for this as well, but I feel the above is most relevant to my experience with the patch so far.


Best,

[Dwight_K._Schrute]

I don't understand why you use the via order for every station the trains doesn't stop.

For the Rapid line the order would be:

Code: Select all

Go non-stop to A

Go non-stop via c

Go non-stop to c

Go non-stop to E

Go non-stop via c

Go non-stop to c

So in station A the departure board will show "E via c" and in station E it will be "A via c"

by the way: great patch

[Eddi]

If you want the local train to wait at B, until the express train overtakes it, then B must be in the order list of the express train. otherwise you don't know when it will pass there.

[Dwight_K._Schrute]

Ok, you're right Eddi. I make my timetables with a lot of trying Never realized the via-option before hthhs mentioned it in his thread

But I have another problem:

Imagine a train between the cities A and B. In B the train unloads all the passengers and drives on a sidetrack C (C is a station so that the train is able to wait) to wait for a while until it drives back to B and loads the passengers for the new journey.

So in A the departure board shows "C". Is there a way to avoid this??

[ChillCore]

Hmm,
How is the OpenTTD supposed to know that the train only waits there?
For as far as the code is concerned C is just another stop.

[Dwight_K._Schrute]

Unfortunately, there is no order to "not load" and "not unload" So my order is in B: transfer and leave empty" and in C it's "transfer and leave empty", too. So I hope to achieve, that no one wants to go to C or wants to board there...

EDIT: Ok, I was wrong, there is an order "unload and leave empty". This order I have in B and C, so the train is empy between B and C. But the departure board still shows "C"

[Eddi]

why shouldn't it show C? after all, that's what the orders tell.

[supermop]

Try this approach; it works for me, and was mentioned earlier I believe.

Vehicle makes four stops plus one scheduled wait period out of service like so:

A---B---C---D---e(wait)

orders should look like this:

Code: Select all

go nonstop to A 
go nonstop to B
go nonstop to C
go nonstop to D (unload and leave empty)
go nonstop to e (no loading)
go nonstop to D
go nonstop to C
go nonstop to B
-end of orders-

My departure booard at A then lists this vehicle as:

Station D; calling at B, C, D


Best,

[Dwight_K._Schrute]

Hmm thank you. But that doesn't work for me. Don't know what I'm doing wrong

[supermop]

Hm, weird.

To be honest I am using a version a couple days old (downloaded Tuesday evening) which mentions Arrivals in the advanced settings but does not yet show them. Perhaps something changed in the next version to cause the behavior you have. You'll have to hear from rei about that.

Best,

[Dwight_K._Schrute]

Ok, shame on me AGAIN.

I should have posted it in Chill's thread. With the newest version on clean trunk it works perfectly.

Sorry!

[hthhs]

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

It was more that I wanted the departure boards to perform as little modification to the existing codebase as possible - see below.

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

Awesome I've included it in the patch attached to this post. Thank you!

After a few months of being hands off with both OTTD and the online community, I was amazed to find this implimentation here. Simple proactive efforts like this make the game delightful, and really bring character to the community that surrounds this game. I was also pleasantly surprised with progress in my favorite projects and in trunk, but this caught me completely off guard. So thanks to Ms. Ayanami for having the inspiration and initiative to realize this. I hope the project progresses gracefully toward candidacy for trunk inclusion.

I agree; it's amazing to see both the game grow and evolve, despite me only having witnessed it do so for approximately the last year.

[..]

With current behavior, the Local is listed as "Station E, calling at: b, c, d, E", which is ideal. However, both the rapid and express will appear as "Station E via b," followed by the list of stops. This does little to distinguish the rapid and express from the local, let alone each other. While one can read the list of stops to make a determination, but ideally one could identify distinct services by the main listing.

My suggested behavior would be this:

Local: Station E, calling at b, c, d, E

Rapid: Station E, via c, calling at c, E

Express: Station E, calling at E

If you have enough space near the stations, you can get the behaviour you describe by using waypoints near stations B, C and D and having the express and rapid trains go via the waypoints instead if they are not calling at the stations, as waypoints are not shown in the departure boards...

Practically, it might be better to omit the "via" alltogether, but if it is posssible to walk through the order list, and on finding a via order, count to the next revenue stopping station, listing that on the board instead could be interesting.

...but this is an excellent idea and has been implemented in the patch attached to this post.



Attached below is a beta of the next version of the patch - I've left out the code by sph that modifies SmallVec as I found a couple of things to do with the order of generated departure lists that I forgot to change last time and I think that this may fix the problems with sorting. I've tried to break it and have failed thus far; but other people will probably have more chance of finding situations that cause problems with it. Please let me know if you manage to break it!

departureboardswallclock8b1-r21007.diff

(89.75 KiB) Downloaded 101 times

Hopefully the patch will be more or less stable following version 8 being finished and released. My third-year undergraduate project starts next week and so I will have much less time available to develop the patch in (and it gotten to where it is now I'd also like to get back to playing OpenTTD instead of coding for it!)

[supermop]

Sounds great! I hope to try it as soon as I can (at work now, and unfamiliar with compiling patches). I hope you can get the code to a state you are happy with before real life consumes all of your time. I respect the simple approach of this patch, and your commitment to keeping changes as minimal as possible. I think this functionality has a real place in trunk eventually (as an optional feature), and while I am unfamiliar with the process that governs inclusion, it seems that an unobtrusive good idea implemented cleanly and concisely stands a better chance than others.

Out of curiosity, where does a station store information about the types of stations it consists of (bus stops, rail platforms, docks or airport). I think this idea is too tangential to work on now--better to refine the core function of the patch first--but if a station can access this information about another, it would be neat if little airplanes could show up next to names of stations with an airport. I think this would actually be more problematic than useful, as a little train symbol next to every station in the list would get crowded and obnoxious.


Anyway, keep up the great work, and I'd be happy to help in any way I can.

Best,

[Eddi]

this information should be trivial to come by, just copy the part that displays the station sign, it already adds these icons

[ChillCore]

Hi hthhs,
I did some testing with the 8b1-r21007 version of your patch.
The improvements from version 2, the previous version I tested, are very nice.

However I found a few minor problems with the gui.

Please see attachments.
1. Is solved when resizing the gui but should be solved without user interaction IMHO.
2. Just some gui improvement suggestions, not really bugs.


Edit: one to many 0's in revision number of patch. See quote below.

[hthhs]

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?

Not by itself... though if this patch were used in conjunction with daylength, it could be made to happen. However, for the shortest day length such that it would match up exactly with the clock you'd need 37 ticks per minute and a daylength factor of 720.

Out of curiosity, where does a station store information about the types of stations it consists of (bus stops, rail platforms, docks or airport). I think this idea is too tangential to work on now--better to refine the core function of the patch first--but if a station can access this information about another, it would be neat if little airplanes could show up next to names of stations with an airport. I think this would actually be more problematic than useful, as a little train symbol next to every station in the list would get crowded and obnoxious.

It turns out that that information is easy to access - stations have a field called facilities that contains it.

I've added a smaller version of your suggestion as an advanced setting - if a vehicle's destination is an airport (and the vehicle is not an aircraft) or a dock (and the vehicle is not a ship), then appropriate icons will be shown in the destination field of the departure boards. This also applies to the station the vehicle is going via, if one exists. Showing the icons in the calling at list would cause problems as the icons are much bigger than the default text size.

Hi hthhs,
I did some testing with the 8b1-r210007 version of your patch.
The improvements from version 2, the previous version I tested, are very nice.

However I found a few minor problems with the gui.

Please see attachments.
1. Is solved when resizing the gui but should be solved without user interaction IMHO.
2. Just some gui improvement suggestions, not really bugs.

Both problems fixed - thank you for reporting them!

I don't plan on adding anything else to this patch before the next full version. Please let me know if you encounter any problems with it!

departureboardswallclock8b2-r21037.diff

(95.01 KiB) Downloaded 121 times

EDIT

It turns out there are 24 hours in a day, not 60. Who'da thunk it?

[ChillCore]

Both problems fixed - thank you for reporting them!

Thank you for looking at the issues so fast.

The first issue I can comfirm fixed.
For the second issue I found a few corner cases that should show "No information requested ..." instead of "No vehicles timetabled ..."
See attachments.

Also while updating I noticed the following:

Code: Select all

- table/settings.h:
	 SDTC_BOOL(gui.departure_destination_type,                     S,  0, false,                        STR_CONFIG_DEPARTURE_DESTINATION_TYPE,          NULL),
 -> alignment, few too many spaces.

-departures_gui.cpp:
	uint entry_height;         ///< The height of an entry in the departures list.
 -> alignment, 1 too many spaces.

^^^ looks like nitpicking but it is easier to note what I saw while I saw it then looking for it afterwards.

[hthhs]

Thank you for looking at the issues so fast.

The first issue I can comfirm fixed.
For the second issue I found a few corner cases that should show "No information requested ..." instead of "No vehicles timetabled ..."

It seems we were expecting different behaviours - my line of thinking regarding your screenshots is that you've requested information on particular types of vehicles and no such vehicles are timetabled for the station, hence the "No vehicles timetabled" message is shown. You have requested some information though, so the "No information requested" message is not shown. This behaviour also happens to be easier to implement!

Also while updating I noticed the following:

Code: Select all

- table/settings.h:
	 SDTC_BOOL(gui.departure_destination_type,                     S,  0, false,                        STR_CONFIG_DEPARTURE_DESTINATION_TYPE,          NULL),
 -> alignment, few too many spaces.

-departures_gui.cpp:
	uint entry_height;         ///< The height of an entry in the departures list.
 -> alignment, 1 too many spaces.

^^^ looks like nitpicking but it is easier to note what I saw while I saw it then looking for it afterwards.

If you insist on nitpicking then I shall remove the nits! Seriously, thank you for pointing them out.

[ChillCore]

It seems we were expecting different behaviours - my line of thinking regarding your screenshots is that you've requested information on particular types of vehicles and no such vehicles are timetabled for the station, hence the "No vehicles timetabled" message is shown. You have requested some information though, so the "No information requested" message is not shown. This behaviour also happens to be easier to implement!

If you explain it like that then yes, the behaviour is correct.
If whenever you feel like refining the behaviour (read: add many lines and complicate the code, lol) then maybe "No vehicles that you have selected are timetabled from this station" could be added.
But for evaluating it is best to keep the code simple, as is your intention no doubt.

If you insist on nitpicking then I shall remove the nits! Seriously, thank you for pointing them out.

No problem.
One of the advantages when updating patches manually in a patchpack is noticing most changes.

[DeletedUser6]

I have a request. My request is a 'Cancelled' notice. If you, say, have a bus route running and you either send the vehicle(s) to depot, or delete the station, for a limited amount of time, the board shows a red 'cancelled' notice.
An example (please excuse the colouring of words, I am using them as an example)
Currently:
18:03 Great Harnley Central On time
18:17 Great Harnley Central Delayed
18:33 Great Harnley Central Exptd 18:44
I propose to add:
18:47 Great Harnley Central Cancelled

Matthew