Page 1 of 1

Access to the style of child flow of frames

Posted: Mon Sep 15, 2025 5:54 am
by Osmo
What?
Ability to access the agui flow's style properties that is created as an element inside every frame. Doesn't need to be a LuaStyle, just margin and padding would cover most of the cases.
Why?
When LuaGuiElement of type frame is created, a child agui flow is created which is used to contain child elements of the frame. This is fine, but a problem arises when you need to change the style of the flow. More specifically, 90% of the time its margin/padding that needs to be changed.
However mods have no access to that, and changing margin/padding on the frame usually doesn't have the desired effect.
I've seen people add another flow to the frame and changing its style just to compensate for the agui flow's margin/padding, which needs to be "reverse engineered", which might not always be possible with the Ctrl+F6 style debug tool. Doing this everywhere is a major annoyance and requires extra time. Creating a style at data stage is another workaround, but doing it every time you want to change 2 numbers, in a system otherwise very hot-reloadable, for a thing that there may be only one of, is very time consuming and requires extra effort.
Tiny rant
This is something that has been bugging me for a long time, and i see other modders having problems it as well. It adds a lot of friction to the experience and can't be reasonably aleviated in a form of a library.
I completely understand if this requires a lot of effort in the current system, but having a request doesn't hurt. Thank you for all the work you do.

Re: Access to the style of child flow of frames

Posted: Mon Sep 15, 2025 12:49 pm
by EvilPLa
You know about this option?
09-15-2025, 14-49-54.png
09-15-2025, 14-49-54.png (50.51 KiB) Viewed 590 times
Edit: nvm, you want it a runtime.

Re: Access to the style of child flow of frames

Posted: Mon May 11, 2026 11:22 pm
by Rseding91
I was actually looking at adding support for this recently but ran into one major issue:

* The way styles are implemented for mod GUIs means these "sub styles" are never actually set for mod GUI elements. The sub styles *always* refer to some style defined in the global "data.raw.style.default" listing. That combined with how GUI elements *read* style values means if runtime you asked to write one of these values the engine would need to create a completely empty sub-style and require you set the parent + any specific values you want set that differ from the default(s).

Example:

* You have a frame style that has a parent of "shallow_frame"
* "shallow_frame" has horizontal_flow_style defined
* If you ask the engine to let you modify "horizontal flow style" for your frame it can't let you modify the global "shallow_frame" so it would need to make an empty horizontal_flow_style on your elements style and then let you modify that.

At that last step it would lose any values that "shallow_frame" had set on its instance of "horizontal_flow_style" over the defaults since it's now un-bound from shallow_frame.

Does that make any sense?