Backend assertion failure (possibly from wrong mouse event handling)

[ruby3141]

from imgui.cpp:1390 (on "docking" branch. For mainline it's on :1354),

IM_ASSERT(!ImGui::IsAliasKey(key)); // Backend cannot submit ImGuiKey_MouseXXX values they are automatically inferred from AddMouseXXX() events.

---

Target game is DJMAX RESPECT V, which doesn't use any mouse input. \ I couldn't find the exact condition to reproduce the crash. still testing.

[veeenu]

What hudhook version are you on? And how are you using the docking branch? This issue occurred before but it has now been fixed and a new release with the fix is on crates.io.

[ruby3141]

Oh It was v0.6.1... I started my project about a month ago with that version, and thought I'm still using newest release because of github's stupid "3 weeks ago".

I'm really sorry for wasting your time.

[ruby3141]

Same problem occured with hudhook v0.6.5 This time I can reliably reproduce it.

Try clicking outside the game window while focused triggers crash.

https://github.com/veeenu/hudhook/assets/3256382/d27d7d89-4317-41a2-a65c-55b1489aabdf

To make sure I did cargo clean, update and build about three times and it still happens.

[veeenu]

All inputs on our end are correctly passed through add_mouse_event. I do not know where that assertion could be triggered. Are you by chance doing ui.io_mut()[something] = ... in your code? That is discouraged and will trigger the assertion above.

[ruby3141]

As far as I know imgui::Ui doesn't have io_mut() method so it's certainly not happening.

For imgui::Context::io_mut() which can be accessed on before_render(), there's some logic to update Io.delta_time and Io.mouse_draw_cursor.

[veeenu]

Right about ui.io_mut, it's not a thing.

Have you tried what happens if you don't perform that logic? Please try to identify if any changes on your end result in this behavior going away so we can pinpoint the problem.

[ruby3141]

Removed everything except hooking part but crash still happens.

use hudhook::{hooks::dx11::ImguiDx11Hooks, ImguiRenderLoop};

struct BlankContext;

impl ImguiRenderLoop for BlankContext {
    fn render(&mut self, _ui: &mut imgui::Ui) {}
}

hudhook::hudhook!(ImguiDx11Hooks, BlankContext);

[veeenu]

You mentioned the docking branch in your first message. How are you accessing that? Are you compiling against a different underlying version of imgui?

I reviewed our code but I couldn't find code paths that can ever hit that assertion, and also I do not have access to that game to test it myself. I need more information, a lot of it, if we hope to find out anything about this at all.

I encourage you to clone the repo locally and introduce log statements nearby the input related code, or at least implement the on_window_proc method and log what messages are received by the game window, and report your findings. Thank you!

[ruby3141]

After the first close of this issue I opt out for imgui docking because it seems unnecessary to me. I accessed it via docking feature of imgui crate by the way. I didn't test anything about the feature, so I've no idea it would work well with hudhook or not.

I will add log and collect info about why did it happen. Slow progression expected since I'm not familiar with rust. (I'm C# main)

[veeenu]

There's no rush! Take your time. This is open source, it's all based on volunteering whatever time one wants or can. :grin:

[ruby3141]

I thought current release v0.6.5 includes commit f058304 (fix for #172). Found out it doesn't, while checking for #176 breaking change on latest source. _{I recompiled and checked over ten times with denial.}

With hudhook = { git = "https://github.com/veeenu/hudhook.git", rev = "f058304463a28e0bd328dc35c85fabaeb0559bee" }, problem is gone. So ultimately I was trying to re-solve already fixed problem for two weeks. 🤦‍♂️

Thank you for your help.

[veeenu]

Huh! I thought it did, actually. My bad. Planning to release 0.7 at some point soonish so that fix can get in. Thank you for reporting this.