Block click-through

[AlastGrey]

something minor this time. This adds a "block click through" toggle to MenuSection (default true). Enabling this will prevent clicks/hover from interacting with the game ui if they are inside the menu border.

[MrDiamond64]

This is a nice quality-of-life feature, so thanks for submitting a PR. Anyway I've been testing out your changes locally and have noticed some issues. With your changes, using any sliders will now result in the UI moving alongside the mouse cursor, when previously the UI would remain in its position. I've narrowed this down to the HandleBoxMovement function being called in OnGui instead of Update.

I also noticed that while you are using any of the input keys (W, A, S, D, or the arrow keys), if you were to click anywhere in the UI your character will stop moving. I'm not too sure how you could go along fixing this, Input::ResetInputAxes resets all input axis and it doesn't seem like you can control what exactly gets reset. I tried downloading the Unity InputLegacy module and opening it in dnSpy to see how it works under the hood and seeing if we can maybe reimplement this function to only reset mouse inputs. However this method is an external symbol so I don't exactly think we can do that. Either way I figure I might bring this to your attention.

In MainUI.cs line 142-153, you check if the mouse position is inside the Main UI box and if the current event is MouseUp, MouseDown, or MouseScroll, and if so you consume the event. What does this do, is there maybe a bug during testing which you encountered which is why this is here? I removed it and I couldn't notice a difference in how inputs are handled. It seems like only the BlockClickThrough method is needed to get no-click through working.

[AlastGrey]

Thanks for the response, the next commit will fix the HandleBoxMovement. For the checking of the current mouse event, in my testing session, certain actions such as detective changing tabs or sabotaging didnt get blocked (or if you click really fast), so i added that as a failsafe. As of writing this comment, I have tried experimenting with some harmony patches and the mouse event consumption in OnGui (which is the failsafe) and it has potential, so i'll see if it can be implemented as the main logic instead of ResetInputAxes.

[AlastGrey]

Alright I've switched to patching PassiveButton.ReceiveClickUp, PassiveButton.ReceiveRepeatDown and PassiveButton.ReceiveClickDown instead of ResetInputAxes so it shouldnt stop every input now.

[AlastGrey]

Fixed a critical bug and added hovering block by patching PassiveButton.SetPassiveButtonHoverStateActive to this feature.