[kovarex] [0.16.25] Disabled GuiElement is no longer click-through.

[eradicator]

I just noticed that unlike in 0.15.x disabling a gui element does no longer make the mouse click "through" the disabled gui element. As a demonstration i created a button with a disabled label on top of it:

code

Code: Select all

--0.15x
/c
a = game.player.gui.center
a.clear()
b = a.add{type='sprite-button',style='slot_button_style',sprite='item/iron-ore'}
c = b.add{type='label',enabled=false,caption=10}

--0.16.x (different style name)
/c
a = game.player.gui.center
a.clear()
b = a.add{type='sprite-button',style='slot_button',sprite='item/iron-ore'}
c = b.add{type='label',enabled=false,caption=10}

In 0.15 the full button is clickable and the disabled label is simply ignored by the mouse cursor. Further disabling the button itself makes it possible to interact with normal in-world entities through the button.
In 0.16 the label always blocks the cursor interaction with the button below it regardless of if the label is enabled or not. This creates some ugly user interaction as the button becomes visibly "unclickable" when the unknowing user accidentially hovers over the label part of the button.

clickability.png (16.1 KiB) Viewed 5426 times

Expected behavior: Disabled GuiElements should be ignored for cursor interaction. The button is just an example. Id should work for all types like before.

[kovarex]

I know about the change, and to be honest, I don't think that disabled things should be ignored in this way.
Why do you need the label to be disabled? If the label isn't disabled it works as you want to right?

[eradicator]

The goal for the button example is to mimick a standard factorio inventory slot button like they're used for example in the inventory/hotbar to show an icon and a number, i.e. the stack size in case of the inventory.

If i try to mimick that by attaching a label to a sprite-button then the label blocks interaction with the sprite button. I.e. the player can't click the sprite-button if they hover over over the label, and the sprite-button does not display it's hovered_graphical_set. Thus i don't as such need the label to be "disabled", i just need it to be non-blocking/click-through, which just happens to be what disabling gui elements used to do.

So in 0.16 attaching a label to a button that way never works the way i need it to regardless of dis/enabled state because the label always blocks interaction with the button below.

(There are also some other cases where i need gui elements to be click-through, like HUD elements that are not supposed to block interaction with the world.)

[eradicator]

Maybe a gif makes it easier to understand? Look how the button doesn't light up when hovering the label.

cursorbutton.gif (1.34 MiB) Viewed 5365 times

[kovarex]

In 0.15, disabling elements made it impossible for the element to be "under mouse".
But this behaviour was changed for 0.16, mainly because it was impossible to create tooltips for disabled elements because of this.

To make it possible to make the "passive" elements, I added the property of ignored_by_interaction{/i] for the next version, which solves this problem, the last line in the code will do what you need.

Code: Select all

/c game.player.gui.center.add{type="sprite-button", style="slot_button", sprite="item/iron-ore", name="button"}
/c game.player.gui.center.button.add{type="label", caption="10", name="label"}
/c game.player.gui.center.button.label.ignored_by_interaction = true

P.S. I didn't even know that it would be possible to add elements into button like this and that it would actually work. It would be nice to provide a way to make it actually look the same way as in vanilla, which means the proper font and proper positioning of the number button.

[eradicator]

Oh, great. Thank's a lot for the ignored_by_interaction! I actually thought about the whole thing and indeed managed to come up with some situations where a disabled element should still be click-blocking, so this is the much better solution. Never thought of tooltips though. Might find a use for that :D.

P.S. I didn't even know that it would be possible to add elements into button like this and that it would actually work. It would be nice to provide a way to make it actually look the same way as in vanilla, which means the proper font and proper positioning of the number button.

Well, what can i say. I requested that feature a year ago but never got any answers, so i got creative and found that weird hack of adding things into buttons. It has a few other very neat uses so i hope nobody decides to "fix" that. Font is easy to mimick, and proper positioning should be possible too now that we have player.display_scale/resolution (before it only worked for 100% scale). But that requries definition of some custom styles, so i chose to ignore that for this bug report in favor of easy reproducability via /c.

Here's what a fixed position offset currently looks like:

fixedposition.jpg (46.66 KiB) Viewed 5266 times

[kovarex]

