[Patch] Trains cortege speed limit v0.4 [r27050]

[aberro]

This patch changes maximum speed behaviour of trains. When train encounters a signal, it looks two signal blocks forward instead of one (i.e. looks for path after safe stop tile 'till next safe stop tile). If train cannot reserve path in second block because another train are reserved path, it's speed limited to speed of train that prevents entrance to second signal block, unless that train is stopped (in this case speed is limited to half of maximum speed of current train). If train which blocking path are moving in opposite direction of current train path, speed doesn't limited.
In other words, when fast train are going after slow one, it slows down it's speed to speed of slow train to prevent regular stopping and starting on signals behind slow train. If fast train finds another way, which bypass slow train, it's speeds up (or don't limiting it's speed).
Trains ARE NOT reserving path in second signal block, their path reservation rules are the same as in original game; forward pathfinding in second block and lookup for trains blocking path are done without actual track reservation.

Current version are not fully tested, I've get rid of most bugs for now, but cannot guarantee that completely. Bug reports are welcome.
CAUTION: after applying patch make sure you've changed versions in saveload.cpp and saveload.h. If you play custom build with other patches, most probably they set their own saveload version different from current trunk. You should then increment SAVEGAME_VERSION and set TRAINSPEEDLIMIT_FROM to that incremented value, otherwise you may broke your savegame compatibility.

Code: Select all

Version history:
v0.1:
  Initial release.
v0.2:
  Reservation bug fix.
v0.3:
  Reference to train blocking path are added to save|load procedure. 
  Some bugfixes.
v0.4.4:
  GetTrainBlockingTrack optimized to check previous value. 
  Fixed reference to path blocking train not being reset. 
  Added condition to do not limit speed when path blocking train is too slow.

P.S.
I don't care for good practices of coding/patching, for merging this patch into trunk, for copyrights or their violation (yes, you may copy this piece of faeces and say that you've done this), for thanks, for curses, for your opinion, for anything but bugs, so don't even bother me with this. If you found bug, especially critical one, you're welcome.

[aberro]

Update is here. Sorry, forget to send flag to one function and therefore trains often get some path reserved where they shouldn't, which is leads to trains being stuck by themselves. Fixed.

[aberro]

New update. Now references to trains blocking path are added to save|load procedure.

[adf88]

1. The patch has a major bug - it doesn't work with signal density ≤2.

2. Read this: https://wiki.openttd.org/Coding_style

3. You can probably greatly improve performance of the patch which is not a bad idea considering that the pathfinding is an exhausting process. It looks like the most resource-consuming part of the patch is the GetTrainBlockingTrack function which iterates over all vehicles. You can avoid looping in most cases by passing a hint to the function. The hint would be the current value of the Train::path_blocking_train. Instead of immediate looping, check the hint first.

[aberro]

it doesn't work with signal density ≤2.

I would consider expanding forward looking to customizable signal blocks count eventually.

Read this: https://wiki.openttd.org/Coding_style

Fixed. Read post scriptum.

You can avoid looping in most cases by passing a hint to the function

That's a good advice, I surely will do this in next update.

By the way, this patch doesn't use pathfinding, only track following algorithm, which is mostly not so performance consuming. Therefore it often may not see blocking train when there is another free track presented (even if that track will be rejected by pathfinding), but it's better to leave as it is because pathfinding is performance consuming.

[aberro]

Update. Added optimization mentioned by adf88.

Tried to add gradual slowing down in few tiles before signals when path after signals cannot be reserved, but PBS just don't work such a way, either this would be too performance consuming.
UPD.: Fixed bug when trains limit their speed by speed of trains which was blocking their path previously but which now is far away. Reference to path blocking trains are now reset always.
UPD.: Added condition to do not limit speed when path blocking train are too slow (1/20th of maximum speed of current train).
UPD.: another fix and another minor version.

[adf88]

I don't care for good practices of coding/patching, for merging this patch into trunk, for copyrights or their violation (yes, you may copy this piece of faeces and say that you've done this), for thanks, for curses, for your opinion, for anything but bugs, so don't even bother me with this. If you found bug, especially critical one, you're welcome.

Sad it is. With your approach you shouldn't bother uploading your patches, just keep them for yourself.

[aberro]

I wouldn't upload patch would it be too bothering to overcome possible benefits from it, like bug reports or like your previous advice. Besides, if someone wants to make coding style being perfect, he could update any patch and request to upload it to post, most probably I'll do it and will use his version for next updates. And if someone considers that somewhat wrong coding style is the reason to ignore a patch he could just ignore it.

[Eddi]

the point of coding style is not that it is correct in the end. the point of coding style is to teach you the ways of how the other people potentially reading your code think, so that understanding code and talking between each other gets easier. (some other parts of code style try to teach you how to avoid common coding mistakes)

someone else fixing your code style completely misses the point.