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: Build signals to the next junction when dragging regardless of the Ctrl state #9637

Merged
merged 1 commit into from Jan 30, 2024

Conversation

ldpl
Copy link
Contributor

@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?

Description

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.

Limitations

  • 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')

@2TallTyler
Copy link
Member

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

@Eddi-z
Copy link
Contributor

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.

@2TallTyler
Copy link
Member

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

@nielsmh
Copy link
Contributor

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.

@Rau117

This comment was marked as abuse.

@FLHerne
Copy link
Contributor

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.

@LordAro
Copy link
Member

LordAro commented Oct 21, 2021

@LC-Zorg
Copy link

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.

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

@ldpl
Copy link
Contributor Author

ldpl commented Mar 16, 2022

My thoughts on this:

  1. It's quite hard to drag signal accidentally, you need to drag to another tile and not notice that highlight changed. And even if a new player does drag accidentally it may lead them to learn about this essential feature so it's even somewhat positive.
  2. Area signal can be used for removing and for increasing signal density. So it's niche but useful.
  3. Highlighting rail to the next junction is a good idea but this type of highlight is not currently implemented in OpenTTD and I don't think should be a part of this PR. Also, imo it would be better to highlight signals to be placed, not rail.
  4. Having a dedicated modifier key that works as a bulldozer mode is very helpful and is already implemented in cmclient but it has it's own challenges unrelated to this PR.

So I think this PR is best to be implemented as is. Sure, some initial confusion is to be expected but I don't think it's worth complicating the game with settings and/or ui elements for something that has no effect on the functionality and only takes a few hours to retrain the muscle memory.

@nielsmh
Copy link
Contributor

nielsmh commented Mar 26, 2022

Random thought that may not be directly relevant to the change proposed here: In addition to the floating cost text after making the change, also make a floating text showing how many signals were built/removed

@frosch123
Copy link
Member

I second FLH's suggestion: I prefer if the area-drag would be removed entirely, so dragging becomes autofill for both ctrl-pressed and ctrl-not-pressed.

@Bouke
Copy link
Contributor

Bouke commented Oct 18, 2022

Having played OTTD for years, I didn’t know this feature (auto-fill) existed. I don’t think I have read any tooltip while playing. Only recently when working on the translations of the tooltips I discovered it. Now I don’t know how I could have lived without it. So making the feature more discoverable is a net win.

@ldpl
Copy link
Contributor Author

ldpl commented Oct 20, 2022

Shall we make a poll? xD
🎉 - to leave pr as it is (area drag with ctrl)
👀 - to remove area drag from vanilla (I'll still add it in CityMania patchpack :p)

@LC-Zorg
Copy link

LC-Zorg commented Oct 20, 2022

The following text was written as part of the program "Let it not be too sweet" ;)

It's kind of funny. You are afraid to add the feature of closing adjacent level crossings, because someone may have several accidents at once, although there are many indications that it is quite unlikely and the benefits of the change are incomparably greater than any losses. Meanwhile, you want to add something that is absolutely sure to cause a whole lot of crashes for almost all players who just try to remove a few signals (instead of just a few, they'll delete all on the line). The main problem here is not the way to build but to remove the signaling. The point is that both activities, building and removing, should definitely remain consistent. What's more, here it will not be a one-time event, but a repeatable one, which results from the habits acquired over the years of playing. For some it will be a one-time event, for others it may be a few, but there will also be players for whom it will be repeated many times. You try to make the game accessible to as wide a group of people as possible, including those with various disabilities, sometimes quite rare (#9581), meanwhile, by accepting such a change without giving a choice, you can ignore most current players, especially those with certain disorders on the autism spectrum. For me personally, this is probably not a problem, probably even if it were optional, I would have turned it on anyway, I also see the undeniable advantages of this solution for new players, but I imagine it will be really annoying for many. So please think about adding a setting for this change.

@ldpl
So my vote is: 🎉 + 🚀 (area drag with ctrl + setting for reverse this change)

@ldpl ldpl force-pushed the signal-drag-mod branch 2 times, most recently from 7cba351 to 9852bfe Compare November 10, 2022 21:38
@2TallTyler 2TallTyler added the candidate: needs considering This Pull Request needs more opinions label Dec 28, 2022
@ldpl ldpl force-pushed the signal-drag-mod branch 2 times, most recently from d1a48a1 to f244b33 Compare February 26, 2023 21:08
@2TallTyler
Copy link
Member

Looking back at old PRs...

I third the suggestion by FLHerne and frosch, to eliminate area drag altogether. You can do as you like in cmclient. 😄

I would approve the PR with that change.

@ldpl
Copy link
Contributor Author

ldpl commented Jan 29, 2024

@2TallTyler Problem is, to do as I like in cmclient I still need vanilla to keep the network command parameter.
But I updated the PR so it doesn't area drag anymore with ctrl.

Copy link
Member

@2TallTyler 2TallTyler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am fine with this change, although I will leave it to a developer above my pay grade to weigh in on leaving an unused parameter for cmclient to use.

@michicc michicc changed the title Invert the effect of Ctrl press when dragging signals Change: Build signals to the next junction when dragging regardless of the Ctrl state Jan 30, 2024
@michicc michicc merged commit b370ae1 into OpenTTD:master Jan 30, 2024
20 checks passed
@TrueBrain
Copy link
Member

To ping all people involved in this ticket, I just created #12034.

tldr; there is no visual indicator the default behaviour changed. You see visually that you will place signals on a stretch of N tiles, but in reality it is placed till the next junction. Or worse: when removing signals, it does this too. This is very unexpected for existing players, as it really looks like a bug. As nothing is telling you anything changed, it takes you a while to figure this out. (yes, the tooltip tells you, but please don't use that as an argument :D ).

As I explain in #12034, I am not against a change like this; but I think we did overlook that the autofill behaviour never had any good visual indicator, and was a "if you knew you knew". With 14.0 closing in, I suggest we revert this PR for now, to find a better way to visually indicate we are changing this default behaviour. Plenty of suggestions available for that, I put a few in the PR :)

Curious what you guys think, looking back on this PR now 1.5 years later, and playing the game for a bit with this new behaviour :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
candidate: needs considering This Pull Request needs more opinions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet