Discussion External API Requirements Thread

Status
Thread Closed: Not open for further replies.
Yes, that makes sense! And more importantly shows my question/point wasn't completely stupid :)

- - - - - Additional Content Posted / Auto Merge - - - - -

Indeed - https://forums.frontier.co.uk/showthread.php?t=99437&p=1545056&viewfull=1#post1545056

The reason I questioned it is I can't imagine personally they'll open up their webserver for calls. Too much risk of too many calls and people trying to hack information out.

I suspect all calls will have to go through the/an ED app on your PC. That way you are already securely logged on etc.

This can be quite easily handled with a cached API server. Data is offloaded nightly or weekly. Player API calls are policed using network policies. Since they are with Amazon, Amazon should also be able to provide them some kind of flood protection.

From an infrastructure perspective, it's safer to have the API hosted on a separate webserver than allow direct game client access. Game clients can be hacked and provide multiple points of vulnerability to exploit. A single webserver provides a single point of control for admins.

When dev's mention API's, I generally assume they mean a webAPI since it is far easier to manage than to integrate into game clients. The patching of all the player clients to support a client side API alone is a logistical nightmare...
 
Would be way cool, but admittedly of very limited practical use, for the API to expose the current location of players in the game, so someone clever could build an Elite version of http://www.flightradar24.com/ - I'd probably use it as a screensaver.
 
On the technical side, I would like it if you tried to adhere to an API standard.
It would make implementing the client side a lot more easy as there are libraries you can bootstrap into.

The one I like best is the JSON API standard.
but I'm guessing people would also like a XML API, but my vote is on a standarized json ;)
 
This can be quite easily handled with a cached API server. Data is offloaded nightly or weekly. Player API calls are policed using network policies. Since they are with Amazon, Amazon should also be able to provide them some kind of flood protection.

From an infrastructure perspective, it's safer to have the API hosted on a separate webserver than allow direct game client access. Game clients can be hacked and provide multiple points of vulnerability to exploit. A single webserver provides a single point of control for admins.

When dev's mention API's, I generally assume they mean a webAPI since it is far easier to manage than to integrate into game clients. The patching of all the player clients to support a client side API alone is a logistical nightmare...

Problem with cached data is it's just that. Out of date, possibly significantly.

I'd imagine a client side library you can call directly via ED or a parallel application/service would significantly cut down on traffic and risk. Some data the client would have locally anyway. And by the fact the client is logged on shows you are a registered user etc.

A web API is of course fabulous but could mean lots of unwanted traffic/spam, where as going through a local client could control/limit that.

Anyway, let's not try and second guess FD :)
 
Last edited:
I built a little desktop Java app for private use for tracking a community's stats in Diablo 3. I think the battle.net API's approach is a great one to use as an example.

Regarding the interface:
- Let people request the data via HTTP GET with all the parameters in the query string so they can bookmark pages they care about.
- Use JSON for the output. It'll still be human-readable when accessed via a browser.

People have covered the kinds of data they're looking for pretty well.

