Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Klaustrophobia on January 19, 2010, 06:38:48 pm
-
This would be an advanced sensitivity control for joysticks (or other controls it might extend to, for that matter) that allows for varying the response over the range of motion. If anyone has played Lock-On: Modern Air Combat, their joystick setup is what I'm talking about. There is an adjustable S-curve that flattens out in the middle and gets steeper near the edges of the range of motion. This allows for more precise aiming adjustment while not impacting full turns. The deadzone and axis "shift" (basically widens or narrows the range of motion) are also adjustable in LOMAC. Now I have no idea if this has been looked at before or is even possible. Thoughts?
-
input needs a total overhaul as far as im concerned. but i usually just use ch control manager to increase the sensitivity in the center of the stick and ramp up fast twards the outside. most high end joysticks let you do this.
-
I know Wanderer has played with joystick curves a couple of times, he's the expert I think. :)
-
oh and the term is gain
-
i'm going to assume the majority of players don't use CH equipment. i know i don't have that kind of money. saitek doesn't have this ability, at least on the versions of software i am using.
-
Yes, I would *like* a pair of CH Pedals and a nice stick setup, but I'm stuck with a Saitek Cyborg Evo with a stiff spring, which makes precise aiming impossible since the spring doesn't like moving.
-
Bah, who needs precise aiming when you plant yourself 50 meters behind your target? :p
-
Bah, who needs precise aiming when you plant yourself 50 meters behind your target? :p
*Shrug* All the extra climbing and diving ought to loosen up your stick!
In other news, I agree that it'd be an awesome and useful feature for FSO to support more advanced input control. I'd personally like to see a bit of add'l support for Logicrap joysticks; first third of the range being low-sensitivity, second third being normal sensitivity, and last third being full-out. Ya know, because the sensors sorta stink in Logicrap sticks.
-
*Shrug* All the extra climbing and diving ought to loosen up your stick!
Funnily enough, I think that was what wore out the spring. :P
-
Game currently uses following system:
Output = Input ^ (3.0 - (Joy_sensitivity / 4.5))
Where input and output are values 0 .. 1 (essentially describing the range of motion AFTER deadzones have been capped) and Joy_sensitivity is the number of lit blobs in the options screens control sensitivity section minus one (0 .. 9). So you get sensitivity curves between x^1 to x^3. If larger range is hoped for (is it?) then we'll have to see what can be done.
-
it's not the overall range, but the ability for the gain (as i am told :P) to vary at different amounts of input. i.e., x^ 3 at the edge of the stick's range and x^1 just outside the deadzone. even something primitive like a "two-stage" axis would be cool, if it can't be done as a smooth, continuous thing.
-
Well the 's' curves described sound (and also seem to be) pretty much exactly like x to nth power curves
-
i'm going to assume the majority of players don't use CH equipment. i know i don't have that kind of money. saitek doesn't have this ability, at least on the versions of software i am using.
ive owned an x45 and an x52, and i coulda sworn they had a gain adjustment. of course i could be thinking about my old sidewinder (ive owned more joysticks than i can remember).
ch controllers are fairly durable, but they arent really that innovative. the throttle has a nice 2 axis thumbstick and the fighterstick has hardware trim knobs, not the most comfy stick yo use though. saitek on the other hand had a nice feel, has the independant trim wheels are nice if the games support them and the trackpoint mouse is a clever touch, the dual position trigger was nice too. thing i didnt like about it was the single spring in the main joystick. you couldnt get a feel over how much x and how much y you were using, the only way you could find center on an axis was to center both of them. as for all usb joysticks, theyre all inaccurate. if you get 10 bit precision you were lucky. older joysticks used to have 16 bit accuracy (they used the 16 bit adcs on your sound card). even the ch hardware only has 8 bit precision. the pro version of the x52 has 10 bit but, i think that the gimbal design, single spring and the internal mechanics kinda render that useless.
-
Can you draw or otherwise depict/describe/function for your 'ideal' input -> output curve (call it gain if you must)?
-
Can you draw or otherwise depict/describe/function for your 'ideal' input -> output curve (call it gain if you must)?
(http://img638.imageshack.us/img638/3534/joysticks.jpg)
That said, it will go flat at max, which would occur early.
-
That's a bad curve. It'll be rather un-intuitive as it has a non-continuous profile and thus will introduce a sharp increase at the sensitivity at some point, which is bad, trust me on this one.
This is one possibility:
(http://www2.wolframalpha.com/Calculate/MSP/MSP17119947i4cii6aeci600001eed0ae208i3c0fd?MSPStoreType=image/gif&s=11)(link when image expires) (http://tinyurl.com/y96gba9)
This is another:
(http://www2.wolframalpha.com/Calculate/MSP/MSP18419947i73033af6hc000043d2h54h634319ba?MSPStoreType=image/gif&s=20)(link when image expires) (http://tinyurl.com/y93zmpg)
And a third one:
(http://www2.wolframalpha.com/Calculate/MSP/MSP69919947hde6h1ehcf700004i6g3f2209bc79i3?MSPStoreType=image/gif&s=23)(link when image expires) (http://tinyurl.com/yd8glpa)
-
remember that mechanical linkages in the joystick can very greatly. most joysticks directly rotate a linear potentiometer with a gimbal. so the number of degrees the stick is turned is proportional to the axis value. other joysticks (such as the x52) convert rotational force to a linear force with rack and pinion gearing, which articulates a hall effect sensor in relation to a strong magnet. assuming the reading from the sensor is linear (which may not be the case as magnetism falls off inversely to the square of distance (i think)) then it too may be proportional to the axis value reported to the game. however i have seen joysticks which use more complex mechanical linkages to expand the rotation of the potentiometer, which may introduce non linearity. one notable example were the ms sidewinder joysticks which used an optical sensor and the curve seemed more tangential.
@ht
i rather find the s shaped curves rather annoying in that they gain sensitivity twards the extents of the range (which i consider the brute force area used only for hard turns) that could be better utilized elsewhere in the curve. traditionally ive used a linear curve. but ive discovered how advantageous having a big area to work with twards the center can be, so you could fine tune your control. so of those 2 curves id perfer the second (all be it closer to linear).
-
@ht
i rather find the s shaped curves rather annoying in that they gain sensitivity twards the extents of the range (which i consider the brute force area used only for hard turns) that could be better utilized elsewhere in the curve. traditionally ive used a linear curve. but ive discovered how advantageous having a big area to work with twards the center can be, so you could fine tune your control. so of those 2 curves id perfer the second (all be it closer to linear).
I quite agree, linear control curve would be perfect if not for the deadzones, both mechanical and electrical.
X52 standard version has a control curve rather close to x^2, probably due to raw Hall effect sensor readings, and I actually use a logarithmic control axis curve in IL-2 to turn it more towards linear one. You might be interested in the fact that the in-game control curve setup there only goes up to 100, but you can manually set greater numbers for a range sensitivity in conf.ini, like this:
[rts_joystick]
1X=0 133 148 146 144 133 123 115 109 104 100 0
1Y=0 133 148 146 144 133 123 115 109 104 100 0
1Z=0 100 100 100 100 100 100 100 100 100 100 0
1RX=0 100 100 100 100 100 100 100 100 100 100 0
1RY=0 100 100 100 100 100 100 100 100 100 100 0
1RZ=0 33 66 83 89 92 95 97 98 99 100 0
1U=0 100 100 100 100 100 100 100 100 100 100 0
1V=0 100 100 100 100 100 100 100 100 100 100 0
FF=0
which IMO works pretty fine with the standard X52.
-
In IL-2, I can never decide if I like HT's first or third one more. They both work well.
-
Sorta odd.. i have preferred setting X45 as follows in il-2
[rts_joystick]
RZ=0 10 20 30 40 50 60 70 80 90 100 0
FF=0
1X=0 1 2 4 7 12 19 30 50 70 100 0
1Y=0 1 2 4 7 12 19 30 50 70 100 0
1RZ=0 1 2 4 7 12 19 30 50 70 100 0
-
A linear "curve" that tops out a bit early (perhaps as a setting?) would be enough for me. The idea is that smaller movements are finer adjustments, wider movements are general adjustments, and that ANY time you bury the stick that you'll have an extreme adjustment. Sort of like flying an actual airplane; if you jerk the yoke or the stick hard to the right, you WILL bank hard to the right. Since Logitech sticks (at a minimum) have trouble staying entirely accurate, it'd be helping out I think.
-
Sounds like you want HT's first diagram then.
-
here's how LOMAC works. deadzone is just like normal, shift is mostly for tweaking aging sticks rather than tuning input response.
default setting
(http://i22.photobucket.com/albums/b345/Klaustrophobia/axiscurve.jpg)
linear (with deadzone)
(http://i22.photobucket.com/albums/b345/Klaustrophobia/axislinear.jpg)
extreme curving
(http://i22.photobucket.com/albums/b345/Klaustrophobia/axisextreme.jpg)
probably about an appropriate level for FS. (user preference though)
(http://i22.photobucket.com/albums/b345/Klaustrophobia/axisideal.jpg)
the main purpose of having this though is to be adjustable, not that everyone should use curved response. i realize it will likely not be as controllable as this, but even a few step levels of adjustment would help for fine aiming with a joystick.
-
All the curves seem to be x ^ n type, seemingly from x^1 to x^10
-
Recall that HT's were only for the positive side of an axis, these seem to cover the negative to the positive. Just in case anyone doesn't realize that.
-
my joystick is fairly linear so i usually just use a flat curve in fs and let the ch profile adjust the gain.
-
on the subject of inputs, how about adding the ability to invert the mouse axis by itself? occasionally i end up using the mouse for fine aiming, but the pitch is backward for me. i find forward mouse = pitch up more intuitive.
-
Sounds like you've been playing too many shooters, Klaus!
-
Amen. :D
-
Sounds like you've been playing too many shooters, Klaus!
or Tachyon
-
Sounds like you've been playing too many shooters, Klaus!
(http://209.85.48.8/10072/112/emo/whistle.gif)
-
id just like to say two words
input overhaul
-
id just like to say two words
input overhaul
That's about as useful as a chocolate teapot. Unless you can give us more information, we can't act on it. What do you want to see?
-
I know taylor talked about a complete overhaul ages ago, although I think he mentioned something about it being tied up with rewriting the pilot file code. Besides the 8-way hat switch support mentioned in the other thread, something that I think would be useful for a lot of people is support for more than one controller simultaneously; as it stands, you have to resort to outside programs like PPJoy to get everything working right. I know a few people have mentioned reverse-thruster support as well.
-
id just like to say two words
input overhaul
That's about as useful as a chocolate teapot. Unless you can give us more information, we can't act on it. What do you want to see?
1: support for more than one joystick
2: separate mouse and joystick bindings (no mixing joystick x and y with mouse x and y)
3: more axis commands (lateral thrusters, vertical thrusters, reverse thrusters, view commands (retail snap, pan snap, relative pan, absolute pan, slew, ect))
4: make it trivial to add more key or axis commands as theyre needed in the future (from c or possibly scripting)
5: ability for scripting to post custom commands to the binding options screen, and reading of these options from scripting
6: config import/export from text file
7: advanced mouse options (privateer style, freelancer style, or standard modes)
8: advanced keyboard axes with custom ramping rate settings
and many more
-
Some controls that differ from available in retail should be masked by default and unmaskable by mods, if they could possibly unbalance the missions by allowing them.
-
The heading is controlled from the mouse cursor, leaving the keyboard for lateral/thrust/brakes commands, this has proved to be very easy way of controlling a ship on other games (for me at least).
-
i'm sure that many people like it the way it is. we are just asking for the option of changing it, not forcing it changed.
-
the point is you can configure it whatever way you want from the existing options screen. default controls would not be changed, new functions would just be added to the list. a good example is the controversial way the view command has been changed since trackir support was added. in retail when you used a view command, your view would instantly change, but now the camera pans to that angle over the course of a few fractions of a second. so you provide one set of view commands for people who like the classic meathod, another for people who like the new setup, people who have a trackir can unbind them all and use the keys elsewhere. people with extra joystick axes could use relative or absolute view axis commands. it s kinda like how things are done in most flight sims, offer more functions than you need, and let the player decide how to configure their controls.
Some controls that differ from available in retail should be masked by default and unmaskable by mods, if they could possibly unbalance the missions by allowing them.
this is a fairly good idea. a mod that doesnt use shields for example, wouldnt need shield commands. so there should be some option for modders to hide those commands to avoid confusing the player. perhaps a controls.tbl. you could exclude, rename, or add commands and type with this table. say a mod wants to call afterburners boosters, does not use shields, and has a vertical thrust axis would use something like this sort of like:
$command: afterbutner
+group: ship
+type: button
+rename: fire booster
$command: equalize shield
+group: misc
+type: button
+remove:
$command: vertical thrust
+group: ship
+type: axis
+min value: 0
+max value: 1
+create:
the first two act on existing commands, the last is a custom command that would show up in the customize controls screen, and its state would be available under scripting (io.Controls["control name"]) or from the mission (commands utilized through the events system). if the new command is an axis, a min and max can be defined, raw joystick data is scaled to the specified range. group and type could probably be omitted on controls that are already in the menu, perhaps you could also move a command to another group with the group option. another command that would be useful is +default: "name of default key,button,or,axis". as it becomes more and more possible for mods to implement custom game functions, a more intuitive way to bind controls becomes necessary for those features.
-
Yup, I've been pondering and discussing this stuff with some people, since it looked like we might be able to expand the hardcoded controls after all. I realized we need to find a way to allow mods to customize what's available, and extending this to existing controls would also be nice, as I know there's a couple retail ones FotG won't need already.
-
i kinda also want to improve input within scripting too. right now we pretty much have low level access to key presses, mouse axes and buttons, trackir and control axes. the problem is they were kinda implemented as they were needed and arent very intuitive or uniform, both for scripters and players, the way they are implemented. on the script side they all work in different ways and arent really consolidated into a simple structure. scripts that i am currently working on use a lua based parser to load a table file containing keybinds, and the only way for the player to configure them is by editing a text file. i consider this a dirty hack. making custom functions available in the control options would make script development a lot easyer (and better for players too, since they dont need to do anything new to use a new feature).
-
I agree with the 1st point : multiple input
New joytick and hotas use multiple input id for each part of it (stick/throttle/rudder) and with the last logitech g940 system you'll loose the force feed back feature with using pp joy.
X52 series is taking ages too and i guess it'll be quite soon before they renew theirs hotas product and i guess they'll use the same thing than logitech.
My x52 is getting more and more crazy and the only thing that retain me from buying the g940 is the fso support, as i ll spend 90% of its lifetime on fs2 ^^
The mod flexibility would be great too !
-
I don't know much about DirectInpit and even less about SDL so I'm not sure how to even approach the multiple stick issue.
As for the different response curves... Could you please answer the following
- What would be the preferred response curve types?
- On what range should these exists?
1: support for more than one joystick
2: separate mouse and joystick bindings (no mixing joystick x and y with mouse x and y)
3: more axis commands (lateral thrusters, vertical thrusters, reverse thrusters, view commands (retail snap, pan snap, relative pan, absolute pan, slew, ect))
4: make it trivial to add more key or axis commands as theyre needed in the future (from c or possibly scripting)
5: ability for scripting to post custom commands to the binding options screen, and reading of these options from scripting
6: config import/export from text file
7: advanced mouse options (privateer style, freelancer style, or standard modes)
8: advanced keyboard axes with custom ramping rate settings
All of these would have to be post 3.6.12 ops.
-
sdl isnt that hard to work with and i think freespace already uses it. heres some code from the nukesim engine.
SDL_Joystick *stick;
int numaxes;
if(SDL_NumJoysticks())
{
stick = SDL_JoystickOpen(0);
numaxes = SDL_JoystickNumAxes(stick);
}
its kinda preliminary so far, this pretty much looks for a joystick, if it finds it it opens the first one, producing a handle, and puts the number of axes into numaxes. for a system which uses multiple joysticks, you get the number of joysticks, iterate through them, count the axes on each, generate some mapping data. to get at the raw joystick data you do something like this:
int joyaxes[6] = {0,0,0,0,0,0};
if(stick && numaxes > 0) //get joystick state
{
SDL_JoystickUpdate();
for (unsigned i=0; i < numaxes; i++)
{
joyaxes[i] = SDL_JoystickGetAxis(stick, i);
}
}
-
FSO doesn't use SDL on Windows, just Linux and OS X.
-
FSO doesn't use SDL on Windows, just Linux and OS X.
why not? sdl works just as well in windows from what i can tell from using it.
-
We've been looking at it, and taylor had this to say (actually, I wish I could find it :P )
Basically, the issue is that SDL support was put in there so that other platforms would work, and so that we didn't break anything, it doesn't change the original behaviour of OSApi.
It'd be a bit of an effort to work around that issue.
-
DirectInput appears (as far as I can tell from MSDN) to work pretty much the same way.
- I've only got one joystick so I can't be sure!