48 replies to this topic

[Loc Nar]

Quote

Is a mouse more accurate then a joystick? Is a joystick superior to a mouse? Well… yes to both. Aaaaand no to both. The real answer? It depends. It depends on what type of movement/inputs the application was engineered around, and the nuts and bolts of how an input device tries to comply...

Greetings Mechwarriors, this is my attempt at organizing my musings on controls into a single entry, doing my best not to sound like a douche. This is the second edition of this, dubbed v1.2. Its is a WIP that represents my *current best understanding of the underlying issues, and no doubt there will be refinements as I move forward. I have a lot of respect for members of MWO and gaming community, and highly value any feedback, corrections, or oversights you want to share. There are no stupid questions, and I welcome scrutiny too since without external pressures to do this better, I’d still be stuck on my partial correct v1.0 (bottom). My intention is not to tell anyone what type of controls are better or worse (hint-they’re all better and they’re all worse! but rather to hopefully clear up some of the persistent myths that have clouded the issues beyond useful discussion in many cases. In addition to needing a basic understanding of the underlying mechanics for our own benefits as users, its also important we know what we’re talking about in case we decide to lend potentially influential opinions on the subject..

What got me going on this was trying to fly my sailplane flight simulator (Condor), between flights in my real glider. Problem is a sailplane cockpit feels and looks nothing like sitting in a chair at a computer, and immersion eluded me despite the rather high fidelity of the simulator. Through experiments conducted while being able to purposefully jump back and forth from RL flying to my evolving glider simpit, I was able to put my finger on what I feel are the key elements necessary for immersion and the list of non-negotiable items was much shorter than I expected. I have found that removing or half assing any of these baseline pillars is pretty much a dealbreaker though. It’s actually not that difficult in many cases to adequately fulfill these minimum requirements, but it may require knowing more about the controls than is common in some cases.

I’m not saying there isn’t a lot more to it, just that these are the bare minimum items I feel need to be taken care of first or else the rest of a simulator project runs the risk of becoming irrelevant. From my experiences, most of what immersion there is to be had comes from these 4 things, and the better they are done the more believable the effect, and like Pareto’s Principal 80% of the result comes from the first 20% of the work. Going beyond these in most cases is an exercise in diminishing returns as far as I can tell, and likewise failure to sufficiently meet the requirements of this list can break the magic of even the most visually detailed cockpit. These are the key to getting to what I call the ‘saturation point’, the subtle point at which one can effortlessly suspend their disbelief and become fully engrossed in the virtual task at hand. To me, this is the whole point of a simulator of any type.

The Essentials for Immersion

1. Correct seating position/ergonomics
2. Believable/functional controls
3. Fill thy eye with screen
4. High fidelity audio

Sounds simple enough, right? Well, maybe not. Number 1, 3 and 4 can potentially be easy since plenty of perfectly acceptable solutions exist, but number 2 is where it can fall apart since controls can be a complicated subject when you examine them more closely, and also I feel the most important item on this short list. I didn’t specify head tracking here, since it’s kinda a cross between lines 2 and 3, but if there is any view panning function in-game, this really should be done with head tracking and almost warrants a entry of it’s own. The interface you use to experience a simulator is not merely there to augment or facilitate the experience, it IS the experience! Failing on any of these, especially controls, is the bonerkiller of immersion and for me killing immersion = killing fun. I’m pretty sure no one reading this needs a screen/monitor lecture and more than likely could lecture me on the subject and its not so hard to come up with good seating or audio; leaving only the topic of controls to expand on.


?.. ?.. ?..

Controls:

When it comes to peripheral controls even in the gaming community there seems to be a lot of partial understandings of what is going on, leading to a lot of confusion on the subject since many people are usually at least partly correct in their assertions, however rarely for the right reasons and nearly always only accounting for a small part of a larger and more complex issue. If your happy with your mouse, keep using it. If your happy with your joystick, keep using it. Is a mouse more accurate then a joystick? Is a joystick superior to a mouse? Well… yes to both. Aaaaand no to both. The real answer? It depends. It depends on what type of movement/inputs the application was engineered around, and the nuts and bolts of how an input device tries to comply. While people can use whatever controls they like and can call it whatever they want, from an objective standpoint different types of control schemes are not arbitrarily interchangeable and do not yield equal results, and it’s important to understand the nuances of these issues..

Up until recently, I’ve mistakenly referred to the input types in layman’s terms, identifying them as either being Relative, or Absolute. While correct on some levels and possessing enough bits of truth to make most people understand what I’m talking about and generally accept my previous explanations, in reality its over-simplification coupled with incorrect nomenclature. For flight related projects, I never needed to know this stuff and I wasn’t trying to learn this much on the subject but through being (rightfully) challenged on my assertions while chiming in on periodic threads that joystick != suck, after making a custom stick just for mech piloting (http://imgur.com/a/ixi64, descriptions in album) and it forced me to look deeper into the problems and solutions in order to back up my claims.

This falls under the engineering field of what are called Human Factors. There’s numerous types of inputs that are recognized in this field which further subdivide into more specific types, of which all control schemes fall into but for the subject of gaming peripherals we really only need to consider a few of the lower order controls. This is an attempt to clarify some facts in the ongoing battle between mice vs joysticks in regards to gaming. Basically, the lower of an order a control is, the easier it is for a human to utilize it for precision tasks, and the orders are loosely based on how many actions are required to achieve the desired effect when used in their native application (things get wonky when you swap as outlined below) or how or how complex it is in general. It’s important to differentiate between these inputs, because they are not particularly interchangeable design criteria and substituting one for the other predictably yields less than optimal results. Identifying the control scheme that any given game or system is engineered around is step one for coming up with viable control schemes beyond the standard options.

Control Types: -attributes (common examples; notes)

zero-order control – manipulates target position. (mouse, touchpad; single input action required)
first-order control – manipulates target velocity. (most joysticks, vehicle throttle; one or two actions required)
second-order control – manipulates target acceleration/rate of velocity change. (car steering wheel, ailerons of larger aircraft)
third-order control – notable lag between control input and perceived action (steering a tanker, trim systems)

Joysticks further subdivide based on their mechanical and electromechanical properties:

Isotonic: cursor moves as a result of movement of the joystick handle. (my mech joystick. other?)
Isometric: cursor moves as a result of the force applied to the joystick handle, which does not move or moves very little (force sensing joysticks -Saitek X65F or Warthog with FSSB R3 mod)
Spring-loaded: resistance is proportional to force applied. Displacement produces proportional inputs, but hands off returns to a neutral position. Offers proprioceptive and kinesthetic feedback. (standard joystick)

As you can probably gather by now, MWO is engineered around zero-order inputs, as are most if not all other shooter games, and many other types and titles. As such, a mouse really is the easiest input device to use, since it offers very high precision, ease of use, and is the most common form of this type of controller so everyone is already set up to utilize this input type.



Well, there are, but a normal off the shelf joystick is simply not one of them. The ubiquitous joystick is a spring-loaded first-order control input device (second-order in some cases, sometimes isometric), and is engineered around very different principals than a zero-order device, and likewise my zero-order mech joystick is engineered around very different principals than a normal first-order joystick. Below I will outline the differences, and why they matter when trying to substitute a first-order controller like a *normal joystick (or just *joystick) for an application designed around zero-order mechanics such as MWO.

Comparing a first-order device vs zero-order devices in a zero-order application:
(aka comparing a *joystick to a mouse in a shooter)

-attributes (effects)

First-Order Controller; Standard *Joystick:

-moves in pitch/roll (unnatural range of motion, not reflexively intuitive)
-Spring Loaded, most likely with detents (fights inputs, negative interactions across the axes center’s)
-requires deadzones (distracting, imprecise, disconnected feeling between inputs and in-game reactions, wasted range of motion, lag)
-fixed displacement generates directional velocity ( ie relative inputs, movements wind up either too slow, or too uncontrollable; difficult not to overshoot past target, requires 2 precision actions to complete one positional change)

VS.
Zero-Order Controller; Mouse:

-moves in x/y Cartesian Plane (natural range of movement of the cursor/reticule)
-no spring centering or detents (nothing fighting inputs, unrestricted movement)
-no deadzones (always in control, precision across centers no different than any other point in x/y, no lag)
-fixed displacement generates fixed position (obvious and easy to control, very precise, requires a single action to complete a positional change)

Vs.
Zero-Order Controller; My Mech Joystick:

-moves in zenith/azimuth (pitch/twist -natural range of movement of the mech)
-Isotonic, with tensioned/greased rubs (nothing fighting inputs, smooth damped movement, always maintains physical orientation related to on-screen state)
-no deadzones (always in control, precision across center no different than any other point in x/y, no lag)
-fixed displacement generates fixed position (obvious and easy to control, very precise, requires a single action to complete a positional change)

For anyone that doesn’t yet understand the significance of zero-order vs first-order controls, here is an analogy. Picture a 12″ square sheet of glass and a marble sitting on it:

Using a first-order controller is like trying to move the marble by picking up the sheet of glass with the marble balanced on it and tilting it front/back and side/side to move the marble, then quickly leveling it again when it’s where you want it to be in x/y coordinates. The more you tilt it, the faster the marble moves and the harder it is to make it stop exactly where you want. Your actions generate directional velocity reactions, proportional to the amount of deflection, which must be quickly brought back level to discontinue the input reaction. Controllers made for this task are specifically engineered to facilitate these inputs with ease. Springs hold it level, obvious centers, deadzones etc, and every convenience feature built into it for this mode becomes a hindrance the second you press it into service as a zero-order.

Using a zero-order controller on the other hand, would be like placing the same piece glass level on a desk in front of you and using your hand to reach out and directly move the marble wherever you want on the plane, and for this reason are also called direct inputs. There is only one action required, and it’s very easy to perform this single action very quickly with very high precision. Just like above though, the mechanical features engineered into these devices produces quite a very specialized form factor to make this easy. Just like above, all the things that make it easy to use for it’s native applications work against you the moment you attempt to use a mouse as a first order controller as I will show.

Working it from the other direction to further demonstrate the importance of using the right control type for a given application, lets examine what happens when you use a zero-order controller like a mouse or my fancy mech stick for a first/second-order application such as Newtonian flight physics.

Comparing a first-order vs zero-order controllers, in a first/second-order application:
(aka flying with a *joystick vs a mouse)

-attributes (effects)

First-Order Controller; Standard Joystick:

-moves in pitch/roll (natural range of movement of the aircraft/spacecraft, reflexively intuitive)
-Spring Loaded, most likely with detents (proportional feedback to mechanically gauge inputs, easy to find and hold neutral position)
-requires deadzones (allows a safe area free of inputs, easy to fly straight, no spamming the axes)
-fixed displacement generates directional velocity ( ie relative inputs, perfectly suited for the dynamics of flight, realistic input>reaction, intuitive control, takes single precision action to perform)

Vs.
Zero-Order Controller; Mouse:

-moves in x/y Cartesian Plane (unnatural range of movement, not reflexively intuitive)
-no spring centering or detents (no feedback to mechanically gauge inputs, difficult to find center/neutral position)
-no deadzones (no safe zone to keep from spamming the axes, very difficult to fly straight)
-fixed displacement generates fixed position (awkward and difficult to control, requires two precision actions to complete a single maneuver)

VS.
Zero-Order Controller; My Mech Joystick:

-moves in zenith/azimuth (unnatural range of movement, not reflexively intuitive)
-Isotonic, with tensioned/greased rubs (no feedback to mechanically gauge inputs, difficult to find center/neutral position)
-no deadzones (no safe zone to keep from spamming the axes, very difficult to fly straight)
-fixed displacement generates fixed position (awkward and difficult to control, requires two precision actions to complete a single maneuver)



This all said, it’s a lot easier for designers to work with higher-order applications such as flight mechanics to be adapted to lower order devices like a mouse, than it is for lower-order application like shooters to be adapted to higher-order controllers like a typical joystick or X-Box controller. Mouse flight can be made to work pretty well, but there is little if anything that can be done to make a first-order joystick better for a zero-order application. I’m sorry to inform those of you waiting for some magic moment with MWO where all the sudden a normal joystick will compete with a mouse, it will never happen, but it has nothing at all to do with analog ‘support’ or anything on PGI’s end like most people assume and some are even holding their breath for. The problem is that MWO is already engineered around zero-order mechanics, and those simply can not be manipulated with a first-order controller to the same degree of precision or ease as a zero-order device.

You can either use a zero-order controller or suffer with sub-optimal results, although one should be careful to use the correct terms when explaining this, unless they’re prepared for a 3000 word essay on why their wrong. To simply say a joystick sucks for MWO is not correct. However to say a first-order joystick even under the best conditions is less than optimal with MWO, is objectively true. The real comparison is not between a mouse and a joystick, but between zero-order and first-order controller, and the first-order controller always loses in a zero-order application. I’m not saying you can’t play MWO with a regular joystick, just understand you really are playing in hard mode if you do. Sure some adapt to it, but mostly by piloting s l o w heavies or assaults since you have to balance reaction speed vs accuracy, usually achieving neither in the process. You can get away with it in an Atlas, but not a Commando…

tl;dr: controls are complicated, but very important to understand. One can adapt control devices to non-native applications, but results will be suboptimal. While less than optimal, its worth noting its easier to manage lower-order devices in higher-order applications, but not the other way around.

About the author:

Some of you may have seen my v1.0 rant on this (http://www.reddit.co...trols_worth_it/), or not. I’ve been talking about this a lot lately, and with the efforts in my mechpit projects (http://mwomercs.com/...440-my-mechpit/, http://mwomercs.com/...57#entry2198157), most notably my mech stick, its no wonder. A little background. I’m an engineering student and I also fly sailplanes as you may have gathered. I’ve been dorking out on sim projects since 2004, and have had the luxury of comparing real sailplane flying to sailplane simulator (Condor) flying over a period of time to develop a basic outline for immersion as well as to help nail down realistic motion control parameters for Ian at builtforfun (http://bffsimulation.com/index.php), who is an instrumental character in the world of homegrown motion control simulator platforms and is the source of most motion platforms extraction parameter software and realistic dynamic motion cuing if you look close enough into most functional motion control cockpits. I’ve worked on other aspects of motion control and control loading projects with RolandVanRoy (simprojects.nl), and designed an analog servo circuit (http://i.imgur.com/gXlN0wu.jpg) that can be used in both control loading (force feedback) as well as motion control applications. It has been tested to good effect, and although not incorporated into any of my own projects as of right now there is a 747 motion platform with FF controls somewhere in Spain based around it and I think Roland has since replaced his LED/LRD (light emitting diode/light dependent resistor) circuits that served the same purpose with them as well

edit: fixed broken picture links...

Edited by Loc Nar, 27 May 2015 - 06:33 PM.

[Foust]

Good read.

[CyBerkut]

Nicely done, Loc Nar!

[Loc Nar]

Quote

I like your articles. I think a simpler message that you're getting at is, a joystick is a best for controlling the rate of change, while a mouse is best for pointing. IE if our primary concern is to control how fast the mech rotated and pitched a joystick is a better device for that application. Though if we want to point to a specific place on the screen (ie aim using the reticule) the mouse is a superior control device. Mice are pointing devices, joysticks are basically throttles which function on two axis. In MWO and most shooters our primary concern is to control the direction we're pointing, not how fast we're spinning to point.

For pointing applications pointing devices will work best, Ie mice, touchpads, touchscreens, digital pens, stylus and tablets. If you primary concern is controlling rate of change a joystick and throttle are great of that application. -Girts N Gravy

Thanks Grits, but I have to do make revisions! To put it as simple as possible, it sounds like this:

A zero order application is best controlled by a zero-order controller, which generated positional information. Examples of zero-order controllers are a mouse, or a touchpad, or can even be a specialized a joystick such as the one I constructed. A normal joystick however is a first-order controller and generates velocity commands instead, which combined with inherent mechanical characteristics that make it excel at being a first-order controller put it at a disadvantage in a zero-order environment such as a shooter game.

Throttles use a friction joint, where normal joysticks use spring centering making the operation of them quite different, although they are generally both first-order controllers which I think is the actual distinction you were trying to make; that they generate velocity commands and not positional ones.

What you're calling pointing devices however is a misnomer. Those are called zero-order controllers, otherwise your assessment is essentially correct, although lacking the inclusion of zero-order joysticks which are just as capable as any other zero-order controller. The terms pointing-device and zero-order controllers are not interchangeable, and making the distinction is important. For instance, a pointing stick is a pointing device, but is a first-order isometric joystick. Also, what you are referring to when you say joystick is the just the garden variety of joystick, a first-order spring-loaded device; but the term joystick covers a broader range of devices than can be bought at Newegg. Without discussing control order along with control devices, discussions essentially amount to something between fluff and misinformation, although many people have at least part of the puzzle already.

[MentalPatient]

Thanks, good read, however I wish someone had told the designers of the mech's about this, maybe they would have just used a mouse instead.

[Odinson]

Hi! Loc Nar, I have read much of your posted material with a great deal of interest, and I think you make some excellent points. However, I feel there are two very important elements you've left out or possibly overlooked...

1) Mice are *not* truly zero-order devices (I'll explain this first)
2) MWO does not use "first order" input (absolute X,Y) in-game

On my first point: a mouse does not generate an X,Y value. It seems to, because you look at a cursor on a screen within a defined boundary and *seem* to be able to simply put the cursor wherever you want. However, the only values a mouse delivers to a computer are X and Y acceleration - in other words, manipulating target velocity. If I pick it up and move it over three inches before setting it back down, the cursor stays where it was - the cursor's position has no correlation to the X,Y position of the mouse. When the mouse stops moving the acceleration instantly drops to zero and the cursor stops in its current position. This gives the illusion of (to use your example) placing the marble anywhere on the plane you want by picking it up, but you actually still manipulated the acceleration of the marble - it just had a mechanism for returning its acceleration to zero instantly.

An example of a true zero-order device would be a Nintendo Wii remote, which uses a camera and a reference point to determine where within the defined boundaries the cursor exists - the X and Y coordinates where the camera "sees" the reference point is translated directly to x and y coordinates on the screen. Direct manipulation of the target location.

Another good example is my Wacom tablet, which places the cursor on the screen at X,Y coordinates directly associated to the X,Y coordinates of the pen on the tablet.

On my second point, I know MWO does not use "absolute positioning" for the cursor in-game, because I tried using a Wii remote set to produce absolute X,Y values and MWO lost its everloving mind and could NOT figure out where my mouse was or what it was doing. If I hit "escape" and got to the menu, the game returns to using an X,Y value for the cursor and I can use the Wii remote, but in-game MWO uses rate-of-change values to move the reticle. So in-game, MWO uses first-order input information. I changed the software I was using to produce X,Y acceleration data instead of X,Y positional data, and BAM it worked exactly as it should.

On an RTS or similar type game (Sim City, StarCraft, WarCraft, The Sims, etc.) where the game uses an "absolute" X,Y value for the cursor all the time - all of those would be closer to a zero-order interface (though still technically not entirely). Any game, however, that has no "defined" screen boundaries (basically any game without a camera "fixed" to a point in the environment) requires first-order input.

The sad end-point of the Wii remote experiment was that it was going to be the foundation for the head-tracking element of my "neurohelmet" VR-build, but once I got done pricing parts the number I arrived at was dangerously close to the price tag of the Oculus Rift developer's kit, so I've scrapped the project.

[Loc Nar]

Quote

Hi! Loc Nar, I have read much of your posted material with a great deal of interest, and I think you make some excellent points. However, I feel there are two very important elements you've left out or possibly overlooked...

Thanks for the kind words as well as the bump, Odinson... it's always a pleasure to discuss these matters with others who care. As much as I like learning new things and expanding my understanding of controls, the parts you think are overlooked are actually on solid ground and you're incorrectly interpreting some of the underlying issues a little, but you are so close to a correct understanding!

Quote

1) Mice are *not* truly zero-order devices (I'll explain this first)
2) MWO does not use "first order" input (absolute X,Y) in-game

1) this is not correct, by default a mouse is a 100% a zero-order controller (explained below, and on page 89 of this book on Human Factors of Engineering)http://books.google....20mouse&f=false
2) no it does not use first-order control, but you misunderstand what that is (more below) MWO using is zero-order control with a restricted range and domain, and contrary to your conclusions it is indeed built on absolute coordinates

