Discussion Journal Documentation for v3.0

Robert Maynard

Volunteer Moderator
Good evening Howard,

A bit I added to my previous post:

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

In addition to this, would it be possible for the timestamp published in status.json to include hundredths of seconds? I ask as the position information resolution is far higher than the time resolution - which makes speed estimated (in arc°) a bit "jumpy".
 
which makes speed estimated (in arc°) a bit "jumpy".
Robert - take distance travelled over the last N seconds and take an average to get speed; it should soften the jumpiness a bit.

That's how we get "microsoft seconds" when copying files; it takes an average of transfer rate over a time period and makes a best guess.
 
Last edited:

Robert Maynard

Volunteer Moderator
Robert - take distance travelled over the last 30 seconds and take an average; it should soften the jumpiness a bit.

That's how we get "microsoft seconds" when copying files; it takes an average of transfer rate over a time period and makes a best guess.

I could do that - however if the vessel has stopped then the status.json stops being updated (something other than position changes) and, from the perspective of the application (at the moment), time has stopped - which would lead to an apparent speed even if the ship / SRV had stopped, unless (quite reasonably, actually) position is considered to be constant in the absence of any update to status.json and time is considered to continue. Definitely an approach to ponder if time resolution remains as is. :)
 
I could do that - however if the vessel has stopped then the status.json stops being updated (something other than position changes) and, from the perspective of the application (at the moment), time has stopped - which would lead to an apparent speed even if the ship / SRV had stopped, unless (quite reasonably, actually) position is considered to be constant in the absence of any update to status.json and time is considered to continue. Definitely an approach to ponder if time resolution remains as is. :)
true; but you know when the last update was because of the timestamp, if time is ticking away and the status file isn't being updated you can assume they've stopped, which will decline their average speed over time eventually to zero. and their ETA will eventually go up towards infinity.

if you were to plot the data it'd look something like this... (X:time, Y:m/s )
I89ao2r.png
 
Last edited:

Robert Maynard

Volunteer Moderator
true; but you know when the last update was because of the timestamp, if time is ticking away and the status file isn't being updated you can assume they've stopped, which will decline their average speed over time eventually to zero. and their ETA will eventually go up towards infinity.

if you were to plot the data it'd look something like this... (X:time, Y:m/s )
https://imgur.com/I89ao2r.png

This is also true. :) I'll revisit the calculation logic tonight.

I've started a development thread for StatusDisplay here: https://forums.frontier.co.uk/showt...json-display-and-surface-navigation-assistant
 
Its great to see that SuperPower reputation is now available.

Of course the next request - this one - is to dump local faction reputation as seen in the galaxy map for a system. Just names and reputation is all that would be required. That would allow a user to build a map of reputation around the galaxy to better plot trade opportunities where reputation grind is less needed.

Of course this would be even better available in the galaxy map itself, but either would be extremely useful to more serious players..
 
Hi,

Is there any chance we pit and bridge builders could get individual impact events and other live telemetry someday? Preferably in a separate file and to be enabled via option toggle, so as to not cause any side effects for regular players?

This works great in x-plane and i can guarantee you this will get ED into the news yet again ;)
 
Last edited:
The beta release of Elite Dangerous: Beyond will be available later today,
here's the documentation for the latest version of the player journal:

http://hosting.zaonce.net/community/journal/v14/Journal_Manual_v14.doc
http://hosting.zaonce.net/community/journal/v14/Journal_Manual_v14.pdf

First of all, GREAT THANKS!

However, I found one large problem. Due to selecting mission rewards on completion, the log have NO CORRECT DATA 4 INFLUENCE. I think, thant MissionCompleted event should be updated, at least by actual influence after completion.

Not so critical advice:

1. Please, make a setting for the status file placement - updating 1 time per second is a good way 2 crash SSDs much quicker...
2. Please, add data from station services status, traffic, rewards etc to the log, on selecting the ithems. If not - 4 me personally it's not a problem :) Tesseract is reading ~90% OK, without any training and self-made dictionaries. At least, 4 my beta BGS parser with OCR.
 

