Inactive module key bindings

[Mike Kienenberger]

I hit an issue with the AWT facade where the Facade's keys aren't being used because the Minimap module shares three of the same keys. While it makes sense for a module to override keys, this continues to happen even when the Minimap module isn't active, and even when the minimap module is removed altogether.

The problem appears to be (and this is speculation) that a particular key only appears in the config file once, and once that key appears in the config file, nothing else is allowed to use it.

I understand why we want to save binding preferences even when a module isn't used, but I think we need some way to give active modules including engine preference when assigning keys. The only way I can see to do that and be backward compatible is to allow a key to be used in multiple bindings in the config file, then try to resolve them at in-game state setup runtime.

In the short term, I have manually edited my config file to remove the minimap module bindings.

 

[Cervator]

I suspect this might get tied to the need of putting per-world config back into the individual world directories - a few things currently are "global" that really shouldn't be (like the overall texture atlas)

In fact, we didn't have an issue for that, now we do

https://github.com/MovingBlocks/Terasology/issues/950

Doesn't necessarily resolve running two modules that request the same keys, but maybe storing the key bindings differently will help (only "activate" the key binding when there is a relevant world)

Might also be a good case for a per-module config screen pre-world-create (or during world setup)

 

[Immortius]

Cervator, key bindings shouldn't be per world. This would make a user have to configure their bindings for each new world, which would be really annoying.

But ok, let us discuss desired behavior.

1. In-game, a key should only do one thing.
2. Keys need to be configurable, even out of game. This configuration needs to carry across between games.
3. An existing configured binding should take priority over a new binding (from a new module)

This is the current behavior, although (3) might not be working correctly when you first start the game, because modules binds are probably processed in an arbitrary order.

The trickiness is that modules aren't always active, and it makes sense to have actions from different modules that aren't (always) used together be able to share the same keys.

I think this is where gametypes + mods would need to come in to play. Then we could have a different configuration per gametype, and that configuration would only consider the modules for that gametype + compatible mods. Managing this at the raw module level is probably too messy.

 

[Mike Kienenberger]

In an ideal world, when you start a game and there are key conflicts between active modules, the user would be given the option to resolve them.

 

[Immortius]

The thing is... modules don't define key bindings. They suggest them. So it would be more a matter of... prompting for unbound controls, I guess.
So perhaps that needs to be an extra property of the binding annotation - whether it needs to be set or not.

 

[Esereja]

can't we have Nui window which has list of all components(i am not sure if this is right word here) of modules which can be dinded to keys and then user can bind there graficaly what ever to which ever.(propaply mouse buttons too and extra buttons of keyboard).
I am thinking binding should be registered dynamicaly and be listed ingame, not hard coded anywhere. if this is case allready good.

 

[Immortius]

That is the current situation, Esereja. So no issue there.

The problem is if you have sets of modules you wouldn't use together that have binds, those binds cannot share inputs at the moment. This is mostly the case where disparate gametypes are involved - bind config should be different for each gametype, inheriting off a common base. So in a combat oriented gametype you might bind the keys around wsad to attack moves or health pots, and in an exploration based gametype you would use them for other things.