I am currently using the following heirarchy; gameobject → canvas → panel(s) → buttons.
I am trying to put together my own keyboard input manager based on the new input system. I prefer the new input system for unrelated reasons.
My problem is I do not want the keyboard input manager to poll the input system to detect key state changes. I want the input system to use a callback and tell me when ANY key changes. uitoolkit has such a feature: aka “RegisterCallback” etc. but I do not want to us the uitoolkit unless I absolutely have to. I also want to avoid using unity to link it all together: there will be enough dynamic stuff going on to make this a headache. i.e. i am doing all this is code.
is there a way to get a callback based system in place using the above stipulations, and all in code?
thanks bugfinders. it would be nice to receive a single callback if any key changes state, and let the keyboard manager dig into the event to see what has changed: in typing this I realized that’s a lot to ask (to have the input system put together a list of keys that have changed state). sounds like I have to have a separate action for each and every key. that’s do-able, but a pain. I am guessing there is no way around that?
that is some pretty heavy reading spiney199: need to spend time absorbing all that. I noticed there was no corresponding OnAnyButtonRelease, but I am guessing other methods/properties/whatever could allow for discerning such. Thanks spiney199! I guess my question is answered. not sure who to give credit to? You both provided valid input: Can I give credit to both of you?
I have a question though, obviously it is for you to think about what you’re about to start developing.
Why do you want to reinvent the Input System using the Input System? What’s the benefit of this, what is that you don’t like in the Input System so you try to develop your own logic doing basically the same?
I am separating concerns by disconnecting key consumers from key providers. the input key manager acts as a proxy? not sure what design pattern here is … been a while. key manager provides a simpler interface for getting key events for consumers. hope i said this clearly.
this was not clear enough. the input system provides some lower level stuff that can be wrapped in a manager,. that also happens to simplify the interface. does that help?
many 3d examples i saw were all about wasd, joysticks, etc. connected to a game object. if we followed the input system tutorials, we saw the default input actions. I am not doing any of that here as yet. I am doing other stuff with the keyboard. Sorry if this seems vague. not trying to be.
I could be barking up the wrong tree here as well. but my original question still holds regardless of the final design.
I mean the input system already provides that separation of concern with it’s input actions API. Thus listeners only care about the action, and not what specific device or what specific binding caused it to fire.
Unless you need to use every key of the keyboard, then at that point you can use the methods I suggested, or just do some polling. It’s not as bad as everyone makes it out to be.
Yeah. I did a lousy job of explaining things spiney199. I could get into a long semi-related discussion as to why. Some readers might even enjoy the nap. Cheers.
How do we mark this answered? I am using bugfinders approach: I guess he gets the most credit. Appreciated your input as well spiney199.
as for marking it sorted - you should be able to edit the thread title there should be an edit in the tiniest font imaginable