Discussion Commanders log manual and data sample
- Thread starter Zac Antonaci
- Start date
Hi Zac!
Thanks for this! I am wondering though.. I would gladly do some community website with Commander logs. However, making a website read a local file on a harddrive may or may not be a bit hard due to security and so on. I don't want to force people to upload .log files to a website and I don't want to create an external program / executable for this. Are there any solutions for this (except for the HTML5 File API reader) or maybe yourself doing an API for this?
Best regards,
CMDR Zindae
Mu77ley
Volunteer Moderator
Yes, this would be a great way of doing it. That way we could easily tail the files and process the events as they are written.
wolverine2710
Tutorial & Guide Writer
Tools authors - I salute you
I've nothing but the highest respect for cmdrs who spend their free time creating third party tools or helping the community in any way they can. Be it advice, twitch/youtube videos etc etc. We have certainly come a LONG in the last 2 years. When I started with ED (PB1) in May/June 2014 there already were a few trading tools. Since then the amount and diversity of 3P tools have grows significantly. If you look at the Tools section of EDCodex you will see that their are currently 142 tools. Covering a very wide range of applications.
We have a GREAT infrastructure in place for collecting and distributing data. An infrastructure just waiting to be fed with data from an official FD api. I will for sure forget a few tools and authors but from the top of my head. There is EDDN (coded by jamesremuscat and later Anthornet) distributing market data, ships and outfitting info. EDDN on DynamoDB by Askarr who provides an archive (of all) send EDDN messages. EDSM (inhumierer, Anthornet) for collecting and calculating 3D coordinates. EDDB by themroc which does multiple things, one being making station and system information data available, MMS by Maddavo. EliteOCR by Seebek - Otis B. later took over. ED-IBE by Duke Jones. EDCE by Andargor who gave us a POC wrt usage of the now declared legal to use Companion API. After that came EDAPI and the now big 500 pound gorilla EDMC by Otis B. EDCodex, coded by Biobob which gives a near complete overview of existing tools etc. Captains log tools by numerous cmdrs which share data and sent data to EDSM. And that is just the distributing/sharing part of it. Just checkout EDCodex to find just about anything you could ever hoped for.
All these tools and commanders have in common that they have a great love for ED and want to give us all a better experience - should 3P tools by your forte. They also have in common that evertime something was added to ED new tools came up to use the new info. A LOT of the data is/was crowdsourced by cmdrs typing in data, or later OCR-ing and later EDMC like tools. The netlogs were probed for every last bit of usefull information. Those tools were basically starving for good and reliable data.
FD so far hasn't provided us with an offical API. An API which would make FAR more and new tools possible. What FD is presenting us now is a good start. I hope that the recommendations by cmdrs are taken seriously and that even more data becomes available. The harder part of an API is creating it, making it good/reliable, rotating files etc. Once in place its pretty trivial to add NEW data to a JSON file. Remember all that data is already available in the client. Personally I had totally given up on FD and I wasn't expecting a client-side API for at least the 1st/2nd quarter of 2017. I'm glad they have decided to give us this API and like I said I'm hoping they add more info to it. Feed me seymore, feed me.....
Whether you like 3P tools I think you can't deny that cmdrs have done a tremendous job. Donating lots and lots of free time for the community and ofc having fun. I think they deserve our appreciation and are now hopefully rewarded by FD by oodles of good data....
Note: As a few cmdrs have pointed out recently. This is one of my trademark posts. Long and full of acronymns.....
I've nothing but the highest respect for cmdrs who spend their free time creating third party tools or helping the community in any way they can. Be it advice, twitch/youtube videos etc etc. We have certainly come a LONG in the last 2 years. When I started with ED (PB1) in May/June 2014 there already were a few trading tools. Since then the amount and diversity of 3P tools have grows significantly. If you look at the Tools section of EDCodex you will see that their are currently 142 tools. Covering a very wide range of applications.
We have a GREAT infrastructure in place for collecting and distributing data. An infrastructure just waiting to be fed with data from an official FD api. I will for sure forget a few tools and authors but from the top of my head. There is EDDN (coded by jamesremuscat and later Anthornet) distributing market data, ships and outfitting info. EDDN on DynamoDB by Askarr who provides an archive (of all) send EDDN messages. EDSM (inhumierer, Anthornet) for collecting and calculating 3D coordinates. EDDB by themroc which does multiple things, one being making station and system information data available, MMS by Maddavo. EliteOCR by Seebek - Otis B. later took over. ED-IBE by Duke Jones. EDCE by Andargor who gave us a POC wrt usage of the now declared legal to use Companion API. After that came EDAPI and the now big 500 pound gorilla EDMC by Otis B. EDCodex, coded by Biobob which gives a near complete overview of existing tools etc. Captains log tools by numerous cmdrs which share data and sent data to EDSM. And that is just the distributing/sharing part of it. Just checkout EDCodex to find just about anything you could ever hoped for.
All these tools and commanders have in common that they have a great love for ED and want to give us all a better experience - should 3P tools by your forte. They also have in common that evertime something was added to ED new tools came up to use the new info. A LOT of the data is/was crowdsourced by cmdrs typing in data, or later OCR-ing and later EDMC like tools. The netlogs were probed for every last bit of usefull information. Those tools were basically starving for good and reliable data.
FD so far hasn't provided us with an offical API. An API which would make FAR more and new tools possible. What FD is presenting us now is a good start. I hope that the recommendations by cmdrs are taken seriously and that even more data becomes available. The harder part of an API is creating it, making it good/reliable, rotating files etc. Once in place its pretty trivial to add NEW data to a JSON file. Remember all that data is already available in the client. Personally I had totally given up on FD and I wasn't expecting a client-side API for at least the 1st/2nd quarter of 2017. I'm glad they have decided to give us this API and like I said I'm hoping they add more info to it. Feed me seymore, feed me.....
Whether you like 3P tools I think you can't deny that cmdrs have done a tremendous job. Donating lots and lots of free time for the community and ofc having fun. I think they deserve our appreciation and are now hopefully rewarded by FD by oodles of good data....
Note: As a few cmdrs have pointed out recently. This is one of my trademark posts. Long and full of acronymns.....
Last edited:
wolverine2710
Tutorial & Guide Writer
It so we can build tools for you to use. Many people use these tools to add to their enjoyment of the game.
Adding my thoughts.
First, please one entry per line and make the individual lines parseable JSON objects.
Second, others have mentioned it but an entry for whenever a ship item (lights, cargo scoop, hardpoints, etc) is deployed or retracted would be useful.
Third, heat. It would be nice to obtain events whenever the ship temperature changes. I realise that this might be a lot of events, so either only do it in the 'danger zone' of 80%+ or only write an event every 5% change.
Fourth, damage. Specifically, module damage (our own, not enemies'). Same comments as for heat as to how you might want to handle it.
With all of this, plus the existing information from the companion app API and the external sources, EDDI might never shut up...
First, please one entry per line and make the individual lines parseable JSON objects.
Second, others have mentioned it but an entry for whenever a ship item (lights, cargo scoop, hardpoints, etc) is deployed or retracted would be useful.
Third, heat. It would be nice to obtain events whenever the ship temperature changes. I realise that this might be a lot of events, so either only do it in the 'danger zone' of 80%+ or only write an event every 5% change.
Fourth, damage. Specifically, module damage (our own, not enemies'). Same comments as for heat as to how you might want to handle it.
With all of this, plus the existing information from the companion app API and the external sources, EDDI might never shut up...
This is a really important item, for EDDI at least. EDDI has additional data for ships and uses the existing ship ID as per the data provided by the companion app as the key. Please include ship ID with these methods, and IDs in general with everything else that you have them for (starsystems, planets, stations, etc.)
I would like to see a log that lists the various factions in the system and their influence for background sim tracking purposes. Other than that this is pretty exciting, certainly easier than the toy Tshark deep packet inspection thing i was working on.
whoops
Last edited:
For some reason my replies are being deleted, from this and the UA thread. Did I break a rule? In any case, I've made plenty of progress with the JSON files as is, and am manipulating them fine in Python. If you guys want, I can try and write a program to make these single-object entries tomorrow.
It looks like there is good support for theline-delimited Json idea, and no-one has spoken against it, so I'm going to switch to that format.
Timestamps will be in ISO 8601 format, inside the event object.
Startup and Shipyard events will include a ship id.
Startup will state current credits balance and loan.
I have a few more days in my schedule to implement some more of the suggestions: expect an updated doc sometime next week.
Timestamps will be in ISO 8601 format, inside the event object.
Startup and Shipyard events will include a ship id.
Startup will state current credits balance and loan.
I have a few more days in my schedule to implement some more of the suggestions: expect an updated doc sometime next week.
Oustanding work! And although I've had plenty of success re-arranging the data as I need to without line-delimited JSON, after looking up the improvements in regards to compatibility it sounds like it's wonderful news! Thanks for keeping us up to date. Is there going to be a schema once everything is finalized?
Last edited:
Robert Maynard
Volunteer Moderator
Would it be possible to offer an option to record state changes for the ship in the log? From the point of view of implementing ancillary displays, I'm thinking that the current state of the ship could be written to log on logging in and then any state changes relating to the ship could also be written when they occur, i.e. ship's lights, landing gear, weapons deployment, systems status, damage, ammunition levels, etc.
.... also, probably asked for, an automatic full log record of the current station's market prices, supply, demand, etc. when docking would be nice!
.... also, probably asked for, an automatic full log record of the current station's market prices, supply, demand, etc. when docking would be nice!
wolverine2710
Tutorial & Guide Writer
Looks good. Thanks for taking the recommendation of this thread and the discord server cmdrs into account
Suffice to say we can't wait for the updated document and JSON file - to see what has been changed/added;-)