Skip to content

Loom (Alpha) #2 of 4: data loading + atlas boot surface#293

Closed
CoreyRDean wants to merge 1 commit into
developfrom
coreyrdean/loom-atlas
Closed

Loom (Alpha) #2 of 4: data loading + atlas boot surface#293
CoreyRDean wants to merge 1 commit into
developfrom
coreyrdean/loom-atlas

Conversation

@CoreyRDean
Copy link
Copy Markdown
Collaborator

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.bb includes 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-file ServerLoadArea walk of Data\Server Data\Areas\. Failures RuntimeError with a Win32 dialog -- same behavior GUE has.

Atlas surface (src/Modules/Loom/Atlas.bb):

  • Grid of zone cards, each showing zone name + portal / spawn / trigger counts (walked from the Area type's fixed-size arrays).
  • Hover state lifts the card border from brass to arcane blue.
  • Click selects the zone; selection round-trips as Handle(Area) so PR #3's world view can recover the typed reference via Object.Area(handle).
  • Top brand ribbon: ""LOOM / World Atlas"" on the left, project's leaf folder name centered.
  • Footer: zone count + Esc-to-exit hint.
  • Empty-state copy for projects with no zones yet.
  • Selection toast in bottom-left confirms the click (placeholder feedback until PR #3 hands off to the world view).

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 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.

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) LoomRenderSplash function.
  • src/Modules/Loom/Atlas.bb: new file.
  • No existing module modified.
  • All five engine targets compile clean. Loom.exe grew from ~2.0 MB (skeleton) to ~2.3 MB (with data layer).

Test plan

  • Run compile.bat -- builds clean.
  • In Project Manager, open a project that has at least one zone, click Loom (Alpha).
  • Loading screen flashes briefly (data loaders run).
  • Atlas appears: top ribbon with project name, grid of zone cards, footer with zone count + Esc hint.
  • Hover a card -- border lifts to arcane blue.
  • Click a card -- bottom-left toast shows the selected zone name.
  • Click a different card -- toast updates.
  • Press Esc -- window closes.
  • Check Data/Logs/Loom Log.txt -- logs every load step + the atlas-selection events.
  • Open a project with no zones (or rename Data\Server Data\Areas\) -- empty-state copy shows.

🤖 Generated with Claude Code

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>
@CoreyRDean CoreyRDean requested a review from a team as a code owner May 26, 2026 21:47
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread src/Modules/Loom/Atlas.bb
Comment on lines +155 to +157
For t.AtlasTile = Each AtlasTile
t\X = gridX + col * (ATLAS_TILE_W + ATLAS_GAP)
t\Y = gridY + row * (ATLAS_TILE_H + ATLAS_GAP)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

@CoreyRDean CoreyRDean deleted the branch develop May 27, 2026 00:02
Base automatically changed from coreyrdean/loom-skeleton to develop May 27, 2026 00:02
@CoreyRDean CoreyRDean closed this May 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant