Make loader crafting GUI persistent to avoid multiplayer latency delay#1574
Merged
Conversation
The loader frame anchored to the controller GUI was created in on_gui_opened and destroyed in on_gui_closed. Script events only run once the input action has made the round trip through the server, while the vanilla crafting menu is latency-hidden and opens instantly, so on slow connections the frame appeared seconds after the menu. The controller frame is now created once per player (on create, join, force change and research finished) and left in place; anchored relative frames show and hide with their target GUI, so it now appears instantly with the crafting menu. The per-entity assembling machine frame keeps the create/destroy cycle and gets its own element name so the two no longer collide. Also adds on_register/on_unregister hooks to the QOL feature framework so runtime toggling via set_loaders draws and removes the persistent frames, and adds tests for the loader GUI. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
grilledham
approved these changes
Jul 11, 2026
grilledham
left a comment
Collaborator
There was a problem hiding this comment.
Makes sense. Decent minor qol improvement.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backstory
Playing on a slow and unreliable internet connection, we noticed the loader panel next to the crafting menu took seconds to appear, shifting the crafting menu over whenever it finally loaded.
Root cause
The vanilla crafting menu is latency-hidden, so the client renders it immediately. The loader frame however was created inside
on_gui_openedand destroyed inon_gui_closed— and script events only run once the open action has made the round trip through the server. On a bad connection that round trip is seconds, so the frame popped in late and re-laid-out the crafting menu when it arrived.Fix
on_gui_openedredraw is kept as a self-healing refresh.on_register/on_unregisterhooks in the QOL feature framework so runtime toggling viaset_loadersdraws and removes the persistent frames instead of leaking them;on_configuration_changedcleanup covers both frames.draw_loader_frame(player.forcewas read before the nil check) and nil-guarded the recipe lookups in the click handlers.Tests
Adds
features/redmew_qol_tests.luafor the in-game test runner: frame drawn/removed on feature toggle, frame persists after the crafting menu closes, frame removed when no loader recipe is enabled, one button per enabled recipe, and the machine frame staying separate and destroyed on close. All five pass in-game. Note: run the suite with the redmew-data mod disabled — the loaders feature intentionally goes inert when that mod provides its own loaders.🤖 Generated with Claude Code