Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nemesis6 on October 31, 2009, 12:12:58 am
-
I was wondering whether some future builds could possibly enable use of extra mouse buttons? That's it really.
-
I believe support for new controls is part of the pilot code overhaul. Until then you can use an external program to bind them to keys.
-
input related stuff should be put in separate config tables, to make it so that adding new controls dont require a pilot file rewrite. seriously, upgrade input already.
-
Then do you want to untie input settings from individual pilot files altogether? Then what about mods? Have different settings for each mod? Should they be stored in a user's data folder like a proper config file? Lots of stuff to think about for that.
-
Couldn't one just utilize separate config files that are tied to specific pilot files? If there were something like a "pilot name" flag at the top, or even the name of the config file itself, one could presumably code the engine to recognize and link the two.
-
I suppose a separate file could be a temporary thing until we can integrate into new pilot file code.
-
With Inferno builds working in multi and a switchover to Inferno being standard planed the pilot files are will already be switched to the Inferno versions. Since Inferno and retail are already different formats is there any reason that features like this can't start to be implemented without new pilot code? If I recall the biggest thing stopping that was multiplayer compatibility for the pilot files.
-
Then do you want to untie input settings from individual pilot files altogether? Then what about mods? Have different settings for each mod? Should they be stored in a user's data folder like a proper config file? Lots of stuff to think about for that.
pilot files have been slowing down progress on input code from day one and i think its high time it gits upgraded. my idea is to stick the input bindings in a seprate table like file, stored in the same folder as the pilot file with the same name but different extension. when a user clones a player, the config file is copied for that user, when a user creates a player, the
config file is created with defaults. when a user edits the controls through the configuration panel, the changes are stored in the file. these files would be editable just like any table, can be transferred between computers, users, mods, game dirs, ect.
there is really no reason to merge it back into the pilot file. separate files are easier to edit, easier to back up, can be moved around easily. you can also keep your pilot file synced between your desktop and laptop, each with a different config file for each system. it also provides a convenient way to set default inputs for mods, tcs, and fs2. mods and fs can include a default config file, which can be used when creating new pilots. also custom configs can be used with command line parameters.
once all that stuff is done then coders can begin working on adding new commands, such as better view controls, more axes, multiple jopystics/mice/keyboards, more control functions, possibly even be able to make scripted and freded functions bindable to controls though the games control options screen.
-
I'm currently working on pilot files.
One thing that is slowing things down is the lack of documentation (which I'm producing at the moment).
Once documentation is done, then we can look at where to go from there!
-
Just out of curiosity, so this can be planned for: is there anything in the interface that would make adding controls to the control lists a problem? It seems to me like one of the few places in the engine that was designed to be dynamic even though its underpinnings aren't exactly that.
-
just make sure controls can be added (or removed) at runtime by script (game init hook) or from a campaign file, or from an input table. heavily scripted mods (or campaigns with sexped input controls) that require new controls would really need something like that to be user friendly. right now its either some obscure scripted menu or having users edit text files to configure new controls.
scripting really only has low level access to input functions and i kinda think it makes scripting more complicated than it need be. so instead of writing a menu, a parser/saver, and input abstraction (all from scratch), you add something like io.CreateControl(name, type(button/axis)) io.getControl(controlhandle/name) io.RemoveControl(handle/name).