Discussion Commanders log manual and data sample

Won't "Saved Games" be different in different locales though?

I use https://forums.frontier.co.uk/showthread.php/289420-How-to-find-the-Saved-Games-directory-(C-) to obtain the relevant path, which should work regardless of the client's locale.
This. It's a hack, as usual for Microsoft, but it works. A cleaner way would of course be to have the localized path name in the registry, but it's hard to push for consistent design when over 1000 people work on a piece of software.

I'm going to put my stuff up on Github so you can just use my code for the entire file watching/reading part, and focus on the handling of the data.

EDIT: Project is now on Github at https://github.com/Toumal/EliteDMX

Localisation doesn't mater: W10 FR, if I point to %UserProfile%/Saved Games/Frontier Developments/Elite Dangerous/ it goes to c:\Yves\Parties Enregistrées\Frontier Developments\Elite Dangerous\
At least I know it work on Win7 Win8 Win10.

For the curious, I use nodeJS:
Code:
var Journalurl=process.env.USERPROFILE+"/Saved Games/Frontier Developments/Elite Dangerous/";
 
There's a hidden desktop.ini file in the folder that tells Explorer to display a localized name.
Nevertheless one should use SHGetKnownFolderPath() instead of hard-coding the path in case the user has moved the folder to another drive.

That is true, and the constant you want is FOLDERID_SavedGames.
Do note that this doesn't work for all versions of Windows, there's no guarantee of this constant being available in the future, and using this in C# is cumbersome unless you use Microsoft XNA (https://msdn.microsoft.com/en-us/library/bb200105.aspx#ID2EWD)

Oh and also, Microsoft has no less than four (4) locations where this constant is defined (See comment at line 1871), so from personal experience I can say that the chance of this breaking at some point is not zero.
 
Do note that this doesn't work for all versions of Windows, there's no guarantee of this constant being available in the future, and using this in C# is cumbersome unless you use Microsoft XNA (https://msdn.microsoft.com/en-us/library/bb200105.aspx#ID2EWD)

Oh and also, Microsoft has no less than four (4) locations where this constant is defined (See comment at line 1871), so from personal experience I can say that the chance of this breaking at some point is not zero.
SHGetKnownFolderPath and FOLDERID_SavedGames are part of the published Windows API since Vista, so I doubt they're going away any time soon. Anyway, they're what FDev are using, so it's what we should use too.

See here for some sample C# code using P/Invoke.
 
SHGetKnownFolderPath and FOLDERID_SavedGames are part of the published Windows API since Vista, so I doubt they're going away any time soon.

Oh sure. However, as I said there's no guarantee that all the constants are in every version of Windows. Especially server editions may not support that constant. And no, they are not part of the "Managed API" so they may be deprecated for any future version of Windows without notice. If you want to be sure you have to use the Managed API function for getting folder locations, but that one doesn't support the saved games folder yet.

I've actually been bitten by this issue in the past (An upgrade to a newer version of Windows Server effectively removed a similar constant), though it probably won't matter much because this here is just a computer game. My main point is that, since this is not a managed API constant yet, using the english language path name might actually be more futureproof than pinvoke (or maybe not, who can tell for sure...)

I'll stay on the english path name for my program for now. PInvoke is much like JNI in that it creates this urge to wash my hands afterwards ;)
 
Oh sure. However, as I said there's no guarantee that all the constants are in every version of Windows. Especially server editions may not support that constant. And no, they are not part of the "Managed API" so they may be deprecated for any future version of Windows without notice. If you want to be sure you have to use the Managed API function for getting folder locations, but that one doesn't support the saved games folder yet.

I've actually been bitten by this issue in the past (An upgrade to a newer version of Windows Server effectively removed a similar constant), though it probably won't matter much because this here is just a computer game. My main point is that, since this is not a managed API constant yet, using the english language path name might actually be more futureproof than pinvoke (or maybe not, who can tell for sure...)

I'll stay on the english path name for my program for now. PInvoke is much like JNI in that it creates this urge to wash my hands afterwards ;)

Of course as a fallback option in case future versions of Windows make these system calls invalid in some way, just have a "Select journal file folder location" button and then just save the location in a config file. Which is what I'm planning to do.
 
Suggestion: Hull Health improvement
Heath in case of Hull repaire as well on RebootRepair:
{ "timestamp":"2016-10-03T22:57:04Z", "event":"Repair", "Item":"Hull", "Cost":182, "Health":0.213655 }
Add Health in LoadGame and ShipyardSwap

Suggestion: Heat improvement
Please consider to make them work as the ShieldState
HeatWarning: { "timestamp":"2016-10-04T00:03:57Z", "event":"HeatWarning", "HeatWarning": true OR false }
HeatDamage: { "timestamp":"2016-10-04T00:03:57Z", "event":"HeatDamage", "HeatDamage": true OR false }

Suggestion: ShieldState improvement
Add a shield status detail in case where ship doesn't have shield:
{ "timestamp":"2016-10-03T23:45:22Z", "event":"ShieldState", "ShieldsUp":false, "State": "Shield/noShield/shieldError/shieldOff" }
Where: (or something more relevant)
ShieldOn = Normal shield status (present and on)
noShield = This ship don't have shield installed (so the shield down is normal and not an error)
shieldError = Shield is present but malfunctioning (present and on)
shieldOff = Shield is manually down (present, no error)

