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. When the crashed trains clear up (in about 3 months from now) change the signal back to its normal state.New players to OpenTTD are confused by signals, partly because there are so many choices available. This makes it impassible without costing you any money. I would recommend using CTRL-click on that signal,with the signal build button pressed, to turn it into a one-way signal in the wrong direction.
If it can, but there are a lot of trains and red signals behind that signal on the right, it will also choose to go left. If it can, but you built a massive rail maze behind that signal on the right, it will still choose to go left. If the train cannot get to its current destination via the right path, it will always choose the left path: the penalty is infinite. I cannot see what's behind both choices so I cannot say for sure what's causing this to be the case.
The train chose to go left because the pathfinding penalty for the route on the left was smaller than that for the route to the right. While this is true, trains do take signals into account when choosing a path: red signals confer a pathfinding penalty. Signals do not affect the path a train takes directly: A signal can only force a train to stop and start, but cannot dictate its direction.
0 kommentar(er)
