Ids don't get reset if some control is still active and no subsequent Im3d::Gizmo call

[nihonium-cfx]

This results in gizmo controls become unresponsive.

Somewhat general steps to reproduce:

1. Have gizmo drawn for some ID
2. Select some gizmo control with mouse so it become highlighted
3. Somehow stop drawing gizmo for this ID with control still being active
4. Draw gizmo again (mouse state doesn't matter), probably with different ID
5. All controls become unresponsive

Related issue in our project https://github.com/citizenfx/fivem/issues/928 fixed with workaround by resetting ids manually if ID gets changed.

[john-chapman]

Hi, thanks for reporting this. It's an interesting edge case; let me summarize to make sure we agree on what's happening:

• A gizmo control is highlighted (it sets m_appHotId and m_hotDepth on the context).
• Subsequently this gizmo is no longer drawn, but m_appHotId/m_hotDepth are not reset and so Im3d still thinks this gizmo is highlighted.
• Some gizmos no longer work because they can't transition to a 'hot' state (they can't override the existing hot state if they aren't in front of m_hotDepth).

I think this could be fixed internally by invalidating the hot/active state if the ID wasn't used by a gizmo within a frame. However I think your client code fix (calling Context::resetId() on selection change events) is still good practice, I'll add a note somewhere in the docs about that.

If you're not already doing it I'd also suggest locking entity selection when interacting with a gizmo. It should be enough to just check Im3d::GetHotId() == Im3d::Id_Invalid when changing entity selection. It would improve Ux and also neatly solve this problem.