Quote

On my first point: a mouse does not generate an X,Y value. It seems to, because you look at a cursor on a screen within a defined boundary and *seem* to be able to simply put the cursor wherever you want. However, the only values a mouse delivers to a computer are X and Y acceleration - in other words, manipulating target velocity. If I pick it up and move it over three inches before setting it back down, the cursor stays where it was - the cursor's position has no correlation to the X,Y position of the mouse. When the mouse stops moving the acceleration instantly drops to zero and the cursor stops in its current position. This gives the illusion of (to use your example) placing the marble anywhere on the plane you want by picking it up, but you actually still manipulated the acceleration of the marble - it just had a mechanism for returning its acceleration to zero instantly.

You are right that it doesn't generate an x/y value, it generates an *x/y delta, which is added to a running total. You are confusing zero-order with absolute values, and they are not the same thing. A mouse is a zero-order controller, but is a relative input device. Relative inputs and zero-order control are not mutually exclusive. Cursor position is directly manipulated in that a fixed displacement generates a fixed *change of position. As a relative device, it is also capable of infinite travel in either axes. The x/y delta is added to a running total via a polling system.

Quote

An example of a true zero-order device would be a Nintendo Wii remote, which uses a camera and a reference point to determine where within the defined boundaries the cursor exists - the X and Y coordinates where the camera "sees" the reference point is translated directly to x and y coordinates on the screen. Direct manipulation of the target location.

