[Scummvm-devel] RFC: Flexible keymapping via new EVENT_ (post 0.10) (Serhiy Batyuk)

[Marcus Comstedt]

Max Horn <max at quendi.de> writes:

[...]
> Of course we want to try to get away from such hard coded assumption.  
> In the context of the new system we discussing and design here, the  
> pause key would be fixed by two things: First off, it would have a  
> high priority, and the mapper would take that into account; secondly,  
> it would have the same "action ID" both in normal and in fighting  
> mode. The mapper would recognize this, and try to keep using the same  
> key for pause in all cases.
[...]

There are two problems here.  The first is that I don't agree with
pause having a "high priority" (as should have been aparent from my
previous post).  Isn't it worse to lose the ability to complete the
game due to a missing action button than to lose the ability to pause?

Secondly, "pause" was only an example anyway.  Even if we accept that
"pause" has a high priority, some other button which hasn't would
still be removed if there wasn't enough buttons to accomodate the
dynamic additions.  Generally, there are three possible scenarios:

1) There is one set of fixed and one set of "extra" actions added
   at some time(s), and all fixed actions have higher priority than
   the "extra" actions.  In this case there is no point in adding
   the extra actions dynamically, since putting them in the fixed set
   would give the same result, both when the "extra" actions would be
   active and when they wouldn't (provided that the "extra" actions
   are ignored by the engine when not in a situation where they would
   have been added dynamically).

2) There are "extra" actions which have higher priority than some
   fixed action.  In this case that fixed action will sometimes be
   unmapped if not enough buttons are available, which will confuse
   the user.

3) All "extra" actions have lower priority than fixed actions, but
   there is more than one such set, and they are active at different
   times.  In this case there is opportunity for benefiting from
   dynamic rebinding without confusing the user, since the fixed
   actions would retain their assigned buttons in all modes, and
   the other buttons (which have context sensitive actions anyway)
   would be reassigned depending on the situation.

Since scenario 1) doesn't benefit from dynamic actions, and scenario
2) confuses the user, only scenario 3) makes pursuing this possibility
worthwile in my opinion.   *However*:  Are there any games which have
such disjoint sets of temporary controls?  Otherwise that scenario is
moot anyway.

Your points regarding grouping dependencies of mapped keys are valid,
but orthogonal to the dynamic actions issue.


  // Marcus