Deranged Bitfiddler wrote:Alberth wrote:Maybe you should reconsider your "first endpoint goes left" idea?
There are only 2 directions for a bridge after proper swapping, and each of them can be build in two ways, ie just 4 ways of building a bridge. Can't you just move the endpoint into the right slot depending on how the user moves?
That could work while dragging a selection over terrain, but for separate clicks it would be annoying to have the player's decision overruled. When the left slot gets cleared then filled with another click, there should be no automatic swapping.
Oh separate clicks, didn't pick that up previously.
How do you handle bad clicks, eg not at the same x (or y), or with wrong heights? I already fail to draw a straight track while dragging (luckily the drag limits my movements), I will totally fail without guidance.
As bridges are always two-way, I don't think a user sees the points as "from" and "to", but between "there" and "there". Especially if you later change the position of one of the end-points, the concept of "from" (first click) and "to" (second click) becomes total nonsense, I think. Always having the left of the bridge at the left side, and the right of the bridge at the right side seems a much easier rule to me.
Deranged Bitfiddler wrote:Alberth wrote:Assuming you add all existing functionality into your new Gui, I don't see the point of two Guis. (And if you don't, consider doing that. It's a lot less confusing to a player if he doesn't have to choose between two windows that do mostly the same thing but not exactly.)
I think some old-timers would be sad to see the old method go away and have the new one forced on them, as there are significant differences in behaviour.
If you handle "start-drag" and "end-drag" as two clicks, you have merged both windows. As a bonus, you're not forcing the player into separate clicks which is useful imho for short distances.
Deranged Bitfiddler wrote:Open after drag-selecting vs. open from toolbar. Disappear on first click vs. remain while tool is active. Diplay only buildable types vs. display all with limitations for each. Unmovable and invisible endpoint selection vs. explicit display with possibility for refining after feedback. Keeping the player wondering "Can I build a fast/cheap bridge in here?" vs. explicitly displaying costs or "Too short/long" for each type. The old style is quicker with one drag-select then a click, the new style is slower with at least three clicks.
The moment of opening and closing the gui is a non-issue imho. Other picker windows also open early, and stay open until disabled.
The costs of buildable bridges are already shown explicitly. The main benefit seems to be the non-buildable bridges. Did you consider adding those in the bridge gui, but not selectable, and eg a text saying why it cannot be build?
Being able to move the endpoints is not likely to happen often. If you add the above information, the first bridge tells me that a 3 long bridge isn't good, I need (for example) a 4 long bridge for higher speed. I abort, and try to build the same bridge again, but with 4 tiles length. On all next bridges I will just drag 4 tiles long bridges to start with, and always immediately end up with the bridge that I want (and the list non-buildable bridges confirms that).
Deranged Bitfiddler wrote:It is a bit like rail-signals, old-style has no window, new-style has a window and an option in Settings>Interface>Construction. Bridge-building would have something similar. Old-style for drag-selecting endpoints then a window that lists buildable bridges and costs. New-style would make the list not so temporal and would make the window more like the station-builder, with more feedback for the selected parameters.
But signal gui didn't change the basic user-interface, it just adds new ways to do things.
Deranged Bitfiddler wrote:The window is kind of an extension to the bridge-types list. Right now that's where the code is, but I think it would be better to split it into two subclasses for easier maintenance. It has ~20 if-blocks just for selecting between old-style and new-style, and it is quite an effort to not wreck either style when changing something.
Having two independent window classes is a lot more effort than 20 if statements.
Note that when I say "one bridge gui", I mean 1 bridge gui, namely yours, ie picker style. Don't try to keep old pop-up functionality and your new functionality both alive. Trying to keep drag as a way to enter endpoints will make the new gui much more acceptable to the current users, I think, and you don't need 20 if statements for that.
Being a retired OpenTTD developer does not mean I know what I am doing.