New bridge building GUI

[Deranged Bitfiddler]

Improvements for bridge building GUI.

Current state

result.png (13.43 KiB) Viewed 2592 times

Patch at http://www.tt-forums.net/viewtopic.php? ... 7#p1154456

Old plan
under reconsideration

• Opens like station-builder, when tool is activated.
• Lists all bridge types available, based on date.
• Selected type is indicated by an arrow.
• Costs or errors with particular types are shown inside the list.
• One click for each endpoint, no need to drag-select.
• Has two viewports to show selected endpoints.
• Any endpoint may be missing, window will remain open, waiting for next endpoint.
• Endpoints may specify an existing bridge. In that case "Demolish" is available, and "Build" becomes "Rebuild".
• Endpoints are selected with a normal click instead of drag-select. This nullifies the requirement for cross-window drag-select.

[Zuu]

Hello,

I don't understand the point of your new GUI. It could be that I don't have it interactively available to get the point, but it still has some . But could you perhaps shortly explain the motivation for this GUI and its purpose, as I am sure you have some reason for it? Will this GUI show when you drag a bridge as today and how does in make sense to swap start/end, or clear only one of the start/end tiles?

Regarding patch review, splitting it up in logical steps is good. If you use a eg. hg queues (mq), it is not so much overhead from making a single patch. (if you rather use git, please do so) Still at experimental state, it sometimes make more sense to make one, and later split. It depends on how certain you are about the resulting patch queue. But any work on allowing multiple viewports in the same window, is clearly a separate patch to the bridge window patch for example.

My first major work on OpenTTD was to add a text filter to the sign list window. To do so, I first had to allow multiple text input fields on the screen at the same time by implementing text edit focus, or it would be to annoying. And now later someone else has made it possible to have multiple edit boxes on the same window. In your case it is not edit boxes, but viewport. But you are a bit in a similar position that in order to implement your intended GUI, you will need to extend our GUI framework to allow what you want to do.

[Deranged Bitfiddler]

I don't understand the point of your new GUI. It could be that I don't have it interactively available to get the point, but it still has some . But could you perhaps shortly explain the motivation for this GUI and its purpose, as I am sure you have some reason for it? Will this GUI show when you drag a bridge as today and how does in make sense to swap start/end, or clear only one of the start/end tiles?

Thank you for leading me to notice my mistake. My mind is so attuned to this right now, I had the wrong assumption about it being easy to guess to those not immersed in it, even after I simplified the post. That removed several unguessable details. I will update the first post.

The reason for swapping is to remove confusion. One endpoint given will fill the left slot first if that one is empty. When the other endpoint gets specified, the viewports may indicate an "inverted" bridge, where the ends point away from each other. This is only an illusion, but it can be confusing. With the swap button, the player can fix this. I would like to avoid automatic swapping, as that could be unexpected and confusing.

Regarding the viewport handling, I took a peek, and an upgrade seems like a lot of work. A lot of code assumes that there is only one viewport for one window. Would be nice to postpone that instead of blocking this.

I guess I should keep the old-style GUI available. I will make this into a separate Window-subclass. That will duplicate some portions, but it will be easier to work on, as there are significant differences in behaviour.

[Alberth]

The reason for swapping is to remove confusion. One endpoint given will fill the left slot first if that one is empty. When the other endpoint gets specified, the viewports may indicate an "inverted" bridge, where the ends point away from each other. This is only an illusion, but it can be confusing. With the swap button, the player can fix this. I would like to avoid automatic swapping, as that could be unexpected and confusing.

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?

Regarding the viewport handling, I took a peek, and an upgrade seems like a lot of work. A lot of code assumes that there is only one viewport for one window. Would be nice to postpone that instead of blocking this.

This is normal. Code isn't prepared for random extensions of functionality. In OpenTTD this is even a policy, we don't add code which is not needed at the time. As a result, it's normal that you need to extend code below the surface. Since the latter type of code is a lot bigger and more complicated, yeah, the biggest amount of work is not the gui.

I guess I should keep the old-style GUI available. I will make this into a separate Window-subclass. That will duplicate some portions, but it will be easier to work on, as there are significant differences in behaviour.

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

[Deranged Bitfiddler]

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.

This is normal. Code isn't prepared for random extensions of functionality. In OpenTTD this is even a policy, we don't add code which is not needed at the time.

That's how most software-projects evolve. No problems there. It was simply unexpected that this needs much more work, like diving into the event-handler and redraw code. And seeing how my attempts so far caused segfaults in the blitter, I have to learn much more about that when I go that way.

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.

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.

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.

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.

[Eddi]

Disappear on first click vs. remain while tool is active.

we have that as a setting for other construction tools [stations, objects, etc.]. the other differences you state are probably bogus.

[Alberth]

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.

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.

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

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.

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.

[Deranged Bitfiddler]

After all this discussion, my plan needs rethinking. I will split off some ideas and make patches for those. The rest will go through more experimentation and maybe get dropped.

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.

Written feedback in the window at least, but what constraints to apply on mouse actions, I don't know yet. I will try to keep the current method alive.

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.

Hmm, that makes sense. Maybe I'm just trying to avoid it because automatic rearrangement usually annoys me, but that's not so important here.

Being able to move the endpoints is not likely to happen often.

It would be rare, but I think the ability should be there.

When the first point is an existing bridge-head, the second one automatically becomes the other end of that bridge. This is already in the game. I want the ability to cancel that second point, while still keeping rebuilding quick and easy.

I kind of have an ulterior motive for this. I'm contemplating on a version of custom bridge-heads where a one-corner-raised slope could have two bridges connected. That needs more fine selecting than "Oh, a bridge-head, here is the other end".

But that is for later.

But signal gui didn't change the basic user-interface, it just adds new ways to do things.

Hmm, right.

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.

That makes it simpler. The only complication is trying to handle both draggable and single click selecting at the same time. I guess that could be confusing, will see later.

[planetmaker]

Just a few random thoughts and I haven't really read or tried the patch yet:

This GUI might be useful for touch devices while it may not be (in my opinion) terribly handy for at least the regular players (this is no argument against it, actually on the contrary).
It's a rather big window - could it be made to maybe expand on click of a button (and the button state remembered) to switch between current bridge selection and the new enhanced view which includes showing starting and end points?

With ctrl+drag one can build the last bridge type again. Is that considered in the new bridge building window and maybe the last selected bridge type auto-selected there, too? Maybe the current default bridge window behaviour can even be changed such that the last selected type is at least automatically scrolled-to on re-opening the window.
Maybe the behaviour of that window can be changed such that double-click builds and single-click selects (this might need debate); then a button 'cancel' and 'build' could be added, too.

[Deranged Bitfiddler]

Well, look what got almost forgotten.

This patch makes limitations visible but with possibility to filter.

result.png (13.43 KiB) Viewed 2596 times

Small change for the player.
Most of the changes are in preparation for further upgrades.

Apply diff-files in filename order.

[Eddi]

you should probably grey out the buttons for the not buildable ones

[Deranged Bitfiddler]

you should probably grey out the buttons for the not buildable ones

That would be annoying later, when the list becomes an actual type-picker instead of the current action-button-like behaviour.