Closed Supremist closed 8 months ago
I need to take more closer look at this, these are just some quick remarks.
I added an extra comment and edited some for better clarity (you won't see changes from email, so check them in the PR please)
Also, I have to emphasize, that now this PR introduce a braking change in the GetMod
function. Just reiterating, to be clear.
I’m sorry to see my PR gets reverted. Can I help to improve it? Possible solutions:
Apparently, more mods used GetMod than I expected... So new functions which do that would be better probably, GetModContext+GetModContexts probably.
GetMod could be wired to GetModContext and return rootObject to not break former bindings.
This was only reason this was reverted, no other really... If it was some separate function in the end, it would be fine.
Yes it's pretty much keeping API compatibility, if you implement the suggestions from wssdude, we will merge it again, just didn't have time to make those changes when everyone was complaining it broke mods ^^
Allow mods to:
Current CET implementation of Input & Hotkey functionality provides a good default for mods. But it ignores the game context in which the key was pressed. That means, if the key is bound in CET then it must be unbound in game. That is ok, but with enough mods users will run out of keys they can comfortably press.
My proposal is to allow input mods to monitor in game context and invoke other mods key bindings depending on context. So a single key can do different action, when the player is in a vehicle or while sprinting, for example. Of course each keybind should be EITHER bound in CET OR managed by separate input mod.