Keybind system

[rakiru]

This is probably something we should deal with before it becomes too much of an issue. As it stands, the base game has a set of keybinds that it uses, and that's it. If any mod adds keybinds, they're generally hard-coded. This obviously isn't ideal (hell, the two mods that do this already (sprint and HRV) both conflict with my own keybinds).

I haven't thought about this in great depth, but a possible idea to consider:

Have a global keybind store. Everything that wants to use keys can call a register function and get a keycode to use in return. They can pass in a default that is returned if it is not already in the registry. Something along the lines of:

KB_FOO = keybinds.register("unique_key", "description", default_key)
KB_JETPACK_FLY = keybinds.register("rakiru/jetpack/fly", "Hold to use jetpack", SDLK_SPACE)

Using the mod name + action as the unique key keeps things nicely organised, but it could be anything. These would be used in the config file and such. The description would be stored alongside them, or could be used by a keybind editor in the launcher/game if desired.

An alternative is that each mod simply does their own thing with client-side configs, but that's obviously far less user-friendly.

Opinions? Comments? Suggestions? Ideas? etc.

(No, I'm not writing a jetpack mod)

[rakiru]

Or, going further, a system like the Source engine and stuff, where you bind keys to commands, and the engine (in this case, the base game) handles all the key stuff and calls the relevant things. That would require a lot of changes though (but would allow multiple keys to be bound to the same thing, etc.).

[rakiru]

I've been thinking more about this for a different project, but the thoughts could be useful here. This is an expansion on the register idea, since I doubt we'll do the command system.

Instead of the register function returning a keycode (such as SDLK_SPACE), it could return a KeyBind object with a pressed attribute that the input manager updates, and [de]register_callback functions, allowing polling and event based input. This could be extended to handle controllers too (perhaps when SDL2 is in), and axes either given their own value attribute, or pressed could be renamed to value.

[Chameleonhider]

Well I haven't been this deep in the rabbit hole and I have little idea what you're talking about...

But I can give you my two cents from UnrealTournament1999: Only client edits the config files. A mod would have a Readme.txt with all the commands + explanations. Client (player/user) reads readme.txt, copies and pastes those commands into his config file himself and assigns a key.

Or have two config files, one for client only and mods he trusts, and one config for everyone to use. If you believe you trust a mod, you put its info from "everyone" to "client-only".

There's 1/10th of a cent: There is one bigger mod "Infiltration 2.9" (for UT1999)(I'm sorry I mention it so much) that consists of many other small mods put into place. Those small mods rarely have any extra/exclusive keys for themselves; they use a few available keys (or key combinations) or menus that are common to the whole mod. For example "Infiltration" adds two new keys for UnrealTournament1999: weapon attachment and weapon fire mode keys. By using alt-fire(built-in), wpn attachment and wpn fire mode keys and combinations, one is able to use M4A1 rifle, its M203 grenade launcher, different ammo for M203 (HE/Smoke/Incendiary/Penetration), different range for M203, is able to switch between scoped(if available) and backup ironsight modes and of course, switch between full-auto and semi-auto. Same keys are used for other weapons, so once you get used to one gun, you can use them all.

Also see "quake 3" for simple (config file scripts)[http://www.urbanterror.info/support/108-scripting/], that'd be neat.

[rakiru]

I suggest you look into how Iceball's config system works. We already have a setup like that.

I'm not sure what your'e trying to add with your 1/10th of a cent paragraph. That's essentially what we'd be doing anyway.

As for scripting, I mentioned that above (Source engine is similar to Q3 in that regard). I'm not sure whether we should actually implement it though. It's certainly something I'd make use of if we did though.