New GUI root for temporary GUI elements

[MagmaMcFry]

Recently I've added a preview feature to Factorissimo2 that allows you to see what's inside your factory buildings by hovering over them. This creates a new camera GUI element, but I'm faced with the problem of where to put it. If I put it in gui.top, or gui.left, it will either be to the right of a bunch of buttons, or push a bunch of buttons out of the way. Furthermore, hovering over a GUI element clears player.selected, which means that hovering over a factory building in the top left corner of your screen will cause flickering as on_selected_entity_changed gets fired each tick (I could manually prevent that from happening by adding GUI update cooldown, but that would be inelegant and impact the functioning of the general case where your mouse isn't in the corner of your screen).

My wish: I'd like a new GUI root (maybe in the bottom left) designed for short-life GUI elements (for extended info about hovered entities, for example). It should be

• rendered above the other GUIs,
• transparent to the cursor, i.e. doesn't affect player.selected and isn't clickable (both to prevent flickering issues when you hover over something, and to discourage other mods from using that root for more permanent GUI elements),
• without element packing (i.e. render each of its toplevel children in the bottom left corner, all on top of each other).

[kumpu]

+1. I would very much like a bottom left gui root. My use-case would be some gauges for vehicles (fuel, etc.).

[eradicator]

Bottom left sounds like a bad idea as that's where the crafting queue goes. Base game uses the right side for hover info, and i've always wanted to be able to add additional info to that. Even if it's by creating yet another frame between the minimap and the normal tooltip.

The ability to have "click through" gui elements would be useful for other things too, not just tooltips.

[kumpu]

Bottom left sounds like a bad idea as that's where the crafting queue goes.

You're right, but why not have the possibility and let the modders worry about that. It's good to have options

[kumpu]

Any word on this from the devs? I could really make use of this!

[eradicator]

Bottom left sounds like a bad idea as that's where the crafting queue goes.

You're right, but why not have the possibility and let the modders worry about that. It's good to have options 8-)

Because in most cases i've seen i don't like the outcome of that worrying :P

Any word on this from the devs? I could really make use of this! :D

Don't hold your breath. Even if this was implemented it would have a 99% chance to come after the gui rewrite, aka 0.17.

[kumpu]

Bottom left sounds like a bad idea as that's where the crafting queue goes.

You're right, but why not have the possibility and let the modders worry about that. It's good to have options

Because in most cases i've seen i don't like the outcome of that worrying

Can't see any reason why modders shouldn't be allowed to screw up; worst case is that the mod gets uninstalled. Right?
There are enough limits to what is possible already.

Any word on this from the devs? I could really make use of this!

Don't hold your breath. Even if this was implemented it would have a 99% chance to come after the gui rewrite, aka 0.17.

Guess you're right... Any idea when that will come out? 0.16 is not even officialy stable...

[kumpu]

Listen up guys, you fail to realize what's at stake here.

Img

Look at it! It's in the wrong corner! Unacceptable.

Either way, if you won't implement this, I'll have to make some terrible hacks. It will probably involve breaking an entire gui root, bringing down other mods with it.
So you see, there really is no choice here.

[Klonan]

Some additional customGui has been wanted for a while,
So instead of:

Code: Select all

player.gui.center.add(gui)

You would make your own root gui:

Code: Select all

player.gui.add(gui)

And then you would be able to align it and put it wherever you want

One problem is that mods would not really know about where other mods Gui's are, so it will be a big pickle mess even more than the current GUI system

[kumpu]

I see, that would be great to have. But I understand it's a bit much asked for, couldn't think of any good way to keep it organized.
That wasn't McFry's and mine idea though - wouldn't giving us just more corner access be (relatively) easy?

[eradicator]

@Klonan:
Would that make the custom roots also movable by the player? That would bring me one big step closer to mimicking vanilla GUI elements. As long as you keep the top/left elements for more common things like tiny buttons. Would mods be allowed only one additional root or could they make several in different positions?
Maybe you could add a list of other-mods currently occupied space or a "would this overlap with something else" function. Though...even if it overlapped, if there's nothing that can be done about it i guess i'd have to display it anyway. I would only use it for things that the player has direct control over opening/closing. And it might bring the current mod button style chaos to the tooltip window :x. Hm. Maybe only allow it for responsible modders /joking.

Things i'd really like to do:

