Discussion Commanders log manual and data sample

hchalkley

Senior Programmer
Frontier
robbyp said:
@hchalkley. Great work on the journal. During decoding for EDDiscovery i noted that Event:Location 'Docked' is 1 or 0, instead of true/false.

Also your document does not state what 'distance' units are used in the Shipyardtransfer are. We worked it out as meters! Such accuracy is commendable ;-)
Click to expand...

Docked should be true/false in beta 4. I think Lightyears would be more suitable for the transfer distance.
 

Toumal

Toumal
I just wanted to say thanks, this is very appreciated!

Here's hoping for more log events in future updates, after the crunch for 2.2 is over!
 

lemny

lemny
Is there an event at startup like current inventory and cargo dump? Or if not, is it planned?
I think it's essential.
 

Arbanax

Arbanax
Been dipping into this thread for a while, as I am interested in third party apps, and have loved what the community had brought to the table. Now we are getting an official API, is there anything that can presently be called functioning suitable to use with the beta testing?

Ab
 

Genar-Hofoen

Genar-Hofoen
Arbanax said:
Been dipping into this thread for a while, as I am interested in third party apps, and have loved what the community had brought to the table. Now we are getting an official API, is there anything that can presently be called functioning suitable to use with the beta testing?

Ab
Click to expand...

It's not an API - an API is an Application Programming Interface, whereby you'd be sending a request to a server or to the local game client to retrieve information.

This is a Player Journal - lines of information being churned out in a text file, from which the various 3rd party applications can read in and chew through the information provided. It's all reactive and a 3rd-party app just needs to keep monitoring the files for new lines of information.

As for functioning apps, I can only speak for Captain's Log at the moment, and I'm busy trying to get a new version up and running in time for 2.2 going live.

I know for a fact there are many 3rd-party website and application authors currently doing the same.

Regards o7
 

Chrysophylax

Chrysophylax
I have found an interaction with windows 10, SSDs and the journal log.

I believe windows is caching the very small writes until a large enough amount of data is written. This means that an app that is listening to file modifications may wait for a very long time (my tests had me wait up to 5 minutes). You may verify this for yourself using any text app that refreshes on file changes and see that it doesn't when it should.

A work-around is to simply force a new file handle to be opened every so often, but this is less than optimal.

I urge Frontier to also consider dumping this data to a socket.
 
Last edited:

eventure

eventure
djadjok said:
Hmm, check here
Click to expand...

Checked! There is no BodyType listed.

Chrysophylax said:
I have found an interaction with windows 10, SSDs and the journal log.

I believe windows is caching the very small writes until a large enough amount of data is written. This means that an app that is listening to file modifications may wait for a very long time (my tests had me wait up to 5 minutes). You may verify this for yourself using any text app that refreshes on file changes and see that it doesn't when it should.

A work-around is to simply force a new file handle to be opened every so often, but this is less than optimal.

I urge Frontier to consider instead dumping this data to a socket.
Click to expand...

Can't confirm that, using W10 & SSD too, every event is properly written, when it happens. Maybe your have activated a powersave mode?
 
Last edited:

Chrysophylax

Chrysophylax
Eventure said:
Can't confirm that, using W10 & SSD too, every event is properly written, when it happens. Maybe your have activated a powersave mode?
Click to expand...

Unfortunately, no.

Wondering if it's a quirk of my particular drive.

Edit: I just started using polling instead. It's not ideal but works :)
 
Last edited:

Otis B.

