Discussion Commanders log manual and data sample

[hchalkley]

Looks like there's a bug:
[...]You can see that "Faction" is supplied twice. I assume that this is because I used a KWS.
From my point of view, the preferable way of fixing this would be to provide a per-faction breakdown of the bounty[...]

Thanks, I'm on it, will do an array as you suggest (for beta5)

 

[Arubeto]

Howard, can I ask a question about something you wrote earlier?

In post #225 you did a small Q&A and wrote:

Q: Will player journal be available in game?/So when are we getting an in game UI for this?
A: This is likely to be added in the future, there’s no ETA at the moment.

Does this mean you are going to introduce a "native" player journal within the game in addition to the tools the community might create?

I'd love to see some "official" journal feature integrated in the game! It's not that I don't like EDDiscovery etc. - I love and use them a lot, actually - but having to tab out of the game to look up an entry is a little jaring and having an in-game journal nicely integrated into the existing menus and HUD would be totally awesome!

 

[iveinsomnia]

Just a little idea for the systems log "problem" (to get more basics details when you arrive in a system, mostly for the already know systems)
Juste add a second log, as for the market "traderoute" file:
"C:\Users\<username>\AppData\Local\Frontier Developments\Elite Dangerous\<userID>"

A single file who update itself every system (no additive, juste replace it) that allow us to see "we are in a new system, I load this file, check datas, close it until the next know system"
Of course the file should be placed in the folder as for the journal event log.
No heavy charge for the game, no heavy files, simple (same json system).

 

[Toumal]

I did a test with the currently existing damage events and... well it's better than nothing, but I think there's a huge potential if very small json events would be added for individual weapon impacts. Note that it would be sufficient to collate them into one event per 50ms. With today's write caches you wouldn't even cause any extra disk head movement, and SSDs are fine with that anyway.

Currently we get one event at every 20% of hull damage. I've made it so there's a damage "flash" effect and then a bit of red blinking, but as you can see there's so much potential for REALLY doing impressive light effects if we had individual impact events.

[video=youtube;1qs1zQLBQjE]https://www.youtube.com/watch?v=1qs1zQLBQjE[/video]

An example for a WeaponImpact event:

{ "timestamp":"2016-07-25T14:46:23Z", "event":"WeaponImpact", "Shields":0, "Hull":0.75, "Weapon":"PulseLaser", "SpecialEffect":"ImpulseAttack" }
{ "timestamp":"2016-07-25T14:47:01Z", "event":"WeaponImpact", "Shields":0, "Hull":0.62, "Weapon":"SeekerMissile", "SpecialEffect":"" }

This would also make the current HullDamage event obsolete.

Also, I'd like to reiterate the benefits of having start&stop events for things like FSD Boost charge state, Interdiction, Supercruise and Hyperspace jumps. Hyperspace in particular would benefit from an event sequence like this:

{ "timestamp":"2016-07-25T14:46:23Z", "event":"FSDChargeStart", "StarType":"K", "TargetSystem":"Sol", "Distance":123, "State":"Boom" etc...}
{ "timestamp":"2016-07-25T14:47:01Z", "event":"HyperspaceCountdown5"}
{ "timestamp":"2016-07-25T14:47:01Z", "event":"HyperspaceCountdown4"}
{ "timestamp":"2016-07-25T14:47:01Z", "event":"HyperspaceCountdown3"}
{ "timestamp":"2016-07-25T14:47:01Z", "event":"HyperspaceCountdown2"}
{ "timestamp":"2016-07-25T14:47:01Z", "event":"HyperspaceCountdown1"}
{ "timestamp":"2016-07-25T14:47:01Z", "event":"HyperspaceCountdown0"}
{ "timestamp":"2016-07-25T14:47:01Z", "event":"HyperspaceJump", "StarType":"K", "TargetSystem":"Sol", "Distance":123, "State":"Boom" etc...}
{ "timestamp":"2016-07-25T14:47:01Z", "event":"HyperspaceExit", "StarType":"K", "System":"Sol", etc.}

...as well as a possible...

{ "timestamp":"2016-07-25T14:46:23Z", "event":"FSDChargeAbort"}

There's a bunch of events that would be made obsolete by this too.

What do you think?

 

[Genar-Hofoen]

EDIT: Scrap this whole post - it's because I'm testing the line by creating a string literal and feeding that to my parser for testing.

Thanks to OtisB for the heads-up!

*headdesk*

Spoiler

Howard,

The Fileheader, specifically the language section, you have two escaped backslashes, and Python json.loads() is breaking because of it.

Example:

{ "timestamp":"2016-09-24T11:56:19Z", "event":"Fileheader", "part":1, "language":"English\\UK", "gameversion":"2.2 (Beta 3)", "build":"r121970/r0 " }