1. Movable vanilla style guis.
2. Adding additional bars above the current ones (health/shield) that properly align and stack with the others.
3. Adding custom tooltips (on_selected) to custom entities. (might be even more awesome if it was possible to make them appear "in world"...that might actually be possible with a "place anywhere" root).
4. Adding a large temporary click-through center gui element to display an on-screen overlay.

For none of those i care how those are implemented. And for each one i'd be pretty happy if they were possible (4 was possible in .15 i think).

[kumpu]

I hope you don't mind if I add my $0.02 to this, as i get it this is a good opportunity to make suggestions while you guys rework the gui system.

What comes to my mind is that this is the same problem any operating system's gui faces. How do they deal with it? Windows, dragging, taskbar.
So how about you keep the current fixed root setup, for logical groops that should be aligned together, and for legacy.
But additionally each mod gets its own "layer". There they can go nuts, create custom roots while not affecting anyone else. Their roots can be dragged. A little icon opens a menu where you can toggle layer visibility or bring a layer into foreground, should it be neccessary.

+ Some neat api functions - setFocus, findFreeSpot, read access to other layers...

[Rseding91]

Since support was added to read the display size for a given player through script that means I could make game.player.gui.screen.add {... } a thing. In that case you would need to tell the game what exact x/y you wanted the window located at and it would do so.

Most likely it wouldn't be in 0.16 but some new system for 0.17 to handle how it would all work isn't out of the question.

[kumpu]

Since support was added to read the display size for a given player through script that means I could make game.player.gui.screen.add {... } a thing. In that case you would need to tell the game what exact x/y you wanted the window located at and it would do so.

Most likely it wouldn't be in 0.16 but some new system for 0.17 to handle how it would all work isn't out of the question.

That would be great!

[eradicator]

That sounds nice! :D
How about the ability for the players to move a window (vanilla gui has it, so it always feels akward if center guis don't), maybe with an optional parameter to disallow it (LuaGuiElement.allow_dragging=false) for elements that are supposed to go on the .screen borders? (I.e. how feasible is it at all to make mod windows draggable.)

[GalactusX31]

I know that this is to open a necro-post, but being able to move GUI windows of mods as well as it can be done with the gui windows of the game, would be great.

That sounds nice!
How about the ability for the players to move a window (vanilla gui has it, so it always feels akward if center guis don't), maybe with an optional parameter to disallow it (LuaGuiElement.allow_dragging=false) for elements that are supposed to go on the .screen borders? (I.e. how feasible is it at all to make mod windows draggable.)

[eradicator]

Since support was added to read the display size for a given player through script that means I could make game.player.gui.screen.add {... } a thing. In that case you would need to tell the game what exact x/y you wanted the window located at and it would do so.

Most likely it wouldn't be in 0.16 but some new system for 0.17 to handle how it would all work isn't out of the question.

Bumpy, bumpy. Any progress on the delicious gui.screen.add()?

[ownlyme]

this basically sums up my 2 topics:

make gui element ignore other elements in parent / x/y position of elements
Ability to enhance game gui

+10000000

[ownlyme]

Any response from the devs?
I really need this function

[Klonan]

Its been added for the next version:

Code: Select all

Scripting:
    - Added LuaGui::screen.
    - Added on_gui_location_changed, on_gui_selected_tab_changed, and on_gui_switch_state_changed events.
    - Added LuaGuiElement type "empty-widget", "tabbed-pane", "tab", and "switch".
    - Added LuaGuiElement::add_tab(), remove_tab(), and force_auto_center().
    - Added LuaGuiElement::location, auto_center, drag_target, selected_tab_index, tabs read/write.
    - Added LuaGuiElement::switch_state, allow_none_state, left_label_caption, left_label_tooltip, right_label_caption, right_label_tooltip read/write.
    - Added LuaStyle::badge_font, badge_horizontal_spacing, default_badge_font_color, selected_badge_font_color, disabled_badge_font_color,
      selected_font_color, selected_hovered_font_color, selected_clicked_font_color, strikethrough_color read/write.
    - Added clear_and_focus_on_right_click to LuaGuiElement text-box.
    - Added LuaGuiElement::get_slider_value_step(), get_slider_discrete_slider(), get_slider_discrete_values(), set_slider_value_step(),
set_slider_discrete_slider(), luaSetSliderDiscreteSlider(), set_slider_discrete_values().