Well, what can i say. I requested that feature a year ago but never got any answers, so i got creative and found that weird hack of adding things into buttons. It has a few other very neat uses so i hope nobody decides to "fix" that. Font is easy to mimick, and proper positioning should be possible too now that we have player.display_scale/resolution (before it only worked for 100% scale). But that requries definition of some custom styles, so i chose to ignore that for this bug report in favor of easy reproducability via /c.

Here's what a fixed position offset currently looks like:

fixedposition.jpg

This looks better, but it is still far from perfect.
To make it look reasonable, I implemented your request, so now there is LuaSpriteButton::number read/write property. When not 0, it will draw number the same way as vanilla does. It includes the proper positioning and usage of shortNumber format (5K, 1.5M etc.)

[eradicator]

This looks better, but it is still far from perfect.

Well, it's a fixed offset as i said. I haven't had the time to implement the proper dynamic positioning that considers string length, resolution and display scale. But...

To make it look reasonable, I implemented your request, so now there is LuaSpriteButton::number read/write property.

Apparently now i don't need to do that anymore and can just use built-in functionality . Which will also hopefully benefit many other mods. How does that work internally btw, is it also a label or some secret magic?

When not 0, it will draw number the same way as vanilla does. It includes the proper positioning and usage of shortNumber format (5K, 1.5M etc.)

Does it format numbers with decimal places like vanilla does too?

percentage.png (24.39 KiB) Viewed 5212 times

PS:
Also "while your at it" (tm) (yes, now i'm beein greedy) there might be some situations where LuaSpriteButton::string read/write would have some applications....

[kovarex]

This looks better, but it is still far from perfect.

Well, it's a fixed offset as i said. I haven't had the time to implement the proper dynamic positioning that considers string length, resolution and display scale. But...

To make it look reasonable, I implemented your request, so now there is LuaSpriteButton::number read/write property.

Apparently now i don't need to do that anymore and can just use built-in functionality . Which will also hopefully benefit many other mods. How does that work internally btw, is it also a label or some secret magic?

This number is not viewed as a gui element internally, it is rendered "on the fly" as part of our SpriteButton implementation.

When not 0, it will draw number the same way as vanilla does. It includes the proper positioning and usage of shortNumber format (5K, 1.5M etc.)

Does it format numbers with decimal places like vanilla does too?

It does not by default, but we use an option (we call it showPercentForSmallNumbers), I can make the option available in the mod api easily.

percentage.png

PS:
Also "while your at it" (tm) (yes, now i'm beein greedy) there might be some situations where LuaSpriteButton::string read/write would have some applications....

What do you mean by the string read/write? You mean, that you would like to have access to the number -> shortNumberFormat method?

[kovarex]

So I added both to 0.16.28:

Code: Select all

- Added LuaGuiElement::ignored_by_interaction which prevents the elements from stealing mouse interaction with the parent elements. (https://forums.factorio.com/58127)
- Added LuaSpriteButton::number which allows the number to be rendered in the standard way in the right-bottom corner of the sprite button.
- Added LuaSpriteButton::show_percent_for_small_numbers which, when set to true, forces the number to be shown as percent when smaller than 1.

I'm aware, that you won't need the ignored_by_interaction now, but it might be actually useful for some different cases.

[eradicator]

PS:
Also "while your at it" (tm) (yes, now i'm beein greedy) there might be some situations where LuaSpriteButton::string read/write would have some applications.... :mrgreen:

What do you mean by the string read/write? You mean, that you would like to have access to the number -> shortNumberFormat method?

I meant that sometimes it might be useful to display a string/word in the button corner instead of a number. Less of a feature for inventory immitation, but quite useful for other GUI buttons. Here's a very crude example (which ofc would need proper icons and not iron ore...)

stringbutton.png (4.96 KiB) Viewed 5150 times

So I added both to 0.16.28:

Code: Select all

- Added LuaGuiElement::ignored_by_interaction which prevents the elements from stealing mouse interaction with the parent elements. (https://forums.factorio.com/58127)
- Added LuaSpriteButton::number which allows the number to be rendered in the standard way in the right-bottom corner of the sprite button.
- Added LuaSpriteButton::show_percent_for_small_numbers which, when set to true, forces the number to be shown as percent when smaller than 1.

Great! Awesome infact :D.

I'm aware, that you won't need the ignored_by_interaction now, but it might be actually useful for some different cases.

I very much still need that for HUD elements as i mentiond briefly above :D. Thanks for that too :D