Discussion External API Requirements Thread

Status
Thread Closed: Not open for further replies.
I could imagine with the right info developers could make an out of game orrery like the mock up of one shown during development, providing present location of self and friends and other useful info.
 
To set the scene, is this API going to be into a FD server to get information, or into the ED application running on your PC, or simply data dropped/exposed by ED (eg: when you enter a system and/or dock at a station)?

Sorry if this is stupid question. But I think it might be useful to set the scene of how/where this data can be obtain from?

I understand the former is the most powerful, but surely the last thing FD want is millions of HTTP requests spamming them every hour?
 
My own little app EDDL (a Diary/Log app) would be enhanced nicely by being able to capture:

The name and details of the system you are currently in
The name and details of the station you are currently docked at
Ship specifications
Commander details (ranking, bank balance, faction ratings)
Currently accepted mission details
Details of currently planned route

These are all things that will make it possible to generate a fuller, more rounded Commanders log.

The other big one is obviously Market data for things like Slopeys BPC tool.
 
I see some suggestions about route planners and that is great!

What would also be cool is to be able to take an externally calculated route and have it set in-game.
 
I'm interested in an API that works the other way around. I'd like to be able to hook into the game externally, to render external data on in-game displays. Right now I'm particularly thinking about an IRC client for one of the side panels. I assume that internally a set of widgets for building up the UI panels already exists, so some way to access those. Spawn a new tab on a given monitor panel, fill it with output widgets and an input bar that takes keyboard input, all with registered event callbacks back to the external program, that sort of thing.
 
Dynamic Signatures & Flight Plans

My suggestion revolves around forum signatures that you find at the bottom of peoples posts on websites. I am going to write this from the perspective of two people. One is a user sitting at work (we will call him Bob), the other is a user sitting at home playing Elite Dangerous (we will call him Sam).

While at work, Bob logs into his favourite Elite Dangerous forum. On reading the posts, he notices his friend Sam had posted a recent message to the forum. At the bottom of Sams post, his signature indicates that Sam is currently online in Elite Dangerous right now, and that he's currently in his Type 6, In Transit. This is because Sam's forum signature has a background image of a type 6, and below his commander name (that also features on the signature), it states " Current Status: In Transit". This information changes as the pilot changes ships, docks , and undocks... so that the forum signature is dynamic.

As Bob and Sam are friends in Elite Dangerous, Bob can now click on Sams Signature where he will then be taken to a special web page that looks like an aviation flight plan log book. From here Bob can see that Sam planned a navigation course 10 minutes ago going from [System] to [System], ( a course that would take 4 jumps) and that Sam is currently in the second system of that planned route. Also on this Flight log site, you can pad it out with past logged routes, a summery of distance travelled today, this week, this month, a basic profile of the pilot, and a chat window that connects to that pilot (Sam) in real time.. (You could sell the fact that the communications frequency the pilot will be operating on, is also logged with the flight plan ) via the flight log page.

Now, not all pilots will want to be tracked in this manor, so when the signature is clicked on from within the forums, Bob would have to log in with his own Elite Dangerous Account. This should then give you means to identify the person clicking on the signature, determine if he is on the pilots friends list, if so, show the flight log screen, if not, show some sort of access denied / classified message, with the option to contact the pilot now in real time ( via a text chat box on the site - going to the pilots text chat comms system ) , and an 'add the pilot to friends list' button. Then it would be down to the pilot to vet the person clicking on the forum signature...

No idea if any of that can be done, awesome if it can.... feel free to adapt and stuff...

Nice!
 

Slopey

Volunteer Moderator
I'll admit I'm out of my comfort zone with thus, but I agree the game needs better social tools. Happy (and better) for it to be in game, but if not maybe someone from the community develop it

Indeed. There are loads of ideas in the above 2 pages, but I think that as much as possible should be provided by FD within the game - there should really be no reason for my BPC to exist for example - there should be an in-game solution to that requirement.

