Per title, we need to be able to zero our FoR for combat - especially when when flying HOTAS (or any controller, really).
Currently, the only way to dogfight is the FE2 / FFE method of last resort - manual thruster control.
- you're interdicted while en route in autopilot
- you switch to manual engine control and apply discrete thruster burns to manoeuvre
- for me, this means moving my joystick off the desk and grabbing for the mouse and keyboard, oldskool style-e.
So it's do-able, as it ever was... for us old timers that know what we're doing. But it's also tedious, not as much fun as it could be, and a major turn-off for newer players - especially those who may be coming from ED and looking for something less arcadey, but still playable with their HOTAS kit.
The solution is very simple:
- add a control to zero the current FoR - in other words, set the velocity reference frame to whatever your current vector at the moment the feature is selected
- i'm interdicted while en route; my current velocity is 10e05 km/s (or whatever high speed) relative to my current navigational FoR (nearest / largest body, per usual)
- upon disabling autopilot, preparing to engage, i 'zero' the set velocity FoR. My ship now considers my current velocity to be stationary. My new FoR is whatever my vector was the moment i hit the reset button.
In reality my velocity hasn't changed. I'm just pretending - temporarilly, for the sake of combat - that i am now stationary, and everything else is moving around me. Any further accelerations i make from now on will add or subtract velocity to that selected FoR snapshot.
I can now dial in a "set speed" of say 50 m/s if i'm in a less agile ship, or maybe 500 m/s or more if i'm in a more manoeuverable fighter.
Now my ship will be using all of its thrusters automatically to manoeuver relative to the other combatant/s, and from my piloting perspective i'm "dragging my heading vector", with the degree of 'drag' being a function of how fast i turn relative to my 'set speed'. This provides the intuitive, instantly-familiar form of 'pew pew' flight control for which a HOTAS is perfect, but likewise benefits all input methods, mouse and keys included.
Anytime i mess up and the 'skidding' gets too much, i can just re-zero the FoR and instantly regain control and my bearings. Let my adversaries worry about any resulting velocity discrepancy. Instant restoration of 'Buck Rogers' style handling, at the touch of a button. "This is now stationary". "Actually, no, not that, this." Wherever, whenever, bang, done. Dial in whatever new set speed seems sensible and manageable and appropriate to one's immediate needs, a couple of hundred meters / sec, say, and you have turn'n'burn dogfighting manoeuverability with full thruster automation (ie. useful flight assist) IRREGARDLESS of your presently-irrelevant interplanetary navigational FoR, or whatever your prior vector. Even if you're plummeting in free-fall through the corona of a red giant, or wherever.. you're the pilot, so should be able to exercise your choice of the most relevant FoR for your current needs and desires.
For clarity, the FoR is only zeroed the once, the moment it is selected - all accelerations made post-selection add or subtract to that specific 'snapshot' vector - which can likewise be reset again at any time.
This means i can keep flying HOTAS, while maintaining rational thruster control, in a more intuitive dogfighting style, per ED et al.
You shouldn't have to literally decelerate from interplanetary velocities down to 'absolute zero' - which in reality, is itself just another relative vector (all of which are ultimately notional, after all) in order to retain the benefits of the "set speed" mode at all times. An FoR doesn't have to be a real body, it is just another vector we're pretending is zero.
After the pew-pew i could then just re-select my navigational FoR by re-engaging autopilot - my velocity automagically jumping from a few hundred m/s back up to interplanetary speed by simply discarding the made-up FoR and switching back to the normal, objective ones..
A related, complimentary feature here would allow pilots to also select any objective FoR at any time. For instance, you could set it to a space station or small moon in a situation where the FoR wasn't switching effectively itself (as used to happen in FE2, and still sometimes arises in Pioneer). But equally, that station could be on the other side of the system... "useful" need be no bar on "possible", and from a purely gaming perspective, is arguably subjective anyway. Likewise, if i set my FoR to an accelerating body such as another ship, up ahead, while dialing in a 'set speed' of zero, my ship will effectively tail the other, automatically attempting to hold a constant distance from it.
This adds good 'gaming bandwidth' for imaginative engagement capitalising on what's already there and possible. You could shadow another craft at a safe distance. Or maybe effectively 'tow' one craft by making it follow another. Little convoy parades, even.. Obviously, this kind of FoR versatility will be an inevitable requirement for any future ship-ship docking, carrier-launched fighters / shuttles or AI wingmen / wings... but also naturally falls out of the existing mechanics.
These kinds of refinements are kind of already implicit conclusions of the current design, almost made conspicuous by their absence, if you get my drift.. it's where the thing's going already, where it wants to go, inexorably, if i may be so bold.. if but for a gentle nudge or two in the right direction..
Finally, another useful addition would be a 'hold acceleration vector under free rotation' mode.
This would allow free rotation of the craft in all 3 axes, as when free-floating, but while using all the available thrusters to maintain an acceleration vector and controlled flight. So that vector could be a manual preset heading, or else the ship could be on autopilot, following its set course, while still alllowing me to rotate in all axes and thus shoot (or just look around) without breaking course. If landing on autopilot, it could override the free rotation mode when deploying landing gear, in order to force landing alignment.
Analogue thruster control would also be a boon - i currently use Mad Catz / Saitek input mapper to add 'bands' to my HOTAS throttle, mapping low forward / reverse thrust either side of a wide dead zone, and full thrust at the extremes, but with only 'hi, lo or off' it's a bit clunky. The 'set speed' mode is of course more practical in most circumstances but 'manual' remains more intuituve in certain conditions, such as during launch / lift-off. Analogue full and half-axis throttle control would be sweet (could also map it to my pedals, for instance).
And head-look for cockpit mode!!! Even just rudimentary mouse-look, would enable head tracking and be so cool (i'm sure it's on the to do list)..
Loving the game so far, it's the ONLY antidote to ED's game-destroying compromises IMHO. Spaceflight is kinetic energy control. Take that away and all that's left is a kind of 'no clipping' mode - in ED's case with a weird droning noise, and no autopilot. Watching your ship make a real re-entry and approach, using real thrust to scrub off real KE, at realistic magnitudes.. seamlessly... just breathtaking, each and every time. The only innovations E4 needed, IMHO, are the fllght control refinements mentioned above... and Pioneer is almost there already..
Beg your pardon; "frame of reference". The velocity reference vector.
Well, just had a play with the mouse look, works great, although there's a big pink ball sitting alongside me in the experimental cockpit view.. minor concern for now. However i can't work out how to toggle mouse look so that i can set it up with TrackIR..? Double-click MMB to toggle/hold would be convenient, or else a toggle/hold option in the config..
So... being able to set your FoR to another ship - such as an opponent - gets us halfway there to the solution i'm suggesting is already implicit; it's a useful and logical feature in its own right - any objective FoR should be selectable at any time - however it still doesn't quite fit the requirement i'm describing, because it's not specific to you and your ship, but dependent upon the reference ship's own accelerations.
Definitely still a useful mode, especially for combat..
What i'm suggesting is a 'virtual' reference frame that can be switched to anytime anywhere, and which is taken from the ship's current vector. In effect, it would simulate the effects of instantly coming to a full stop - at least, from your instruments' point of view.
In reality, your physical velocity hasn't changed; instead, the objective reference frame (planetary body or whatever) your velocity was being measured relative to has been temporarilly suspended - in place of an 'imaginary' body relative to which you are stationary at the instant the mode is selected, but which you then accelerate relative to when applying further thrusts. A virtual reference frame, with its own vector, that coasts onwards on whatever course and speed you were at when it was set, and which can be likewise reset at any time.
So it's not using another ship as a static reference, but more like adopting our own ship's rest frame; however it's not quite that either, since the rest frame is always considered stationary; here, we're taking the instantaneous rest frame - at the specific moment the mode is selected - and just letting it roll, as if your rest frame is a superimposed ghost that you will depart from when applying any thrusts.. it'll just float onwards, passively, an invisible, virtual velocity reference in the same way as any other, but which can be reset at any time.
It's just a disembodied free-floating vector, taken from the ships current vector at the moment it is selected, and used as a temporary static reference in order to accomodate the handling advantages of a comparatively low 'set speed' independently of the current 'actual' velocity relative to an objective FoR (planet, station, ship or whatever).
The objective point in all this is simple - at lower 'set speed' modes, the ships handle with the kind of intuitive responses that folks can instantly get to grips with. It's Biggles in space, there's a clear and intuitive tradeoff between momentum and manoeverability - the faster you go the more you 'skid' etc., so that makes for instantly accessible gaming, with well-defined bounds and causation.
At navigational velocities however the 'set speed' mode is worse than useless. To be fair, it's an entirely innappropriate mode for any en-route fracas anyway, but, if you're interdicted, it's that, or manual thrusts. Joystick aside, mouse and keys at the ready..
So, rolling the current vector into an independent, virtual FoR, instantly restores the handling benefits of a low set speed.
To make a really bad analogy, it'd be like being able to instantly re-center the 'blue zone' handling envelope in ED (spit), at any time. The ship still 'knows' my actual velocities, likely relative to every other entity in the system, but the only one it's displaying is relative to a disembodied floating FoR that is where my ship would be if i hadn't applied any thrust since generating it.
To make the function more useful, instead of simply zeroing the FoR, it would be handy to be able to set a preset default speed, that can be eaily varied. Hit a button on the controller and you're instantly at 250 m/s, or whatever your optimal 'blue zone' (spit). Hit it again and you're back to ludicrous speed. Your actual speed is irrelevant - your 'global' speed needn't restrict your 'local' handling performance envelope. Delineation of functional and virtualised FoR's is the key...
...another way to conceptualise what i'm on about, would be to suppose that, upon the push of a button, my ship releases a particle. A minute spec of dust, little more than an invisible pixel, that is stationary relative to me at the moment it's spawned, and which my velocity can be temporarily referenced to, independently of anything else.
Because it's invisible, and stationary relative to me at the instant it's spawned, it could be local or distant; we could even spawn an actual object, far away on the other side of the system - a rock or something - so long as it's stationary relative to our ship at the moment it's spawned, its location is irrelevant, it's just a throwaway reference frame to temporarily accord the familiar 'planes in space' handling of a low set speed, nested within a higher-velocity (ie. interplanetary) refererence frame.
The user interface could continue to display the velocity from the current FoR as it does presently, but with the addition of a 2nd tier FoR displaying the parent (ie. navigational) FoR.
This basically expands upon the fact that we already have nested FoR's - so for instance, we begin a station approach from a stellar FoR, following hyperspace. En route we may pass through other FoR's from planetary approaches, and so these become the primary FoR and the stellar FoR is relegated to the 2nd tier display.
As we approach a moon, that becomes our primary and the parent body, the secondary FoR. Likewise for appraoching a station around that moon - the FoR priorities shift as usual, but while retaining display of the previous FoR that the current one is nested within..
You could go silly with this feature and continue adding tiers dynamically as appropriate, so that in a complex of nested orbits the tiers between your current FoR and the stellar baseline could really stack up... but that's useless information to a pilot, only of academic interest. Two tiers is enough to provide the logical framework for the player to grasp the relationship between FoR's and ship speed / handling, and thus how a virtual FoR works to their advantage.
This ability to freely and instantly recover to a stable handling envelope may seem like a cheat, however it's one that's implicit within nature - simply exploiting the fact that velocity is entirely subjective, and can even be notional.. so long as you're in no imminent collision danger. It's kind of a 'win' button for getting the most fun from the game's available mechanics. In terms of risk / benefit or cost / reward, it's a clear trade-off between the benefits of twitch-response gameplay, at the expense of temporarily neglecting navigation. For example, deploying a virtual FoR in stable orbit would be failry low risk, while doing so on approach would be high risk, and you'd need to keep an eye on your velocity relative to the planet.
The basic point is that the game already accomodates the kind of pew-pew handling that certain parties have contended is impossible in a game with realistic spaceflight. And this seems to have cemented a general consensus on the issue - that you can have arcade or realistic fun, but not both at the same time. But that conclusion is predicated on the assumption that velocity is some kind of objective absolute - that one must possess near-zero momentum relative to the vacuum itself in order to retain fighter-jet handling, and that once you're at high velocity relative to some arbitrary reference, the laws of mechanics somehow change (seriously, Michael Brooks told me he thought acceleration really was velocity dependent). But motion and thus speed is arbitrary - anything anywhere can be at all possible velocities simultaneously relative to anything anywhere else - and virtual FoR's are the artifice we need to bridge the otherwise-conflicting nature of dynamically-varying local vs global (ie. combat vs nav) priorities..