hiltinsurance.blogg.se - Openttd path signals

This brings me to a conclusion that was already made in the closing comment of the previous attempt on this: I think the GUI needs a redesign to make visually more clear what is going on with what signals can be selected and cycled through. (this is normal btw happens a lot to my PRs too if I am not careful about it :P)

I think that balance is a bit lost in the current state of this PR. There is always a part of our community that wants to fine control everything, so you get an infinite matrix of options and selections :) I am surprised nobody asked for an option to only have "one-way" but for PBS and Block signals :P We just have to be challenging, also to ourselves, what makes for a good addition for the few, but doesn't confuse the many. But by combining what you can cycle through in combination with a "None" setting, it becomes rather unclear to me, and it really feels like we are trying to fit a square peg in a round hole. But it seems some feature-creep happened while doing so, making it all feel slightly more out of place when looking at it as a whole.įor example, if the setting was just: PBS, Block, All, and it allowed cycling through your selections, this would have made perfect sense to me. Do not get me wrong: I am all in favour of reducing the amount of settings. Not sure if we do this on other places, but just mentioning it here.Īll in all, for me, this PR makes the signal more confusing than it already is, especially when looking at the settings. The blue "Recommended" is impossible to read when it is not selected in the dropdown.The "None" option seems to be cycling through PBS signals.Even then it took me some time to parse that information :D This was already the case before your PR, but with your PR it becomes even fuzzier. It took me quite some time to find the tooltip that mentions this. The mentioning of "Cycle" is completely unclear unless you know exactly what you are talking about.I do understand what you try to achieve here, but the user feedback is so minimal, it just isn't very clear.

The "None" option feels weird it is rather undocumented what signal it will put down.

This is really frustrating me for some reason.

Changing the signal setting closes the signal GUI.

I just started the preview and did some play-testing.

This PR affects the NewGRF API? (label 'needs review: NewGRF')įirst of all, I did not look at the code.

The compatibility wrappers (compat_*.nut) need updating.

ai_changelog.hpp, gs_changelog.hpp need updating.

This PR affects the GS/AI API? (label 'needs review: Script API').This PR affects the save game format? (label 'savegame upgrade').The bug fix is important enough to be backported? (label: 'backport requested').This list is a reminder for the reviewers. Some things are not automated, and forgotten often. This PR was inspired by #7504 but mostly builds on work hiding pre-signals for his Realistic Braking feature. I am open to debate on any of these changes. You can still control-click the signal button in the Rail construction menu to build signals without creating a toolbar.

Settings > Construction > Enable the signal GUI has been removed.

Settings > Company > Cycle through signal types now defaults to Path signals only, and the option for Block signals only has been removed.

Note that players only see this when they first open a game - after that, the toolbar opens with the last signal used selected.

Settings > Company > Signal type to build by default: Path signals has been removed and hard-coded to one-way path signals.

In an attempt to simplify the confusing combination of settings affecting signals, I have made additional changes: For the players who use them for signal logic, priority merges, or stubborn habits, they can be enabled via an Advanced-level setting, Show signal types. Path signals are the only signals needed by the majority of players, so this PR hides all non-path signals from the signal GUI by default. New players to OpenTTD are confused by signals, partly because there are so many choices available.