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

Change: Make pf.yapf.rail_firstred_twoway_eol on by default #9544

Merged
merged 1 commit into from Nov 19, 2021

Conversation

@ldpl
Copy link
Contributor

@ldpl ldpl commented Sep 6, 2021

Motivation / Problem

I think it's a perfect time to change the default as #8688 now officially makes block signals an advanced feature for advanced players and those advanced players play with twoway_eol on xD

Jokes aside it's a useful feature that allows a number of cool techniques so changing the default will let players use them on servers even if the server owner is not aware (or forgot) of such setting and didn't specifically enable it. And help avoid confusion when trying to copy those techniques from the wiki or other players. As for the only argument against it that I know of it no longer stands (that it makes broken newbie networks even more broken).

More info on twoway eol can be found here: http://web.archive.org/web/20191223024422/http://wiki.openttdcoop.org/Two-way_end_of_line

Description

Just changed the default value of pf.yapf.rail_firstred_twoway_eol from false to true.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR touches english.txt or translations? Check the guidelines
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')
@JGRennison
Copy link
Contributor

@JGRennison JGRennison commented Sep 6, 2021

At the moment, this setting is not even in the settings window at all and has no explanatory text attached to it.
I would suggest that having it in the settings window with a detailed explanation of what it does should probably be done even if it is not actually turned on by default.
If it is turned on by default it should be absolutely be in the settings window as people trying to make old school block signal networks will either need to turn it off or be made aware of its existence and adjust their signalling accordingly.

Loading

@ldpl
Copy link
Contributor Author

@ldpl ldpl commented Sep 6, 2021

as people trying to make old school block signal networks will either need to turn it off or be made aware of its existence and adjust their signalling accordingly.

I think that's a very far-fetched use-case, twoway_eol is enabled on multiple servers including reddit, and yet I've never seen anyone even noticing that. While the opposite happens from time to time when someone tries to make an overflow or smth and can't figure out why is it broken.

IMO it should be just changed and forgotten like selectgoods and other relics of the past.

Loading

@2TallTyler
Copy link
Member

@2TallTyler 2TallTyler commented Sep 7, 2021

The linked article shows "arrows" in a terminus station using pre-signals. Do these become necessary? While I agree that new players will hopefully avoid being confused by block and pre-signals (unless Reddit and Discord start telling everyone to use such signals because lag and other debunked reason...which I can totally see happening 😕), I can see this becoming an issue for old-school players who are not aware of this change. A lot of Steam reviews seem to indicate longtime players coming out of the woodwork; I just don't know how in-touch they are with development and advanced strategies like this.

Loading

@ldpl
Copy link
Contributor Author

@ldpl ldpl commented Sep 7, 2021

I can see this becoming an issue for old-school players who are not aware of this change. A lot of Steam reviews seem to indicate longtime players coming out of the woodwork; I just don't know how in-touch they are with development and advanced strategies like this.

@2TallTyler you realize that argument can be used to turn down any change including #8688? And, in fact, the first thing those players will have to do now is finding those old signals that are hidden behind a setting that's not even shown by default. Also, let's face it, the old way of "two-way everywhere" signaling was created in a different era for a different game with a different pathfinder. By modern standards, it's just an illogical crap that's bound to break eventually and the sooner it does so the sooner player will throw it out and learn proper signaling. There aren't many cases for correct use of two-way signals and afaik none of them break with twoway_eol. More so, as far as I understand it, the only thing twoway_eol does is making trains lost sooner in a potential deadlock situation.

P.S. And that steam peak is already over. Judging by mp activity overall increase is 20% at best.

Loading

@2TallTyler
Copy link
Member

@2TallTyler 2TallTyler commented Sep 7, 2021

Yes, I realize that. I hate that argument as a catch-all impediment to progress as much as you do.

My question is whether using two-way combo signals at terminus stations, which as far as I'm aware (certainly could be wrong) is the correct setup when using pre-signals, now requires "arrows" to work properly.

In other words, I'm not arguing against this change. Just questioning your "it only breaks newbies' incorrect signaling" argument, so we can all understand the full ramifications of this change.

Loading

@ldpl
Copy link
Contributor Author

@ldpl ldpl commented Sep 7, 2021

My question is whether using two-way combo signals at terminus stations, which as far as I'm aware (certainly could be wrong) is the correct setup when using pre-signals, now requires "arrows" to work properly.

No idea why is it recommended there, hopefully someone more knowledgeable can hop in and explain. My only guess is that it's some old quirk as for all I can see it works perfectly fine without and even coop wiki never mentioned it in the stations section:
http://web.archive.org/web/20191220212643/http://wiki.openttdcoop.org/Main_station#Regular_Terminus

Loading

@vituscze
Copy link
Contributor

@vituscze vituscze commented Sep 7, 2021

The "arrows" are there to make the layout behave more nicely when lost trains are involved. They are not necessary to make it work.

Loading

@V453000
Copy link

@V453000 V453000 commented Sep 7, 2021

Indeed, those are for lost trains. Lost trains can misobey firstred 2way eol, if the track they're being forced onto has no forks.

Loading

@V453000
Copy link

@V453000 V453000 commented Sep 7, 2021

Strictly from "are pre-signals the use case for terminus stations". No. PBS is strictly superior there. Unless you need to connect the platforms to some kind of pre-signal logic, which is a specific rare case and IMO doesn't count into this comparison.

The main reason why block signals are to be recommended is not terminus stations. It's mainly in places where multiple tracks merge/cross. Because it's much clearer when they break in terms of throughput, and they invite "the right" solution - instead of adding more random tracks crossing and making the crossing wider, block signals basically motivate to use bridges/tunnels, and solve the problem by parallelizing the traffic completely.

On top of that, pre-signals are much more reliable in terms of picking between paths with higher penalty differences. This is probably largely thanks to the penalty on firstred exit signal, which I guess you could theoretically combine with PBS but I haven't seen anybody do that in a real game.
And of course there's the whole first 2way for PBS, which somewhat works too.

TL;DR Path signals are basically strictly superior for terminus stations, but lead the player down the very wrong route in junctions, and have a hard time making quick and precise decisions in joining tracks with penalty differences.

Loading

Copy link
Member

@LordAro LordAro left a comment

Everyone that still uses block signals seems to think this is a good idea. Who am I to argue?

Loading

@LordAro LordAro merged commit ad90e88 into OpenTTD:master Nov 19, 2021
15 checks passed
Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants