Discussion Journal Documentation for v3.0

Or you could set up a junction point...

I know. I also know, how to move the folders inside the user folder.

But there are many people outside, who dont know about this.
Maybe most of the writes happen inside cache. But there are also many SSDs without cache outside... Also nobody knows how SSD controllers work. If you write some bytes every second, the chance your data is written directly to SSD is very high.

But it seems, frontier devs dont care about this.
 
Still no answer to my question: Will there be a option to move the commanders log directory?
I use a SSD and dont want to use a software which writes every second to this disk.

Yes you can!

You can move your "Save Games" folder to somewhere else :)

M0BqdXP.png
 

Robert Maynard

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

Robert Maynard

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

Fair point. However a dozen or more characters for a single bit of useful information seems wasteful, to me at least.
 
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.. :)
 

Robert Maynard

Volunteer Moderator
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.. :)

True - however it'd be nice if status.json was self-contained (i.e. could be used to provide vehicle state without resorting to parsing the journal).

You make a good point though - bits 0 & 1 of the status.json flags could offer 4 states rather than 2.... ;)
 
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)
 

Robert Maynard

Volunteer Moderator
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)

:D

When defining the flags for the settings file for StatusDisplay I chose to define a zero value (for multi-flag-bit values) as "error" and limit the possible valid values to ((2^bits)-1).

I'd like to see some flag-bits assigned to the current "space" that the player is in, i.e.:

0: "normal" space;
1: Glide;
2: SuperCruise;
3: HyperJump.

This would always be 0 for the SRV and SLF.
 
Last edited:

Robert Maynard

Volunteer Moderator
we are missing the canopy breach flag as well, or running on emergency oxygen.

Indeed. They'd make good display elements for my program. :) Also life support time remaining.

I made an early suggestion for more flags / values here:

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]
"Temperature":[percentage]

.... 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.... ;)
 
Last edited:
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 or OS because of the file system constantly smashed.
 

Robert Maynard

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

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.
 
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.
Where is the old udp broadcast method used by every other 'sim' out there!!!
 
Top Bottom