Discussion Commanders log manual and data sample

Requests for changes outstanding>
1. Commander name sooner in the journal. We start seeing friends online before we know who's friends they are
2. "End of journal" event when the client exists.
3. Faction global conflict states "ConflictState": { "systemname": "sol", "state":"War" } in Location and FSDJump for each faction that's at war somewhere else in the galaxy. Same for pending and recovering conflict states.
4. force windows notification of journal updates when journal is flushed to disk; so changes are picked up automatically by filewatcher without having to do crazy things to trick windows into triggering changes.
5. add MissionIds to combat kills for mission targets (civilian/pirate/cz etc).
6. for merit giving valid power play kills (eg enemy faction, controlled system) add "powerplay_voucher":"30"; into murder event.


Image for #3 (taken from a different system)
https://cdn.discordapp.com/attachments/241987037803184128/390187258621329408/unknown.png

#7 "Vehicle destroyed" events for fighter and SRV destruction and vehicle state tracking.
#8 "Limpet used" event for limpet cargo tracking (this would trigger as soon as a limpet is deployed)
#9 "Cargo lost" event for cargo lost to hatchbreaker limpets, damaged cargo hatches, etc.
#10 "Mission status" event on initial startup for mission tracking (like we already have with "Loadout", but for missions)
 
Last edited:
#7 "Vehicle destroyed" events for fighter and SRV destruction and vehicle state tracking.
#8 "Limpet fired" and "limpet destroyed" events for cargo tracking
#9 "Cargo lost" event for cargo lost to hatchbreaker limpets, damaged cargo hatches, etc.
#10 "Mission status" event on initial startup for mission tracking (like we already have with "Loadout", but for missions)
#11 Mission ID for tourist beacon scan and beacon name!
#12 Make TouristDestinations a json friendly list within missions
#13
StationType, controlling faction, superpower & powerplay faction/controlled/exploited to "event":"DockingGranted"
 
Last edited:

Robert Maynard

Volunteer Moderator
Just to feedback - a very low-tech approach to using the very much appreciated CG journal data:

run cmd
cd \users\users\Saved Games\Frontier Developments\Elite Dangerous\
find ":445," *.log >CG445.txt
notepad CG445.txt

.... then copy/paste into Excel and I am quite contentedly tracking the Diamond Frogs CG progress using journal data from all of my CMDRs.

Thanks very much, Howard. :)
 
Just to feedback - a very low-tech approach to using the very much appreciated CG journal data:

run cmd
cd \users\users\Saved Games\Frontier Developments\Elite Dangerous\
find ":445," *.log >CG445.txt
notepad CG445.txt

.... then copy/paste into Excel and I am quite contentedly tracking the Diamond Frogs CG progress using journal data from all of my CMDRs.

Thanks very much, Howard. :)

That's all very well but it's the most Heath Robinson / Rube Goldberg approach imaginable.

Those of us trying to write tools such as EDDI to professional standards can't afford to be so slipshod.
 
Last edited:
Referring to my proposal here, another solution that I think is better:

I am currently using the screenshot event from the journal for my software to perform a approach calculation at certain coordinates on the surface of planets.
For this purpose I send "F10" to Elite, wait for the screenshot event in the journal and read the data. The data from the screenshot event is rather poor (length and latitude only) and I know that other programmers often ask for additional parameters and information.
This extended information, however, if it were generated regularly and with sufficient frequency, would fill the journal without need.

Proposal:
Add a new event that is only there to generate a selection of the most interesting flight and environment data.
This event should not be generated automatically, but only on request, e. g. F9, F11 or any other key (or key combination).

As a result, 3rd party software would be able to evaluate extended information, but only if it is needed and explicitly requested. And also in the required frequency (no matter if every 60s or 5s or only 60 minutes)

For future versions of the journaling interface, you could probably implement a better trigger than sending a key combination to Elite, but as long as nothing is planned, such a "RequestedExtendedData" event, triggered by pressing a key, would be a great thing for the developers of 3rd party software.