Which generates:

"ValueError: Invalid \escape: line 1 column 90 (char 89)" if I feed that line to json.loads()

According to this StackOverflow question, there should be four backslashes in a properly formatted JSON line :

http://stackoverflow.com/questions/...sh-in-json-string-in-javascipt-and-python-2-7

(EDIT: json.loads() works fine when I add the two extra backslashes)

Is it just down to me using Python (affects javascript as well) or is that incorrectly formatted JSON, as the Python json library is suggesting?

 

[themroc]

Edit: invalid bug report

 

[Andargor]

Howard,

The Fileheader, specifically the language section, you have two escaped backslashes, and Python json.loads() is breaking because of it.

Example:

{ "timestamp":"2016-09-24T11:56:19Z", "event":"Fileheader", "part":1, "language":"English\\UK", "gameversion":"2.2 (Beta 3)", "build":"r121970/r0 " }

Which generates:

"ValueError: Invalid \escape: line 1 column 90 (char 89)" if I feed that line to json.loads()

According to this StackOverflow question, there should be four backslashes in a properly formatted JSON line :

http://stackoverflow.com/questions/...sh-in-json-string-in-javascipt-and-python-2-7

(EDIT: json.loads() works fine when I add the two extra backslashes)

Is it just down to me using Python (affects javascript as well) or is that incorrectly formatted JSON, as the Python json library is suggesting?

Perhaps the language field should be using standard language codes, such as en-GB, en-US, fr-FR, and so on.

Also see IETF Best Current Practice 47

EDIT: Or perhaps avoid backslashes altogether and use forward slashes, e.g. "English/UK"

 

[Genar-Hofoen]

Never mind - I am and idiot.

Ugh.

 

[eventure]

The body parameter of the "SupercruiseExit" event is really wired. Once it is the correct planet name, you are close to, or the other time it is a station name, or the star system name.

An example for body = system name (exiting not close to a body):

 "timestamp":"2016-09-25T09:09:53Z", "event":"SupercruiseExit", "StarSystem":"Flech", "Body":"Flech" }

An example for body = station name (exiting close to a spaceport):

{ "timestamp":"2016-09-25T09:28:37Z", "event":"SupercruiseExit", "StarSystem":"Flech", "Body":"Saberhagen Port" }

The station "Saberhagen Port" is close to the planet "Flech 2".

An example for a proper body name (exiting close to a planetary installation):

{ "timestamp":"2016-09-25T09:48:11Z", "event":"SupercruiseExit", "StarSystem":"Oto", "Body":"Oto B 4" }

I would suggest to call the parameter "InnerSystemLocation" instead of body, or leave it blank, if the position of a player is not close to a stellar body.
Otherwise please define, what "Body" is. I thought until now, that it is a stellar body, like a star, planet, etc.

 

[jgm]

The body parameter of the "SupercruiseExit" event is really wired. Once it is the correct planet name, you are close to, or the other time it is a station name, or the star system name.

An example for body = system name (exiting not close to a body):

 "timestamp":"2016-09-25T09:09:53Z", "event":"SupercruiseExit", "StarSystem":"Flech", "Body":"Flech" }

An example for body = station name (exiting close to a spaceport):

{ "timestamp":"2016-09-25T09:28:37Z", "event":"SupercruiseExit", "StarSystem":"Flech", "Body":"Saberhagen Port" }

The station "Saberhagen Port" is close to the planet "Flech 2".

An example for a proper body name (exiting close to a planetary installation):

{ "timestamp":"2016-09-25T09:48:11Z", "event":"SupercruiseExit", "StarSystem":"Oto", "Body":"Oto B 4" }

I would suggest to call the parameter "InnerSystemLocation" instead of body, or leave it blank, if the position of a player is not close to a stellar body.
Otherwise please define, what "Body" is. I thought until now, that it is a stellar body, like a star, planet, etc.

I thought it was whatever you're locked on to relative velocity-wise i.e. whatever the blue marker is on in your navigation panel.

Not sure what happens if you drop out in deep space though; worth a try to find out.

 

[Special Circumstances]

The body parameter of the "SupercruiseExit" event is really wired. Once it is the correct planet name, you are close to, or the other time it is a station name, or the star system name.

An example for body = system name (exiting not close to a body):

 "timestamp":"2016-09-25T09:09:53Z", "event":"SupercruiseExit", "StarSystem":"Flech", "Body":"Flech" }

An example for body = station name (exiting close to a spaceport):

{ "timestamp":"2016-09-25T09:28:37Z", "event":"SupercruiseExit", "StarSystem":"Flech", "Body":"Saberhagen Port" }

