[zookeeper]

NOTE: Only after writing the patch (and most of this post!) did I realize that strings.tbl can already be used to override the names. Whether that means this patch is useless or whether it'd still be nice to have a table-side override available, I don't know yet.

***

TC's might want to use different names for some keybinds, so this patch enables that via controlconfigdefaults.tbl.

Example of use:

Code: [Select]

#ControlConfigOverride

$Bind Name: Fire Secondary Weapon
    $New Name: Launch Bomb
    $Has XStr: 0

$Bind Name: Enter Subspace (End Mission)
    $New Name: Engage Warp Drive
    $Has XStr: 0

#End
Patch:

Code: [Select]

Index: controlsconfig.h
===================================================================
--- controlsconfig.h (revision 9153)
+++ controlsconfig.h (working copy)
@@ -41,8 +41,9 @@
  short joy_default;  // default joystick button bound to action
  char tab; // what tab (category) it belongs in
  bool hasXSTR; // whether we should translate this with an XSTR
- char *text; // describes the action in the config screen
+ char *default_text; // default description of the action
  char type; // manner control should be checked in
+ char *text; // overridable description of the action
  short key_id;  // actual key bound to action
  short joy_id;  // joystick button bound to action
  int used; // has control been used yet in mission?  If so, this is the timestamp
Index: controlsconfigcommon.cpp
===================================================================
--- controlsconfigcommon.cpp (revision 9153)
+++ controlsconfigcommon.cpp (working copy)
@@ -533,9 +533,13 @@
 // initialize common control config stuff - call at game startup after localization has been initialized
 void control_config_common_init()
 {
- for (int i=0; i<CCFG_MAX; i++)
+ for (int i=0; i<CCFG_MAX; i++) {
  Control_config[i].disabled = false;
 
+ // init the overridable description with a copy of the default
+ Control_config[i].text = strdup(Control_config[i].default_text);
+ }
+
     control_config_common_load_overrides();
  if(Lcl_gr){
  Scan_code_text = Scan_code_text_german;
@@ -590,7 +594,7 @@
         {
             config_item& r_ccConfig = Control_config[i];
             
-            if (!strcmp(szTempBuffer, r_ccConfig.text))
+            if (!strcmp(szTempBuffer, r_ccConfig.default_text))
             {
                 /**
                  * short key_default;
@@ -602,6 +606,10 @@
                 
                 int iTemp;
                 
+                if (optional_string("$New Name:"))
+                {stuff_string(szTempBuffer, F_NAME, iBufferLength);
+                 r_ccConfig.text = strdup(szTempBuffer);}
+               
                 if (optional_string("$Key Default:"))
                 {stuff_string(szTempBuffer, F_NAME, iBufferLength);
                  r_ccConfig.key_default = (short)mEnumNameToVal[szTempBuffer];}

Yes, I didn't convert the control_config.text field to an SCP_string, but in this case it doesn't really seem to matter. If you think it absolutely should be done, then feel free to write such a patch. I spent enough time on that already to realize that I'm certainly not going to undertake something like that.

[Nuke]

so we can disable binds we dont use, we can rename binds. yes, you know whats next:
custom binds

[mjn.mixael]

My understanding is that custom binds will be more feasable under the new pilot code in 3.7.

[z64555]

StrDup() allocates space on the stack and then returns a pointer to it... is there a mechanism already in place to de-allocate that space at program termination?

[zookeeper]

Custom binds would actually be reasonably easy to add already. But if the new pilot code would affect how it gets done, might be better to wait for that first.

StrDup() allocates space on the stack and then returns a pointer to it... is there a mechanism already in place to de-allocate that space at program termination?

Allocated space needs to be de-allocated at program termination? I figured that's a job for the OS so I didn't worry about it.

[z64555]

StrDup() allocates space on the stack and then returns a pointer to it... is there a mechanism already in place to de-allocate that space at program termination?

Allocated space needs to be de-allocated at program termination? I figured that's a job for the OS so I didn't worry about it.

...That's what I'm hoping, at least - either the default deconstructor takes care of the de-allocation or the OS does. But since I can't really find any place in the code that does this, I can only assume the worse. 

[Nuke]

My understanding is that custom binds will be more feasable under the new pilot code in 3.7.

thats been the mantra for years. but the ability to have custom control binds in the control config screen rather than in some text file that the user shouldnt even have permission to edit, that would be awesome.

[chief1983]

We've already added one custom bind to the Antipodes 8 branch, for toggling between primary firepoint grouping on ships with it enabled.  The control is bindable in the controls menu.  It is geared towards FotG so that the X-wing can cycle between 1x4, 2x2, and 4x1 grouping for instance.  The code committed for adding that command could be used as an example of how it can be done.

[Nuke]

i was thinking more for custom functions for scripting/events to use. but new hard coded controls are good. id like to have horizontal and vertical thrust axes that aren't hackishly implemented with a script.

[z64555]

i was thinking more for custom functions for scripting/events to use. but new hard coded controls are good. id like to have horizontal and vertical thrust axes that aren't hackishly implemented with a script.

The engine has to support lateral and vertical thrust axes before you can configure them. 

[Nuke]

take a value between -1 and 1 (which is already done with the keyboard controls) and multiply it by the max lateral or vertical thrust. if the value happens to be sourced from an analog axis rather than from keyboard keys. boom analog. you can feed arbitrary values in there from scripting. so it was only a minor jump to feed mouse delta into that formula. so if your hotas has a mouse,like the trackpoint mice found on saitek sticks, or some axes you can map as a mouse (i use the ministick on my ch pro throttle). you can do this with script. actually i think i posted that on the scripting board somewhere. really the only thing really that needs to be done is merge in the pilot code from antipodes, and possibly, sdl on windows. and the rest is trivial.

im actually rather pleased to see the framework neccisary for input upgrades the engine sorely needs is being worked on. ive only been asking for them since the scp started some many years ago.

[z64555]

Well, no, that's not the problem. Currently the engine can only use 4 axis, even though all throughout the code there's provisions for 6 and you can even assign 6 axes in the F2 menu. I haven't taken the time to track down why this is exactly, but I seem to remember it being somewhere in the joystick files.

There's also this bit of an ordeal of axis misnaming, somewhere between DirectX and the engine, the Rx, Ry, and Rz axes are mixed up. 

[Nuke]

yea its easier just to index axes by their number. direct input allows up to 8 axes on a controller. so named axes probibly some kind of legacy bs that dates back to the era of the game port. i wrote a joystick interface for a r/c transmitter i built. just a simple little sdl application, reads joysticks, reads a bind file and then transmits the data over a transmitter on a fake serial line to what ever device is at the other end. problem is how do you associate an axis with a bind without resorting to some arbitrary data by which to identify your sticks. the trick to keeping your axis indexing correct is to create a joystick hash. i just take the device name string and then append "-" number of axes "-" number of buttons "-" number of hats, and whatever information you can pull from the api. then you generate a crc-32 from the string which is usually descriptive enough to find the device on your system later on to re apply bindings, even if joysticks are unplugged or moved around. i dont think that system ever screwed up (though it might if you have two of the exact same joystick on your system).

what axis name you display to the user can just be an array of strings with the standard axis designations for that index. i think thats what happens anyway. i remember back when the only four axes you had were x,y,z and r. i thing those still are the original designations. then you started seeing xrotation, yrotation, u, v, w, slider0, all kinds of oddball designations that are seldom describing the axis very well.