Roujin wrote:

Here's a screenshot :)

Attachments

• waypoint_stats.png (50.60 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5537

Roujin wrote:

New version with two fixes (thanks to Swallow)
* Changed the text color to black
* Use InvalidateWindowClasses instead of multiple InvalidateWindow calls (more efficient)

+ new screenshot with black text attached ;)

Attachments

• waypoint_stats_2_r15401.diff (9.43 KiB)
• waypoint_stats_2.png (50.21 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5538

peter1138 wrote:

Is uint8 enough?

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5550

Belugas wrote:

Can there be anything else than trains passing at waypoints?
If not ( and I think it's the case ), i would change the name of the variables to something less redundant.
Like passage(or traffic or else)_this_month etc...

And maybe i'd add a reset button somewhere..

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5569

Roujin wrote:

peter: I think so. I tried getting a top score with the 6xx kmh maglev engine, and got nowhere near 255. I cannot be absolutely sure of course because my trains had some space between each other; maybe the openttdcoop guys know some fancy setups to cram those together with minimum distance to each other, but I doubt one can reach 255 trains in a month.
Without changing something like the daylength of course...
Should I change it to uint16 nevertheless?

Belugas: point taken, will change it to traffic_... (sounds good imo). Will also look into a reset button...

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5574

Progman wrote:

You can hit the limit 255 with a testing case (see screenshot, 255 trains in 18 days), however it will never be used in a real game.

1. Why does the max() value doesn't count the current month? (see in the screenshot, too)
2. Why is the counter saved in the savegame (and so increase the savegame version)? Imho its enought if it is calculated only during a game and shows something like "N/A" if the game isn't run at least one game-month.

Attachments

• Sudston Transport, 2055-06-18.png (29.80 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5576

Roujin wrote:

I had a talk with Rubidium on IRC and he suggested to cap it at 255, so I've done that.
Also Ammler tested the patch on some real game from openttdcoop, and it seems that in normal games (where you actually try to transport something; not to reach the limit of this patch) no more than a throughput of about 60 trains/month is archieved.
Technically, it is possible to reach this limit though - I'm attaching the savegame where I did this (just unpause (may lag quite a bit) and watch). 300 trains go through the waypoint in about 20 game days there. Had to set all of them to "ignore signals" though - with signals inbetween I doubt that it's possible to reach the limit.

I've also renamed the variables (and also the strings) to *traffic, and added a reset button for the "maximum traffic" counter, and "maximum traffic" is now updated during a running month (if "traffic this month" exceeds all prior records), not only on month change.

Attachments

• waypoint_stats_3_r15476.diff (10.27 KiB)
• stats_test_extreme.sav (26.20 KiB)
• wp_stats_extreme.png (16.79 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5577

Roujin wrote:

Progman (didn't see your post before..):

1. fixed/done in above patch :)
2. I took that over from the old patch this is based on (see url in original task description). Appearently the original patch author did not save the values first either, but then peter came with a revised version that saved the values. So I thought saving those values is preferred, and did so in my patch.
   Personally, I'd save them (why not?). Just to prevent any bug reports a la "Waypoint stats not working after loading game"...

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5578

Belugas wrote:

Plus, I'd say that savegame revisions is not a bad thing, if it brings a bonus.
PLus, users would certainly complain about the fact that their data are lost. And the will complain, for sure..
So it's the best path, in my mind :)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5583

Roujin wrote:

Well, everything fine then? Everyone agree on "cap at 255"? Any other issues left?

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5653

Belugas wrote:

1- Both Rubidium and me (at least) are not confortable with the 255 cap.
2- I spent about half an hour with the window opened and i found out what I do not like about it. The multiplication of "traffic" . It's redundant. So i suggest something like this:

Traffic
This month : xxxxx
Last month : xxxxx
Most in a month : xxxxx

that way, me, personnaly, it willl be ready for trunk

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5660

Roujin wrote:

Here's a new version with the mentioned changes.

1- data type changed from uint8 to uint16 --> cap raised from 255 to 65535
2- changed drawing code and strings according to Belugas' proposal.

Screenshot included.

Attachments

• waypoint_stats_4_r15594.diff (10.41 KiB)
• waypoint_stats_4.png (44.92 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5688

frosch wrote:

(as already said on IRC)

+ this->wp->traffic_highest = this->wp->traffic_this_month;

That won't work in multiplayer. It only sets the value on a single client. And as it is stored in savegame elsewise, that is generally a bad idea.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5689

Roujin wrote:

Of course.. what a silly mistake. I did not think about multiple companies / multiplayer at all.

Here's a new version that uses a command instead, and also assures that no one can reset the counter of another company's waypoint.

Attachments

• waypoint_stats_5_r15597.diff (12.84 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5690

Belugas wrote:

little upgrade... and addons

Attachments

• waypoint_stats_6_r15698.patch (14.76 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5769

Belugas wrote:

and here we go again.
P.S.: It's not in trunk yet, since after some discussions, we agreed on a bigger better wider feature, based on this idea.
But i though of updating it just to be sure work is not going to die

Attachments

• waypoint_stats_7_r15844.patch (14.84 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620#comment5845

andythenorth closed the ticket.

Reason for closing: Won't implement

Mass closure of patch tickets with no commentary for >5 years. Goal is to reduce patch queue as an experiment to see if it aids faster reviewing and rejection/acceptance (it may not). If this offends you and the patch is maintained and compiles with current trunk, discuss with andythenorth in irc. (andythenorth has no ability to review patches but can re-open tickets).

This comment was imported from FlySpray: https://bugs.openttd.org/task/2620