New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Train speed adaption. #8354
Conversation
I tried this. When I let two trains run in a circle without any signals, the faster one slowly catches up with the slower one. (until they collide). Maybe related to the acceleration code. |
I think this is unrelated to the acceleration model. If your circle has a junction, then near it the train will stop the checking the path front of it and will accelerate to full speed. So if your trains are close to each other in that part of the rail, they will collide.
Lines 427 to 429 in 63af148
By the way if your company saves on traffic lights, don't be surprised if accidents happens. :P |
Ah, too bad. So, no self-regulating networks without signals. |
Basically this introduces orange signals (not sure if they use that in every country .. they do over here :P), where a train knows only the next segment is free, so he better adjust his speed to not hit a red signal for the next segment. I concept, I really like that, but I am not really sold on the current implementation. Mainly, it seems to re-implement a simple path finder, where a lot of cases are not handled (yet). So I am wondering two things:
I am a bit out of the loop of the current conditions of a lot of the OpenTTD code-base, but I just wanted to share my thought on it :) |
At the risk of going off-topic, I agree with TrueBrain that yellow/orange signals would be a better way to solve this problem. There was a previous patch for this, and I believe JGRPP adds an extended path reservation which is similar to the patch (without the visual aspect). |
63af148
to
63ddf69
Compare
I did some more thinking about it, and the more I think about it, the less I like the implementation (in concept) of what you try to achieve :) To elaborate a bit more: Many of the train mechanics can be easily explained:
Sure there are a few odd bits and pieces here, but mostly it is also what we see in the real world. This patch .. goes against that. Because of some magical thing a train slows down because the train before him is slower. This .. is hard to explain, especially to new players. At least, that is how I currently look at this. The mechanism you try to achieve here, I guess (I read it somewhere, but I cannot find it where nor here :D), is to avoid trains speeding up, hitting a red light, standing still, etc. So less "smooth", so to say. This can be achieved in other ways, that do fit the mechanics of the game more. Like the one mentioned above: yellow lights. But I am sure there are others. So for now I am going to decline this idea; not because of the implementation but purely because I think the idea doesn't fit the game as we currently have it. If you (strongly) disagree with this point, I would love to hear the counter-points. And a Pull Request that implements the same result with another mechanics is more than welcome; as I do understand that having trains not accelerating and decelerating all the time can be useful if you have a mixed network of old and new trains. But I think it asks for another solution :) Nevertheless, tnx for the PR! I really do appreciate you upstreaming some of the code in patch packs :) |
This patch is based on @KeldorKatarn's commit:
KeldorKatarn/OpenTTD_PatchPack@c5a709d
I added a station check to see the train stops there or not and 2 more configuration options.
The forum thread can be found here with the history of the patch:
https://www.tt-forums.net/viewtopic.php?f=33&t=52085&start=20