Discussion Commanders log manual and data sample

Hi Howard,
Just going through the spec and noticed that I can tell if cargo scooped is stolen, e.g.
{ "timestamp":"2016-06-10T14:32:03Z", "event":"CollectCargo", "Type":"agriculturalmedicines", "Stolen":false }

but if I am re-loading from save then the initial event omits that
{ "timestamp":"2017-02-10T14:25:51Z", "event":"Cargo", "Inventory":[ { "Name":"syntheticmeat", "Count":2 }, ...

So I cannot tell if I could sell my cargo or it has to be BlackMarketed.
 
Regarding the engineering modification changes, there has been some work on this, for the 'companion api' - but I don't know exactly when this will go live. It doesn't need to be synchronised with a game update.

Looks like it's in 2.4 beta - you're simply the best!
 
Last edited:
• The 'Scan" event is generated for all bodies in a system, when scanning a navigation Beacon
This is going to be big for EDDB & related projects.

For those who have not realized it yet, this is generated even if the system has already been scanned — and, in fact, even if the system’s complete data have been available from the start of the game (like Sol or Shinrarta Dezhra). This means we can now gather high-precision data for all inhabited systems. (I believe every inhabited system has a nav beacon; correct me if I’m wrong.)

Even though I am in no way affiliated with EDDB or any other data-gathering community project,
Howard, big thanks for this!
… And now that maybe I have your attention … ;)

Current scan events almost get us to the point of being able to construct our own system maps.

Almost.

We’re missing just two kinds of information in the “Scan” events:
  • a "ParentBodyName" field to tell us what, if anything, a particular body is orbiting (this is not always possible to figure out from BodyName);
  • and, if that “parent body” happens to be a barycentre of a binary pair, the orbital parameters of the said barycentre (and its ParentBodyName!). (It could be just a separate “Scan” event, generated whenever a “Scan” event is generated for a body which is part of a binary pair. This ought to be checked recursively, to handle cases where the parent of a binary pair’s barycentre is itself a binary pair’s barycentre.)
Would it be possible to implement, please?… Not necessarily for 2.4 release; later would be fine, too…
 
This is going to be big for EDDB & related projects.

For those who have not realized it yet, this is generated even if the system has already been scanned — and, in fact, even if the system’s complete data have been available from the start of the game (like Sol or Shinrarta Dezhra). This means we can now gather high-precision data for all inhabited systems. (I believe every inhabited system has a nav beacon; correct me if I’m wrong.)

Even though I am in no way affiliated with EDDB or any other data-gathering community project,
Howard, big thanks for this!
… And now that maybe I have your attention … ;)

Current scan events almost get us to the point of being able to construct our own system maps.

Almost.

We’re missing just two kinds of information in the “Scan” events:
  • a "ParentBodyName" field to tell us what, if anything, a particular body is orbiting (this is not always possible to figure out from BodyName);
  • and, if that “parent body” happens to be a barycentre of a binary pair, the orbital parameters of the said barycentre (and its ParentBodyName!). (It could be just a separate “Scan” event, generated whenever a “Scan” event is generated for a body which is part of a binary pair. This ought to be checked recursively, to handle cases where the parent of a binary pair’s barycentre is itself a binary pair’s barycentre.)
Would it be possible to implement, please?… Not necessarily for 2.4 release; later would be fine, too…

@Howard As grateful as we are for nav beacon scans, a Boolean or other identifier that a given scan is part of a nav beacon scan would really make nav beacon scans a lot easier to handle. Is that a possibility? Thanks!
 
@Howard As grateful as we are for nav beacon scans, a Boolean or other identifier that a given scan is part of a nav beacon scan would really make nav beacon scans a lot easier to handle. Is that a possibility? Thanks!

6.5 NavBeaconScan
When written: when scanning a navigation beacon, before the scan data for all the bodies in the system is written into the journal
Parameters: NumBodies
It's in the v13 journal docs.
 
@Howard As grateful as we are for nav beacon scans, a Boolean or other identifier that a given scan is part of a nav beacon scan would really make nav beacon scans a lot easier to handle. Is that a possibility? Thanks!
Bugs aside there's the new "NavBeaconScan" event that is issued first and gives you a count of how many "Scan" events it will cause to immediately follow. So look for that, then count the following Scan events until you hit the count, then you know any additional Scan events are standalone, user-initiated, ones.
 
Bugs aside there's the new "NavBeaconScan" event that is issued first and gives you a count of how many "Scan" events it will cause to immediately follow. So look for that, then count the following Scan events until you hit the count, then you know any additional Scan events are standalone, user-initiated, ones.


That's understood.

The problem is that the Cottle interpreter within EDDI is unable to keep up with the subsequent scan events in real time and is incapable of producing an accurate count, thus losing later non nav-beacon scans.
 
Last edited:
That's understood.

The problem is that the Cottle interpreter within EDDI is unable to keep up with the subsequent scan events in real time and is incapable of producing an accurate count, thus losing later non nav-beacon scans.
Whilst that's obviously a problem with EDDI ... it does perhaps suggest that it would be useful to have an "EndNavBeaconScan" event emitted once all the 'attached' Scan events have been written.
 