Robert Maynard

Volunteer Moderator
Bump thread - top post edited with latest docs for beta3

Thanks, Howard. :)

Can you advise if status.json will be updated if there are positional changes that are below the current apparent delta-position threshold for necessitating re-publishing?
 

hchalkley

Senior Programmer
Frontier
Regarding updates to status.json based on location - assuming nothing else changes, then the Latitude or Longitude would have to change by 0.02deg to trigger an update, or the Altitude would need to change by 5%, or the Heading change by 10 degrees. (but the heading needs to be steady - if you get into a spin it should not trigger multiple updates)
 

Robert Maynard

Volunteer Moderator
Regarding updates to status.json based on location - assuming nothing else changes, then the Latitude or Longitude would have to change by 0.02deg to trigger an update, or the Altitude would need to change by 5%, or the Heading change by 10 degrees. (but the heading needs to be steady - if you get into a spin it should not trigger multiple updates)

Thanks very much for that insight, Howard.

Given the precision of published positional information, i.e. 6th decimal place of lat/long in degrees, to the nearest metre of altitude and to the nearest integer degree for heading, it's a bit frustrating that small changes are "ignored" in terms of re-publication - especially given that, when travelling over the surface of a landable body in a ship, at sufficient speed, the update is every second but travelling more slowly results in significantly longer between publications. Arguably, positional precision is less of an issue when travelling quickly than it is when travelling slowly, yet the frequency of publication varies inversely with the perceived need for positional precision.

Swapping to an SRV, travelling on the surface of the same body, the updates to position will be much less frequent and, on a large body, much, much less frequent and therefore more and more out of date.

I would really appreciate it if either per-second publication could be considered or reducing the re-publication threshold for each variable to the minimum perceivable change in value as an option for those that want "high-precision" positional status.
 
Last edited:
he updates to position will be much less frequent and, on a large body, much, much less frequent and therefore more and more out of date. I would really appreciate it if either per-second publication could be considered or reducing the re-publication threshold for each variable to the minimum perceivable change in value as an option for those that want "high-precision" positional status.

Have to agree with Robert, SRV should have a greater degree of accuracy travelling at 30m/s than a ship travelling at 100-10,000m/s.
Especially since the accuracy of the data is so high.

I'd also agree with Robert that second-by-second (or half/quarter second) snapshots for movement would be more consistent than updates-by-threshold.

After-all - since we don't get notifications from the O/S that the file has changed we have to poll the file every second regardless of whether it's changed or not.


+10,000m/s speeds are totally possible ;)
unknown.png
 
Last edited:
Regarding updates to status.json based on location - assuming nothing else changes, then the Latitude or Longitude would have to change by 0.02deg to trigger an update, or the Altitude would need to change by 5%, or the Heading change by 10 degrees. (but the heading needs to be steady - if you get into a spin it should not trigger multiple updates)
If lat/long change is really the update trigger then the results are going to be wildly inconsistent.

0.02° of longitude is more than 5 km at the equator of Achenar 3, but less than a centimetre close enough to the pole of any body.

I agree, too, that timer-triggered updates would be a better idea.
 
Regarding updates to status.json based on location - assuming nothing else changes, then the Latitude or Longitude would have to change by 0.02deg to trigger an update, or the Altitude would need to change by 5%, or the Heading change by 10 degrees. (but the heading needs to be steady - if you get into a spin it should not trigger multiple updates)

Many thanks for this update. A 0.02deg change works for me, and I hadn't even considered the spin problem. :)

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. I'm not planning
on anything like as beautiful as this concept art, but it would be nice to have a go.

If I am being cheeky (and why can't I be?) then I would ask for the Orbital Parameters to be copied/moved to the the DiscoveryScan event. This way an
orrery could be built quickly and displayed so the commander so (s)he can plan their path of exploration around a system. If you do consider adding the
Barry Point data in a future release, then would it be possible to include in the status.json file the system co-ordinates of the ship?

Thanks for all the hard work from you and all at FDev
 
Top Bottom