Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

@stormcone
Copy link
Contributor

@stormcone stormcone commented Dec 5, 2020

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

@frosch123
Copy link
Member

@frosch123 frosch123 commented Dec 8, 2020

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.

@stormcone
Copy link
Contributor Author

@stormcone stormcone commented Dec 8, 2020

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.

train_speed_adaptation
The left circle will work. The right one won't, because of the junction on the right side.
I think as of the lines:

OpenTTD/src/train_cmd.cpp

Lines 427 to 429 in 63af148

} else if (KillFirstBit(ft.m_new_td_bits) != TRACKDIR_BIT_NONE) {
/* Tile has more than one track and we have no reservation. Bail out. */
break;

By the way if your company saves on traffic lights, don't be surprised if accidents happens. :P

@frosch123
Copy link
Member

@frosch123 frosch123 commented Dec 8, 2020

Ah, too bad. So, no self-regulating networks without signals.

@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Dec 14, 2020

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:

  1. wouldn't it be better to introduce orange signals as a concept, over some magic "I am going to adjust my speed because I heard from a mouse that the train before me is going slower" :D
  2. can't we hook into the path finder better, that it returns the train in front of you on the segment or something?

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 :)

@2TallTyler
Copy link
Member

@2TallTyler 2TallTyler commented Dec 16, 2020

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).

@stormcone stormcone force-pushed the train-speed-adaption branch from 63af148 to 63ddf69 Dec 17, 2020
@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Dec 18, 2020

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:

  • If a train goes uphill, it slows down
  • A red signal means a train stop
  • a PBS signal reserves a track
  • etc etc

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 :)

@TrueBrain TrueBrain closed this Dec 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants