Feature Version Overlay - bh679/dungeon-train-mc GitHub Wiki

Version + branch overlay

v0.107.0 β€” PR #147 β€” the in-game HUD now scales with the new HUD slider (X β†’ Options β†’ HUD); ships at 0.4 by default. The title-screen overlay is unaffected β€” it draws before the client config loads, so it stays at vanilla size for legibility. v0.7.0 β€” PR #11 β€” in-game HUD overlay (top-left) v0.8.0 β€” PR #12 β€” mirrored onto the main menu (TitleScreen) v0.34.0 β€” PR #44 β€” in-game HUD now suffixes the closest-train carriage index

Displays Dungeon Train v<version> (<branch>) in the top-left corner both in-game and on the Minecraft title screen β€” useful for spot-checking which build is installed before loading a world. Since v0.34.0, the in-game HUD also appends β€” Carriage: +N showing the player's closest carriage index so you can glance at the top-left and know which carriage you're standing on.

  • Values are baked at build time. build.gradle's processResources task expands mod_version and the current git branch (short SHA on detached HEAD) into src/main/resources/dungeontrain_version.properties. The overlay loads that once on class init and caches the formatted string.
  • In-game HUD (VersionHudOverlay) registers via Forge's RegisterGuiOverlaysEvent on the MOD bus. Respects F1 (hideGui); F3 draws over it, which is intentional.
  • Main menu (VersionMenuOverlay) subscribes to ScreenEvent.Render.Post on the FORGE bus and renders only when the current screen is TitleScreen.
  • Both overlays share a single VersionInfo.DISPLAY constant so the text, coordinates (4, 4), colour 0xFFFFFFFF, and shadowed rendering are identical everywhere.

Carriage index suffix (v0.34.0)

Dungeon Train v0.34.0 (main) β€” Carriage: +3

  • 0 = the origin carriage captured when the train spawned. Positive numbers = carriages forward along +X, negative = behind the origin. Matches the pIdx value the rolling-window manager already uses for everything else.
  • Suffix only renders while you are within NEAR_RADIUS = 128 blocks of a Dungeon Train. Walk further away and the HUD drops back to the plain Dungeon Train v… (…) line.
  • F1 still hides the whole HUD β€” including the suffix.

Data flow

The carriage index lives server-side (the client doesn't run the rolling-window math). The server pushes updates to each near-train player via a thin CarriageIndexPacket whenever their pIdx changes:

TrainWindowManager.updateWindow  β†’  new CarriageIndexPacket(true, pIdx)  β†’  VersionHudOverlay.setCarriageIndex
  • Server piggybacks on the pIdx = floor((local.x βˆ’ shipyardOriginX) / dims.length()) that TrainWindowManager.updateWindow already computes every tick β€” no extra math on the hot path.
  • Raw pIdx, not debounced. The debounced committedPIdx used by the rolling-window manager intentionally lags behind the player's motion to smooth out flapping. The HUD wants the true current value so you can watch it update as you walk, so it reads the raw local.
  • Send-on-change only. A Map<UUID, Integer> LAST_SENT_PIDX in TrainWindowManager tracks the last value pushed per player; no packet is sent on unchanged ticks.
  • Dropout clear. After each tick's sweep of every train ship, a post-pass sends CarriageIndexPacket.absent() to any tracked UUID that wasn't reached by any train this tick β€” covers "player walked outside NEAR_RADIUS" and "trains unloaded". Offline UUIDs are dropped silently.
  • Network protocol bump. Adding CarriageIndexPacket bumped DungeonTrainNet.PROTOCOL_VERSION from "1" to "2". Matching client+server required β€” mismatched versions are rejected by Forge's handshake as per the channel's own contract.

Files

⚠️ **GitHub.com Fallback** ⚠️