[prototype]Mark where trains frequently get stuck at signals

[Eddi]

This patch might help finding bottlenecks in the network by giving locations where trains wait for a long time.

This uses m7 for rail tiles [not road crossings or tunnel-/bridgeheads] as an 8-bit counter.

every 4 ticks that a train waits at a signal, the counter is increased by 1 [takes 1024 ticks to get to maximum of 255], every 256 ticks the counter is decreased by 25%. this emphasises trains that are currently waiting, and slowly phases out trains that have been waiting in the past months.

the values are then painted on the smallmap when you open the "routes" view.

Edit: updated to r19525

[Ammler]

tested on current #openttdcoop PublicServer, but we use mostly block...

NOTE: currently seems to work only at path signals

... so I didn't find many red dots, but it has, also orange and green.


Nice idea anyway.

Greets
Ammler

[Eddi]

Well, i know where to put the check for the block signals, but the counting seems off then, maybe that code path is not run every tick, need to investigate that further.

[XeryusTC]

Very nice patch indeed, it helps you identify problem areas in a way that the traffic overview doesnt show. Too bad it currently only works with path signals though.

[Eddi]

updated the patch, should now work with block signals, too.

the problem is, the block signals are handled in TrainController() which does not appear to be run every tick for stopped trains. initial tests have shown this to be every 5 ticks, but i can't be sure if that holds for all vehicles, so counting might be slightly off.

[Zephyris]

Nice Simple but effective.

[Ammler]

The patch does still apply to trunk, but somehow the gui is broken, how easy to fix?

-Ammler

[Eddi]

quick skim says in smallmap_gui.cpp:GetSmallMapRoutesPixels there was an "else if (t == MP_RAILWAY)" block added, this must be replaced by the stuck-counter block.

[ChillCore]

Thank you for the update Eddi.

While I was reading your patch ...
Would it not be better for codingstyle to have :

Code: Select all

/**
* Colour Coding for Stuck Counter
*/
...

delared after the violet aray?

I know it does not do anything to the way it works, it would just look better if your patch is to hit trunk.

Needless to say I like this patch. It helps a lot to identify the troubled areas in my long lasting game.

[Eddi]

[...]after the violet aray?

that part was introduced after i wrote the patch, i didn't check whether it needs to be reordered...

if your patch is to hit trunk.

honestly, i don't expect that to happen...

first, it doesn't record trains waiting on bridges or in stations. (this might be solved by using the counter at the signal tile, not at the tile the front engine waits, but that is difficult to determine, e.g. trains may be "waiting for path" while not at a signal at all)

second, it needs a better GUI representation, i just kinda hijacked the "routes" view...

... i don't think i'm going to do either of that ...
feel free to pick it up, though...

[ChillCore]

that part was introduced after i wrote the patch, i didn't check whether it needs to be reordered...

Because I have been quite busy around that part of the code it kinda jumped out towards me.

honestly, i don't expect that to happen...

That would be a shame because it is very useful.

first, it doesn't record trains waiting on bridges or in stations. (this might be solved by using the counter at the signal tile, not at the tile the front engine waits, but that is difficult to determine, e.g. trains may be "waiting for path" while not at a signal at all)

I did not notice that. My bridges usually are enclosed by signals to minimize the gap and I still put signals in front of my stations eventhough they have a build in signal since some time now (I just think it looks better).

second, it needs a better GUI representation, i just kinda hijacked the "routes" view...

... i don't think i'm going to do either of that ...
feel free to pick it up, though...

Would introducing a button for it and using for example "MP_WAITING_SIGNAL_TIME" be enough?
If so I might give it a try ...
My guess is that the rail colours would have to be preserved for trunk inclusion to be considered.
I think I will start by including it in my patchpak to see how it behaves with other patches (Signals in tunnels and on bridges).

[Eddi]

My guess is that the rail colours would have to be preserved for trunk inclusion to be considered.

i tried, but the rail colour is very bright, it's difficult to make out the coloured spots in there, which is why i made it black. the original colouring also includes two pixels of the terrain, leaving only two pixels for the rail colour. i made it use the whole 4 pixels.

I think I will start by including it in my patchpak to see how it behaves with other patches (Signals in tunnels and on bridges).

that should be easy to determine: if they use m7 for rail tiles, it's not going to work (the grass growth patch is the only one i know that does that)

i did not modify bridges or stations or level crossings, so it's unlikely to conflict anywhere...

[ChillCore]

i tried, but the rail colour is very bright, it's difficult to make out the coloured spots in there, which is why i made it black. the original colouring also includes two pixels of the terrain, leaving only two pixels for the rail colour. i made it use the whole 4 pixels.

Maybe having a seperate view will solve that.

that should be easy to determine: if they use m7 for rail tiles, it's not going to work (the grass growth patch is the only one i know that does that)

Thanks for the info.
I tried using m8 for the grass growth but that does not seem to exist.

i did not modify bridges or stations or level crossings, so it's unlikely to conflict anywhere...

Hmm grass or signals ...
Signals seem less cpu intensive. (Less places to check)
But this is off-topic here.

[Michi_cc]

and I still put signals in front of my stations eventhough they have a build in signal since some time now (I just think it looks better).

They don't. What you see is simply the general don't-just-crash-my-trains protection. Just compare the position of the two waiting trains in http://www.tt-ms.de/forum/attachment.php?aid=1014.

-- Michael Lutz

[ChillCore]

They don't. What you see is simply the general don't-just-crash-my-trains protection.
...

Ah, OK. I assumed that they had like depots. Depots do have one built in them, don't they?
If not I have some more reading to do.

/me should stop assuming ...

[Michi_cc]

Depots have signals built in. But as a train inside a depot has no real position anyway, it wouldn't make a difference where the train waits for a free path

-- Michael Lutz

[xmirakulix]

Updated to current trunk

[xmirakulix]

Updated to current trunk

[adf88]

I refreshed the patch:
- change: stuck counter now decreases to 0 so a highlight will disappear after certain period of time (previously once highlighted signal was staying highlighted for eternity)
- removed magic constants
- fixed coding style (whitespace)
- moved new functions in rail_map.h higher (to keep MakeXXX functions on the bottom as usually)