Discussion Discussion thread to request journal changes to improve 3rd party apps

[jixxed]

Today created https://issues.frontierstore.net/issue-detail/76154 to make Frontier aware of journal changes that would greatly improve the 3rd party app experience. Feel free to drop here whatever you can think of that is still missing. We can add it in a follow up request or perhaps they read it here.

link to the requested changes from the issue: https://docs.google.com/document/d/1m0V_o_oDoRFvYXzxSMN-5PtLv8jgu8kt9Tk4qB5o9Vg/edit?usp=sharing

Try to keep the original format for suggestions from the document so it is clear what we want and why we want it. This allows for Frontier to prioritize issues based on size and impact. Low effort/big reward VS big effort/low reward.

Type
Issue
Potential Resolution
Benefit

 

[CMDRDanFitz]

100% supporting this. 3rd party tools/websites are an integral part of the Elite experience. Upvoted on my 3 main accounts.

 

[Skywalkerctu]

The current journal doesn't record the inventory of the carrier, unless a trade order was set. It'd be great if the journal could record the name and amount of commodities in the carrier's cargo hold. Something like

"inventory": [{"commodity": "gold", "amount": 200}, {"commodity": "silver", "amount": 42}]

This can be its own event or part of the CarrierStats event.

 

[jixxed]

The current journal doesn't record the inventory of the carrier, unless a trade order was set. It'd be great if the journal could record the name and amount of commodities in the carrier's cargo hold. Something like

"inventory": [{"commodity": "gold", "amount": 200}, {"commodity": "silver", "amount": 42}]

This can be its own event or part of the CarrierStats event.

a local variant of the CAPI fleetcarrier response would be nice, written at least when docked to it or when visiting carrier management. preferably also update every x minutes so trades can be monitored or even on any change to the carrier so it becomes a state file. CAPI currently updates only once an hour and it hard to use this way.

 

[Neilski]

Sounds good! Hopefully FD will give it some attention.
The journal has been neglected for quite a lot of the time over the years, with periodic bursts of improvement.

Have you considered making the list into a spreadsheet rather than a document? (This would instantly make it easy to sort the bug list by severity, for example, or filter for other things.)

 

[SenorKarlos]

System Architect information provided in system, docking, etc updates, and on contribution/progress updates (which need slowing down as mentioned)

 

[Cmdr Razzafrag]

I was late to the party to add my suggestions to the document, but I will add my items here for consideration. First one:

First Footfall

Type

New event

Issue

Currently these is no way to detect in the journal if the user has achieved a First Footfall in the game.

Potential Resolution

A simple “event” : “FirstFootfall” written to the journal would suffice

Benefit

This would allow 3rd pary apps to identify and track which bodies a user has earned First Footfall for, and allow them to react with verbal congratulations.

EDCoPilot, for example, attempts to track First Footfalls, and record their locations, for posterity!

Current workaround is to try to detect the "flag" icon when it displays on the screen, but this is hit and miss

 

[Cmdr Razzafrag]

Second suggestion:

NPC Kill

Type

New event

Issue

Currently there is no event recorded for killing an NPC that is not Wanted, or in an Anarchy system. There is no event because they do not warrant a Bounty or a CombatBond event. Can we have a KilledNPC type event in these cases.

Potential Resolution

Write an NPCKill event to the journal, with NPC name, shiptype (if applicable) and faction, in cases where there is no Bounty or CombatBond resulting from the kill.

Benefit

Allow 3rd party tools to accurately track kill totals, and/or react to the NPC death.

 

[Cmdr Razzafrag]

Third request :

VistaBonusApplies element

Type

Additional data element written to scan events

Issue

Currently, afaik, there is no reliable way to determine if the biological sample being scanned will qualify for the 4x bonus. Bios found on first discovery systems and First Footfall bodies are obvious, but there are many that have never been scanned on already discovered systems and visited bodies.

Potential Resolution

Add a VistaBonusApplies element.

Minimal fix : add to the ScanOrganic event when a sample is first scanned
Ideal fix: add to both the ScanOrganic event AND to the SAASignals found event for each of the "Genuses" records reported

Benefit

This will allow 3rd party tools to more accurately predict the credits earned / not handed in for Exo samples, as well as to identify to the user the more lucrative items worth hunting for (those that have not been previously reported, and therefore qualify for the bonus)