For exposing the local program (whatever you're willing to give people visibility to), LUA is great. Runes of Magic used that approach pretty well.
http://runesofmagic.gamepedia.com/List_of_Functions
 
I'd like to see flight telemetry for use in motion simulators similar to many flight and driving sims, in particular: Ship angular velocity, Ship velocity and Ship acceleration.

I'd also like some rumble parameter for those of us with transducers, specifically rumble frequency and rumble amplitude (or alternatively an audio stream separate to the main sounds). This is determined by thins like: shooting, getting shot, engine vibration, flying damaged, entering atmosphere, turbulence (while fuel scooping or if we ever land on planets).

I'd also like some telemetry for external instrumentation panels, such as speed, target, distance to target, target status (planet, station, friendly, hostile, etc), lights status, landing gear status, cargo scoop status.
 
For a web API, the battle.net interface is a good example. I built a little desktop app with Java to track stats for a list of players in Diablo III without too much trouble.

Instead of POST, it would be nice to support GET so people can share links with all the parameters specified.
Return the output in JSON. It's human-readable in a browser and easy to parse with standard libraries in many languages.

For the local program, LUA is nice for whatever data (or functions) you want to expose. Runes of Magic is a good example there.

I think people covered the use cases pretty well.
 
Last edited:
I honestly thing just having a pocket Galaxy map would be amazing, particularly if you could then sync it up to your account when you log on play. It would effectively be part of your ship then so no need to "jump" to the map screen to plot routes. It could also allow you to research routes away from your pc or out of game. keeping it simple cos i dont think it needs to be complex.
 
I'm not sure if anyone covered it yet, but thinks i'd like to have access to:


  • Shield levels
  • Hull damage/integrity
  • Ammunition levels
  • Hit data (target hit/ damage values?)
  • target data
  • fuel levels
  • ship speed/trottle levels.
  • systems power levels

It would be cool to make an app that could show you your hit%, how much damage you've done to a particular enemy during a fight(by weapon/weapon type if possible) provide warnings when your ammo is low. provide warnings when your shields/hull is low. stuff like that. Also could have some flight data recording to asses post-fight information "oh man, i was at full throttle the whole time, I need to remember to slow down a bit to turn next time". or "wow, my weapons power was low/out a lot, i need to invest in a better power plant"

Basically anything i could make some analytics tools out of.
 
What we need: (from a reddit post) pretty much every data you can get in game + a player/system history

Just some examples. When you are in a system you can get all data about the system. Factions, stations, planets. What you might not get is data from other player or ships in the system because that are infos that not necessary handled by a FD server.

If you are on a station you can also access market and board but you have to be docked and also online/in game to prevent to much data mining.

Galaxy map is a bit more difficult because the game lives from the need of exploring so if you just can write a program to scan the galaxy its a bit boring. But in some degree a way to access system data should be allowed. Maybe a open map with the core system and main information like fraction (empire,fed...), law, population, type (high tech, extraction...), absolute position(x,y,z)

And also a important point, who can access the data. EVE Online has a good way. You can create different key with different access right. E.g. you can make one key for a "high score site" where only the commander stats available but also a different key for Slopey where only the market data is accessible.

Last but not least a history. For player something like last visited station/system, last transactions, missions, fights... and for the system; player visited, faction status, maybe fights (bounties claimed/given per day), maybe global market transactions (like the trading routes, e.g. high amount of gold exported also per day)
 
One note here: the API should not give more information than the game itself. E.g. many people want to have the black market info. Is it on the system map? then make this available on the system API. If not a player have to dock for the info. BTW can we have fake black markets where the police set a trap for smugglers ;) and maybe also better prices for well knows customers.

EDIT: I found the edit button ;)
also already mentioned a POST/GET and as response a JSON-String would be preferred
 
Last edited:
Michael,

Can we clarify if you mean an API hooked into the client, or an API on the webserver?

Personally I'm wary of anyone collecting via an API any data outside of the system they are in, or any data that their commander doesn't actually know of.

I think for anything I want to make the data exposed in the companion app's /profile call is plenty. Although I don't think coordinates are included in that, there's lots of guys that would current system coords handy :)

I assume the API would be on the server and not on your client but I agree a player have to collect the data e.g. you can get the market data from slopey because other players collected this data. This is ok not a way I like but ok. Not ok is when you can scan in advance systems and markets without someone ever was there.
 
Assuming you're planning on some sort of API key for authorization to get info from a player account, and not just generic info such as ship fitting stats:

I think the most helpful thing for 3rd party app development would be implementation of the ability to transfer funds between players, and then being able to access this "transaction log" from the external API. It opens a whole new career path, allowing players to "play" as developers and make money for their ships by offering tools and services to other players. Everyone benefits. Being able to do this is one of the primary features that has lead to having such a massive developer community for 3rd party apps in EVE Online.
 
And what would you use these for? It's useful to see what problem you're trying to solve rather than just a list of information - thanks!

Michael

- System name, station name and type: For a travel log.
- Galactic coordinates: distance=sqr((coordx1-coordx0)^2+(coordy1-coordy0)^2+(coordz1-coordz0)^2). this formula gives the distance between 2 points on a 3 dimensional space, so we'd be able to include the distance traveled on the travel log.

Edit to reply a post by Jim Falcon

Jim Falcon said:
BTW can we have fake black markets where the police set a trap for smugglers ;) and maybe also better prices for well knows customers.

This. Is. A. GREAT. Idea ! Try to sell the goods and... BAM ! There's a bounty on you. And ocasionally, legit black markets can be "taken over" by the cops, so no one could ever be sure.
 
Last edited:
Let me add another vote to please reach out to the SimVibe folks and find out what they need to add E:D support to their software. I've used SimVibe for iRacing and it's a phenomenal improvement in immersion. I'd love to get the same thing working with E:D. I know they've said on their forums that they'd love to add support for E:D.

2nd'd :)
 
218

I know this is probably a silly request, and I am sure most of these requests will revolve around the types and amount of data we get, but I will ask anyway:

Can we please please get a REST API? I know everyone who isn't me loves formatting XML to pass back and forth, and loves .NET APIs but I am not a clever man and every REST calls I've needed to make have always been super easy for me to get data back.

...barring that just give me some cURL examples when you're done making some crazy fancy SOAP JSON XML C# .NET API EX Plus Alpha with HyperFighting API so I can figure out how to bang my rocks together to get data back.
 
Status
Thread Closed: Not open for further replies.
Top Bottom