Suggestion: Docked improvement
add "LandingPad":29 in Docked. (= Knowing the landing pad after all potential change or unknow state, loading, ship swap, resurect, etc ...)

Suggestion: Fuel improvement
add "MaxFuel":64.000000 and "ActualFuel":48.401279 in Docked.
Allowing to know the base max of the fuel and the curent fuel of the ship after a potential change.
 
Last edited:
I realise it's unlikely to make 2.2 at this point, but could the FSDJump event also include an array showing the Star Type(s) as they are in the galaxy map? So something like:
Code:
"StarType":["F7 VAB","M3 VA"]

Can we also get the Atmosphere / Composition breakdowns as hashes for the Scan event, at some point?

Edit: And thanks for adding the other extra detail to Scan event in beta 5.
 
Last edited:
I've taken a look at the various additions and they look good. Thanks for adding them.

A couple of items on SendText and ReceiveText:

ReceiveText now has a channel but SendText doesn't, would it be possible to add it?

Also, ReceiveText's channel just shows as 'npc' for NPCs rather than the actual channel (direct/local). Would it be possible to provide the channel info for NPCs as well? We don't need to know that the message is being sent from an NPC because that info is already in the 'From' string
 
If there's time (I know, I know :) ) it would be good if there was a complete list of a player's current inventory - materials, commodities, data. Just a dump at game load would be good.

Regards o7

Agreed, currently the Companion API does not give a count of cargo, materials and data. The journal will give us deltas, but the inventory would still have to be checked manually if there are no counts.

As an alternative to a full dump, perhaps add the total count in the actual event, e.g. a "total" field for the type in the event?

EDIT: remove ship's cargo, not sure.
 
Last edited:
Great update. A couple of additions I'd love to see if there's another iteration:

- SupercruiseExit parameter indicating the target exited at. Examples: station name, RES type, USS, Mission Target etc. This could replace the miscellaneous USSDrop event.
- Mining prospecting result: type of ore and quantity.

Howard, can there be a ProspectEvent that returns the materials from a prospector drone, with the name of the current body/ring/belt, same as the 6.1 Scan event for planets and moons, minus the stellar parameters?
 
Last edited:

hchalkley

Senior Programmer
Frontier
Here's the latest manual vesion 5: http://hosting.zaonce.net/community/journal/v5/Journal_Manual.doc

Thanks to everyone for your feedback and suggestions: you have helped make this feature better than it would have been originally. Unfortunately only critical bug fixes can be approved now for beta6, as we're getting close to release. Any suggestions which have not yet been implemented will be considered for inclusion in v2.3. I look forward to seeing some awesome addon apps.
 
Here's the latest manual vesion 5: http://hosting.zaonce.net/community/journal/v5/Journal_Manual.doc

Thanks to everyone for your feedback and suggestions: you have helped make this feature better than it would have been originally. Unfortunately only critical bug fixes can be approved now for beta6, as we're getting close to release. Any suggestions which have not yet been implemented will be considered for inclusion in v2.3. I look forward to seeing some awesome addon apps.

OHHH NO! is there no way you can sneak in a change to "PVPKill"? all I need is the ship killed, Currently all I get is the CMDR Name & Rank, but the crime one gives me a Ship name, not all PVP players keep Report Crimes on.
 
Here's the latest manual vesion 5: http://hosting.zaonce.net/community/journal/v5/Journal_Manual.doc

Thanks to everyone for your feedback and suggestions: you have helped make this feature better than it would have been originally. Unfortunately only critical bug fixes can be approved now for beta6, as we're getting close to release. Any suggestions which have not yet been implemented will be considered for inclusion in v2.3. I look forward to seeing some awesome addon apps.

Thanks! Hopefully you'll be able to continue making improvements for the point releases as they come.
 
Here's the latest manual vesion 5: http://hosting.zaonce.net/community/journal/v5/Journal_Manual.doc

Thanks to everyone for your feedback and suggestions: you have helped make this feature better than it would have been originally. Unfortunately only critical bug fixes can be approved now for beta6, as we're getting close to release. Any suggestions which have not yet been implemented will be considered for inclusion in v2.3. I look forward to seeing some awesome addon apps.

Thanks for your work and a big thanks for all att frontier that made the journal a reality!! The journal contains much more info than i imagined. But we always wants more so i guess we will make a good list for suggestions to 2.3. Will be fun to add many new features to EDDiscovery that the journal logging enables.

We have worked hard with EDDiscovery to make it ready for release of ED 2.2 and we are almost ready to release now for a first version.
Here is a beta for test https://github.com/EDDiscovery/EDDiscovery/releases/tag/Release_5.0.1Beta
 
Any suggestions which have not yet been implemented will be considered for inclusion in v2.3. I look forward to seeing some awesome addon apps.

Alright, I'll see what I can do with what we have right now :) Here's hoping shield and hull hit events can be considered lateron, because those would enable some pretty spectactular effects ^_^
 
Back
Top Bottom