Overlapping keybinds

[LevFendi]

For different actions that use the same keybind (some do this in vanilla, some in FA), do we want to keep the different control names when unifying the event handler? This question is mainly about letting players rebind actions.

[ahicks92]

So, to sorta elaborate on discord. I see only two alternatives to collapsing our key prototypes.

The first is to try my whole big UI event unifier plan and see if that's good enough. I don't think it is. The oversight there is that I don't think we can get at assignments if the user has changed the default. If that is the case then we can't distinguish between users changing keys and overloads. It's also complicated though it at least has the advantage of being "fix it once".

The other alternative is to keep the status quo. At this point I'm hard against that. The latest I found is opening chest inventories with a rail in hand which tries to place the rail. There's also the occasional way to "trick" the UI today into letting a key through. If we keep status quo then we will have to keep trying to fix these forever. The conditions are not (and cannot be) in one place. It's a mess because one must figure out which two or more events tried to trigger then figure out how to make their conditionals not overlap.

If event handlers themselves return true if they did something then the body of the actual thing binding to a key is literally event_1() or event_2() or event_3() ... though it is possibly clearer with if statements. That provides us a way to migrate without a bigger change. The bigger change we probably want is moving the conditionals up a level instead so that the conditionals for a key are in one place, then they can use if/elseif/.../else to guarantee that only the first triggers (or works because or short-circuits).
I am skeptical that enough people remap keys to make it worth the effort of carrying the tech debt of this forever. For things like page up and such that have come up the real fix is to make sure we have alternatives rather than making players figure it out.

On guarantees: something that has come up is "there's no way someone can hit two keys withing 1/60th of a second". This is true. The complexities are twofold. If the game UPS drops then it is entirely possible. the ticks become slow enough. The other is that some (possibly all) OSes will hold back keys if the system locks up or "stutters", then deliver them all at once. Windows for example will actually deliver a giant batch of messages for everything if anything along the way causes the message queues to stall. This case is rare, the UPS case is rare, together though...and for the first scanner is currently heavyweight and will lock up a multiplayer server. Not sure what happens there. We could ask if there is a guarantee if we wanted but what we're doing right now is a bad idea anyway.

[LevFendi]

For determining remaps, I have been struggling with the problem you described for a long time. I would too prefer to have just one set of checks per key but I also could not figure out how to do both. If keeping one set of checks means reducing the rebinding flexibility then I think the smallish UX loss is worth the massive simplicity gain. For example, there will be one left bracket event for everything that usually involves the left bracket and that will be it.

As for simulating multiple inputs, there is a console command for setting the game speed, to super slow rates if you want. We can use this to check what happens under multiple key presses. I am not sure what the concern is about multiple events firing on the same tick?