Adding the element to the SAASSignals event could help earlier identify and highlight there is a lucrative sample worth pursuing, when the body is surface scanned.

If the user does not surface scan, but scans the sample, then the ScanOrganic event would be also able to identify the bonus would apply, and 3rd party apps could react to this information.

 

[eLCy]

Wrote this in the ticket comments, will copy it here as well.

I'm surprised that adding a list of ground conflicts to FSDJump/Location was mentioned, but the point about adding a conflict conclusion event was not. Currently, there's no completely reliable way to determine which faction won a conflict (especially if the player is in Open where enemy commanders might influence the outcome), nor even to confirm that the conflict was actually finished rather than the player leaving too early (this can be somewhat determined by indirect signs in ground conflicts, but remains purely speculative for space ones). This issue has existed for years and has been raised several times on Frontier forums - it's strange that the document doesn't address it.

Regarding conflicts, I'd also like to suggest logging the participation of other pilots in the instance, both on enemy and allied sides.

For more specific suggestions, a simple:

{ "event":"ConflictFinished", "WinningFaction": ..., "LosingFaction": ... }

would solve 95% of all our problems.
For the remaining 5%, adding a ConflictStarted event with an Intensity: Low/Medium/High field would eliminate the need to rely on secondary indicators to determine conflict intensity (payout sizes for ground conflicts, signal name in SupercruiseDestinationDrop for space ones).
Adding these two events to the journals would allow us to discard all assumptions, guesswork, errors, and 400 lines of code - in favor of unambiguous, reliable checks and calculations, all in just 30-50 lines.
We already have a set of events serving similar purposes for missions - why not add them for conflicts?

 

[WarmedMints]

No event for squadron allegiance page. That would be in there for me as well as a shed load of things.

As developers it can be frustrating as the journals are like an Ikea flatpack, they give you almost everything you need

 

[cmdr erlich]

In the PowerplayMerits event, it would be really nice to include the system where those merits' control points were being applied. As they sometimes occur when you're turning in items in a different system, you can't use the current location.

Edit: Never mind. I see this is in a different event.

 

[Darplata94]

I miss the old bug reporting subforum. I have something I would like changed / consider a bug.

"event":"ShipLocker" is borderline spam

Type
Update to the logic that controls when the "event":"ShipLocker" entry is made.

Issue
Ever since Odyssey was released, "event":"ShipLocker" is entered into the journal on game startup, and after "event":"SupercruiseEntry", "event":"SupercruiseExit", "event":"StartJump", "event":"FSDJump", and "event":"ShipyardSwap", those are some of the specific places I found. It is entered after "event":"StartJump" if you are jumping to hyperspace, but it is not entered if you are jumping to supercruise. It is also entered into the journal at the end of the disembarkation process when going on foot and after "event":"Loadout" at the end of the embarkation process.
Currently each of my "event":"ShipLocker" entries are 10196 characters long. When pasted into a lone text document it is (size: 9.95KB) (Size on disk: 12.0 KB). 2 years ago I endurance raced every available ship to Sagittarius A* un-engineered and my journal save file doubled in size in 4 months. I have been playing fairly actively for 8 years.

Potential Resolution
I recommend that "event":"ShipLocker" only be entered into the journal on game startup, if there was a manual change to the backpack before disembarking onfoot, and if there is a change in the contents of your backpack before embarking back into a vehicle. If you have an on foot delivery mission it would be alright if it was updated on disembarkment, but if you're just doing exobio scans there isn't really a reason for "event":"ShipLocker" to be added to the journal.

Benefit
It would de clutter the journal and make it easier to read with my human eyes, and I won't ever have a 43MB journal file after flying an un-engineered Federal Gunship nonstop for 18h and 1445 jumps. Each of my "event":"ShipLocker" entries were 12963 characters long at this point in time.

Workaround
Finish engineering suits and weapons, then sell all odyssey mats in your inventory.


This is a screenshot of notepad spread across two 4k displays. Each of the large identical blocks is one entry of "event":"ShipLocker". While simply traveling, it is entered twice per jump.

 

[jixxed]

I miss the old bug reporting subforum. I have something I would like changed / consider a bug.

"event":"ShipLocker" is borderline spam

Type
Update to the logic that controls when the "event":"ShipLocker" entry is made.

