A Rain World HUD owns a list of parts and calls each part’s update, draw, and cleanup methods. The extension type is global::HUD.HudPart, and the owning object is global::HUD.HUD. Add a part with global::HUD.HUD.AddPart(global::HUD.HudPart) so it participates in that lifecycle.
| Member | Role |
|---|---|
HudPart(HUD hud) | Receives the owning HUD |
hud | Retains that owner |
slatedForDeletion | Requests cleanup and removal on a HUD update |
Update() | Changes the part’s logical state |
Draw(float timeStacker) | Positions its visual objects |
ClearSprites() | Removes the part’s visual objects |
A part should create and retain the objects it needs for drawing, change logical state in Update(), place or interpolate visuals in Draw(float timeStacker), and remove its sprites or other visual objects in ClearSprites(). Drawable lifetime covers the related drawable cleanup rules. Use Camera coordinates when converting room positions into positions for a camera-owned overlay.
Lifecycle in the HUD
global::HUD.HUD.Update() walks its parts list backwards. When a part has slatedForDeletion == true, the HUD calls ClearSprites() and removes that part from the list. Otherwise, it calls the part’s Update(). global::HUD.HUD.Draw(System.Single) calls Draw on every remaining part. global::HUD.HUD.ClearAllSprites() calls ClearSprites() on all parts.
This gives a part two cleanup routes. Set slatedForDeletion when the part itself has reached the end of its useful lifetime. Also make ClearSprites() safe when the containing HUD clears all visuals during a broader transition. The static source establishes that both routes call cleanup. It does not establish how a custom sprite API reacts to duplicate removal, so keep ownership inside the part and test transition behavior with the exact visual objects it creates.
Call hud.AddPart(part) once after constructing the part. Keeping an object elsewhere without adding it leaves it outside the HUD’s update, draw, and removal loops. Repeated attachment can create duplicate overlays, so the hook or owner that creates the part should check whether its intended instance already exists.
Choose the owner before attaching
global::RoomCamera exposes a public global::HUD.HUD hud field, but a camera is not proof of a player HUD. global::HUD.HUD.OwnerType includes player, sleep screen, death screen, fast travel, arena, character select, and other contexts. A gameplay overlay should inspect the HUD owner or attach from a hook point already known to create the intended player HUD.
The ownership choice affects multiplicity:
- One part per camera gives each camera its own visual state.
- One part per player needs a verified mapping from the HUD or camera to that player.
- One shared session part needs an owner whose lifetime matches the session rather than one camera.
Choose one ownership model for the tested context. Cooperative play can have multiple cameras and player-specific HUD parts. A single global guard may suppress a needed part on a second camera, while an unconditional camera hook may add duplicates when a HUD is rebuilt.
The inspected global::HUD.HUD constructor takes FContainer[], global::RainWorld, and global::HUD.IOwnAHUD. The evidence does not establish a universal constructor hook or the point at which every RoomCamera.hud becomes non-null. Keep attachment guidance tied to a tested game context instead of assuming that every camera constructor has a ready player HUD.
Connect settings, input, and text
A HUD part may read ordinary mod state during Update(). For example, a future hint overlay could skip visual work when the showHint value from Remix settings is false and map hintOpacity from 0 through 100 to its own alpha calculation. The compiled Remix example only defines those controls. It contains no HUD hook, part, or hint drawing code.
For a prompt that reacts to a game action, detect the action edge using Player input and let the part own the resulting display timer. Keeping input detection and display lifetime separate avoids tying sprite cleanup to whether a button remains held. Text shown to the player can pass through the translator behavior in Localized text, with a shipped English fallback key.
Runtime checks
This page is source verified for build 22785462. No custom HudPart was run in the game. Before publishing an attachment recipe, test it in single player and split-screen cooperative play. Record how many parts are created, which owner type each HUD reports, and whether ClearSprites() runs on room changes, process changes, death, and camera removal. Also test disabling the mod if the chosen hook can remain subscribed across plugin lifecycle changes. Hook lifecycle explains named subscription removal and repeatable Rain World initialization.
Sources
global::RoomCamera.hud,global::HUD.HUD,global::HUD.HUD.AddPart(global::HUD.HudPart),global::HUD.HUD.Update(),global::HUD.HUD.Draw(System.Single),global::HUD.HUD.ClearAllSprites(), andglobal::HUD.HudPartinAssembly-CSharp.dll, SHA-256B6BE1D4E18CE219D21091B51564CB6A11C1E4106B41DE903EB8E58849CB16FDB. See Runtime reference.