Some quick notes:

You can set your FoR to the opponent with ctrl+leftmouse, which makes combat much easier.

Headlook is there, with the middle mouse.

Wow fantastic, will go have a play with both right now...

What is "FoR"?

Frame of Rotation?

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..

Ah, yes I've been meaning to add a toggle mouselook for a while now because the hold+drag doesn't work with my wireless trackball.

Right now it's not possible.

Ah, yes I've been meaning to add a toggle mouselook for a while now because the hold+drag doesn't work with my wireless trackball.

 

Right now it's not possible.

I also bought a trackball recently. It has only two buttons, so a mouselook toggle would be very handy for me too.

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..