We don't want to open Pandora's box and have FD provide (if they're willling to) so much in the API that you need to run 4 different external apps just to play the game.

In one sense, the question shouldn't be "What data do you want from an API?" (as we'll say "as much as possible please!"), it should really be "Which 3rd party tools should really be in game, are we going to do that, and if not that's when we should provide that info in an API", unless it's something which can't be done easily externally (cockpit lights/switches etc).

Market calculators/route planners etc, should be in game - that's an easily achievable tranche of features which FD could implement if they wanted to, hence there'd then be no need for a complex API, or the tools.

But something like exposing cockpit indicator states is some thing that a 3rd party tool can't provide via crowdsourcing or other means, so it *needs* an API either way to go down that route.

As much as I'd like an API based source of commodity data (basically permission to scrape the iOS app feed, without the email verification), FD have to decide if they're going to implement this sort of stuff themselves, or they ultimately want (or are happy for) us to do it. If there's no need for a BPC or a route planner externally, then they don't need the API to push that information out, for example.

If they add an API, and we all jump on it and release a plethora of tools, then why would they ever integrate those into the game? Meantime, the player then needs to run one or more 3rd party tools and alt-tab or run 2 screens/multiple machines, which is hardly ideal from a player perspective, even though it scratches our app itch.
 
To set the scene, is this API going to be into a FD server to get information, or into the ED application running on your PC, or simply data dropped/exposed by ED (eg: when you enter a system and/or dock at a station)?

Sorry if this is stupid question. But I think it might be useful to set the scene of how/where this data can be obtain from?

I understand the former is the most powerful, but surely the last thing FD want is millions of HTTP requests spamming them every hour?

Yes this is an important point. I would suggest to have both, but for different information:

- Web-based for semi-static information, such as systems, stations, star coordinates and such

- Client-based for the player's information. I like the idea of a local daemon (HTTP, UDP, whatever) to allow the development of local tools or interfaces

Security is a concern if you use a web-api for a player's information, particularly if you use ED store credentials to authenticate. Hence, local client.
 
What I want:

The option for the game client to send the following information either as a xml to a local folder, or as JSON to a server address.
1. When I enter a system - System name, various system parameters and most important the in game coordinates as exported in various spreadsheets by MB during beta/gamma
2. When I enter a station
a) Commodity market itemname/itemcategory/buy/sell/demand/supply/demandlevel/supplylevel
b) List of modules sold at station
c) List of ships sold at station

3. It would also be great to download/request a parseable (xml/json) statistics page for my commander.

4. For exploration and methodical visiting systems, it would help me greatly to get a parseable list of near systems (up to 20LY would be great), as listed in target panel. As an extension to the target panel, coordinates added to that list would also help a lot.

Games in 2015 lives and dies by 3rd party tools. The games that get a strong 3rd party mod/tool community live longer.
 
Last edited:
This may be outside the scope of the proposed APIs, but I'd for one like to see a panel in the cockpit that an external app (really, plugin) can insert limited types of information or UX into. I'd kill for a HUD video/audio player with standard media controls that talks to, say, my Plex server or iTunes Connect or Spotify for long trading routes in the Oculus Rift. Also such a thing would be useful for a wiki interface, route planner, trade data webapp, etc.
 
So if we're asking for data - add:
  • ship availability/price
  • modules + price
  • factions.

You're basically building the ED universe equivalent of google..

Or.. just a wild idea.. take the things that 3rd parties are already doing and put them in the game..
Adding to your ships computer tools that contain a pilot log that can record where I've been, notes and trade/commodity prices, ship/module availability, I saw there. (yes, stale is OK) automatically, including faction status etc. And add the ability to delete entries I dont want any longer, and to search what I have.

Having external route planners and trade hunter apps are great (I use them) I would still prefer that the equivalent was available in game.
 
Sorry, didn't comb through the thread yet. What I want is some sort of players heat map. It would display the player traffic of a certain time interval.
For this, I think I will need ...

* Numbers of unique players accessed the system (maybe sync with the same update interval with the ingame one?)
* Type of the ships that accessed the system
* (optional) Number of deaths occurred in last 24 hrs
* Access to system name
* Access to system allegiance
 
Things I would like to see in the API:
For trade optimization:
- System, and station names
- distance of station from star
- Relevant trade information (ie: prices, quantity, demand) for a particular station
- Station landing pad sized