There is certainly a lot of information that could be packed into such an event, but I am currently explicitly interested in the following data:
* celestial body in whose orbit or gravitational range the spacecraft is located
* height, latitude, longitude
* current course
* speed
* if known to the on-board computer (see information in the system map, e. g. because the celestial body has been scanned during an earlier visit) additional information about the celestial body such as radius, etc.

How about that?

Translated with www.DeepL.com/Translator
 
Last edited:
Journal mission expiry different from transactions

Hey everyone.
I've been working with the journal for the first time, and want to get a list of accepted passenger mission. I now have a list of accepted missions but noticed something strange.

I'm using the 'MissionAccepted' event and getting the 'Expiry' key, then converting it into a format similar to in-game, E.G. '2H 32M' as the time left. However, I noticed the the time given in the journal file is different from the times shown on the in-game transactions panel.
I have verified it is not a programming error my side. but the 'Expiry' is written for a different time in the journal vs in-game. It only seems to happen on passenger missions however.
For example, the in-game transaction panel reads '1H 54MIN' remaining, but the expiry date stamp would indicate it has 2 hours 21 minutes. Based on 20 different missions, the discrepancy varies anywhere from 20 minutes to 30 minutes extra when using the 'Expiry' written to the journal. The discrepancy seems random, I cannot see any correlation between mission length etc vs the discrepancy.

Does anyone happen to know why this is, and if there is something that can be done about it?

* Edit *
This only seems to happen to non-VIP passengers, VIP passengers seems to have the correct expiry, this leads me to think this may be a bug?

Thanks in advance!
 
Last edited:
I would like a small change to the "Screenshot" event:

The information about the longitude and latitude only appears after a
quite low altitude (far below orbital cruise) in the journal.
It would be nice if the information would appear as soon as the entry into the orbital cruise height. Or as soon as the cockpit display shows the coordinates (already above the orbital cruise height).

These coordinates can be used in 3rd-party software to calculate a course to specific target coordinates. At the moment you have to fly very close to the planet, although the coordinates are already shown in the cockpit.

Thank you, Duke Jones

PS: A statement in the journal about the current altitude would also be very nice. ;)

I would think this could theoretically come from the same source as the cartesian coordinates that are logged in the netlog.

One thing to note is it appears the ship only enters the rotating frame of the planet when below dropout altitude Correction: about 75% of orbital cruise altitude. Above this altitude, the reference frame is non-rotating. It's possible that the information necessary to convert the non-rotating frame coords to rotating frame coords isn't available to the journal writer.
 
Last edited:
Referring to my proposal here, another solution that I think is better:

I am currently using the screenshot event from the journal for my software to perform a approach calculation at certain coordinates on the surface of planets.
For this purpose I send "F10" to Elite, wait for the screenshot event in the journal and read the data. The data from the screenshot event is rather poor (length and latitude only) and I know that other programmers often ask for additional parameters and information.
This extended information, however, if it were generated regularly and with sufficient frequency, would fill the journal without need.

Proposal:
Add a new event that is only there to generate a selection of the most interesting flight and environment data.
This event should not be generated automatically, but only on request, e. g. F9, F11 or any other key (or key combination).

As a result, 3rd party software would be able to evaluate extended information, but only if it is needed and explicitly requested. And also in the required frequency (no matter if every 60s or 5s or only 60 minutes)

For future versions of the journaling interface, you could probably implement a better trigger than sending a key combination to Elite, but as long as nothing is planned, such a "RequestedExtendedData" event, triggered by pressing a key, would be a great thing for the developers of 3rd party software.

There is certainly a lot of information that could be packed into such an event, but I am currently explicitly interested in the following data:
* celestial body in whose orbit or gravitational range the spacecraft is located
* height, latitude, longitude
* current course
* speed
* if known to the on-board computer (see information in the system map, e. g. because the celestial body has been scanned during an earlier visit) additional information about the celestial body such as radius, etc.

