For example, right-clicking on the center slot of a crafting table while standing on it is impossible, since the output of the table blocks it. When there is an output, this is expected, however when there isn't an output, the click to what we want to click on is blocked despite no item actually being there to claim.

This should be fixed by a change that will take place during #273's development.

Although #273 has been merged, this is not fixed, likely due to not having any logic for blocking the output's right-click when it's empty.

This one's actually a bit more tricky.

In short, ClientLogicSubscriber#handleRightClickInfos always returns when the first hitbox click has been handled, even if it returns a negative, "click not handled" cooldown. We need to loop until either no hitbox is left to handle or a non-negative cooldown is returned.

The VR case doesn't need to be handled since VR is always interacting with one hitbox per check (whichever box the hand is in).

Okay, so because of hovering for item guides needing to be handled, I need to take a smarter approach to this.

In short, I think I should introduce an "active hitbox" system. Any hitbox that isn't active is treated as if it isn't there. Output item hitboxes will need to be declared for built immersives, so that they can be marked as inactive.

Whether a hitbox is active will be kept in HitboxInfo, since that's how hitboxes for interacting are defined from an API perspective anyways. It'll contain a basic getter and setter that are exposed via the API so authors can control hitbox "activeness" at their will.

The above approach adds unnecessary bloat to the API. The API already supports returning null hitboxes from built immersives, and non-built immersives can just handle the case directly. Authors should be expected to just return null for hitboxes that shouldn't be rendered or be interactable. I will follow that in this case.