Or you could set up a junction point...
When working on StatusDisplay, specifically when defining the flags for the settings save file, it struck me that the flags at bits 24, 25 & 26 are already wasting space - and could offer more.
Each "vehicle" is mutually exclusive, therefore only one flag can be set at a time. With this in mind, the three flags could be reworked to be treated as a 3-bit binary value, i.e. from 0 to 7. This would offer scope for 5 more vehicle types (or even "on foot"! ) with no extra flag requirement.
Similarly, flags 17 & 18 could offer 4 different values, i.e. 0 = FSD inactive; 1: FSD Charging (SuperCruise); 2: FSD Charging (HyperDrive); 3: FSD Cooling.
That is a level of optimisation that doesn't fit at all with the current: 'parse a json file'.
If we are to propose a change in that, I'd go for defining custom fields and get rid of the flags at all, it is inefficient anyway.
Just remember you have the docking status as a flag (bits 0,1), in the location event (as docked), as the loadgame event (startlanded) and as a full dock/undock event..
You make a good point though - bits 0 & 1 of the status.json flags could offer 4 states rather than 2....
haha, I swear, I thought you were going to notice it and point this out!!!
I'll start this time:
0 not docked
1 docked (pad)
2 landed (planet)
3 bugged (inside the planet)
we are missing the canopy breach flag as well, or running on emergency oxygen.
With that in mind, would it be possible to add a couple more flags?
27 134,217,728 0800 0000 FSD Charging (HyperJump)
28 268,435,456 1000 0000 HyperJumping (currently shows "Flags":0)
29 536,870,912 2000 0000 Ship Shutdown (by Thargoids)
30 1,073,741,824 4000 0000 Hyperdiction
31 2,147,483,648 8000 0000 Game Client Closed
Nice to haves would be other numeric values:
"Throttle":[throttle setting in range -100 to 100 (%)]
"Speed":[in relevant unit for current space]
.... and a little more precision on heading would be great, recognising that it does not need to change on the HUD and that position data precision already exceeds that of the HUD....
Indeed. They'd make good display elements for my program.
I made an early suggestion for more flags / values here:
Alongside the speed, I think having exported the translational and rotational acceleration would help for sim cockpits a lot, kind of FFB, but I'm afraid we are running into having a constant modified file which renders the 'output file' format extremely dangerous for the disk.
Where is the old udp broadcast method used by every other 'sim' out there!!!True. Which is where an official API to retrieve game published information directly from the client without resorting to disk would be very good - or being able to redirect the transient files published at high frequency to a ram-drive.