Bump thread - top post edited with latest docs for beta3
Still no possibility to change the directory for commanders journal?
I dont want to play this game, if it writes to my SSD every second...
Last edited:
Bump thread - top post edited with latest docs for beta3
Bump thread - top post edited with latest docs for beta3
{ "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 } ] }
Not related to the Journal, but I've wondered since release why FD chose Blue for better/good instead of Green?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.
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.
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?
^^ 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:
In both cases a simple solution would be to include orbital data in the respective object in the 'Parents' array.
- 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'.
That said, in order to build a proper orrery we’d need more parameters. Currently we get:
We’re missing:
- 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)
- 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)
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![]()
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 Edidn't get that right.
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.
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 accuracylol
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.
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.