Runtime binding of inputs to actions (closed)

Feature requests
#1

I would like to propose the implementation of the following single function

sys.bind_input_action( input, action)

so that one can define in runtime the input bound to an action. Maybe sys is not the best place to put such function…

Some notes.

  1. input is one constant out of the same set used in the input_binding file
  2. If it is needed by the engine, one may restrict this function ONLY to actions already defined in the input_binding file. (In other words, action is not a generic (hash) string. )
  3. This function does not break the backward compatibility.
  4. As far as I may guess this should be very easy to implement.
  5. This simple function would drastically eases the implementation of a user configurable input on PC for keyboard and gamepads; and this is almost mandatory for any game on PC.

While I love coding in c++, I am not able to compile the engine… so I don’t think I may implement the above function myself. Also, my definition may not be “canonical” or expressed in the right technical way, I am not an expert in software description… Sorry!

I hope this proposal has some sense.

3 Likes
#2

Make a feature request issue?

Is action a callback function? Then input would be a hash?

Would the action table be passed to the callback function so it can decide how to deal with it? I do not immediately see how this is better than on_input just different. You can have a single on_input entrypoint in your project and use it to call various functions, this is often done.

What problems have you ran into with compiling the engine? Keep trying and provide feedback!

#3

Thanks @Pkeod!

I see from your answer that I have been terribly bad in explaining my proposal. It is clearly my fault! English is not my native language, sorry.

Let me try to explain it again. In a Defold project there is a file named *.input_binding where raw input is bound to actions. I would like to be able to change this binding in runtime. For example

sys.bind_input_action(“J”, “jump”)

maps the key “J” to the action named “jump”. So when the user press “J” the function on_input get called with action_id = “jump”. (Maybe it is better to have always hashed strings and not strings, but this is not the point here.)

My use case is configurable input for keyboard and gamepad. Indeed how can I implement configurable input on Defold now? I have to define a lot of binding of raw input to actions (with the same name of raw input) and then use same variable to store the real action I have to listen to in on_input. But this means that I am just trying to bypass the binding feature of Defold.

Another, and maybe be way better, route is to have a function like

function on_raw_input

similar to on_input but with action_id equal to the raw input hash (as in the *.input_binding file). Also this doesn’t break the backward compatibility. One is not forced to use it in a script when on_input is a better choice. Moreover it is not computational costing to the engine since the input events from the users are very rare in any scenario.

I hope that now my idea is somehow clearer.

About compiling the engine. I was not saying that I have some issue compiling the engine. I haven’t even tried… since I know I am not that good in such things…

2 Likes
#4

Yes, that is more clear to me. So you want to be able to rebind the associations of the .input_binding file at runtime to be associated to different hashes.

Have you seen https://github.com/britzl/defold-input ? specifically https://github.com/britzl/defold-input/blob/master/in/mapper.md

It can be fun and useful to try and get things to compile. Be sure to try it with Defold’s engine and editor eventually someday. :slight_smile:

1 Like
#5

Yes, I have seen the mapper of britzl. If I understand, it is indeed bypassing the binding feature of Defold by defining all possible actions.

It seems to me way more logical to have a new function like the on_raw_input I have tried to describe in my previous post.

Of course I will go with defining all bindings since I am implementing configurable inputs in these days. But I just wanted to give my contribution to the engine with this proposal.

#6

The raw input thing may be possible but people need to read the source and understand how currently it’s being done and what the performance impact there would be with changing the systems. Having a input file that defines every key may cause no meaningful performance difference so it all needs to be investigated. We have had live games for 2 years on multiple platforms with all input defined and at least there was no apparent issue in any of our projects.

2 Likes
#7

Yes, but I was not saying that using all bindings has a performance impact. Just that having the binding feature always there and be forced to bypass it seems a bit strange. And I am sure there is absolutely no issue in using all input definitions. Nor I am complaining about Defold, I love it!

1 Like
#8

Doing your own remap is a perfectly valid way of using it.

Also, keep in mind that each added “helper utility” will add to the engine size, and perhaps not that many will use that particular feature.

1 Like
#9

Yes, probably I am not able to explain my feeling that a remap of a map is a little bit strange. Just this!

Also, the input_binding sounds a bit “higher level” with respect to the other feature of Defold. But this is only my idea, and I was only trying to propose something useful, really!

1 Like
#10

There’s an issue on GitHub: https://github.com/defold/defold/issues/3268

We decided to close it since it was fairly low prio and there are reasonable workarounds. I’m on the fence on this one. It’s definitely useful to be able to rebind keys and it’s something that a portion of games would use. But its also one of those things that aren’t used that frequently. I very rarely rebind keys when I play games as I find the existing and default keybindings often are carefully thought out.

2 Likes
#11

:cry:

You know, here I was, thinking of proposing that the current input system be separated into an extension! I don’t think it fits with Defold’s theme of minimalism, especially if you consider what you have to do to get around it for rebindable input.

All inputs from OS --> Defold maps inputs to actions --> User binds every input to an action --> User maps inputs to actions.

You end up with the same system duplicated twice. Raw --> Mapped --> Raw --> Mapped.

To me, the current built-in system is already a helper utility. Exactly the sort of thing you could have multiple community libraries for, or nothing at all. Sure, not all games need rebindable input. On the other hand, not all games need action bindings at all. If you’re only using one key to do one action and never changing that key, then there’s no point. Your average mobile game only uses “touch” and possibly “multitouch”…

I realize this is a way more serious change than I make it sound, with the whole input stack, collection proxies, backwards compatibility, etc. This is just my two cents. I always want rebindable input. :slight_smile:

3 Likes
#12

Now that your return to this, let me write down a very simple idea I had:

add an option to game.project in order to send raw_input to on_input and just ignore the binding in game.project

This is EXTREMELY easy to implement. Let say less than 256 byte of code in the engine :), just a joke of course… and does not break compatibility and each user takes its route: either bound or raw input.

Ciao!

2 Likes