How about that?

Translated with www.DeepL.com/Translator

I agree this is a good idea. It would neatly give us current position whilst building in sufficient delay that, I suspect, should calm any FD fears about impact on game performance or bots being created to achieve undue gain in player performance.
If it could be done every 10 to 15 seconds then we could get (whilst waiting for FD & Beyond) some useful surface navigation support tools that wouldnt suffer the problems with OCR capture of the coordinate data whilst trying to peer at the planet surface.
 
I have a request, when the "ModuleBuy" event is written, for example, it gives a localised name for the module, it would be great if the "Loadout" event could too as it seems difficult to get the actual name of a module from the references that event gives.

Although, I wonder if anyone has or knows of a list of module names pair with the reference such as "Hpt_PlasmaPointDefence_Turret_Tiny" -> "Point Defence Turret".
 
I have a request, when the "ModuleBuy" event is written, for example, it gives a localised name for the module, it would be great if the "Loadout" event could too as it seems difficult to get the actual name of a module from the references that event gives.

Although, I wonder if anyone has or knows of a list of module names pair with the reference such as "Hpt_PlasmaPointDefence_Turret_Tiny" -> "Point Defence Turret".

Here:
https://github.com/EDSM-NET/Alias/tree/master/Station/Outfitting
https://github.com/EDCD/FDevIDs/blob/master/outfitting.csv
 
One issue I have found, when purchasing a fighter bay and then purchasing a fighter, there seems to be no event to indicate a fighter was purchased? I read about the "RestockVehicle" event, but that doesn't seem to be being written?

I purchased the fighter bay then purchased a fighter, but only an event for the fighter bay purchase was written (as below)
{ "timestamp":"2017-12-20T22:29:34Z", "event":"ModuleBuy", "Slot":"Slot02_Size7", "BuyItem":"$int_fighterbay_size5_class1_name;", "BuyItem_Localised":"Fighter Hangar", "BuyPrice":505128, "Ship":"type9_military", "ShipID":6 }
 
Last edited:
Outpost type is missing from the journal docked (and docking requested).

In the journal at the moment it just says "Outpost" but there are many kinds of outpost.
Civilian, Industrial, military, etc

Please include the full outpost type description - they are needed for showing where the pads are.

yNCL74S.png


Thanks.
 
Hey everyone.
I've been working with the journal for the first time, and want to get a list of accepted passenger mission. I now have a list of accepted missions but noticed something strange.

I'm using the 'MissionAccepted' event and getting the 'Expiry' key, then converting it into a format similar to in-game, E.G. '2H 32M' as the time left. However, I noticed the the time given in the journal file is different from the times shown on the in-game transactions panel.
I have verified it is not a programming error my side. but the 'Expiry' is written for a different time in the journal vs in-game. It only seems to happen on passenger missions however.
For example, the in-game transaction panel reads '1H 54MIN' remaining, but the expiry date stamp would indicate it has 2 hours 21 minutes. Based on 20 different missions, the discrepancy varies anywhere from 20 minutes to 30 minutes extra when using the 'Expiry' written to the journal. The discrepancy seems random, I cannot see any correlation between mission length etc vs the discrepancy.

Does anyone happen to know why this is, and if there is something that can be done about it?

* Edit *
This only seems to happen to non-VIP passengers, VIP passengers seems to have the correct expiry, this leads me to think this may be a bug?

Thanks in advance!
Good find. You need to report it as a bug in the bug reporting section of the forum :)
 
Hi all, just a reminder to everyone that Howard asked us to post all bugs and feature requests for the journal in the bug and feature request sections of the forums. He doesn't watch this thread, but the bug and feature request sections are watched by many devs.

Cheers :)
 
Perhaps this was answered earlier - apologies if it has. Will the log include npc dialogue strings? There were a few TTS translators that used scrapes before, if the NPC dialogue is in the file, then TTS apps would be more conveniently written.
 
Top Bottom