Discussion Commanders log manual and data sample

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

It's like christmas ^_^

Thank you SO much! Tell you what, I'll make sure to put something together which I hope is newsletter-worthy.
 
I wouldn't mind having a go at creating an orrery view app. However, I need a bit more info on the body another body orbits and the type and size of orbit with inclination etc. is it possible to get this? It might be better to get it from a combination of discovery and detailed scand, I'm happy to glue together myself. I'd be looking at modelling it in a 3D engine and then having a play button to show orbits in action with various play speeds and a moveable camera. I know it'll be a challenge but if you can get me the data I'll give it a red hot go as we say in oz!!!!
 
It's great!
But could you add the ability to get information about all the factions in the system.
Their influence in the system.
Their current, pending and recovering states.
It is also desirable what assets in their owned.
At least while in the system.
 

hchalkley

Senior Programmer
Frontier
This player's journal is intended to provide a log of significant gameplay events: it is not intended to include any large-scale data dumps of commander profile, market commodity listings or shipyard and outfitting stock lists.

It also not designed to include updates to ship's micromanagement state like hardpoints, landing gear, scoop, lights etc: if we do make this sort of data available, we would do it in a different way. In particular, we don't want to broadcast network packets - this has the potential for causing problems on a Lan. We will be investigating other data sources in the future.

I’ve implemented a lot of your suggestions, but some have been left out because the requested information was not immediately available at the point in the code where I'm currently logging the data (referring to things like powerplay stats, and mission IDs) I'm not saying it's impossible, just that it would take more time, and I was aiming for best 'bang for the buck'.

To answer a few specific questions:

Q: Will player journal will be available in game?/So when are we getting an in game UI for this?
A: This is likely to be added in the future, there’s no ETA at the moment.

Q: Are these events going to be unique to the player, or are we going to get them regardless of who did it
A: it's only supposed to record events relevant to the player - if in practice you get events relating to other ships, please report it as a bug!

Q: Also, is there any standards for how long the logs are kept, and how often they're split? Sorry if that's been answered, I just couldn't find it with a search.
A: A new file is started each time you start the game. You'll get 'LoadGame' event each time you start from the main menu.

Q: And a question on synchronisation: if I receive (for example) a "ShipyardBuy" event can I query the companion app API safe in the knowledge that it will give me the data on the new ship, or might there be a delay between seeing the event and the server being updated? I'm very much hoping the former, because otherwise it's going to be a right pain to provide useful event-based triggers.
A: As I understand it, there's a master database server, and multiple webservers behind a load-balancer to handle all the queries, so there might possibly be a small latency between an update happening and the correct results on a subsequent query.
 

Robert Maynard

Volunteer Moderator
Many thanks for all of the clarifications!

This player's journal is intended to provide a log of significant gameplay events: it is not intended to include any large-scale data dumps of commander profile, market commodity listings or shipyard and outfitting stock lists.

A bit disappointing regarding the commodities / shipyard / outfitting.

It also not designed to include updates to ship's micromanagement state like hardpoints, landing gear, scoop, lights etc: if we do make this sort of data available, we would do it in a different way. In particular, we don't want to broadcast network packets - this has the potential for causing problems on a Lan. We will be investigating other data sources in the future.

I have a pair of these that I use to control certain ship functions with a set of "dumb" control sheets created by NCSarge:

814gvTl0g3L._SL1500_.jpg


.... and have been contemplating fitting them with LCD screens to mimic ship control settings however there's no way to interrogate the game to get the current settings.

Being able to mimic the ship's current settings using log outputs would be a boon - I'd really like to see this information made available.

It's been used to good effect in other games:

hqdefault.jpg
 
Last edited:
I’ve implemented a lot of your suggestions, but some have been left out because the requested information was not immediately available at the point in the code where I'm currently logging the data (referring to things like powerplay stats, and mission IDs) I'm not saying it's impossible, just that it would take more time, and I was aiming for best 'bang for the buck'.

Fair enough. Obviously you can't implement something that'd require massive rewrites of other code. That being said, I will say that for the PowerPlay events to be truly useful, they need to include the merit states for the systems being affected. We'll have to make due until then.

