Hi, I'm the developer of Mouse Tweaks. I recently added a Fabric version and just got a bug report that Mouse Tweaks doesn't work when Replay Mod is loaded.

The way Mouse Tweaks works is it listens to ScreenEvents.BEFORE_INIT and checks if it can handle the screen that it gets. In particular, the check succeeds if screen instanceof AbstractContainerScreen.

Now this is what I'm seeing in the log on opening some GUI with Replay Mod loaded:

[21:39:26] [Render thread/INFO]: [STDOUT]: [Mouse Tweaks] You have just opened a class_479.
[21:39:26] [Render thread/INFO]: [STDOUT]: [Mouse Tweaks] Handler: GuiContainerHandler; Mouse Tweaks is enabled; wheel tweak is enabled.
[21:39:26] [Render thread/INFO]: [STDOUT]: [Mouse Tweaks] You have just opened a MinecraftGuiScreen.
[21:39:26] [Render thread/INFO]: [STDOUT]: [Mouse Tweaks] No valid handler found; Mouse Tweaks is disabled.

So Mouse Tweaks does recognize the screen, but then, immediately after, some MinecraftGuiScreen opens which it no longer recognizes.

I'm assuming this is something that Replay Mod does. How should we fix this, is there something Replay Mod should do in this case, or is there a workaround I can add to Mouse Tweaks?

Thanks.

Eh, yeah, that GUI lib of ours is a bit of a mess and I am trying to eventually get rid of it, it's just quite a lot of work, so that won't happen in the near future.
It doesn't open the MinecraftGuiScreen though, it merely initializes it. A tiny but important difference.

I believe the most ideal way to fix this (and potential incompatibilities with other mods that do weird stuff; if there are any) is for Mouse Tweaks to inject (just the Main.onGuiOpen(screen) call) at a different location, specifically into MinecraftClient.openScreen(Screen), right after the assignment to currentScreen. That way, no matter what weird stuff third-party mods pull, it'll always be in sync with what screen is actually open.
Alternatively, a lot simpler but maybe a tiny bit less robust (and you need to be able to deal with duplicate calls for the same screen), one could just call Main.onGuiOpen(mc.currentScreen), i.e. don't look at which screen is being initialized, instead look at which screen is actually open right now.

Thanks for a quick and detailed response!

I believe the most ideal way to fix this (and potential incompatibilities with other mods that do weird stuff; if there are any) is for Mouse Tweaks to inject (just the Main.onGuiOpen(screen) call) at a different location, specifically into MinecraftClient.openScreen(Screen), right after the assignment to currentScreen. That way, no matter what weird stuff third-party mods pull, it'll always be in sync with what screen is actually open.

That's what I went with now. I injected at setScreen()'s RETURN and I use Minecraft.screen to safeguard against recursive invocations. Seems to work fine with Replay Mod now.

Oh, I believe you want to keep your event registrations in BEFORE_INIT, otherwise you'll end up registering them twice to the same screen in the recursive open case.

Oh, I believe you want to keep your event registrations in BEFORE_INIT, otherwise you'll end up registering them twice to the same screen in the recursive open case.

Hmm, right. Actually I went ahead and got rid of manual onGuiOpen() altogether; instead I now pass the screen from the event handlers into Mouse Tweaks functions, where they check if it's a different screen from last time and do the onGuiOpen() then. This way regardless of any init() ordering or duplicate setScreen() or whatever it should just work.

do you have link to new mousetweaks so i could download it and play with replay mod?