Discussion Status.json, BodyID, journal event 'ApproachBody' and 'LeaveBody'

[eventure]

1. Please add the BodyID to the status.json to have a more precise identification of the current location within a star system, beside approaching a station or planet to get the BodyID value from the journal.

2. Please synchronize the events 'ApproachBody' and 'LeaveBody' with the status.json 'Has Lat Long' flag, so any surface navigation could begin when the data of LAT, LNG, ALT and HEADING arrives.
Without the synchronization of the events and status.json output, it is impossible to make use of the data, without knowning for which object they can be used. Now I have to wait for the events,
to give me the data (BodyID, BodyName), I require, to identify the location to make use of the status.json output.

Thanks in advance,
Eventure

@Posted it also into the Suggestion Thread.

 

[Pro Cambarus]

It is true that the haslatlon triggers further from the planet than the ApproachBody event. I implemented two variants of navigation: one that is linked to a specific body and one that is not. The former starts significantly later.
Also there is a limitation of the use of the ApproachSettlement event that has no LeaveSettlement counterpart so there is no way to tell whether a settlement is actually (still) in the vicinity.

According to my observations the status.json does not yield a valid json in 5% of the attempts when it is checked for modification and read and processed for content if it is modified. (It still serves the purpose as this exception can be easily intercepted and the frequency is not game breaking.) Did anyone notice similar phenomena?
(There was an isolated case of one user having no "Flags" key in the variable unpacked from the status.json json, but it was not reproduced since.)

 

[markkuk]

According to my observations the status.json does not yield a valid json in 5% of the attempts when it is checked for modification and read and processed for content if it is modified. (It still serves the purpose as this exception can be easily intercepted and the frequency is not game breaking.) Did anyone notice similar phenomena?

I noticed that each update of status.json triggers two modification events, one when the file is cleared and another when new data is written. I added a check for non-empty result before trying to parse the file contents. I'm using Python language and Watchdog

class MyEventHandler(PatternMatchingEventHandler):
    def on_modified(self, event):
        try:
            with open(event.src_path, 'r') as statusfile:
                status_json = statusfile.read()
                # The status file is cleared before writing new data, causing
                # two modify events. Check that the file isn't empty before
                # trying to parse it as JSON
                if status_json: 
                    status_dict = json.loads(status_json)

 

[Pro Cambarus]

I noticed that each update of status.json triggers two modification events, one when the file is cleared and another when new data is written. I added a check for non-empty result before trying to parse the file contents. I'm using Python language and Watchdog

Thank you for your kind update. I also use Python but I use the os to avoid importing too many modules (also this is not an event based solution for this is more compatible with the main program cycle, though apparently not as efficient in catching two phase write processes). I'll try to intercept the empty stage using that or will fall back to watchdog or other event based module packages.

Edit:
File length checking using the os module seems to resolve the issue, thank you again.