Discussion Commanders log manual and data sample

[MagicMau]

Hi, the prospect of a journal is amazing. I'm already working on a C# implementation to read the journal. Hope to share that soon.

Startup and Shipyard events will include a ship id.

Will the ModuleBuy/Sell/Swap events also include ship id?

Also I noticed that the Collect and EjectCargo events examples in the Word document describe the boolean values as 1/0 (for Abandoned/Stolen). Will that stay this way, or could you please change those to true/false?

 

[Micha]

But it means that anybody who wants just a log will need to run a third party app to get it and it will do just the same as the game does. There is no real benefit from it (that app needs to write stuff onto disk anyway, so why it shouldn't be done by the game directly?).

The point is we're (maybe) getting a LOT of transient and completely uninteresting EVENT data in the journal now. Equipment turning on/off, that sort of thing. There's NO POINT in storing all of that in a persistent log file, so by devolving the logging into a third-party app solves multiple issues:

• community-defined logging format (in case of required tweaks/bugfixes in the -format- (not the data), we don't rely on a new ED patch)
• community-defined event logging (if we want to turn on/off logging of certain events, it's easy to tweak the logger and/or have it interface directly with apps, instead of building additional logic into the game-client)
• improved performance (instead of having dozens of apps all parsing a file which needs to be written and flushed on every event); especially for things such as Voice-Attack plugins

A custom logger can log only the bits worth preserving (which may differ from person to person), saving valuable HDD space for people running on restricted rigs. I'm speaking from experience as my "netlog" folder is now approaching 10GB in just over half a year of playing. Ok, maybe there's a separate argument for running an occasional "compaction" and/or compression routine over the logs but a preventative is to only log "interesting" events, not "all" events.

The -whole point- of this Journal is to enable third-party apps, so the concern about "needing to run a third party app" seems a bit facetious. There's literally no other point for this data except for third-party apps, unlike the netlog which is (primarily) for client debugging for the developers in case of issues.


I think there are some good reasons for throwing EVENTS out as network packets instead of to a file, and then letting the community deal with them as required (the various apps -already- store events relevant to themselves in their own ways - usually in a database). But it was just a suggestion; if there are -compelling- reasons for disseminating events via a log file, please present them rather than just "A user may want a log file".


EDIT: Ah, you added some additional notes. Yes, a possibility is to have the game send events to both network for transient data and log file for more persistent data. But that increases complexity in the game client AND requires the game developers to make the distinction. AND requires 3rd party apps to potentially monitor multiple sources. Whereas if the logging is done by a community app, it can be MUCH more flexible in what is logged and what isn't and won't require game client patches to fix any omissions or bugs (as long as the game client spits out all the required data).

Also remember - we want to keep it as simple as possible for the game developers to implement as this is likely only a tiny side-project for them to appease the development community. The more "features" we request, the less likely they are to be implemented.

 

[Artie]

The point is we're (maybe) getting a LOT of transient and completely uninteresting EVENT data in the journal now. Equipment turning on/off, that sort of thing. There's NO POINT in storing all of that in a persistent log file, so by devolving the logging into a third-party app solves multiple issues:

• community-defined logging format (in case of required tweaks/bugfixes in the -format- (not the data), we don't rely on a new ED patch)
• community-defined event logging (if we want to turn on/off logging of certain events, it's easy to tweak the logger and/or have it interface directly with apps, instead of building additional logic into the game-client)
• improved performance (instead of having dozens of apps all parsing a file which needs to be written and flushed on every event); especially for things such as Voice-Attack plugins

A custom logger can log only the bits worth preserving (which may differ from person to person), saving valuable HDD space for people running on restricted rigs. I'm speaking from experience as my "netlog" folder is now approaching 10GB in just over half a year of playing. Ok, maybe there's a separate argument for running an occasional "compaction" and/or compression routine over the logs but a preventative is to only log "interesting" events, not "all" events.....

Well, from my standpoint - the most of the currently proposed events in the log are interesting for me, more precisely for Inara (not everything, but most of it). Even the ModuleBuy, ModuleSell and ModuleSwap (it may help to keep the ship configurations up-to-date, if there won't be any event that will provide whole ship configuration at startup and shutdown). As far as I know, there is no event for the equipment on/off currently (if it is meant for power on/off on the right panel in-game) and I agree that kind of event is something that should be on UDP port rather than in the log file.

Also, let's not complicate it for the users - currently with the netlog files they must find a config file, do some changes, locate the .log file and import it. It's complicated enough. When you tell them that they need to download 3rd party app, install it, set options "this, this and that", they must run it together with each game launch and then they must do the rest, they will correctly ask: "Why it is so complicated? Why do I need to run another app that may lower my performance? Why it shouldn't be written by the game itself?" And I am not talking about cases when they will have some settings wrong, using an outdated app with some bugs or outdated specification and so on, it will be an utter mess. The file size is relevant just for the single file/batch, when it needs to be imported to the website (too large file(s) or too much fragmented small files can cause problems with upload), not so relevant for the archive - nobody forces user to store them and nobody forces user to keep them in the game folder. In the current days of terabyte hard drives is few gigabytes nothing (well, at least if user doesn't have just the small SSD in his computer)

It's simply a double edged sword and there can be even more problems. As I said, please let's do not mix requirements for the two different things too much. Apps that reacts to the player's actions during the game session needs something and apps that are rather intended for storing data after the game session needs something else. Currently proposed log format is rather for the data storing, but it also includes things that may be useful during the session and in my view it is a reasonable compromise. But if we would like to have it perfect, log file AND UDP is a very valid method how to satisfy both requirements. No just log or not just UDP. Both. Because each one is better for something else.

edit: Eh, sorry for the wall of text. I hope it will bring more light to this "issue" and my standing as someone who imports the data and not "consume" them on the fly.

Also remember - we want to keep it as simple as possible for the game developers to implement as this is likely only a tiny side-project for them to appease the development community. The more "features" we request, the less likely they are to be implemented.

Yes, I agree completely. So it's even additional reason why we should stick to what was already proposed by Howard and just try to propose doable and easy improvements and extensions instead of changing things completely. When "we" will finetune the current stuff, that UDP (for example) can be eventually built on top of that.

 

[MagicMau]

Hope to share that soon.

A bit sooner than expected. I put my draft implementation here on Github, mostly for my own use, but maybe some of you find it useful as well.
I will try and keep it updated as soon as more details on the journal come in.

 

[clinton]

Add BountyID and MissionID

Not sure if this has mentioned yet, but like my earlier suggestion to add ShipIDs, BountyIDs and MissionIDs should be added, so we can work out what mission has been completed/what bounty handed in.

Indeed adding IDs is always a good idea if one's available.

 

[hchalkley]

I have been able to include a number of your suggestions, so here's the update to the reference manual

Updated Manual: Journal_Manual.doc

Updated sample journal file: Journal.160726141417.01.log

I won't have much time to make further changes over the next couple of weeks, but there may be a chance for a few more tweaks later on

 

[robbyp]

Thank you for your help ;-)

Looks good.

In the future, I'd like to see some basic UI states in there telling us which view the commander is looking at (systems,target,camera,galaxy map,system map) etc. Just so we could tailor our programs to what the commander is viewing. I do not wish to know any other UI states for my purpose, just those, so it should not provide a cheat vector.

Rob

 

[Esvandiary]

Great changes, thank you very much for the effort!

 

[themroc]

I have been able to include a number of your suggestions, so here's the update to the reference manual

Updated Manual: Journal_Manual.doc

Updated sample journal file: Journal.160726141417.01.log

I won't have much time to make further changes over the next couple of weeks, but there may be a chance for a few more tweaks later on

A big thanks! Adding more information about systems/stations/bodies is the best news possible. This will make it so much easier to keep track of the actual universe.

Again ... Thanks!

 

[Artie]

I have been able to include a number of your suggestions, so here's the update to the reference manual

Updated Manual: Journal_Manual.doc

Updated sample journal file: Journal.160726141417.01.log

I won't have much time to make further changes over the next couple of weeks, but there may be a chance for a few more tweaks later on

Nice changes, thank you for it. Do you think there will be possible to put more features in until it will be released? I am especially asking about the overall assets value and superpower reputations at least, without it is updating of cmdr's profiles incomplete a little bit. Keep up the good work!

 

[Shadowdancer]

I must say that I still am not—and never will be—a fan of the "_Localised" suffixed attributes. Having those as a hash below a single "Localised" or "Translation" (or whatever) attribute would look way cleaner to me and would not require further string matching and extraction to use them.

 

[Esvandiary]

One quick query...

With the "Scan" event, is there any way to fire that event on bodies you already have information on (i.e. have previously scanned)?
e.g. Would it be possible to immediately fire a Scan event when you target a body you already have data on?

 

[jgm]

I have been able to include a number of your suggestions, so here's the update to the reference manual

Updated Manual: Journal_Manual.doc

Updated sample journal file: Journal.160726141417.01.log

I won't have much time to make further changes over the next couple of weeks, but there may be a chance for a few more tweaks later on

A lot of good changes in there, thanks for putting in the effort.

 

[eventure]

I have been able to include a number of your suggestions, so here's the update to the reference manual

Updated Manual: Journal_Manual.doc

Updated sample journal file: Journal.160726141417.01.log

I won't have much time to make further changes over the next couple of weeks, but there may be a chance for a few more tweaks later on

Great work, but is there a way to add also the reputation to a superpower and their progress value, like for ranks?

 

[Martin Schou]

I won't have much time to make further changes over the next couple of weeks, but there may be a chance for a few more tweaks later on

Great work all round - seriously, if I could buy you a pizza or similar I would (sadly I'm flat broke).

Two issues that I do hope you get a chance to look at - one is fairly minor and should be quick to implement/fix, the other quite a bit larger.

The small one:

Docked/FSDJump/Startup/ressurection (4.1, 4.7, 4.9)

On these events you write out this set of information on factions:

Faction
FactionState
Economy
Government

Is it possible to add Allegiance to this list? Pretty please with sugar on top? It would allow us to semi-automatically map out the galaxy in terms of super powers (Alliance, Empire, Federation and Independent - not flight, x-ray vision, super strength and sense of smell).

As I said, this should a tiny change to a few events.

Now for the bigger one.

PowerPlay events. I cannot stress how useful it would be if the PowerPlay events dealing with merits gave us a merit count for the system affected. Currently we are stuck using cached data that is only updated when handing in; this is problematic, as we can experience crashes that keeps the cached data on the client. Since different powers have different mechanisms for expansion/fortification/preparation, this can make a huge difference at the end of cycles. These are my suggestions:

Entry	Priority	Request	Rationale
9.1 PowerplayCollect	Medium	Include system name and merit count if relevant	Half the powers carry fortification merits from their control systems to the HQ. Currently there no way for these powers to get the latest (and thus correct) fortification numbers without delivering them to the HQ; the other half can deliver one fortification merit carried from HQ to any control system and get the correct number. Similar differences exist for preparations, where half the powers can deliver 1 merit with no required destination to get updated numbers and the other half have to deliver it to a control system to get the correct number. Logging the correct number (when picking up fortification merits at a control system or preparation merits at a non-PowerPlay system) would partially alleviate this without massive code changes to PowerPlay. It would also be extremely helpful for organized PowerPlay groups. Parameters: System: name of system; relevant for half the powers when doing fortifications and preparations Power: name of power Type: type of commodity Count: number of units TriggerFor: If expansion or fortification, show the trigger for the system. QuantityFor: If expansion or fortification, show the current merit count for the power and the system TriggerAgaisnt: If expansion or fortification, show the trigger for the system. QuantityAgainst: For expansion and fortification, show the current merit count opposing or undermining the system PreparationCount: For preparations (as they can be contests) list each power with more than 0 merits in the system and their merit counts. Examples: Spoiler Outbound Fortification (picked up in HQ and delivered to a control system). Here we only know that we have picked up 10 fortification merits. { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayCollect", "Power":"Aisling Duval", "Type":"aislingpropaganda", "Count":10 } Inbound Fortification (picked up in a control system, delivered to HQ and can ONLY be used to fortify a specific control system). Here we know the system, that we picked up 10 fortification merits and the current merit state of the system (currently cancelled). { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayCollect", "Power":"Edmund Mahon", "Type":"mahonlegislativecontracts", "Count":10, "System":"Ithaca", "TriggerFor": 5314, "QuantityFor":6724, "TriggerAgainst":18818, "QuantityAgainst":90210 } Outbound Preparation (picked up in any control system and delivered to a target system). Here we only know that we have picked up 10 preparation merits. Where we picked them up is irrelevant, and can be determined by previous logs: { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayCollect", "Power":"Edmund Mahon", "Type":"mahontradeagreements", "Count":10} Inbound Preparation (picked up in a target system and delivered to any control system and can ONLY be used to prepare a specific target system). Here we know the system, that we picked up 10 preparation merits and the current merit state of the system (currently two powers vying for the same system, ALD with 11,485 losing to Zachary Hudson with 23,862) { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayCollect", "Power":"Zachary Hudson, "Type":"hudsonrestrictedintel", "Count":10, "System":"LHS 2088", "PreparationCount":[ { "Power":"Arissa Lavigny-Duval", "QuantityFor":11485 }, { "Power":"Zachary Hudsonl", "QuantityFor":23862 } ] } Outbound Expansion (picked up in a control system and delivered to any expansion system). Here we know that we picked up 10 expansion merits. Where we picked them up is irrelevant, and can be determined by previous logs: { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayCollect", "Power":"Edmund Mahon", "Type":"mahonlegislativecontracts", "Count":10} Inbound Expansion (picked up in an expansion system and delivered to any control system). Here we know that we picked up 10 expansion merits and the current merit state of the system (currently failing to expand as the expansion trigger hasn't been met). At the time of this writing, this is not possible, so I'm using Mahon as an example: { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayCollect", "Power":"Edmund Mahon", "Type":"mahontradeagreements", "Count":10, "System":"Sothis", "TriggerFor": 96471, "QuantityFor":4006, "TriggerAgainst":5253, "QuantityAgainst":1740 }
9.2 PowerplayDefect	Medium	Include new merit count for the new power	When defecting to a power, you end up with a new merit count. Including that number in the log would help immensely in tracking a commander's merits throughout a cycle. Parameters: FromPower ToPower OldMeritCount NewMeritCount Example: { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayDefect", "FromPower":"Zachary Hudson", "ToPower":"Li Yong-Rui", "OldMeritCount":8280, "NewMeritCount":4140 }
9.3 PowerplayDeliver	Medium	Include system merit count	Due to caching issues and PowerPlay bugs, the client is not always able to display the correct number for a system, even if you've just delivered merits (crashing springs to mind along with turmoil systems). Having the system merit count for the merits you've just delivered would alleviate this a bit, and it would be extremely helpful for organized PowerPlay groups. Parameters: Power Type Count System TriggerFor: If expansion or fortification, show the trigger for the system. QuantityFor: If expansion or fortification, show the current merit count for the power and the system TriggerAgaisnt: If expansion or fortification, show the trigger for the system. QuantityAgainst: For expansion and fortification, show the current merit count opposing or undermining the system PreparationCount: For preparations (as they can be contests) list each power with more than 0 merits in the system and their merit counts. Examples: Spoiler Outbound Fortification (picked up in HQ and delivered to a control system). Here we know that we delivered 10 fortification merits and the current merit state of the system (currently fortified) { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayDeliver", "Power":"Aisling Duval", "Type":"aislingpropaganda", "Count":10, "System":"Karsuki Ti", "TriggerFor":5045, "QuantityFor":18088, "TriggerAgainst":46327, "QuantityAgainst":0 } Inbound Fortification (picked up in a control system, delivered to HQ and can ONLY be used to fortify a specific control system). Here we know the system, that we delivered 10 fortification merits and the current merit state of the system (currently cancelled). { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayDeliver", "Power":"Edmund Mahon", "Type":"mahonlegislativecontracts", "Count":10, "System":"Ithaca", "TriggerFor": 5314, "QuantityFor":6724, "TriggerAgainst":18818, "QuantityAgainst":90210 } Outbound Preparation (picked up in any control system and delivered to a target system). Here we know that we have delivered 10 preparation merits and the current merit state of the system (two powers vying for the system, with ALD winning with 15,571 over Mahon with 7,002) { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayDeliver", "Power":"Edmund Mahon", "Type":"mahontradeagreements", "Count":10, "System":"Aditi", "PreparationCount":[{"Power":"Edmund Mahon", "QuantifyFor":7002}, "Power":"Arissa Lavigny-Duval", "QuantifyFor":15571] } Inbound Preparation (picked up in a target system and delivered to any control system and can ONLY be used to prepare a specific target system). Here we know the system, that we delivered 10 preparation merits and the current merit state of the system (currently two powers vying for the same system, ALD with 11,485 losing to Zachary Hudson with 23,862) { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayDeliver", "Power":"Zachary Hudson, "Type":"hudsonrestrictedintel", "Count":10, "System":"LHS 2088", "QuantityFor":23862, "PreparationCount":[ { "Power":"Arissa Lavigny-Duval", "QuantityFor":11485 }, { "Power":"Zachary Hudsonl", "QuantityFor":23862 } ] } Outbound Expansion (picked up in a control system and delivered to any expansion system). Here we know that we delivered up 10 expansion merits and the current merit state of the system (failing to expand, as the expansion trigger has not been met) { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayDeliver", "Power":"Edmund Mahon", "Type":"mahontradeagreements", "Count":10, "System":"Sothis", "TriggerFor": 96471, "QuantityFor":4006, "TriggerAgainst":5253, "QuantityAgainst":1740 } Inbound Expansion (picked up in an expansion system and delivered to any control system). Here we know that we delivered up 10 expansion merits and the current merit state of the system (currently failing to expand as the expansion trigger hasn't been met). At the time of this writing, this is not possible, so I'm using Mahon as an example, which is why the example is identical to that of Outbound Expansion: { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayDeliver", "Power":"Edmund Mahon", "Type":"mahontradeagreements", "Count":10, "System":"Sothis", "TriggerFor": 96471, "QuantityFor":4006, "TriggerAgainst":5253, "QuantityAgainst":1740 }
9.8 PowerplayVote	Medium	Include system merit count	It would be extremely helpful for organized PowerPlay groups to have the preparation merit count logged when voting for a preparation system. Parameters: Power Votes System PreparationCount: list each power with more than 0 merits in the system and their merit counts. Example: { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayVote", "Power":"Denton Patreus", "Votes":10, "PreparationCount":[ { "Power":"Denton Patreus", "QuantityFor":1802 } ] }
9.9 PowerplayVoucher	Medium	Include system merit count	When handing in combat voucher for either expansions or undermining, getting the system merit count (expansion merits or undermining merits) logged would be quite helpful, especially with undermining as (due to PowerPlay bugs) the status for turmoil systems are not properly displayed (always 0 merits for both fortification and undermining). This addition would be extremely helpful for organized PowerPlay groups, and it would work as a workaround for the bug without massive code changes to PowerPlay. Parameters: Power Systems:[{SystemName, Merits, TriggerFor, QuantityFor, TriggerAgainst, QuantityAgainst}, {SystemName, Merits, TriggerFor, QuantityFor, TriggerAgainst, QuantityAgainst,}] Example: { "timestamp":"2016-06-10T14:32:03Z", "event":"PowerplayVoucher", "Power":"Zemina Torval", "Systems":[ {"SystemName":"Ithaca", "TriggerFor": 5314, "QuantityFor":6724, "TriggerAgainst":18818, "QuantityAgainst":90210 } ]}

These all have a common theme - system merit counts. If merits are the lifeblood of PowerPlay, the number of merits in a system are the electrical signals in its nervous system. Currently we are stuck with old cached data, and I personally feel that logging the correct numbers would alleviate some of the issues with stale data that we see as organized PowerPlay groups in a way that is low on resources both in terms of development, as it's simply expanding a log entry, and with the organized PowerPlay groups, as we could reduce the amount of manual data entry we have to do.

All of these changes will ensure that the logs always have the latest known merit information for systems that have been affected; this includes all triggers, fortification, undermining, expansion and opposition merits as well as the state of any preparation systems. This would be invaluable for both organized powers *and* anyone trying to track the global progress in PowerPlay as the cycle progresses.

I realize that the ask for the PowerPlay entries is a big ask, but if you deliver, I promise to name an Anaconda after you when we can name our ships.

Kind regards
CMDR Vectron
PowerPlay organizer for Edmund Mahon
Alliance Office of Statistics
Gateway

 

[Purrcat259]

I have been able to include a number of your suggestions, so here's the update to the reference manual

Updated Manual: Journal_Manual.doc

Updated sample journal file: Journal.160726141417.01.log

I won't have much time to make further changes over the next couple of weeks, but there may be a chance for a few more tweaks later on

Awesome news!

My quick feedback:
Can CollectCargo and EjectCargo (7.2/7.3)'s Stolen/Abandoned flags be converted to boolean instead of ints?

Thanks!

 

[Micha]

One quick query...

With the "Scan" event, is there any way to fire that event on bodies you already have information on (i.e. have previously scanned)?
e.g. Would it be possible to immediately fire a Scan event when you target a body you already have data on?

Can I request an addition to the data-per-body for a "Scan" event; specifically, the (list of) "First Discovery" commanders (if any) for a body.

Can we also get a "SystemScan" event, which is triggered on a Discovery Scanner and would list basic info (full info if previously surface-scanned) of all bodies in range of the scan. "type" to be "Basic", "Intermediate", or "Advanced".

 

[djadjok]

I have been able to include a number of your suggestions, so here's the update to the reference manual

Updated Manual: Journal_Manual.doc

Updated sample journal file: Journal.160726141417.01.log

I won't have much time to make further changes over the next couple of weeks, but there may be a chance for a few more tweaks later on

Excellent work!
While I don't want to be annoying I'd like to add (heh, repeat) some suggestions/questions regarding this new release of the manual mostly concerned my current in-game field of interest: persistent not-hidden planetary settlements. I've marked the presence of some points in the new release that are linked to the "planetary surface" events but the overall information provided is very limited and lack important details.
First of all - and the most important - information about the given settlement. Looks that we'll have "USS Drop" info, so why we cannot have same kind of info about a settlement? I mean:
(1)settlement name
(2)settlement owned by faction (faction name/allegiance/government)
(2a)faction current state?
(3)settlement on-planetary coordinates (as of travel destination target)?
(4)settlement full layout information - size, security, "economy"(industrial/exploration/etc) or just in descriptive form like "Large_Industrial_002" (as it appear sometimes in the netlogs - the best solution). If this info will be provided then it will be better to cut away any size-related "+" from settlement's name(1) (to avoid possible and already present issues)
While I greatly appreciate the amount of work and significant variety of planetary settlements provided for us by developers in-game and understand the initial idea to hide this information from players I must say that while this number is big it is however limited so this is not a mystery anymore at least for me, so I don't see any reason in continuation to hide this info and not to unlock it.
The problem I see here is that one normally cannot dock at a planetary settlement. Only limited number of layouts provide some kind of a "landing pad" that can be used only in a state of a direct assault on a given settlement (far from "normal" conditions), also no normal docking procedure so far observed for those cases. But at the same time as far as I understand any "populated" persistent-not-hidden installation in-game (like starports/outposts/planetary ports AND named planetary settlements - owned by factions) have some kind of "influence"/proximity area (or just some predefined distance of "direct visual", say ~ 20 km for example). So my suggestion - fire an event to the journal upon entering (normal flight/srv)/dropping (from supercruise) to/in the influence/proximity area of a settlement with full info described above (can be also valid for other "populated" in-game objects). Maybe to avoid spamming of the log only on the first enter/game reload in a given instance (not sure that this countermeasure is necessary).
note 1: In case of misunderstanding I must underline once again that all I've said above is related to persistent-not-hidden planetary settlements, those one can see on the system map and is not related to any on-the-fly generated/instance dependent/not persistent surface POI's.
note 2: providing layout "model" name can at least reduce the effect of the known issue with some "small" size settlements naming - with those that have lost "+" sign in their names on some stage of generation and so can be confused with "tiny" settlements.
Questions/suggestions regarding proposed journal from the same - "planetary settlement" - point of view:
-> 4.1 Docked.
When written: when landing at landing pad in a space station, outpost, or surface settlement
Don't catch at all the event "docked" in case of surface settlement. What does that mean? Some extension for future development?
->4.9 Location.
When written: at startup, or when being resurrected at a station
This can be influenced in case of a "startup" near a planetary settlements (influence zone)
->4.11 SupercruiseExit
When written: leaving supercruise for normal space
same as above - dropping directly in the settlement's influence zone
->4.13 Undocked
When written: liftoff from a landing pad in a station, outpost or settlement
Same question as for 4.1 (Docked)
->5.3 Died
When written: player was killed
Just wonder what will be written in case of a player killed by a skimmer or stationary turret.
->8.17 RedeemVoucher
When Written: when claiming payment for combat bounties and bonds
I hope that intel data is not forgotten (as it is so far). Yep, so far I haven't found any marks of intel data in the in-game statistic or influence on rank progression (doubt if any but I haven't dig here too far).
-> 10.3 DatalinkScan
When written: when scanning a data link
Parameters:
Message: message from data link
And what about:
1)type/text description of the object that was scanned? Terminal/Data Point. "Security Access Terminal", "Data Point", "Core Data Terminal", crashed nav.beacon, etc?
2)Boolean describing type of access - private/public


cmdr Dja

 

[Andargor]

I have been able to include a number of your suggestions, so here's the update to the reference manual

Updated Manual: Journal_Manual.doc

Updated sample journal file: Journal.160726141417.01.log

I won't have much time to make further changes over the next couple of weeks, but there may be a chance for a few more tweaks later on

Great work!

Can I reiterate my suggestion to include route events, i.e. which systems are in the route when it is set? Very useful to track trip progress in another screen.

EDIT: As a corollary, setting bookmarks would be very cool to pump to log. Allows sharing with friends with the third-party apps.

I hope that in addition, if there is ever an API allowing us to feed information back to the client, that we would be able to provide a desired route from a third party app. Customized routes FTW

Also, have you read our comments to pump out the raw events out of the client on a UDP port, in addition to dumping to log? If it is not too complex to implement, it allows for low-latency event handling.

 

[themroc]

Dear hchalkley,


Thanks again for this awesome wonderland of data. [up] The current state is awesome already. And we (EDCD) would not be developers if we would not give feedback once again. It is way less than the last time though.

Entry	Priority	Request	Details
3.3 LoadGame	High	Overall assets value	There are actual credits, loans, but overall assets are missing for the complete overview of player’s “net worth”
4.1 Docked	Various	Journal should log more station properties on docking.	High priority: Distance to arrival Allegiance Facilities Secondary economy (if it is not handled by the single key) Medium priority: Prohibited goods Wealth Population Is controlling station Low priority: Exported goods Imported goods Non-ruling factions
4.7 FSDJump	Various	Journal should log more system properties on arrival.	High priority: System reserve (common, pristine etc.) Allegiance Low priority: Population
6.1 Scan	High	Write a Scan entry even if the Cmdr has previously scanned the body.
6.1 Scan	Various	Journal should log more information about the body.	High priority: Gravity Medium priority: Earth masses Radius Low priority: Semi major axis Orbital eccentricity Orbital inclination Arg of periapsis Axis tilt
6.1 Scan	Medium	Journal should log detailed information about the rings on scan.	It looks like the “Rings” property reports the count of rings. A list with following properties would be great: Name Type Mass Semi major axis Inner radius Outer radius Materials Surface temperature (star)
6.1 Scan	Medium	Journal should write an entry also if the Cmdr doesn't have a DSS fitted.	Not clear whether this entry is generated if the user isn’t carrying a detailed surface scanner. Only a minority of Cmdrs have a DSS installed; it would be great if some basic information gets logged when they don't have one.

Created in a community effort by EDCD.