Discussion Journal Documentation for v3.0

Bump thread - top post edited with latest docs for beta3

Once more, THANKS!

Several quesions about MissionCompleted event (the sample below is taken from document mentioned):

Code:
{ "timestamp":"2018-01-30T10:00:20Z", "event":"MissionCompleted", "Faction":"Farack 
Stakeholders", "Name":"Mission_Collect_name", "MissionID":65391731, 
"Commodity":"$AgriculturalMedicines_Name;", "Count":12, "DestinationSystem":"Farack", 
"DestinationStation":"Mitra Estate", "Reward":10000, "FactionEffects":[ { "Faction":"Farack 
Stakeholders", "Effects":[ { "Effect":"$MISSIONUTIL_Interaction_Summary_outbreak_down;", 
"Effect_Localised":"Outbreak Down", "Trend":"DownGood" } ], "Influence":[ { 
"System":3932143293138, "Trend":"UpGood" } ], "Reputation":UpGood } ] }

"Reward":10000 - is it final reward or addition 2 original on selecting money?
FactionEffects - I see one faction, but the mission is not passenger. Shall we see two FactionEffects items 4 passenger missions?

and the most interesting questions :)

"Influence":[ { "System":3932143293138, "Trend":"UpGood" } ] - is it common influence 4 the mission, or addition on selecting reward? And how 2 convert UpGood to something like + / +++? Good is 1, 2 or three (Low/Med/High)? System name may be mapped from initual event, but, please, give an advice about understanding UpGood
 
Last edited:

hchalkley

Senior Programmer
Frontier
The trend values ("UpGood" etc) are based on the info available at the time of mission completion - the data is used to put an up or down arrow, coloured blue or red for good/bad, in the mission result screen. It does not say anything about the amount of change.
 
The trend values ("UpGood" etc) are based on the info available at the time of mission completion - the data is used to put an up or down arrow, coloured blue or red for good/bad, in the mission result screen. It does not say anything about the amount of change.
Not related to the Journal, but I've wondered since release why FD chose Blue for better/good instead of Green?

Traffic light analogy is often used for positive/negative changes and dashboards.

Is it a palette issue of some type, or just the art direction choice?
 
I also like the inclusion of a body's parents. However, as I explored and looked at the data is became clear that the Barry Points data is not included.
While the information we have allows us to build up a system map like presented in game, it would not be possible to build an orrery.

^^ This. (LOL at “Barry Points”. For those not getting it, dobbo means barycentres of binary pairs.)

In fact, there are 2 types of bodies for which orbital data are needed but missing:
  • Barycentres of binary pairs. Those show up in the 'Parents' arrays as 'Null' with ID != 0.
  • Asteroid belts. Those show up in the 'Parents' arrays of asteroid clusters as 'Ring'.
In both cases a simple solution would be to include orbital data in the respective object in the 'Parents' array.

That said, in order to build a proper orrery we’d need more parameters. Currently we get:
  • semi-major axis
  • eccentricity
  • inclination
  • argument of periapsis
  • orbital period (usually, but not always, trivially derivable from semi-major axis and relevant bodies’ masses)
  • axial tilt of parent body, where applicable (important because orbital inclinations are expressed as relative to the parent’s equatorial plane)
We’re missing:
  • some angle to tell us the orientation of the major axis (it could be longitude of ascending node or some other angle)
  • some parameter to tell us where each body is in its orbit
  • longitude of the rotation axis of the parent body, where applicable (axial tilt being the latitude)
 

Mu77ley

Volunteer Moderator
Not related to the Journal, but I've wondered since release why FD chose Blue for better/good instead of Green?

Traffic light analogy is often used for positive/negative changes and dashboards.

Is it a palette issue of some type, or just the art direction choice?

Red/Green is a bad combination for colour blind people.
 
^^ This. (LOL at “Barry Points”. For those not getting it, dobbo means barycentres of binary pairs.)

In fact, there are 2 types of bodies for which orbital data are needed but missing:
  • Barycentres of binary pairs. Those show up in the 'Parents' arrays as 'Null' with ID != 0.
  • Asteroid belts. Those show up in the 'Parents' arrays of asteroid clusters as 'Ring'.
In both cases a simple solution would be to include orbital data in the respective object in the 'Parents' array.

That said, in order to build a proper orrery we’d need more parameters. Currently we get:
  • semi-major axis
  • eccentricity
  • inclination
  • argument of periapsis
  • orbital period (usually, but not always, trivially derivable from semi-major axis and relevant bodies’ masses)
  • axial tilt of parent body, where applicable (important because orbital inclinations are expressed as relative to the parent’s equatorial plane)
We’re missing:
  • some angle to tell us the orientation of the major axis (it could be longitude of ascending node or some other angle)
  • some parameter to tell us where each body is in its orbit
  • longitude of the rotation axis of the parent body, where applicable (axial tilt being the latitude)

Thanks foe the correction on the Barrycenters :)

Not sure we need your list of missing data. Could they not all be globally fixed.

For example, the parameter to tell us where each body is in orbit is a function of the clock. FDev went to lengths to get the game clocks synchronised so that the rotation of the stations can be synchronised
to it. I assume that the same is true for the location of the bodies in their orbits. All system could start with their bodies in alignment at 0 degs at some epoch (1970-01-01 00:00:00) and then the delta
between then and 3304 would scatter them nicely. No need to store this data in the persistent stores.