For external peripherals:
- Ship telemetry (Shield, Hull, and subsystem damage, and power on off status)
- Available systems for jumping
- ability to toggle sub systems on or off, or select jump points from external peripherals
- current target information, including sub system targeting.
- Cargo in hold, and ability to eject it.

I think the trade information is self explanatory, for tools like Slopey's BPC, Thrudd's and EDDN.

The external peripherals information would be useful for Logitech G13/G19 and other displays on keyboards for quick glance and some limited interaction. It would also be helpful for people with the Saitek x52 Pro joysticks, as we have a screen that can be used for some limited data as well. The potential exists for people to use this information on a virtual display, like a tablet or cellphone as well.
 
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 :)
 
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.
 
I fully understand you FD guys intend to release an well modeled, stable and mature API, but until then it would relief the community of a lot of fuss if the game could simply drop a log file with the following content:

on enter system:
station list: name, distance, maybe a GUID, time stamp
on docking:
station: name, maybe GUID, time stamp, type, max pad size, has black market, has commodity market, has repair, has outfit, allegiance, governed by, economies, market data
market data: type (legal/black), commodity list
commodity list: name, time stamp, maybe type, sell, buy, supply #, demand #, demand (l/m/h), demand (l/m/h)

Even a bare csv without a frozen format would do the trick, even if it changed every patch level. Perhaps with opt-in via a line in AppConfig.xml.
This is all the data traders require for their 'job', which is atm painfully and prone to errors OCR'd & manually entered.
This log file drop doesn't give away anything the player could not see anyway, which avoids the related part of the discussion. Also it seems like relatively little work that could be done preliminary.
Pretty please? ^^
 
Yes this is an important point. I would suggest to have both, but for different information:

- Web-based for semi-static information, such as systems, stations, star coordinates and such

- Client-based for the player's information. I like the idea of a local daemon (HTTP, UDP, whatever) to allow the development of local tools or interfaces

Security is a concern if you use a web-api for a player's information, particularly if you use ED store credentials to authenticate. Hence, local client.

Yes, that makes sense! And more importantly shows my question/point wasn't completely stupid :)

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

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 :)
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.
 
Last edited:
Player location data

Apologies if this long thread already has this suggestion.

Last known player location (i.e. other players, not one's self)
Identities of players one has killed
Identities of players who have killed you
Identities of players you have interdicted
Identities of player who have interdicted you

Specifically, this being a multiplayer game, one should be able to create consequences for various good and bad behavior. If someone rips you off or nukes your player and you want to issue some payback (or engage otherwise), you should be able to manage it. You can't find where they are RIGHT NOW, but you can figure out where they were last.
 
From the faction flipping community, we would love to access to the following:
  • Polling method for System Map Information
    • Factions in each system
    • Influence of each faction
    • State of each faction
  • Polling method for Galaxy Map information
    • Allegiance of system
    • Position of system
  • A way to limit the above polling onto to inhabited space or inhabited systems
  • A way to easily hook the API into Java

The above polling methods do not have to be real time. They can be cached information updated nightly or some other time interval that is easy to maintain on your infrastructure. The third polling method doesn't necessarily have to exist, but it would reduce server load on your end. Since there is no neat way of polling your servers for only inhabited systems other than iterating through all 400 billion systems.

My idea is to use the above to create a Faction Influence map with appropriate spheres of influence. The map will be used to indicate expansion directions and track player progress in the faction war.

A stretch goal is for players to be able to opt in their debug information to track their position on this map. They can use this to see the location information of other players as well.
 
I am making an application called EDDiscovery for fun.

It basically has 2 functions now. Captains log and a route planner.
It is fun to keep a record on travels. And i like to map stars and se it in a map too.

I want an API that can.

* Get the name of the current system i am in. For logging my travel history.
* Maybe get a last x visited systems.

* Ask for information on a system. But inly information that i have explored should be visible.
* Maybee coordinated for the current system. I both want it and not. It maked life easier to get it but it is also fun to map out the coordinates of the stars.
 
Status
Thread Closed: Not open for further replies.
Top Bottom