Loom (Alpha) #2 of 4: data loading + atlas boot surface#293
Conversation
Wires GUE's data-layer modules into Loom and replaces the skeleton's
splash loop with a clickable zone atlas. Loom now opens the same kind
of project GUE opens, reads the same .dat files through the same
loaders, and shows every zone as a card the user can click.
Includes added (same modules GUE pulls in, in the same order):
RCEnet, Media, MediaImport, Projectiles, Language, Items, Inventories,
Animations, Spells, Actors, Environment, Interface, ServerAreas,
Packets, Logging.
Deliberately omitted:
- MediaDialogs.bb / CharacterEditorLoader.bb -- F-UI-tied editing
surfaces, not needed for a read-only data layer.
- ClientAreas.bb -- depends on GetFilename$, which lives inside
GUE.bb itself (not in a shared module). ClientAreas loads the 3D
zone mesh; we don't need that until PR #3, at which point I'll
either extract GetFilename$ to a shared helper or define a Loom-
side mesh loader.
- F-UI -- still not pulled in. The atlas is custom-drawn through
Theme.bb, hit-tested with raw MouseX/Y. F-UI shows up in PR #3
only for surfaces that need text input or native file dialogs.
Atlas surface (src/Modules/Loom/Atlas.bb):
- Grid of zone cards, each showing the zone name and portal /
spawn / trigger counts (walked from the Area type's fixed-size
arrays, same pattern the prior Loom-on-GUE atlas used).
- Hover state lifts the card border from brass to arcane blue.
- Click selects the zone; the selection round-trips as Handle(Area)
so PR #3's world view can recover the typed reference via
Object.Area(handle).
- Top brand ribbon shows "LOOM / World Atlas" on the left and the
project's leaf folder name centered.
- Footer shows the zone count and an Esc-to-exit hint.
- Empty-state copy when a project has no zones yet.
- Selection toast in the bottom-left confirms which zone was clicked
(placeholder feedback until PR #3 hands off to the world view).
Boot flow (src/Loom.bb):
1. Bootstrap globals + ChangeDir to project root (unchanged from PR #1)
2. Open Blitz3D window + start log
3. Loom_DrawLoadingScreen("Loading project data...")
4. Run every Load* call in GUE's order; RuntimeError on failure
(mirrors GUE.bb's expectation that the project's .dat files exist)
5. Atlas_Init() builds the tile list from `Each Area`
6. Per-frame: Atlas_RenderAndUpdate returns Handle(Area) on click
7. Esc exits cleanly
All five engine targets (Server, Client, Project Manager, GUE, Loom)
compile clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 50d39965cf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| For t.AtlasTile = Each AtlasTile | ||
| t\X = gridX + col * (ATLAS_TILE_W + ATLAS_GAP) | ||
| t\Y = gridY + row * (ATLAS_TILE_H + ATLAS_GAP) |
There was a problem hiding this comment.
Add scrolling or paging for atlas tiles
The atlas layout keeps incrementing row and t\Y for every zone but never adds any vertical scrolling/paging or clipping-aware hit testing, so projects with more zones than fit in one screen render extra cards below the viewport where the user cannot hover or click them. At the default Loom window size this means only the first screenful of zones is actually selectable, which breaks the atlas’ role as a full project zone picker.
Useful? React with 👍 / 👎.
Summary
Second of four PRs building the Loom alpha. Stacked on top of #292 (loom-skeleton).
Wires GUE's data-layer modules into Loom and replaces the skeleton's splash loop with a clickable zone atlas. Loom now opens the same kind of project GUE opens, reads the same .dat files through the same loaders, and shows every zone as a card the user can click.
What's in
Data layer (
src/Loom.bbincludes block) -- the same modules GUE pulls in, in the same order:RCEnet,Media,MediaImport,Projectiles,Language,Items,Inventories,Animations,Spells,Actors,Environment,Interface,ServerAreas,Packets,Logging.Plus the loader sequence on boot:
LoadDamageTypes->LoadAttributes->LoadFactions->LoadAnimSets->LoadProjectiles->LoadItems->LoadActors->LoadSpells-> per-fileServerLoadAreawalk ofData\Server Data\Areas\. FailuresRuntimeErrorwith a Win32 dialog -- same behavior GUE has.Atlas surface (
src/Modules/Loom/Atlas.bb):Areatype's fixed-size arrays).Handle(Area)so PR #3's world view can recover the typed reference viaObject.Area(handle).What's deliberately NOT in
MediaDialogs.bb/CharacterEditorLoader.bb-- F-UI-tied editing surfaces, not needed for a read-only data layer.ClientAreas.bb-- depends onGetFilename$, which lives insideGUE.bbitself (not in a shared module). ClientAreas loads the 3D zone mesh; we don't need that until PR #3, at which point I'll either extractGetFilename$to a shared helper or define a Loom-side mesh loader.Theme.bb, hit-tested with rawMouseX/Y. F-UI shows up in PR #3 only for surfaces that need text input or native file dialogs.Blast radius
src/Loom.bb: include block expanded + boot flow now runs data loaders and the atlas loop instead of the splash loop. Removed the (now dead)LoomRenderSplashfunction.src/Modules/Loom/Atlas.bb: new file.Test plan
compile.bat-- builds clean.Loom (Alpha).Data/Logs/Loom Log.txt-- logs every load step + the atlas-selection events.Data\Server Data\Areas\) -- empty-state copy shows.🤖 Generated with Claude Code