Issue
Ever since Odyssey was released, "event":"ShipLocker" is entered into the journal on game startup, and after "event":"SupercruiseEntry", "event":"SupercruiseExit", "event":"StartJump", "event":"FSDJump", and "event":"ShipyardSwap", those are some of the specific places I found. It is entered after "event":"StartJump" if you are jumping to hyperspace, but it is not entered if you are jumping to supercruise. It is also entered into the journal at the end of the disembarkation process when going on foot and after "event":"Loadout" at the end of the embarkation process.
Currently each of my "event":"ShipLocker" entries are 10196 characters long. When pasted into a lone text document it is (size: 9.95KB) (Size on disk: 12.0 KB). 2 years ago I endurance raced every available ship to Sagittarius A* un-engineered and my journal save file doubled in size in 4 months. I have been playing fairly actively for 8 years.

Potential Resolution
I recommend that "event":"ShipLocker" only be entered into the journal on game startup, if there was a manual change to the backpack before disembarking onfoot, and if there is a change in the contents of your backpack before embarking back into a vehicle. If you have an on foot delivery mission it would be alright if it was updated on disembarkment, but if you're just doing exobio scans there isn't really a reason for "event":"ShipLocker" to be added to the journal.

Benefit
It would de clutter the journal and make it easier to read with my human eyes, and I won't ever have a 43MB journal file after flying an un-engineered Federal Gunship nonstop for 18h and 1445 jumps. Each of my "event":"ShipLocker" entries were 12963 characters long at this point in time.

Workaround
Finish engineering suits and weapons, then sell all odyssey mats in your inventory.


This is a screenshot of notepad spread across two 4k displays. Each of the large identical blocks is one entry of "event":"ShipLocker". While simply traveling, it is entered twice per jump.

Good one. There is a request to treat a the json files as state files, since that would remove the need for a lot of journal events.
Even a simple empty shiplocker event would be better here and do the writing to the file, like it already does with material collection.

{ "timestamp":"2023-10-29T12:09:52Z", "event":"MaterialCollected", "Category":"Encoded", "Name":"tg_shutdowndata", "Name_Localised":"Massive Energy Surge Analytics", "Count":1 }
{ "timestamp":"2023-10-29T12:09:52Z", "event":"ShipLocker" }

 

[Othon von Salza]

For me, there is a single suggestion I would very much appreciate to be added by FDev.

A journal event for when you are close to an interactable NPC (NPCNear), one when you are close enough for it to talk to you and one when it shows the interaction button when you are very near and looking at it (NPCInRange).

Following fields would be sufficient:
{ "timestamp":"2023-10-29T12:09:52Z", "event":"NPCNear/NPCInRange" ,"name":"Christopher Kennedy"}

Following fields could be handy:
{ "timestamp":"2023-10-29T12:09:52Z", "event":"NPCNear/NPCInRange" ,"type":"bartender","name":"Christopher Kennedy","station":"Faust Lab","starsystem":"123123132",etc.}

Apart from that .. there is indeed a lot of spam. Shiplocker event is one example.
ColonisationConstructionDepot is another more severe one which is triggered every 20 seconds or so when docked at a construction site.

 

[jixxed]

Type
Additional field(s) which is/are present in UI

Issue
The ModuleRetrieve event does not log the engineering effects and experimental effect like the Loadout event does. There is no way to identify the module properly when this information is missing. The following module is a pre-engineered one, but there is no way to see that. There are now 2 pre-engineered modules next to a default engineered one that would match with this configuration.

{
    "timestamp": "2025-06-26T14:36:03Z",
    "event": "ModuleRetrieve",
    "MarketID": 3705689344,
    "Slot": "LargeHardpoint2",
    "RetrievedItem": "$hpt_basicmissilerack_fixed_large_name;",
    "RetrievedItem_Localised": "Seeker Missile Rack",
    "Ship": "cutter",
    "ShipID": 25,
    "Hot": false,
    "EngineerModifications": "Weapon_HighCapacity",
    "Level": 5,
    "Quality": 1.0
}

Potential Resolution
Add the same information related to the module that is also part of the module in the Loadout event

Benefit
Allows to update information in 3rd party apps for the current ship without the need to exit the outfitting screen.

Workaround
Commander needs to exit outfitting to trigger a Loadout event