And thank you for being as receptive and open to our ideas and suggestions.
 
It also not designed to include updates to ship's micromanagement state like hardpoints, landing gear, scoop, lights etc: if we do make this sort of data available, we would do it in a different way. In particular, we don't want to broadcast network packets - this has the potential for causing problems on a Lan.

Thanks for your comments. I'd just like to point out that the port broadcast idea would be to localhost (127.0.0.1/8), so there would be no impact on a LAN.
 
Last edited:
Two questions, that are important for me:
1) Will the netlog dump continue to exist beside the journal?
2) If so, is the content output for 'SYSTEM:' changed in anyway?

Thanks in advance.
 
I wouldn't mind having a go at creating an orrery view app. However, I need a bit more info on the body another body orbits and the type and size of orbit with inclination etc. is it possible to get this? It might be better to get it from a combination of discovery and detailed scand, I'm happy to glue together myself. I'd be looking at modelling it in a 3D engine and then having a play button to show orbits in action with various play speeds and a moveable camera. I know it'll be a challenge but if you can get me the data I'll give it a red hot go as we say in oz!!!!

Hi Calvert, have you looked at http://www.elitegalaxyonline.com/ ? :)
 
1) Will the netlog dump continue to exist beside the journal?
2) If so, is the content output for 'SYSTEM:' changed in anyway?
You might be better off switching to the journal in any case because it doesn't require messing with the VerboseLogging setting, and the entries will be flushed to the file so (unlike the netLog) won't be delayed by I/O buffering.

The "FSDJump" and "Docked" journal entries are a little harder to parse than "System:" and "GetSafeUniversalAddress" netLog entries, but that's because they will contain more useful info.
 
Last edited:
You might be better off switching to the journal in any case because it doesn't require messing with the VerboseLogging setting, and the entries will be flushed to the file so (unlike the netLog) won't be delayed by I/O buffering.

The "FSDJump" and "Docked" journal entries are a little harder to parse than "System:" and "GetSafeUniversalAddress" netLog entries, but that's because they will contain more useful info.

Sadly, the journal doesn't produce any Body ID and relative position data in KM for the location in a star systems or for stations, so I have to pull these data from the netlog, but only these for now.
TCE heavily relies on the Body ID, to detect a stored market/location before landing on it without using EDMC to pull your current market name after landing.
 
Last edited:
Oh man, this is great! My inner nerd (not so inner) prays that someone develops a General Ledger app.

I would love to do a bit of financial planning, and budgeting would be great, but mostly to answer that age-old question, "Why are the credits gone?"
 
This player's journal is intended to provide a log of significant gameplay events: it is not intended to include any large-scale data dumps of commander profile

Sure, but you added already all ranks and progress for the player, why not the reputation of the player to superpowers? It would make the the progress/rank event complete. Didn't understood, why these data are left out.
 
Last edited:
Hi Calvert, have you looked at http://www.elitegalaxyonline.com/ ? :)

I had not!!! What an excellent piece of work. I should have googled before I posted!!! My idea was to be a little more cmdr centric, but if I'm honest that was more of a byproduct than a goal!! I shall look into the elitegalaxyonline a little more as this kind of thing interests me a lot and I don't know how I managed to miss that!!! Good job I'm not working for the canonn, I'd miss probes and artifacts all over the place!! Thanks again for the reference.
 
This player's journal is intended to provide a log of significant gameplay events: it is not intended to include any large-scale data dumps of commander profile, market commodity listings or shipyard and outfitting stock lists.

It also not designed to include updates to ship's micromanagement state like hardpoints, landing gear, scoop, lights etc: if we do make this sort of data available, we would do it in a different way. In particular, we don't want to broadcast network packets - this has the potential for causing problems on a Lan. We will be investigating other data sources in the future.

I’ve implemented a lot of your suggestions, but some have been left out because the requested information was not immediately available at the point in the code where I'm currently logging the data (referring to things like powerplay stats, and mission IDs) I'm not saying it's impossible, just that it would take more time, and I was aiming for best 'bang for the buck'.

To answer a few specific questions:

