Discussion Journal Documentation for v3.0

1.1 ChangeLogVersion 14 – for v3.0 (25/Jan/2018)
  • Commodity names and Material names are now localised
  • Added NpcCrewRank and NpcCrewPaidWages events
  • Added ShipTargetted event
  • Added Commander at startup before other loadgame events
  • Added Shutdown event
  • Fixed station name in "Docking Denied" event
  • Added solid composition data when scanning a planet
  • Include community goal ID in events: CommunityGoalJoin, CommunityGoalReward,CommunityGoalDiscard
  • Added some info about the name of a community goal's top tier, and the global bonus info (ifavailable)
  • Added Reputation event, to provide info on player's rep with superpowers
  • Include fines in MissionFailed and MissionAbandoned events, where appropriate
  • Add Statistics event at startup
  • Include StationType info in DockingRequested, DockingGranted, DockingDenied,DockingCancelled, DockingTimeout
  • Include UnderAttack event
  • Include SystemAddress 64bit id value in FSDJump, Location, Docked, StartJump, NavBeaconScan
  • Add StoredModules, and StoredShips
  • Added Missions list at startup
  • Added info to Cargo/Inventory to show whether cargo is stolen
  • Report results of DiscoveryScan to the journal
  • Include ScanType in Scan event
  • Add FighterDestroyed and FighterRebuilt events
  • Add LaunchDrone event
  • Add Shipyard Pricelist, and Outfitting pricelist, Market pricelist, written to separate files
  • Include BodyID in Location, SupercruiseExit, Scan, ApproachBody, LeaveBody
  • Include MarketID in many events where relevant
  • Include ship's HullValue, ModulesValue, and Rebuy price in Loadout event
  • Fix an error in the ShipyardNew event description
  • Note EngineerApply event is no longer generated
  • Added "Quality" and "BlueprintID" properties and "Modifiers" array to EngineerCraft
  • Added "EngineerLegacyConvert" event
  • Added "EngineerID" property to EngineerContribution, EngineerCraft, EngineerProgress events
  • Include Engineering data for modified modules in the Loadout event
  • Include list of possible modifiable module attributes in appendix
  • Added MaterialTrade and TechnologyBroker events
  • Added info on the real-time Status.Json file
  • Include TotalEarnings in SellExplorationData
  • Added ModuleInfo event
  • Note Loadout event after using outfitting
  • Note Altitude and Heading in Screenshot event
  • Added SystemsShutdown event
  • Added SRVDestroyed event
  • Added Wanted flag in Docked event
 
Last edited:

Robert Maynard

Volunteer Moderator
Howard,

Reading the specification for the Status File, it seems to be just the thing I was looking for to provide data for the yet-to-be-started programming project I've been putting off to change the state of the images in the middle of the Thrustmaster Cougar MFDs (2x mounted on the front of a 11.6" 16:9 monitor) that I use as game controllers (in addition to KB/M & stick).

With that in mind, would it be possible to add a couple more flags?

27 134,217,728 0800 0000 FSD Charging (HyperJump)
28 268,435,456 1000 0000 HyperJumping (currently shows "Flags":0)
29 536,870,912 2000 0000 Ship Shutdown (by Thargoids)
30 1,073,741,824 4000 0000 Hyperdiction
31 2,147,483,648 8000 0000 Game Client Closed

Nice to haves would be other numeric values:

"Throttle":[throttle setting in range -100 to 100 (%)]
"Speed":[in relevant unit for current space]
"Temperature":[percentage]

.... 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.... ;)
 
Last edited:
Status.json -- how will this work if you have multiple versions of elite running at the same time?

Can it be renamed to Status-CMDRName.json please :)

thanks
 

Robert Maynard

Volunteer Moderator
Slightly different from "multiple versions of Elite running at the same time" but similar, I flip between four CMDRs periodically (using the same game install - I just log out on the current CMDR and in on another CMDR) and would really like it if the CMDR name was included in the title of the journal log file.
 
Slightly different from "multiple versions of Elite running at the same time" but similar, I flip between four CMDRs periodically (using the same game install - I just log out on the current CMDR and in on another CMDR) and would really like it if the CMDR name was included in the title of the journal log file.


  • Added Commander at startup before other loadgame events

in theory that's what this is - they can't add it to the filename because, in the case of a "clean save" option, they wont know what the commander name is. and thinking about it; they may have the same problem with status.json, depending on when they start writing it; but in theory you should be in the cockpit before they start writing status.json to disk but the journal is started as soon as the client opens.
 
Last edited:
Great stuff! Thank you!