Whilst that's obviously a problem with EDDI ... it does perhaps suggest that it would be useful to have an "EndNavBeaconScan" event emitted once all the 'attached' Scan events have been written.

Agreed, that's one option.

There are several potential solutions.

For example, the 'NavBeaconScan' could eliminated by adding a 'source' parameter to the 'Scan' events, stating (obviously) the source of the scan... Beacon, 'honk', DSS, etc.

As it stands, a user/app has no way of 'knowing' the origin of the data or, given the opportunity, to selectively ignore a scan... all journal scan events have equal weight and are processed the same.

IMO, this would be the most elegant solution, but YMMV.
 
Agreed, we'd for a long time been asking for a "ScanType" field to be added to the "Scan" event, mostly to tell the difference between non-DSS and with-DSS surface scans. This is an added reason to want this. Of course it may be that the code doesn't easily allow for this.
 

_trent_

Volunteer Moderator
Not sure if this is the right place to ask this, but would it be possible to have the ship count, crime report, bounty hunting report for each system to be put into the journal?

The influence levels and states of the factions we currently have for each system is great, but it would be even cooler if we could see the player activity in each system over the past 24 hours.
 
Agreed, that's one option.

There are several potential solutions.

For example, the 'NavBeaconScan' could eliminated by adding a 'source' parameter to the 'Scan' events, stating (obviously) the source of the scan... Beacon, 'honk', DSS, etc.

As it stands, a user/app has no way of 'knowing' the origin of the data or, given the opportunity, to selectively ignore a scan... all journal scan events have equal weight and are processed the same.

IMO, this would be the most elegant solution, but YMMV.

Oh god.

I've already updated Captain's Log 2.1 with the new NavBeaconScan - it works perfectly. And now you're asking for it to be changed because this Cottle thingy used in EDDI can't keep up with the journal entries. :/

I can understand where you're coming from. But there has got to be a solution to EDDI's problem - can't you buffer the next X amount of scans indicated by NavBeaconScan? Then feed those one by one into EDDI's journal parser?

When I first tested my CL 2.1 with the NavBeaconScan, its GUI froze due to the way CL2 was programmed - the assumption previously was that the user could only scan one body at a time, and CL2 is programmed with interactivity in mind - so a scan would result in an immediate update in the GUI, showing body data.

The new NavBeaconScan flooded the parser, which flooded the GUI with update signals, which froze the GUI as it attempted to process each and every signal.

The solution for me was to stop sending the usual GUI update events from the parser, and instead bring up a progressbar which updates in real time with the amount of 'scans out of <expected scans>' processed. Once that's done, the progressbar is removed and normal operations commence.

Now, I don't know anything about this Cottle thing. I'll have a search to see what that's all about, but I'm sure there must be a way to bung 'X amount' of journal Scan events into some kind of a FIFO queue, to be processed at a speed it can cope with.

If FDEV do change the NavBeaconScan, I'm hoping it'll do it in a manner which is not going to have me change anything in my nicely running parser. CL2 is written entirely in Python btw.
 
Agreed, that's one option.

There are several potential solutions.

For example, the 'NavBeaconScan' could eliminated by adding a 'source' parameter to the 'Scan' events, stating (obviously) the source of the scan... Beacon, 'honk', DSS, etc.

As it stands, a user/app has no way of 'knowing' the origin of the data or, given the opportunity, to selectively ignore a scan... all journal scan events have equal weight and are processed the same.

IMO, this would be the most elegant solution, but YMMV.

I disagree - you know the next X scans are going to be NavBeacon scans - for which I added a isnavbeaconscan against the star system entry in CL2's database. This means that when CL2 shows scan data for a system, it won't show an estimated value for the data, because it's navbeacon data.

I've done a crapton of work for this NavBeaconScan in CL 2.1 and any such change will be a real ballbreaker.
 
Righty - after speaking with the guys on the EDCD Discord, I'm sure they'll be able to sort their problem out. I was extremely tired and cranky and was just about to go to bed when I spotted the posts earlier.

Apologies for going off on one guys. You'll do a fine job once you get up to speed on the EDDI codebase :)
 
Glad that we're all cool, o7.

(BTW the character Ky Vatta was taken from a book too - I like Iain M Banks and Elizabeth Moon equally).

Fact is, among reasonable people, a Discord chat is so much better than static forums for talking things out in real time.
 
Nav beacon scans are still not 100% reliable in beta 3, I've updated my bug report but my confidence that this will get fixed is VERY low.
 
I would like to propose two new events to be added to the Journal output:

Event "ApproachBody":
This event is fired, when the ship reaches the orbit of a body and the altitude indicator is shown at the HUD.

Code:
{ "timestamp":"2017-09-01T20:11:50Z", "event":"ApproachBody", "StarSystem":"Sol", "BodyName":"Earth", "Radius":6371 }


Event "LeaveBody":
This event is fired, when the ship leaves the orbit of a body and the altitude indicator disappears from the HUD.

Code:
{ "timestamp":"2017-09-01T20:12:08Z", "event":"LeaveBody", "StarSystem":"Sol", "BodyName":"Earth" }
 
Last edited:
Top Bottom