Discussion Clarifying the existing API's usage

Hi Brett,
This all looks great. I just want to clarify what a reasonable query rate for the current API is. In your other post, you mention we should not "cause a severe degradation of services", but how do we know when this has happened, apart from at the point its too late :)

My previous API experiments have queried the API once every 5 or 10 minutes, which I assume is a reasonable level, but what if someone wanted to scrape a series of FSD jumps from the journey data in as close to real-time as possible. Is a query rate of one call every 30 seconds ok?

Cheers,
Nick
 

Brett C

Frontier
Hi Nick,

Unfortunately I do not have the numbers in front of me right now - will ask about it. FWIW, five minutes sound reasonable, however I do not know the hardware and bandwidth pipe that the IOS API server has. Thanks. :)
 
Hi Brett,
This all looks great. I just want to clarify what a reasonable query rate for the current API is. In your other post, you mention we should not "cause a severe degradation of services", but how do we know when this has happened, apart from at the point its too late :)

My previous API experiments have queried the API once every 5 or 10 minutes, which I assume is a reasonable level, but what if someone wanted to scrape a series of FSD jumps from the journey data in as close to real-time as possible. Is a query rate of one call every 30 seconds ok?

Cheers,
Nick

That problem would be better solved by using verbose logging and scraping the netlog. This doesn't touch the API and will work even if the API is unresponsive.
 
Have you kept records of players jumps and history to this point? So at a later time we may get some of those stats? Or is all of that lost?
 
The EDDiscovery tool already tracks the player's jumps using the network log file.

Thanks Howard, that hadn't occurred to me, and it sounds like this is as semi-official as use of the mobile app API.

My only issue with this is that it's not 100% trusted, which creates some issues with data validation if you were to want to use the data for something competitive, like a race.
 
Thanks Howard, that hadn't occurred to me, and it sounds like this is as semi-official as use of the mobile app API.

My only issue with this is that it's not 100% trusted, which creates some issues with data validation if you were to want to use the data for something competitive, like a race.

For races you can make people take screenshots of the galaxy map at checkpoint systems, since the galmap shows your current location and has a clock. That's what was done for the Buckyball Run A* / The A* Challenge and other Buckyball Racing Club events, anyway.

Also, a big +1 for system coordinates in the netlog please, that would be fantastic for being able to visually track where we go (e.g. on exploration trips). Thank you indeed for that info nonetheless though Mr Chalkley!
 
Last edited:

Slopey

Volunteer Moderator
Have you kept records of players jumps and history to this point? So at a later time we may get some of those stats? Or is all of that lost?

I think you're getting confused. The EDDiscovery tool reads the netlog, parses and stores the system list (as does my BPC and several other apps). This has nothing to do with FD or the API - it's a 3rd party application. Because an FD dev posted it, doesn't mean the API can give you a list of jump history, only that the 3rd party tool he mentioned can.
 
Last edited:
The EDDiscovery tool already tracks the player's jumps using the network log file. The next update to the game will include a change to write the starsystem name into the log file at the default verbosity level.

Wouldn't it make sense at that point to introduce a separate "travel log" file for such information that is a bit more structured and explicitly machine readable? Maybe something syslog-like, e.g., (pardon my CSV)

Code:
[2016-01-19T18:27:31.99Z] ENTER SYSTEM,HIP 31337
[2016-01-19T18:28:55.01Z] SCAN,L2,HIP 31337

Put it into an appropriate place (My Documents on Windows?), flush frequently, and make sure to document and communicate schema additions or changes.

(edit) my other thought would be an XMPP "push service" in the game, but that would be a bit more involved :p
 
Last edited:
The EDDiscovery tool already tracks the player's jumps using the network log file. The next update to the game will include a change to write the starsystem name into the log file at the default verbosity level.

EDDiscovery: https://forums.frontier.co.uk/showthread.php?t=138155

Please please please, even with sugar on the top, include the coords for the star system too.

And maybe also write the other stuff that makes people use the API for what it was not designed for. Scraping data. Like station names, price dump, module dump...

And written to log the systems withing 20LY (name, coords).

Making sure there is a active 3rd party community is so important. Much of the effort so far have been to reverse-engineer data, not the usage of the data itself. The changes above would shift focus from reverse-engineering to actually using the data.
 
Please please please, even with sugar on the top, include the coords for the star system too.

And maybe also write the other stuff that makes people use the API for what it was not designed for. Scraping data. Like station names, price dump, module dump...

And written to log the systems withing 20LY (name, coords).

Making sure there is a active 3rd party community is so important. Much of the effort so far have been to reverse-engineer data, not the usage of the data itself. The changes above would shift focus from reverse-engineering to actually using the data.

Do we really want to have every coordinates?
I'm sure lot of people like to try to figure out where systems are, and it adds some layer to the game while keeping some mystery about the galaxy mapping.
 
Please please please, even with sugar on the top, include the coords for the star system too.

And maybe also write the other stuff that makes people use the API for what it was not designed for. Scraping data. Like station names, price dump, module dump...

And written to log the systems withing 20LY (name, coords).

Hm... I really think we should start with asking for the things that are easy to add without potentially introducing any bugs (coords in the existing netlog), and then maybe look at those other things down the line. Especially if this might just be showing up in the next patch release rather than 2.1.

I know these things would be helpful in the long run, but scope creep is bad, mmm'kay :D
 
The EDDiscovery tool already tracks the player's jumps using the network log file. The next update to the game will include a change to write the starsystem name into the log file at the default verbosity level.

EDDiscovery: https://forums.frontier.co.uk/showthread.php?t=138155


While EDDiscovery is great I would like to note that there are other applications that do the same thing as EDDiscovery. This is NOT to dissuade use of EDDiscovery, but to let people know that there are other options also.

Captain's Log: https://forums.frontier.co.uk/showthread.php?t=155545
AndDiscovered (Android): https://forums.frontier.co.uk/showthread.php?t=167693
 
Because an FD dev posted it, doesn't mean the API can give you a list of jump history, only that the 3rd party tool he mentioned can.
FYI before E: D 1.3.02 the API did return a history of systems visited (in order of first visit IIRC). But no timestamps.
 
FYI before E: D 1.3.02 the API did return a history of systems visited (in order of first visit IIRC). But no timestamps.

Well I'll be damned, I never noticed! I'll keep my June 2015 dumps safely stashed like they were my firstborn... They have my Sag A* trip among other things!
 
Last edited:
Back
Top Bottom