Add Radar paths to Ritual altars

[LostPoE]

Radar had no target entry for Ritual altars, so it drew no path to them.

Target choice

Targets Metadata/Terrain/Leagues/Ritual/RitualRuneObject, not RitualRuneInteractable.

An altar is three co-located entities. The interactable is an IngameIcon that only loads within roughly 160 grid units, while the terrain object loads at 490+. Targeting the interactable would only draw a route once you were already standing on the altar, which defeats the point of having one.

ExpectedCount: 99 keeps each altar as its own cluster rather than averaging several into a single midpoint that sits on none of them — the same approach as the existing Sanctum lever entry.

Retiring the route

The entity watch in AddRoute needed two changes.

An altar is not a chest. It has no Chest component, and its entity stays valid for the rest of the map once the ritual has been run, so IsOpened could never retire its route. The completed state has to be read off the state machine. current_state, traced through one altar's entire life in a map:

state	meaning
0	pack around the altar still alive, interaction_enabled=0, not clickable
1	pack dead, interaction_enabled=1, ritual can be started
2	ritual running, interaction_enabled=0 again
3	done, the zone's rituals_completed increments, isTargetable goes false

Only 3 retires the route. States 0 and 2 are both unclickable but still worth walking to, so keying removal on clickability (interaction_enabled / isTargetable) would erase the path for most of the altar's life — precisely when it is most useful.

The watch cannot stay bound to the entity it was handed. The client only keeps entities within roughly 250 grid units per axis, and a map's altars sit much further apart than that, so walking toward one unloads the others. The existing entity.IsValid condition then retired their routes, and EntityAdded would not rebuild them on reload because their positions were already in _allTargetLocations — so every altar you walked away from lost its path permanently.

Altars are therefore looked up by entity id in the live entity list on each poll. Ids survive the unload where the captured reference does not, and an altar that is not currently loaded reads as unobservable rather than finished. Chest behaviour is unchanged: for those, an invalid entity is still gone for good.

This one is worth a look from someone who knows the intent of the original IsValid check — it was harmless for the existing entity targets (an Expedition encounter at ExpectedCount: 1, Sanctum levers all within one room), and Ritual altars are the first target spread far enough apart to trip it. If it is load-bearing for something I have not spotted, the narrower fix is to make the invalidity rule conditional on the target rather than on the entity type.

Verification

The state table was read off a live client rather than inferred: one altar's state machine was polled every 2s from spawn through completion. The culling behaviour is from the same capture — one altar was observed loaded, then absent for four minutes while the player moved away, then loaded again under the same entity id.

Tested in a real Ritual map: routes to every altar appear while their packs are still alive, survive walking across the map to another altar, and only the completed altar's route clears. Builds clean against ExileCore2.

🤖 Generated with Claude Code