It seams strange to me that Frontier would hold back some of this orbital data. More likely is that they haven't bothered to tell us what the fixed constants are.
 
Not sure we need your list of missing data. Could they not all be globally fixed.

For example, the parameter to tell us where each body is in orbit is a function of the clock. FDev went to lengths to get the game clocks synchronised so that the rotation of the stations can be synchronised
to it. I assume that the same is true for the location of the bodies in their orbits. All system could start with their bodies in alignment at 0 degs at some epoch (1970-01-01 00:00:00) and then the delta
between then and 3304 would scatter them nicely. No need to store this data in the persistent stores.

That certainly is a possibility, and I did consider it, though never mentioned here. If true we ought to be able to test it easily enough in our own Solar System.

(For the record, when I said “some parameter to tell us where each body is in its orbit” I presumed it would be most likely expressed as the mean anomaly at whatever the game’s epoch is.)

I have actually noted that our Moon’s orbit is wrong in E:D – specifically, the angle between Moon’s orbital plane and Earth’s orbital plane is way too high (in reality it is about 5.2°, close to coplanarity). This could indicate that E:D does not store the orientation of the major axis. If true it would certainly make things simpler for any orrery-like application :)
 
That certainly is a possibility, and I did consider it, though never mentioned here. If true we ought to be able to test it easily enough in our own Solar System.

(For the record, when I said “some parameter to tell us where each body is in its orbit” I presumed it would be most likely expressed as the mean anomaly at whatever the game’s epoch is.)

I have actually noted that our Moon’s orbit is wrong in E:D – specifically, the angle between Moon’s orbital plane and Earth’s orbital plane is way too high (in reality it is about 5.2°, close to coplanarity). This could indicate that E:D does not store the orientation of the major axis. If true it would certainly make things simpler for any orrery-like application :)

I wouldn't test this idea in Sol. Sol is a special case and Frontier may have "cheated" and not entered the planets' true positions into the Stella Forge. But any set of systems with a single star and a set of planets in the same orbital plane should do.

I haven't done any check of how close Sol is to what it should be. I wonder why E:D didn't get that right.
 
Last edited:
I wouldn't test this idea in Sol. Sol is a special case and Frontier may have "cheated" and not entered the planets' true positions into the Stella Forge. But any set of systems with a single star and a set of planets in the same orbital plane should do.
I haven't done any check of how close Sol is to what it should be. I wonder why E:D didn't get that right.

That's true of the whole bubble; a lot of it is manually crafted.

Good luck trying to count the orbits of mitterland hollow with any degree of accuracy ;) lol
 
I think, that needed info about exact reward selected. Something like "SelectedAdditionalReward" : [{"Influence": "Low",....}]
 
I wouldn't test this idea in Sol. Sol is a special case and Frontier may have "cheated" and not entered the planets' true positions into the Stella Forge.

If the engine supports the concepts of the longitude of ascending node and/or mean anomaly at epoch (or anything equivalent), then it would be rather strange for FDEV not to use them for our Solar System.

If, on the other hand, the engine does not support those, it would readily explain why Moon’s orbit is incorrectly oriented in space.

But you’re right that checking just Sol is not enough. Randomly-generated systems would be the best choice.

That's true of the whole bubble; a lot of it is manually crafted.

Systems that existed in FE2/FFE are manually crafted, as are most systems with exoplanets known at the time E:D was created (some exoplanets were added later, too). But I believe the vast majority of the systems in the bubble are not manually crafted, even if the stars themselves are manually placed.

Good luck trying to count the orbits of mitterland hollow with any degree of accuracy ;) lol

We can easily have the exact orbital period of Mitterand Hollow from the journal, so it’s not as bad a choice as it might seem.

However, to verify the hypothesis that Ω=const and M[SUB]0[/SUB]=const, we need to have fairly exact positions of all planets in a system at the least. That is going to be quite a lot of work. I’m not going to tackle it any time soon… :)
 

Robert Maynard

Volunteer Moderator
The beta release of Elite Dangerous: Beyond will be available later today,
here's the documentation for the latest version of the player journal:

Edited updated to v15 for beta3:

Good morning Howard,

Has the definition document been updated since v15?

If so, releasing the latest version would be greatly appreciated indeed. :)

Best regards,

RM.
 
Hello FD,

Can you implement a lua interface that provides all the variables listed in the journal and status files? And can you also provide functions to do simple things such as lower/raise landing gear, turn lights on/off, deploy/retract hardpoints, enter/exit supercruise/hyperspace, and so on? Providing this interface through lua improve lag time and better integration with 3'rd party tools. And security shouldn't be a problem if you're just providing what you're writing now in the journal/status files.

Thanks
 
I found a cockpit signal missing in the status.json, the IMPACT warning, it would be great to have it as well.
 
The beta release of Elite Dangerous: Beyond will be available later today,
here's the documentation for the latest version of the player journal:

Edited updated to v15 for beta3:

Doc: http://hosting.zaonce.net/community/journal/v15/Journal_Manual_v15.doc

PDF: http://hosting.zaonce.net/community/journal/v15/Journal_Manual_v15.pdf

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

Don't know about that, but you can move the whole Saved games folder if you like. Right click - Properties - Location.
 
Back
Top Bottom