Repository navigation
Fit the signal grid to the screen instead of running off it - #4
Merged
Merged
Conversation
A reader aggregating a whole network produced a fixed 8-column table with no scroll pane and no height cap, so the window grew one row per 8 signals until it ran off the bottom of the display. On a pY-sized network that is 100 rows, of which only about a third are reachable at any window position. Widening alone does not fix it: 800 signals still needs 24 columns to fit at 1080p, and a fixed width that wide is absurd for a reader showing three signals. So the grid sizes itself, with no knobs: - The table lives in a scroll-pane capped at 60% of screen height, rounded down to whole rows so no row is cut in half. - Column count is derived from the signal count, clamped to what the screen allows. Small readers stay exactly as compact as before; large ones widen to the cap and then scroll. Three problems that only bite at that scale come along with it: - update_signal_display cleared and refilled the table on every update, which would reset the scroll position twice a second and rebuild hundreds of elements. Buttons are now updated in place and only the surplus destroyed. - Section 2 is rebuilt from a hash table each update, so signal order drifted between refreshes. Entries are sorted into prototype order, keyed by type, name and quality so the order is total and identical on every client. - The prototype lookup behind each button had no nil guard, so opening a reader whose stored output named an item from a removed mod raised. force_auto_center now runs after the grid is populated; centring the empty window first left it hanging off the bottom as the rows arrived. Also drops the dead cybersyn_content_reader_signal_display style, which hardcoded the 280x300 geometry this replaces, along with the stale commented-out scaffolding and a duplicate button.number assignment. Verified against a graphical 2.1.7 host at 3600x2025 / 1.5 UI scale: 8 signals render 8x1 as before, 60 render 10x6, 800 render 24 columns capped at 20 visible rows with all of them reachable by scrolling, and 1502 behave the same. Suite is 9/9. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A47dkZVVahTZsepP8LnbLM
danbopes
force-pushed
the
signal-grid-fit-to-screen
branch
from
August 1, 2026 15:55
9230988 to
43d1635
Compare
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.
Addresses the report that the signal window does not fit on screen in pY.
The problem
The grid was a fixed 8-column table with no scroll pane and no height cap, so the window grew one row per 8 signals without bound. Measured on a graphical 2.1.7 host at 3600x2025 / 1.5 UI scale:
y=0At 800 signals the old window sat at
y=0and ran off the bottom with roughly a third of the rows reachable and no way to get at the rest.Approach
Widening alone does not solve it. 800 signals still needs 24 columns to fit at 1080p, and a window that wide is absurd for a reader showing three signals. So the grid sizes itself, with no settings to configure:
scroll-panecapped at 60% of screen height, rounded down to whole rows so none is cut in half.Rode along
Three things that only bite at this scale:
update_signal_displaycleared and refilled the whole table each update, which would reset scroll position twice a second and rebuild hundreds of elements. Buttons are now updated in place, surplus destroyed.Also fixed
force_auto_centerrunning before the grid was populated, which centred the empty window and left it hanging off the bottom as rows arrived.Net diff is three files:
gui.lua,gui-styles.lua(drops the deadcybersyn_content_reader_signal_displaystyle that hardcoded the 280x300 geometry this replaces), andchangelog.txt.Verification
Suite is 9/9 (
./factorio-test.py cybersyn-content-reader). Screenshots taken against a live graphical host at each of the sizes in the table, including scrolled-to-bottom at 800.Not exercised end-to-end: scroll position surviving a live
Update_Combinatorcycle. That needs a tracked reader, whose section 2 gets overwritten from real Cybersyn state each tick, which would wipe the synthetic signals. The change is structural (no moreclear()), but I did not watch it happen in game.Versioning
Stays on the pending
1.1.1. Only1.1.0is tagged on the remote, so theVersion: 1.1.1 / Date: ????block is fmtk's post-release stub from shipping 1.1.0 and was never published; these entries belong in it.🤖 Generated with Claude Code
https://claude.ai/code/session_01A47dkZVVahTZsepP8LnbLM