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

Invert the effect of Ctrl press when dragging signals #9637

wants to merge 1 commit into
base: master
Choose a base branch


Copy link

@ldpl ldpl commented Oct 20, 2021

Psst, I heard you like controversial changes ;)

Motivation / Problem

Signal autofill while being one of the most essential feature for playing and enjoying OpenTTD is currently hidden behind Ctrl magic. That makes it very hard to find for new players. And those who know about it still have to do that extra ctrl press every time which also makes it easier to accidentally build a semaphore when dragging too little. On the other hand, filling only selected stretch is one of the most useless feature in the game imo. I honestly struggle to think of any use case where it would be preferable to autofill. Dragging presignals when building priorities maybe?


This PR inverts the effect of Ctrl press when dragging signals. Now, with ctrl it will only fill the selected stretch while without it will do autofill to next junction/signal.


  • Changing habits is hard

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')
@ldpl ldpl force-pushed the signal-drag-mod branch from 6edbafe to 76ad9d4 Oct 20, 2021
Copy link

@2TallTyler 2TallTyler commented Oct 20, 2021

You know I like controversial changes. :D

I had no idea dragging signals without holding Ctrl extended them in the selected area only. I also can't think of a common use case for this.

I am +1 to this change. And not just to distract people from complaining about my signal change. ;)

Copy link

@Eddi-z Eddi-z commented Oct 21, 2021

slight usability problem i see is if someone accidentally drags the mouse while building signals, they might not realize what they did, or how to undo it.

Copy link

@2TallTyler 2TallTyler commented Oct 21, 2021

That already happens though. Dragging a signal without ctrl pressed builds signals along the length of track selected.

Copy link

@nielsmh nielsmh commented Oct 21, 2021

When currently dragging signals without Ctrl, it builds signals only along the part you dragged over, that part is all visible on screen.

With this change, dragging signals without Ctrl can affect a very long stretch of rail, potentially make changes across the entire map, and the player might not realize what has happened, or how to reverse it.


This comment has been minimized.

Copy link

@FLHerne FLHerne commented Oct 21, 2021

I don't see the point in a new setting - like others above I've never intentionally used the non-Ctrl version and can't think of any case where it's preferable.

A different usability concern related to that: many users won't read the changelog, so will continue pressing Ctrl. This will now result in "covered area" dragging, which looks similar (some signals built) but isn't what they expect. There will definitely be bug reports.

I wonder if the "covered area" version should be simply removed rather than hidden behind Ctrl, unless someone emerges with a real use for it. This would cause Ctrl-drag to continue to function as now, because for inputs with no special function the Ctrl is just ignored. It would also allow reusing Ctrl for some future enhancement when people have got used to not needing it.

+1 to this patch in general, with or without any of the suggestions so far.

Copy link

@LordAro LordAro commented Oct 21, 2021

Copy link

@LC-Zorg LC-Zorg commented Oct 23, 2021

Yes, this is a controversial change. :) But considering the new players the idea seems right. I admit that I very rarely, if ever, use dragging to build just a few signals, and almost always use + Ctrl. But as you have noticed, the biggest problem can be habits. :) Also for me, although I like the idea, I don't know how long it would take for me to switch to and how many times I would have caused an accidents. For some players, especially older players, this switch might be difficult. It is also worth noting that sometimes the construction, and especially the rebuilding of signaling, requires very quick action, and then the learned reflexes make themselves felt.

Another significant problem is the removing of signaling. To keep the method consistent, also when removing, a drag along the track should remove the signaling all the way. And this is, in my opinion, the biggest utility problem of this solution, because while you lose some money by accidentally building the signaling, accidental deletion will often result in accidents.

Nevertheless, I like this change and I would have a few ideas what can be done to civilize it a bit. ;)
1A. Make this change as an option where new players would use the new method and current players would use the one that is now. This solution is not perfect as it causes some divergence when a new player would expect some features to be explained, but it seems too important to force players to change. (I like this idea on average)
1B. You can also add a switch in the signaling building window, which would change the functions +Ctrl. This would be beneficial as it would give players the opportunity to notice that different methods exist, try them out, and choose a better one for themselves. This additional part of the window could be rolled up. (I have mixed feelings here too)
2. In order for the player to see that there has been a change in the construction method, it would be beneficial to highlight the entire section on which the traffic lights would be placed - the player would see what happens when he releases the button and this could help a lot in changing habits (it is easy to get used to something that is logical). This highlighting would be particularly advantageous in the event of signal removal. (Ps. This change could even be made for the current method)
currently   after some improvments

  1. In order to avoid accidental construction or especially the removal of signaling from the entire section, this function could work if the length of at least 3-4 tiles is drag (the length of the vector should matter here, to allow construction also on winding sections).
  2. Create an official test version of the game and make it available to players so that they can evaluate the solution. A simple preview and 5 minutes of play will not answer the question of whether it is good.

5. Adding the function of building an additional signaling device just before the intersection ending the section on which signaling devices are built. This would be useful especially with increased distances between the signals.
6. Assign the Alt+ click/drag to the function of clearing signaling. Alternatively, Ctrl+ may have a signal removal function, while Alt+ a build / delete function on a specific section. This is a feature that you use frequently and a keyboard shortcut would be a nice help. The use of Ctrl+ would also be quite consistent here, given that tracks and roads can be removed this way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

8 participants