Q: Will player journal will be available in game?/So when are we getting an in game UI for this?
A: This is likely to be added in the future, there’s no ETA at the moment.

Q: Are these events going to be unique to the player, or are we going to get them regardless of who did it
A: it's only supposed to record events relevant to the player - if in practice you get events relating to other ships, please report it as a bug!

Q: Also, is there any standards for how long the logs are kept, and how often they're split? Sorry if that's been answered, I just couldn't find it with a search.
A: A new file is started each time you start the game. You'll get 'LoadGame' event each time you start from the main menu.

Q: And a question on synchronisation: if I receive (for example) a "ShipyardBuy" event can I query the companion app API safe in the knowledge that it will give me the data on the new ship, or might there be a delay between seeing the event and the server being updated? I'm very much hoping the former, because otherwise it's going to be a right pain to provide useful event-based triggers.
A: As I understand it, there's a master database server, and multiple webservers behind a load-balancer to handle all the queries, so there might possibly be a small latency between an update happening and the correct results on a subsequent query.

So I can fully appreciate where you are trying to draw the line. To harp on my own agenda though, I can see that we are so close to having all the data from the detailed scan to be massively useful for community projects, we are just missing a couple of the parameters that you can get on the System Map. Is there no chance that you could add those to the scan data so that the community can have access to quality celestial body data? Since this even will only fire for someone with the detailed scanner when they actually scan a body, I think we are avoiding the large scale data dumps you are referring to. Selfishly I'd like to see the following data in the scan JSON:-

  • Body Name
    - ALREADY IN PROPOSAL
  • Planet Class
    - ALREADY IN PROPOSAL
  • Earth Masses
    - NEW REQUEST (according to manual, but I think the sample JSON has it there already)​
  • Radius
    - NEW REQUEST (according to manual, but sample does have it in the JSON as above)​
  • SurfaceTemperature
    - ALREADY IN PROPOSAL
  • TerraformState
    - ALREADY IN PROPOSAL
  • Volcanism
    - ALREADY IN PROPOSAL
  • Atmosphere
    - ALREADY IN PROPOSAL
  • Composition
    - (%age rock/ice/metal) NEW PROPOSAL (not really essential)​
  • OrbitalPeriod
    - ALREADY IN PROPOSAL
  • SemiMajorAxis
    - NEW PROPOSAL
  • OrbitalEccentricity
    - NEW PROPOSAL
  • OrbitalInclination
    - NEW PROPOSAL
  • ArgumentOfPeriapsis
    - NEW PROPOSAL
  • RotationPeriod
    - ALREADY IN PROPOSAL
  • AxialTilt
    - NEW PROPOSAL
  • TidalLock
    - ALREADY IN PROPOSAL
  • Rings
    - ALREADY IN PROPOSAL


I kept the above to planets as I think it's obvious that when a star has companions, the same orbital characteristics will be needed. There aren't really all that many new paramters required so do I stand a chance at getting them or am I asking too much (there aren't too many red ones ;))? I have highlighted my key wants, I'm not asking for you to take anything away, I'm just trying not to clutter the post too much ;)
 
Something that doesn't seem to have been mentioned is the encoding of the journal. Can we assume that it is UTF-8 encoded? The samples that have been provided so far have been 7-bit ASCII with no Byte Order Mark
 
Last edited:
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


Thanks for the update. Many good changes and a big thanks for the new journal systems.

I have 2 questions:

1. Character encoding for journal file will it be UTF8 without bom? (For the localized strings)

2. First version of fileheader had a timezone field. I want it back to see which timezone was used for files afterward. Might be changed with time for traveling users.
 
Thanks for the update. Many good changes and a big thanks for the new journal systems.

I have 2 questions:

1. Character encoding for journal file will it be UTF8 without bom? (For the localized strings)

2. First version of fileheader had a timezone field. I want it back to see which timezone was used for files afterward. Might be changed with time for traveling users.

I concur with BravadaCadelanne and you that encoding should be UTF8 without BOM, especially if they want to put some localized strings in.

As for timezone, most of us recommended logging in UTC, leaving the local timezone conversion to whatever tool consuming the log.
 
Last edited:
Back
Top Bottom