Any chance we get a journal entry with the Minor Faction influences values and states when opening the system map for a specific system?
 
  • Added Commander at startup before other loadgame events

Please make this when the friends list loads, not when you select what game mode you want.

Thanks.
 
Hi Howard,

Many thanks for your work on the Journal, it is very much appreciated.

I've done a little testing with the new live beta, and very much like what you've and your team have done. The status updates contain everything I
was hoping for when you broached the subject in our little discussion at the Expo. I would, however, still council that these be available via a a network
interface as writing this data to an SSD might life the device rather quickly.

However, this post is to point out that there is a little bug/feature of the current implementation that I would like to bring to your attention. I have
raised a bug report, but the format for those doesn't really lend itself to what I getting the information over that I want.

The current implementation where the status update is only written when there is something worth reporting works very well (as I said above) and is
very much better than the heartbeat update cycle we talked over at the Expo (IIRC). However, the status is not being update if there is only a change
to the location. I found it quite easy to maintain a constant heading in the SRV which results in no status updates as I drive for kilometres.

I wouldn't want to see changes with very minor location deltas as this would flood the journal output, and I noted that the altitude does have some kind
of delta limiter. Something similar for the lat and long values would be appropriate. While driving around in an SRV I felt an update on a change to 3
decimal places was about right. In a fighter or ship that should be lower as the ground speed will be higher, and my guess would be some function of
altitude and/or speed would work best.

Hope this helps, and once again many thanks
Steve
 
I wouldn't worry about the SSD lifespan being eaten by the ickle ED Player Journal; disks get written to in far higher volume by other system processes, SSD controllers and modern filesystems have SSD wear leveling algorithms to shift the heavily written blocks around onto 'younger' memory cells.

HOWEVER: has nobody written a bit of 3rd party middleware yet to be the canonical log parser and make it available via an API to each and every tool that wants to use the data? It would seem to be all kinds of useful for reasons other than keeping your SSD young and beautiful.
 
Would be great to get the custom system descriptions added to the journal when we jump in, this way our travel history would be much more entertaining reading :D
 
I wouldn't worry about the SSD lifespan being eaten by the ickle ED Player Journal; disks get written to in far higher volume by other system processes, SSD controllers and modern filesystems have SSD wear leveling algorithms to shift the heavily written blocks around onto 'younger' memory cells. .

I maybe a bit over sentient to this as I did have a netbook and killed the flash drive in that - at an inconvenient time too.

HOWEVER: has nobody written a bit of 3rd party middleware yet to be the canonical log parser and make it available via an API to each and every tool that wants to use the data? It would seem to be all kinds of useful for reasons other than keeping your SSD young and beautiful.

I have, but it is unreleased as yet. It makes the journal data available via a telnet (like) interface so any machine on the network (I'm targeting Android) can pick up the journal data.

I did post about it and got shot down, no one wanted a common way of getting the journal data published it seamed.
 
HOWEVER: has nobody written a bit of 3rd party middleware yet to be the canonical log parser and make it available via an API to each and every tool that wants to use the data? It would seem to be all kinds of useful for reasons other than keeping your SSD young and beautiful.

There is one out-dated project (edproxy)

I currently work on a gateway. Its very simple. Just serving the JSON data and do sync with eddn (like edmc). But currently there is a massive problem: heavy RAM usage or slow data transfer
There are three ways:
1. load data from commanders log if needed -> less RAM usage but very slow
2. load entire commanders log at start -> heavy RAM usage but fast
3. write commanders log to (local) database, read from database -> less RAM usage, speed is ok, duplicated data may end in new problems

Also the filewatcher dont work perfect... so many exceptions to catch.

thats why i dont release it yet ;)

Its the worst "API" i ever used. Sad but true: its better then nothing...
 
There is one out-dated project (edproxy)

I currently work on a gateway. Its very simple. Just serving the JSON data and do sync with eddn (like edmc). But currently there is a massive problem: heavy RAM usage or slow data transfer
There are three ways:
1. load data from commanders log if needed -> less RAM usage but very slow
2. load entire commanders log at start -> heavy RAM usage but fast
3. write commanders log to (local) database, read from database -> less RAM usage, speed is ok, duplicated data may end in new problems

Also the filewatcher dont work perfect... so many exceptions to catch.

thats why i dont release it yet ;)

Its the worst "API" i ever used. Sad but true: its better then nothing...

Outdated yet unreleased? Sounds like an ideal candidate for outside contributions! Want to sling me a tarball? Seriously, writing caching transform layers to glue one business system to another with the minimum of interference is what I do all day.

EDIT: Is this it? https://bitbucket.org/westokyo/edproxy/
 
Last edited:
Top Bottom