Another good example is my Wacom tablet, which places the cursor on the screen at X,Y coordinates directly associated to the X,Y coordinates of the pen on the tablet.

The Wiimote is indeed capable of limited zero-order control (IR tracking), and cabable of more with the WiiMotionPlus module. I had some interesting Wiimote projects ~2008, but just like in your case they became obsolete methods to achieve my objectives by the time the hardware was matured enough to do what I thought it was going to. Pre-motion plus module it was very limited in what it could do though and I needed subtle 6doF 1:1 tracking that was not IR based for my project, but this is all getting further off the subject of MWO and controls.

Your Wacom tablet is a great example zero-order controller, and of a native absolute one. Not sure if you realize, but those can also be run with relative coordinates (reducing it to a generic trackpad in the process, since it's the absolute capability that makes it desirable) where it behaves exactly the same as a mouse where is takes the precise positional delta and adds that to a running total using polling. Both absolute and relative modes are still 100% zero-order control however.

Quote

On my second point, I know MWO does not use "absolute positioning" for the cursor in-game, because I tried using a Wii remote set to produce absolute X,Y values and MWO lost its everloving mind and could NOT figure out where my mouse was or what it was doing. If I hit "escape" and got to the menu, the game returns to using an X,Y value for the cursor and I can use the Wii remote, but in-game MWO uses rate-of-change values to move the reticle. So in-game, MWO uses first-order input information. I changed the software I was using to produce X,Y acceleration data instead of X,Y positional data, and BAM it worked exactly as it should.

Incorrect, and by this I can infer you also do not quite understand what first-order is. First order control means that conrol displacement generates velocity commands rather than positional commands. The further you displace the control, the faster the velocity of the cursor/target/reticule. Analog throttle is a perfect example of first-order control in MWO, where a fixed displacement to your throttle controller generates a fixed velocity of the mech, and the velocity is proportional to the displacement. Going one layer deeper, analog steering is a second-order control, since in that case fixed displacement generates a fixed rate of change (movement about an axis).

Reticule aim however is zero-order control, and despite your perceptions from your experiments it does indeed use a fixed value for a fixed position, ie: absolute positioning (again, just reticule aim, analog throttle is first-order control and analog steering is second-order control) and for this reason is precisely why my absolute value zero-order zenith/azimuth joystick works in the first place. The fixed displacement of my stick reports the same exact values every time. Since MWO *is based off restricted/fixed absolute values, the same fixed numbers my stick generates in turn generates the same exact Cartesian coordinate positioning on-screen, every singe time.

zero-order zenith/azimuth absolute joystick for mech piloting:
(installed in my mechpit, and has >3200 matches on it)

I can't speak on your Wiimote experiments and where that is going wrong for you, but it is leading you to erroneous conclusions. Wiimote hacking is tough enough with titles and applications that have normal support for peripherals... MWO is pretty bare-bones as far as UI/controls go so it makes sense that you are having troubles with it since you are at the mercy of whatever intermediary programming you are using to make sense of it (ppjoy, GlovePIE, other?)..

Quote

On an RTS or similar type game (Sim City, StarCraft, WarCraft, The Sims, etc.) where the game uses an "absolute" X,Y value for the cursor all the time - all of those would be closer to a zero-order interface (though still technically not entirely). Any game, however, that has no "defined" screen boundaries (basically any game without a camera "fixed" to a point in the environment) requires first-order input.

The sad end-point of the Wii remote experiment was that it was going to be the foundation for the head-tracking element of my "neurohelmet" VR-build, but once I got done pricing parts the number I arrived at was dangerously close to the price tag of the Oculus Rift developer's kit, so I've scrapped the project.

As to the games you mention... naturally they are coded for zero-order control as that is the defacto indsustry standard and game companies know that gamers have a mouse handy and nearly all games are catered to the kbm crowd for this reason.

I know I for one am really looking forward to the day I can use my TrackIR5 setup with MWO. I had a neurohelmet all planned too, but there's just no reason yet... sigh. Of course it can be used in emulator mode instead of other zero-order controllers (mice, my mech joystick, your Wacom or other touchpads, trackball, etc...) since it too is a pretty good one, but I much prefer the stick that I made and just want to use TrackIR for head tracking, but decoupled from aiming...sighs again

[Loc Nar]

I kinda need to eat my hat here... MWO does not use fixed coordinates after all. It's been a long time since I've played around with edge behavior testing that I drew my conclusions from, but my recent playing around is inconsistent with what I remember and have been spouting. I either had it wrong initially, or something changed between last year and now, but MWO is definitely coded around relative inputs. It's zero-order yes, but zero-order relative (textbook mouse inputs), not zero-order absolute.

What this means in practice right now, is that any zero-order absolute workarounds (such as my own stick), have to keep the sensitivity of the inputs scaled just shy of what allows full range of torso movement, otherwise it *behaves as a mouse does in this situation, leading to a desynchronization between stick and torso. I've not noticed it all this time because I ran my sensitivities just shy of full range of movement for other reasons -controlability. The extra 5% of torso twist or arm movement was less important to me than having decent control over the range I did have, so I've always run it there and began focusing on gameplay and tactics once hardware was up to speed and paid little attention to this issue since.

Foust's recent experiments with his own zero-order stick (modded T16000M) is what got me to revisit this issue since he was experiencing the decoupling that happens in this case, inspiring more current testing on my own gear and figured I'd update this post since my last entry was basically asserting just the opposite.

Odinson, I apologize... you are correct, MWO is indeed based in relative inputs. The rest of the points I explain are accurate and the gist the same, but on this issue I stand corrected.

The good news is that someday PGI will get around to coding absolute inputs and others may make their own devices to utilize that form of input. The bad news is that would change almost nothing in practice, and an off the shelf spring loaded or isometric joystick will be just as much a fish out of water as it was before. Basically nothing short of making making a stick solves the mechanical disadvantages a native first-order controller has built into it to aid it in it's task, and you will still be playing against twitch oriented mousers.

For my own control scheme it would make almost zero difference whether PGI does it or not. If they don't, my stick will continue to work just fine as is. If they do, it will work *slightly better, in that it will allow me the option of using the full range of motion instead of ~95%. TrackIR or Oculus support on the other hand will be a total game changer, but additional joystick options will change next to nothing in practice since MWO will still be a zero-order application optimized around mice being mostly played by mouse users, rendering the landscape bleak for most joysticks and you'll still basically be bringing a knife to a gunfight...


*when moving torso with a mouse as normal, torso movement stops at the mech's max range in-game, despite continued input by the mouse, however the torso immediately begins moving back the moment the mouse is traveling back, leading to the mouse winding up in a different spot on the mousepad when the torso is centered. No problem, either pick it up and put it back where you want, or 'c' center the torso after sliding it there, but with a stick using absolute mouse emulation (currently the only way to get zero-order control from a joystick) this leads to frequent desynchronization that can only be solved via 'c' centering

[CyBerkut]

Loc Nar, I can't speak for anyone else... but I forgive you. LOL!

Once again... good info.

[Foust]

We are really limited in our options. The only workable solution as Loc Nar has illustrated is to use mouse emulation and limit range of motion to within the torso rotation limits. Not only does this limit that last X% of torso rotation, it also removes the additional range of motion provided by arm mounted weapons.

Even at those limitations it is the best band-aid for making the joystick integration suck less. I think if someone who knew how to code got a hold of TARGET that they might be able to make it better, however we are still at the mercy of how the inputs are handled in MWO.

It is a hard life for a absolute device in a relative world....

[Loc Nar]

Quote

Not only does this limit that last X% of torso rotation, it also removes the additional range of motion provided by arm mounted weapons

Luckily this is not *quite the case. When using a mech with arms, undesirable edge behavior being described does not begin until you move past the *arm's stops. This means that with the appropriate sensitivity settings you get 100% of the torso and the -5% (or whatever amount) buffer comes out of the arm travel.

When I switch between mechs with arms and ones with shields/pods, I still have most of the arm travel I want at the same sensitivity settings, but sometimes bump it up one notch to increase it (under 100% still...) if I'm gonna run them much cause I'm losing a little more than I'd like, but more often than not I just leave it since it's already close.

This is likely the main reason why this was unnoticed by me as well, since I wasn't losing any torso range (ran HBK, CTF, and COM mostly at the time), just some off the ends off the arms which I was already intentionally truncating, but my motivation was the same -to reduce sensitivity to what felt a properly controllable.

Y axis has never been an issue due to the extremely limited range of mech travel in that axis, but even with the generous useable range of motion of my stick in twist (over +/- 60deg) the proportionatly larger range of motion of mech's torso twist had to be dumbed down a bit or it just felt too twitchy.

Either way, its still s a hard life for an absolute device in a relative world though!

[Celtic Warrior]

I'm currently using this configuration

cl_joystick_gain = 2.7
cl_joystick_sensitivity = 2
cl_joystick_throttle_range = 0
cl_joystick_invert_throttle = 1
cl_joystick_invert_pitch = 1
cl_joystick_invert_yaw = 0
cl_joystick_invert_turn = 0
cl_joystick_deadzone = 0.1
sys_MaxFps = 60

it would be nice to add in a control to the torso twist speed. It works alright but I still have a pretty big dead spot in the center. Not sure if its just a cheap joystick or what? Thrustmaster - It is made in china

[Gremlich Johns]

Soooo, as I am using a Logitech Extreme 3D Pro and a razer Nostromo, how might I improve my JS action to exceed the scores in the following matches with only using standard adjustments not involving a cfg file.?




Uploaded with ImageShack.com

Uploaded with ImageShack.com


Uploaded with ImageShack.com

Uploaded with ImageShack.com

Edited by Gremlich Johns, 22 September 2013 - 10:56 AM.

[Loc Nar]

...for some reason this thread is taking a weird turn, so first as a reminder, this is intended to teach people about control order, peripherals, and how it relates to MWO and other games; not about joystick support or tuning, but rather the fundamental underlying mechanics. There are already outlets for joystick support, but as far as I know this is the only thread that gets into the subject beyond surface issues...

Quote

how might I improve my JS action to exceed the scores in the following matches with only using standard adjustments not involving a cfg file.

..by using a TARGET enabled stick or similarly functioned comprehensive emulating software I'd assume. As to it 'improving' your game, there are more variables than that however you would likely gain mechanical advantages not previously available to you if you are using the in-game bindings and logitech software...

If you can do the above scores a using first-order control scheme, you would be top league using a proper zero-order setup. I pretty consistently have decent dmg games, but if I were using your setup I don't think I could do anywhere near as well as you do with it. I look forward to when we can set up private matches and such... it would be fun to do duals and whatnot.




...however running slow mechs like Atlases or Hunchies seems to be a somewhat typical adaptation to the limitations of using first-order control in a zero-order environment so my question is can you also do it in fast mechs?

[Galil Nain]

Firstly, a HUGE thankyou for putting this out here in easy to understand (unless I've got what's below totally a**-backwards) English.

However...

I'm not sure if I'm misunderstanding this, or if this particular use case was not applicable to the explanations given thus far:

Given a situation where a pilot is operating with arm lock set to OFF, I can fully see that control of the ARM reticule is zero-order, but how about the TORSO reticule? It lags behind the arm reticule, moving relative to its position, and seems to move more rapidly the further the arm reticule is from the torso reticule. Does this not imply that in an "unlocked arms" situation, torso movement is first- or second-order, rather than zero-order?

Or have I completely misunderstood and need to re-read your explanations again after a few more sizable doses of caffeine?

[Loc Nar]

Quote

Given a situation where a pilot is operating with arm lock set to OFF, I can fully see that control of the ARM reticule is zero-order, but how about the TORSO reticule? It lags behind the arm reticule, moving relative to its position, and seems to move more rapidly the further the arm reticule is from the torso reticule. Does this not imply that in an "unlocked arms" situation, torso movement is first- or second-order, rather than zero-order?

Thanks for the kind words, and the the question. I wish there were an elaborate answer, but this one's pretty easy. Arm and torso aim are actually no different from each other than the speed that they arrive at their destination, to simulate the fact that the arms are lighter and the mass can moved quicker, and also that the arms may also be able to extend beyond the arcs of the torso.

The positioning mechanism behind them is no different though, and both are zero-order relative inputs in this case, but it sounds like you understood it all well enough to avoid a second helping, so log in and burn some armor instead. Zero-order is not characterized by response time of target, but rather in that there is a direct correlation between the displacement of the input device and the target position.

A slow slow Atlas is just as much under zero-order control as a zippy little light, even though you can apply a full input, go pour a cup of coffee and come back to the computer as it's completing it's task of turning the arms and torso where the light moves almost as fast as the inputs. What matters is that the same input displacement achieves the same mech torso travel. If your mouse accel values are 0, the inputs always produce the same results regardless of input speed. Even with those tweaked it's still zero-order, just no longer linear in regards to speed of inputs.

Perfect segue... you mention armlock, and that complicated matters for this scheme and punctuates the above points. Among other things, mouse accel values are automatically bumped up (despite setting to 0 in the menu) and the response becomes less linear the faster it is input and results in different mech positions from the same displacements but at different speeds. It's pretty annoying actually. Subtle/slow inputs are the unchnaged, but increasing speed of them proportionally amplifies the effect and even one single sharp/fast input with arms locked is enough to misalign the center bad enough to need to 'c' center it back again.

...Luckily it's a feature that amounts to a downgrade of performance and make mechs harder to precisely control instead of easier (why they do this by default to noobs is beyond me), so I don't have to deal with any negative effects or feel like I'm missing anything by never using it.

[Galil Nain]

Thanks for the rapid response... 'tis a shame that I didn't post my question and wait for the response before posting this in the suggestions subforum. That being said, I'd appreciate your thoughts on it as an idea?

[Loc Nar]

Quote

That being said, I'd appreciate your thoughts on it as an idea?

When I first skimmed your post I didn't get it, but I see where you're going there. Independent L/R zero-order aim for the arms, and separate torso zero-order aim, in this case using scrollwheels (scrollwheels are also zero-order...) to affect it.

Assuming a suitable controller scheme could be mapped to MWO and it supported it, it wouldn't be ideal because everyone else is performing much simpler tasks and you would be flailing around shooting off your own feet while getting focused down by mechs in 'easymode', however this doesn't mean a mech combat simulator couldn't be built this way, or that it wouldn't be fun.

If all the mechs were controlled this way, then it would be pretty interesting since everyone will be flailing at first and a bunch of new tricks would need to be learned by all, but does sound like an awful lot of things to manage and I'm not sure would appeal to most. If such a game existed however, I would certainly try it, and if I liked it I would adapt my cockpit for it. While there would be many ways it could be handled, naturally a dual stick version of my zero-order getup would be the first place I would go with it!

[Koniving]

Loc Nar, on 19 May 2013 - 09:34 AM, said:

Zero-order

I've got a request. Trying to find joysticks by Zero-Order or Zero Order as part of their description is very difficult. You would think this would be a bragging right or selling point for their joysticks. Is it possible that they use other terms to define joysticks as first order, second order, third order and zero order?

Do you have a list of joysticks that are zero order? I desperately want one.

Edited by Koniving, 03 November 2013 - 08:12 AM.

[Loc Nar]

Quote

I've got a request. Trying to find joysticks by Zero-Order or Zero Order as part of their description is very difficult. You would think this would be a bragging right or selling point for their joysticks. Is it possible that they use other terms to define joysticks as first order, second order, third order and zero order?

Do you have a list of joysticks that are zero order? I desperately want one.

Thanks Koniving, I hope I can be of help on your quest, but there are no easy answers here. It will be next to impossible to use zero-oder as a descriptor for a type of joystick searches since it's not so much a type of stick as much as a mode that a stick can operate in. Technically any joystick returning absolute values for a positioning task (such as reticule aim in MWO) is a zero-order joystick, and the real differences are mechanical ones since the different tasks spawn very different mechanical arrangements to keep from failing in ergonomic implementation. Unfortunately sticks optimized for positioning as opposed to vectoring can not be bought since *no one makes such a creature that I know of.

To complicate this further, for MWO, the only way to currently even use absolute inputs is by using mouse emulation. For any TARGET capable stick (Thrustmaster Cougar, Warthog, or T16000M) this is as easy as pie, but all other sticks require the use of 3rd party emulators that allow control over axes to allow absolute inputs, such as evilC's UJR, JoystickMouseTool, or Joy2Mouse, but I only have experience with TARGET.

What makes my own joystick unique and why I call it a dedicated zero-order joystick is because I constructed the gimbals to be purpose-built for positional pointing tasks while using absolute inputs -ie: zero-order control. As such, my stick moves in the natural ranges of motion as the mech's torso I am controlling, with pitch +/-15deg and yaw +/-45deg, and since these axes do not have springs forcing them back to center they are called zenith/azimuth, more like a telescope base than a normal joystick. Also as such, it's just as much a boat anchor in a flight application (or any other vector based application) as a normal joystick is for reticule aim in MWO.

Instead of spring centering, I have highly damped friction rubs that make the stick move very smoothly, but hold whatever position it is left in while I am not moving it and also have no tactile indication of center so there is no difference in resistance/feeling of movement, regardless of where I am in x/y on the stick the same way there is no varying influence to the movement of a mouse regardless of where it is on the mat.

This all said, if you are looking for a reasonably priced/accessed version of a zero-order *optimized stick, I suggest looking to Foust's work he has done with the T16000M. By removing it's centering spring and in it's place putting a plastic donut shim to induce friction, he has effectively and simply modded the gimbal to aid in the task of absolute positioning. The T16000M is kind of a must have stick IMO in general, as it lets one explore complex control schemes regardless of a games state of support or lack thereof. TARGET is already better 'support' than fully fleshed out AAA titles generally get anyhow...





*I say makes, however the Steel Battalion controller was such a device, however if Golden Gun, Von Pilsner, and Hack-n-fly's experiences are anything to go by, it looks like the software side of it is more complicated and likely less rewarding than physically modifying the SB controller with the guts from a T16000M would be, as suggested in this post in my mechpit thread.

Edited by Loc Nar, 03 November 2013 - 12:50 PM.