Class ModInventoryUiTests
- Namespace
- GrindFest
- Assembly
- GrindFest.dll
The InventoryList example mod's overlay: does it follow the hero's inventory?
This exists because it did not. The overlay read Character.Inventory.Items during render and never
subscribed to anything, so it only redrew when some unrelated poll happened to hand React a different object -
and when that stopped happening, taking an item out of the inventory left the old contents on screen
(reported 2026-09-24: "it doesn't react reactively"). The game's own UI panels subscribe instead
(useObservableList, and [EventfulProperty] + useEventSync for single values), which is what
the mod now does too.
The assertions are the player's view: the strings on the overlay, read out of the UI Toolkit tree with the framework's Ui helpers - the same ones the panel tests use. The action is the player's too (BotHero.Drop), not a poke at the list.
Skips itself when the mod is not installed: the overlay belongs to a MOD, and a project without it has nothing to assert (a skip, not a failure - see DevTestSkipException).
public class ModInventoryUiTests : DevTest
- Inheritance
-
objectModInventoryUiTests
- Inherited Members
Methods
- OverlayFollowsTheSelectedHero()
WHICH hero the player controls has to reach the panel without polling: the overlay binds
Party.SelectedHero, and the party raisesOnSelectedHeroChangedon a real change. The C# half and the UI half are asserted together on purpose - either can look fine while the pair is broken (an event nobody raises re-renders nothing, and a panel that only ever redraws by accident passes a re-read test).Selection is moved by deselecting and selecting again rather than by switching between two heroes: a second hero costs a bot compile and a MaxHeroes fight, and the panel's reaction to the selection is the same event either way. The selection is restored in the finally, so the next test starts where it left.