Otis B.
Chrysophylax said:
an app that is listening to file modifications may wait for a very long time (my tests had me wait up to 5 minutes). You may verify this for yourself using any text app that refreshes on file changes and see that it doesn't when it should.
Click to expand...
ReadDirectoryChangesW (win32) or FileSystemWatcher (.net) are only guaranteed to fire when the monitored file is closed (or some other change occurs that causes the file's metadata in the file system to be updated) which only happens when you quit the E: D client.
This is a Windows optimisation/limitation. Use polling.
 
Last edited:

MagicMau

MagicMau
Otis B. said:
ReadDirectoryChangesW (win32) or FileSystemWatcher (.net) are only guaranteed to fire when the monitored file is closed (or some other change occurs that causes the file's metadata in the file system to be updated) which only happens when you quit the E: D client.
This is a Windows optimisation/limitation. Use polling.
Click to expand...

Here's an example of a polling implementation for reading the journal in C#, if that helps.
 

Toumal

Toumal
Chrysophylax said:
I believe windows is caching the very small writes until a large enough amount of data is written. This means that an app that is listening to file modifications may wait for a very long time (my tests had me wait up to 5 minutes). You may verify this for yourself using any text app that refreshes on file changes and see that it doesn't when it should.
Click to expand...


What you want to do is to use polling for the actual file reading. If you use C# FileStream for reading then you can use a function like this to find out if there's data available:

public bool NewDataReady()
{
return (_fileStream.Length >= _fileStream.Position);
}
Click to expand...

This will return true if there's more data available than you have read so far. You can then use ReadLine to get the next JSON log message.
What I *would* suggest to use FileSystemWatcher for is to listen for file creation events happening on the directory. This will enable you to be notified about new log files being created, saving you the hassle to read the "end logfile" message and parse out the new filename.

// Create a new FileSystemWatcher and set its properties.
FileSystemWatcher watcher = new FileSystemWatcher();
string path = Directory.GetParent(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)).FullName;
if (Environment.OSVersion.Version.Major >= 6)
{
path = Directory.GetParent(path).ToString();
}
watcher.Path = path + "\\Saved Games\\Frontier Developments\\Elite Dangerous";
watcher.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite
| NotifyFilters.FileName | NotifyFilters.DirectoryName;
// Only watch log files.
watcher.Filter = "*.log";

// Add event handlers.
watcher.Created += new FileSystemEventHandler(OnCreated);

// Begin watching.
watcher.EnableRaisingEvents = true;
Click to expand...

and the event handler:

private static void OnCreated(object source, FileSystemEventArgs e)
{
// Specify what is done when a file is changed, created, or deleted.
Console.WriteLine("File: " + e.FullPath + " " + e.ChangeType);
// Here you can switch over to the new log file with whatever it is you're doing
}
Click to expand...
 

gazelle

gazelle
jgm said:
Won't "Saved Games" be different in different locales though?
Click to expand...

No, I don't know where the localisation happens, but it's not at the filesystem level. When I don't use Explorer (or the windows filerequester) I see the real names instead of the localised ones (eg: C:\User <-> C:\Benutzer)

local.png

edit: I'm using Directory Opus as filebrowser in case you wonder.
 
Last edited:

Toumal

Toumal
gazelle said:
No, I don't know where the localisation happens, but it's not at the filesystem level. When I don't use Explorer (or the windows filerequester) I see the real names instead of the localised ones (eg: C:\User <-> C:\Benutzer)

View attachment 111945

edit: I'm using Directory Opus as filebrowser in case you wonder.
Click to expand...

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
 
Last edited:

Otis B.

Otis B.
gazelle said:
No, I don't know where the localisation happens, but it's not at the filesystem level. When I don't use Explorer (or the windows filerequester) I see the real names instead of the localised ones (eg: C:\User <-> C:\Benutzer)
Click to expand...
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.
 
Last edited:

gravityStar

gravityStar
MaterialCollected - count

MaterialCollected has a counterpart event: MaterialDiscarded.
{ "timestamp":"2016-06-10T14:32:03Z", "event":"MaterialCollected", "Category":"Raw", "Name":"sulphur" }
{ "timestamp":"2016-06-10T14:32:03Z", "event":"MaterialDiscarded", "Category":"Raw", "Name":"sulphur", "Count": 5 }

MaterialDiscarded has a count, MaterialCollected does not. Can a count be added to the MaterialCollected event?

---
Edit: I should have searched more thoroughly, count is already being added. Sorry, nevermind and thank you.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom