Discussion Commanders log manual and data sample

[nrage]

As for "Is there a chance that you'll get to add all factions, allegiances, governments, states and their influence levels in a system to the log at some point? " (etc), I was specifically asked by the designers not to include large info-dumps into this journal - it's supposed to be a list of things that *you* the pilot have done.

We don't really need a large info dump.

And, the information should only be delivered when the pilot has done something, like arrive in the system. Or, opened the system map. Or, docked. At those points the pilot could themselves have obtained the information manually, so it seems reasonable to allow automatic collection of it.

So, on FSDJump, Dock, or some new OpenSysMap event I would really like to see..
- A list of local factions, including; faction name, local faction influence%, current faction state.

If we could also get each factions pending state(s) and recovering state that would be even better, but I would settle for the name, influence and current state.

 

[NeoTron]

The new version of the Player Journal reference manual (v9) for 2.3 beta 1 is now available.

[...]

• Add info at startup with new events for Cargo, Materials, Passengers, and Loadout

This is great! With regards to the loadout event - some comments:

• The event appears to be lacking details to make it truly useful, i.e actual statistics on the rolls on engineered modules.
• Just writing on startup is limiting the usefulness. It would be valuable when swapping ships, as well as when loadout is changed.

It would be great if this could replace exporting ship information from the mobile app API, since that API requires our account login/password to be entrusted to a third party application. However for it to be a viable replacement, it would need details and would have to be exported on more occasions.

 

[lemny]

This is great! With regards to the loadout event - some comments:

• The event appears to be lacking details to make it truly useful, i.e actual statistics on the rolls on engineered modules.
• Just writing on startup is limiting the usefulness. It would be valuable when swapping ships, as well as when loadout is changed.

It would be great if this could replace exporting ship information from the mobile app API, since that API requires our account login/password to be entrusted to a third party application. However for it to be a viable replacement, it would need details and would have to be exported on more occasions.

This!

For example: I can build my entire base fitting in 1 Minute in Coriolis.io by hand... but then I want to enter my mods... oh boy...
It would be great if we could import such data from the logfiles.

 

[jgm]

This!

For example: I can build my entire base fitting in 1 Minute in Coriolis.io by hand... but then I want to enter my mods... oh boy...
It would be great if we could import such data from the logfiles.

Worth pointing out that apps like EDDI and EDMC can export your entire build including modifications to Coriolis.

 

[Olivia Vespera]

Worth pointing out that apps like EDDI and EDMC can export your entire build including modifications to Coriolis.

I did not know this. Interesting.

 

[lemny]

Worth pointing out that apps like EDDI and EDMC can export your entire build including modifications to Coriolis.

But how do I get my loadout to them? I think it's only possible if you enter your ED account data. And are you sure the API supports the modifications?

 

[jgm]

But how do I get my loadout to them? I think it's only possible if you enter your ED account data. And are you sure the API supports the modifications?

There are instructions in each of them. You do need to provide your ED account data. In EDDI it's as simple as adding your account details, going to the 'Shipyard' tab and hitting 'Export to Coriolis' for whichever ship you want.

 

[NeoTron]

Worth pointing out that apps like EDDI and EDMC can export your entire build including modifications to Coriolis.

Me:

It would be great if this could replace exporting ship information from the mobile app API, since that API requires our account login/password to be entrusted to a third party application. However for it to be a viable replacement, it would need details and would have to be exported on more occasions.

Until recently, EDMC stored these credentials in clear text. Now due to a post I made on reddit, the author is at least using the OS keychain capabilities. However even then, other programs running as your user will have access to the credentials. There's literally no way to store a password securely on a desktop device without a secret key. In Open Source software, this has to be a user inputted key/pin.

EDDI encrypts the password, yes, but the encryption key is in the source. Both methods are better than plaintext, but aren't particularily secure.


Frontier should either provide some kind of token method for the API (either generate a token like EDSM or GuildWars 2, or using a standard like oauth) and/or provide relevant information in the journal log (primarily detailed ship data and commodity market information).

 

[jgm]

Me:



Until recently, EDMC stored these credentials in clear text. Now due to a post I made on reddit, the author is at least using the OS keychain capabilities. However even then, other programs running as your user will have access to the credentials. There's literally no way to store a password securely on a desktop device without a secret key. In Open Source software, this has to be a user inputted key/pin.

EDDI encrypts the password, yes, but the encryption key is in the source. Both methods are better than plaintext, but aren't particularily secure.


Frontier should either provide some kind of token method for the API (either generate a token like EDSM or GuildWars 2, or using a standard like oauth) and/or provide relevant information in the journal log (primarily detailed ship data and commodity market information).

EDDI uses the Windows vault to store the user's password.

And we've been asking for token-based authentication forever but it isn't coming. We have to work with what we have.

 

[NeoTron]

EDDI uses the Windows vault to store the user's password.

Fair enough. Same as EDMC does now... and as noted, not secure for programs running as the user. Seems like this was actually changed after my post about EDMC's unencrypted passwords as well, so very recently:

https://github.com/cmdrmcdonald/Eli...84618a9#diff-d8eeaa1f75c039a28b8fef593c9bf2dc

(edit: realize now that you're the author for EDDI - could have made that clear and say you changed it to use the credential storage - given it's not even a month ago it changed ;-)

And we've been asking for token-based authentication forever but it isn't coming. We have to work with what we have.

What we are getting in the new journal is part of the information you need to use the API for. I asked for it to be taken to the level where we don't need the API (for ship loadouts specifically).

Just dump all the information on login, ship yard ship change and upon exiting outfitting.

 

[jgm]

Fair enough. Same as EDMC does now... and as noted, not secure for programs running as the user. Seems like this was actually changed after my post about EDMC's unencrypted passwords as well, so very recently:

https://github.com/cmdrmcdonald/Eli...84618a9#diff-d8eeaa1f75c039a28b8fef593c9bf2dc

(edit: realize now that you're the author for EDDI - could have made that clear and say you changed it to use the credential storage - given it's not even a month ago it changed ;-)

EDDI has a lot of changes going on, not sure that what it used to do has much relevance to the current security levels but hey.

What we are getting in the new journal is part of the information you need to use the API for. I asked for it to be taken to the level where we don't need the API (for ship loadouts specifically).

Just dump all the information on login, ship yard ship change and upon exiting outfitting.

Already asked for, but the API is still going to be needed unless FD has a significant change of heart and starts dumping more data in the journal.

 

[NeoTron]

EDDI has a lot of changes going on, not sure that what it used to do has much relevance to the current security levels but hey.

The point is that regardless the method, it's impossible to save the password securely without an additional level of encryption. Due to being open source being open source, a user input of some sort is required. Even in closed source projects you need this to be truly secure, but a compiled in secret isn't as straight-forward to get. It was to highlight to Frontier why dumping more data is a good thing - the less we need to rely on the insecure API that isn't even meant to be used by independent apps, the better.

Already asked for, but the API is still going to be needed unless FD has a significant change of heart and starts dumping more data in the journal.

Naturally. Baby steps. The ship loadout is a start, so let's try to push for it to be as good as it can be. Even if it's just on login, it should include full engineering details.

 

[malenfant]

Ship names confirmed for 2.3

I know there's a suggestion out there for including the full stellar classification in the details for a star scan, e.g. M4 Va, K7 IIab, A4 Ib, TTS6 IVb, K0 Vz, T7 V, Y4 V, O0 Vz, B9 VI, etc. I see that it's not included in this updated manual and I assume that's because the scan data is from the System Map but this classification is from the Galaxy Map. If it's not possible to include the full stellar classification in the journal then could you please tell us the algorithm that the game uses for calculating the stellar classification from the star's scan data?

That was probably my suggestion but yes, PLEASE can you add Star Size to the journal.log files? It'd be useful for EDDiscovery output and data-mining for star size distributions.

https://forums.frontier.co.uk/showt...earch-for-display-star-SIZE-in-the-Galaxy-Map!

 

[WizzyThing]

Release

Big thanks, (especially for the PDF) however can I PERHAPS also request that you release these docs as markdown via github or something?
We could see diffs of the changes, right now telling the changes from the PDF changes and your notes is rather hard, seeing the doc changes directly would be great.
Collaboration would be improved too.

If github is not option it might still be a good idea to use markdown (for diffs).

 

[hchalkley]

The "Passengers" event contains:

"Manifest": array of passenger records, each containing:
o MissionID (int)
o Type (string)
o VIP (bool)
o Wanted (bool)
o Count (int)

 

[Martin Schou]

Any chance of improving the current PowerPlay events?

* PowerPlay collect and deliver could do with a location; it's rather annoying to have to go through the log and figure out where you're docked to get the location information.

* PowerplayVote needs to be changed, as we no longer have nominations but can only vote for expansion or consolidation.

* When PowerPlay cargo is dropped, please log which system the cargo belongs to (this depends on the power's mechanics, but it's stored somewhere), because otherwise it becomes impossible to track system merits properly.

* When picking up dropped PowerPlay cargo, please log which system the cargo belongs to.

* I'm not 100% certain, but I think we're missing a redeem event for PowerplayVoucher.

* And for PowerplayDeliver and PowerplayVoucherRedeem, can we please get information on the results? E.g. if I'm delivering, log the new preparation/expansion/fortification numbers for the affected systems, and if I'm redeeming vouchers, log the new opposition/undermining numbers for the affected systems (keep in mind that we can deliver/redeem for multiple systems at once).

Pretty please with sugar on top.

 

[Robert Maynard]

What he said. Another BGS runner seconds this.

Thirded. Having to use the System Map (to get more accurate influence percentages) and travel to each system (to get Pending and Recovering states) becomes over-familiar after a few times.

 

[Misaniovent]

This would be great.

 

[MattG]

There's only a limited amount of time left for late changes - after beta2 is locked down, it's only critical fixes allowed. I'll probably be able to get the destination star system name in StartJump, but I'm not promising anything.

Just seen AtmosphereComposition has been added - thank you! If you get a few mins, could you also add another for Composition of the planet (CompositionComposition?) to show Rock/Metal/Ice/Whatever breakdown? And AxialTilt still looks like it's missing. If you get a few more minutes, can you add an array of StarType to FSDJump to show the star types as they are on the galaxy map - so we can know the system contains an "F3 VAB" and a "M0 VI" (rather than just "F"). e.g. "StarTypes":["F3 VAB","M0 VI"]

Thanks again for AtmosphereComposition, maybe my days of OCR are nearing an end!

 

[SHEPR0N]

Any chance of improving the current PowerPlay events?

This would be very nice to see indeed. The PP community can make little to no use out of the current PP related entries, with those adjustments that would radically change.