The station "Saberhagen Port" is close to the planet "Flech 2".

An example for a proper body name (exiting close to a planetary installation):

{ "timestamp":"2016-09-25T09:48:11Z", "event":"SupercruiseExit", "StarSystem":"Oto", "Body":"Oto B 4" }

I would suggest to call the parameter "InnerSystemLocation" instead of body, or leave it blank, if the position of a player is not close to a stellar body.
Otherwise please define, what "Body" is. I thought until now, that it is a stellar body, like a star, planet, etc.

Might be more useful to separate out Body and Station. Body being closest body (if within an appropriate distance), and station populated if near a station.

 

[nrage]

Might be more useful to separate out Body and Station. Body being closest body (if within an appropriate distance), and station populated if near a station.

Definitely. That way an application can easily display the value in the right way, without having to try and figure that out.
Of course, it's still relatively trivial to figure out which is which if you know the current system name.

 

[jgm]

Definitely. That way an application can easily display the value in the right way, without having to try and figure that out.
Of course, it's still relatively trivial to figure out which is which if you know the current system name.

Has anyone checked what is reported when dropping to a nav beacon? A USS? A POI? An asteroid belt?

The reason that FD probably went for 'Body' is that it allows them to put the nearest marker without worrying about type.

 

[eventure]

Has anyone checked what is reported when dropping to a nav beacon? A USS? A POI? An asteroid belt?

Not yet, but I am really interested in what is reported!

The reason that FD probably went for 'Body' is that it allows them to put the nearest marker without worrying about type.

If so, then it could be helpful to add the type. Maybe Howard could bring more light into it.

 

[Andargor]

I was looking at ways to determine station orientation while in supercruise, since the HUD doesn't display it (yet, right FD? ). I've found that the log files output your relative position to bodies in a similar fashion you describe. My conclusion was that the game engine uses local coordinates that change as you move through a system.

If the log hooks in to the engine SC flight model with these dynamic frames of reference, getting this changed may be challenging.

 

[jgm]

I was looking at ways to determine station orientation while in supercruise, since the HUD doesn't display it (yet, right FD? ). I've found that the log files output your relative position to bodies in a similar fashion you describe. My conclusion was that the game engine uses local coordinates that change as you move through a system.

If the log hooks in to the engine SC flight model with these dynamic frames of reference, getting this changed may be challenging.

Sounds interesting. It would be interesting to take shots of your view as you drop from supercruise and see if you can match them with the station.

Of course, if FD just oriented stations so that the airlock pointed towards the body they were orbiting it wouldn't be necessary.

 

[eventure]

I was looking at ways to determine station orientation while in supercruise, since the HUD doesn't display it (yet, right FD? ). I've found that the log files output your relative position to bodies in a similar fashion you describe. My conclusion was that the game engine uses local coordinates that change as you move through a system.

If the log hooks in to the engine SC flight model with these dynamic frames of reference, getting this changed may be challenging.

Sadly the log does not record your SC flight through the star system, nor when driving a SRV. The "system" row is not written in this state, so the position data is not available.
Created a minimap for SRV operations, but overlooked that the data was missing. At least it is usable when in normal flight above the ground.

 

[Andargor]

Sounds interesting. It would be interesting to take shots of your view as you drop from supercruise and see if you can match them with the station.

Of course, if FD just oriented stations so that the airlock pointed towards the body they were orbiting it wouldn't be necessary.

Yeah, the station points inwards, but at a 45 deg angle from its orbital plane, and about 20-30 deg prograde. I've put my slim findings here.

Bottom line: the current state of affairs doesn't look good, but eventually if the station orbital data gets logged to EDDN/EDDB through the commander's log, then maybe the orientation can be calculated. How to represent that to the pilot is another ball game.

 

[hchalkley]

The body parameter of the "SupercruiseExit" event is really wired.[...]

A Body is StellarForge's term for any of the elements of a star system - stars, planets, moons, starports, asteroid belts, barycentres of binary star systems, etc (but not rings). Your local position is relative to the nearest relevant Body.

 

[Genar-Hofoen]

Hi Howard o7

As I'm writing a parser for Captain's Log, I'm getting rather concerned that I don't have a complete list of all the different planet and star types reported in the Player Journal.

Would it be possible to provide such a list? At the moment I'm doing an exploration run in Beta in order to try and obtain that, but that's eating up development time.

Also, would it be possible to have a list of the Atmosphere types?

The documentation is really good, by the way, but it's kind of incomplete if it doesn't include lists of all the possible return values for all the different parameters. Yes, I realise that writing such verbose documentation is a chore in itself, but from our side's point of view, the lack of this information is making our job a LOT more difficult than it should be

Regards o7