Factorio Forums

Hi,

this new scroll-pane GUIelement is great ! No need to implement pages on lists anymore.

But would it be possible to read/write the vertical (and horizontal) position of the pane ?
Maybe like GUIelement.set_pane(vertical,horizontal) when vertical,horizontal are in [0,1] range ?

Because sometimes, when the user click something in the GUI, I want to show him a specific item of a big list which is in a scroll-pane.

Or sometimes, if you have to refresh/rebuild the inside of the scroll-pane, you want to reposition it at the same place than before, so that the user does not see the difference, otherwise the scrool-pane always come back to its 0 position...

I reup this thread.
I use these new scroll pane that are very handy, but I often need to read or write their position, when I need to recrate the list and position it at the same position than before. Or if I want to show the end of the list just after creating it.

Scroll-pane!? It seems that something is missing on the API document.
I wonder if it can be used as a simple scrollbar when its position supports read/write (e.g. for the color picker )

I thought scrolling was done now using a frame with the scroll policy set as applicable?

Being able to read/write the scroll position on anything that scrolls is pretty vital requirement tho...

The issue is the scroll position isn't saved anywhere and isn't part of the game state so there's no easy way to give read access to it that wouldn't cause desyncs.

I could probably add a method that does something like: "scroll_into_view(GUI element)" where it would scroll that specific item into view. Would that work?

Rseding91 wrote:I could probably add a method that does something like: "scroll_into_view(GUI element)" where it would scroll that specific item into view. Would that work?

Yes. I could handle what I need with this feature.

an scrollingElement.is_in_view(guiElement) would also be useful - eg. to avoid doing updates on elements that aren't in view.

aubergine18 wrote:an scrollingElement.is_in_view(guiElement) would also be useful - eg. to avoid doing updates on elements that aren't in view.

Again that has the same problem: widget positions aren't saved in the game file so it would lead to desyncs if that information was used incorrectly (which it almost always would be).

Posting in correct topic this time:

Out of curiosity, why does the GUI get included in MP game state? Surely it's the actions that arise from the GUI (such as updating an element or item on the map, etc) that matter and not the front-end UI the user used to trigger those actions?

As far as I understood, game desync is detected by comparing clients memory in a brute way.
And only user's control inputs (mouse clicks, keys) are transmitted to other clients.
Mod actions modifying GUI inplace of the user would not be transmitted to other clients, leading to desync.

Rseding91 wrote:

aubergine18 wrote:an scrollingElement.is_in_view(guiElement) would also be useful - eg. to avoid doing updates on elements that aren't in view.

Again that has the same problem: widget positions aren't saved in the game file so it would lead to desyncs if that information was used incorrectly (which it almost always would be).

What about an on_gui_scrolled event?
I guess you know the scrollbar position when the player scrolled it? But don't know whether this will affect game performance.

more likly a on_scrollbar_released(LuaGuiItem, position) event.

aubergine18 wrote:Posting in correct topic this time:

Out of curiosity, why does the GUI get included in MP game state? Surely it's the actions that arise from the GUI (such as updating an element or item on the map, etc) that matter and not the front-end UI the user used to trigger those actions?

They're thinking modders would be too stupid to use client sided gui + custom synchronization correctly, and force everyone on a more restrictive system so it can't be done wrong.

steinio wrote:more likly a on_scrollbar_released(LuaGuiItem, position) event.

If you look into the RGB value bars for changing locomotive color, the scrollbars can update the textfields whenever they are scrolled and before they are released.
But this can be the solution if the on scrolled event is causing trouble on game performance.

I have implemented this for 0.17.19 (I have source access).
Includes: scoll_to_left, scroll_to_right, scroll_to_top, scroll_to_bottom, and scroll_to_element, and works for both scroll-panes and text-boxes.
If you think a scroll_to(x, y) would be useful, please make a new request topic for it.