Discussion External API Requirements Thread

Hanz Olo · Jan 22, 2015

I was quite happily chipping away at a little app I was making that was gleaming some basic information from the netlog....until 1.06 where the contents of the netlog is much cleaner and much less useful to me. I was watching the most upto date netlog file for changes so that I could track when a player changed system. Something in the proposed api that lets an external app know the name of the new system is a must please. Knowing the galactic coordinates of the system would be nice as well since simple vector3 mathematics can be applied to calculate distances between systems in an external app. While we are on a wish list, knowing what ship the player is flying and when they change ships would also prove to be very useful.

I'm using Unity3d v4.6.1 to build my application and am already at the point where it is nicely overlaying E

, not taking up too much space in the top right hand corner of the screen.

A bit of an aside, but is there any log file in the current client version that is logging changes in the player's current system?
Until 1.06 I was using the most recently modified file containing the word "netlog" found in AppData\Local\Frontier_Developments\Products\FORC-FDEV-D-1002\Logs\
The development of my app is totally scuppered without such a gem! Thanks for everything and thanks in advance for all to come!

WalterHWhite · Jan 22, 2015

I'm really glad this kind of approach is being used, I will most definitely use the API.

I only found out about the thread via the dev update... (apologies if these ideas have been mentioned already, havent read 22 pages)

Two suggestions for the API itself
- Use JSON output
- Allow cross-origin requests so Javascript can be used (no server side programming required)... this'd allow people to save copies of a webpage/app to their local machine.

General Suggestion
- Provide as much data as you allow and can! The community will take care of the rest.

Data suggestions
- Allow system lookup based on name, return co-ordinates and potentitally any related metadata like factions and whatnot (make it an API option as to how extended the information is)
- Lookup minor factions to discover what systems/stations they are in, and if they are the ruling faction (helpful for turning in bounties to factions you can't find).

Xelous · Jan 22, 2015

Please note: The links below are not as useful as I'd like because:

'due to extensive link spamming from new user accounts, the usage of hyper links within posts and topics are not allowed for your user group.'

Sorry about that folks, but please read on, and do try to follow the links I've provided.

My API Ideas
Personally I would like to see an open API for most all the data collected in the interface:

Player details
Current System
Current Station
Player Statistics
Player Rank
Player Current Cargo
Player Fitting
Player ship
Commodities traded
Current Station Commodities
Explored systems by the player
Explored planets within system by player

A real hierarchical API giving access down into the data within the client, data which one can only get at the moment with such techniques as OCR or just by breaking the EULA...

I'd love to just come and code this for Frontier, but I'm rather busy with my day job

Example usage of such an interface....
To give an example of real-world usage of this kind of interface I'm afraid I must shamelessly plug my own patreon funded project, search for "Xelous".

More details of which can be found by looking for Tools I've already written on my blog, here: megalomaniacbore.blogspot.co.uk/

Raw Data on Disk (XML)
1. A data folder on disk, which stores the available data of the last pilot running within the client, which is a local cache of the data from the game, updated at a set interval, and would include the following:

* Pilot Name
* Credit Balance
* Current System (Unless in hyperspace)
* Current Station (Unless not docked)
* Ranks
* Statistics - as currently shown in the client
* Commodities - as viewed in the station services (only for the last station visited, and only if the player opens the commodities page)

Followed by supporting information, or information currently being farmed from the client in other manners, e.g. Market Data

I would like to see this exported, saved, as a universal or recognisable format; my personal preference being XML (and well formed XML at that) or some other value format.

Dynamic Link Library (DLL) based Retrieval
2. Alternatively I would like to see a DLL based API, exporting a set of static C style functions which provide the information from the system:

struct Player
{

char* _PlayerName;

unsigned long _PlayerBalance;

char* _CurrentSystem;

char* _CurrentStation;

Rank* _CurrentRank; // Where Rank is a sister structure of the correct form

Statistics* _CurrentStatistics; // Again where the statistics are a known and correct form for the data already in the client

};

struct Commodity
{

char* _Name;

unsigned int* _Buy;

unsigned int* _Sell;

// Etc etc...

};

extern "C"
{

const int GetPlayer(Player*); // Returns 0 for success or anything else for failure, filling out the given player structure

const int GetCommodityCount(); // Returns the number of commodities 0 to n in the current station

const int GetCommodity(const int& p_Index); // Returns the commodity in the given index

}

For the actual internal implementation, I'd utilise C++ as I believe the client is written in C++, we only export these functions as "C" calls for ease of use in python, C#, C or C++ with the minimal of fuss.

In C# we might access this functionality thus:

[dllimport("eliteapi.dll")]
public static extern int GetPlayer(ref Player playerData);

Or in C++ we could do this:

#include "eliteapi.h"

With code thus:

Player* l_Player = new Player();
// Clear the memory etc
if ( GetPlayer(l_Player) == 0 )
{

std::string l_PlayerName(l_Player->_PlayerName);

std::cout << "Player name: " << l_PlayerName << " has " << l_Player->_PlayerBalance << " credits" << std::endl;

}
else
{

// Error failed

}

Or more intricately, for the commodities:

Player* l_Player = new Player();
// Clear the memory etc
if ( GetPlayer(l_Player) == 0 )
{

// We know we're docked

if ( l_Player->_CurrentStation )

{

int l_CommodityCount = GetCommodityCount();

// We know the player went into commodities, or owns the trade data maybe for this system?

if ( l_CommodityCount > 0 )

{

for (int i = 0; i < l_CommodityCount; ++i)

{

Commodity l_c;

if ( GetCommodity(&l_c) == 0 )

{

// use the commodity data

}

}

Example usage of such an interface....
To give an example of real-world usage of this kind of interface I'm afraid I must shamelessly plug my own patreon funded project, search for "Xelous".

More details of which can be found by looking for Tools I've already written on my blog, here: megalomaniacbore.blogspot.co.uk/

Drazik · Jan 22, 2015

A ship module you could purchase called "trade computer" - the slot the computer went in was ship cargo size dependent. So a hauler could only install a size 1 module - an ASP could only install a size 5 and nothing below or above that class size.

Restrict the trade data that can be bought based upon the class size+jump range of the FSD - so you couldn't exploit the system if you owned a type 9 with a 27ly jump range, by just buying a 9ly sidewinder and buying all the system data. You'd only be able to buy 9ly worth of data. If you changed ships, you lost that data because it's in a different computer in the other ship.

When I purchase trade data or dock in a system - the trade data should be more expensive dependent on the class size of trade computer my ship has. Hauler trade data would be cheap, Anaconda/type 9 trade data would be VERY expensive, I'd like the commodity info to become available on the docking computer as I purchase it.

Then when I've accumulated enough trade data, I'd like things to be automatically worked out by the trade computer like margin per ton between station A and station B.
I'd like to be able to lock in a set route as determined partially manually using the trade computer.
The trade computer then stopwatch times each leg of the journey and prompts with timing stats and profit margins gained/lost each time I dock.
The trade data can expire after 24 hours and becomes unavailable in the trade computer unless re-purchased or systems docked in.

If this concept is not implementable by Frontier as an ingame feature, then I'd still like the trade data that I purchase to be saved to my computer in csv or xml or json format.
Then the above functionality could easily be implemented by 3rd party offline and online tools.

I wrote a basic powershell script that does most of the above once it has the CSV data gained through OCR. If the raw trade data that I'd purchased ingame was available - it would be fantastic.

Oh also - 3d co-ordinates of systems. Frontier used to have this in-system co-ordinates IIRC, you could find lots of discarded cargo, fill your hold, then use co-ordinates to fly back and pick up the rest.

CMDR Drazik (Chris)

jerram · Jan 22, 2015

Reddit ED API discussion Link

Awesome to hear this is being discussed!

I posted on Reddit a couple of weeks ago asking for API ideas - link as follows:

<link not allowed> /r/EliteDangerous/comments/2rmyai/what_apis_are_we_asking_for_list/

The topic went thus:
CMDRs, looking to put a list of wanted APIs together. More creative the better. If there is a link to a list its very welcome, I just want to get the visibility up to other CMDRs and Frontier.

Notes panel. Readable-writable notes from evernote, nozbe, google keep etc. I would like a panel I can push any content to.
reddit. Pull up reddit lists and starred posts, since it is the defacto realtime comms for our community. Eg, head to Arque for bounty hunting. Eg, Trending comms in your zone. Player hookups.
soundcloud or youtube integration so i can crank the pantera as i start an interdiction
E Galaxy map API. So when Im at work I can plan my evening second use case: provide a link to a location in the forums that you can save via evernote and jump to in the game.
updates on my team mates, like CMDR Bling just took down a lakon 9 in his tricked out Sidewinder.

I have about 3 months in the game, and back the opinion that Frontier have created the first livable galaxy reality simulator. Frontier could now start subbing out spare / overlapping galaxies to expanding alien civilisations, competing spacefaring games or paying alternate game play front ends. They have nailed the citizens flying around in space under their own command thing.
However as a member of the 21st century, (pretending to be in 3301), I need online and IRL notes, music, chat, maps and apis i can create with.

Props to the Reddit community for all the awesome input (raw list):

= Inbound APIs - api you can use to push data into ED

Web browser panel
music player built into the UI
Leap Motion integration for using your hands on the menus in VR

= Outbound APIs - data you can pull from ED

E Galaxy map API. So when Im at work I can plan my evening second use case: provide a link to a location in the forums that you can save via evernote and jump to in the game.
updates on my team mates, like CMDR Bling just took down a lakon 9 in his tricked out Sidewinder.
Game state. So an external application can poll for conditions, such as landing gear up, cargo scoop down, FSD charging or aborted, under attack, shields down, etc.
Ship / Game status api
for IRL lights and display screens and buttons that actually respond to in-game events
realtime monitoring of your ship systems without being in the seat
use a tablet (or mobile phone) as an external HUD element
GalNet news ingame downloadable to the ship, so I can read that on the travel
station trade-data of the visited stations on the panel between the legs
feeds in the station services
most wanted lists and those specific things
Trade data to push to external tools.
Jump and realtime ship data for external GPS
trade data - at least publishing a galaxy data api that would give you the same info that you have access to from the Galaxy map. AKA Slopey's tool.
Real time open/group CMDR mapping would be cool. Just like FlightRadar24 for example
Public PVP API. Player kills and deaths
Telemetry data for motion platforms and bass shakers. This would be amazing
Log market data for easy reuse!
Comms interface to post messages and accept commands
Poll current system/station/security
Poll commander details (ranks, net worth, status, transactions)
Poll and set ship details (pips, modules, functions, cargo/refinery)
Poll and set target (and subsystem)
Poll and set waypoints
save notes
Exploration - pull the system I'm in, the coordinates, the nearest systems, etc. In game, I'd like to see a path of the route I've followed
balance and location
System, Station, Fuel, Ammo
Ship position and heading in 3d space (speed+xyz)
Jump Range (Current + Max)
Market data for last station
Targeting information (What you've targeted)
Module and power (pips) info
Mission data (Destination and timer tickers)
a tool that tells you the best trade from where you are within a toggle'able jump distance. You don't need to work out the trade, your "COMPUTER" does it for you. No numbers game, just immersion.
control API to expose every command possible
Map API to enable 3rd party plotting
Trade API for data exports
Bounty API to help track down wanted players and such
Sound API to allow audio streaming that takes into account damage and such
HUD API for color change, other effects
News API so I can browse at my leisure
Ship State API so I can build dedicated panels for my stimulator
Communication API so I can chat with 3rd party tools
Route planning/Destination Targeting API. It would be awesome if you could submit these from another device and have your in game ship target that planet/station/jump rout.
I would love to have a galaxy map on a tablet or second computer where I could plan my trips, and target different stations once I'm in a station
run the galaxy map on say, an android tablet between my HOTAS bits
player counts in systems, over the last 30 minutes would be nice
Direct Twitch.tv integration with chat (see chat messages in game)...
Spotify integration...
A local clock
Location-contextual APIs that handles nearest celestial bodies/stars, so I can implement local/system/regional text, voice and video chats. Also, help me track my journeys across uncharted stars.
Video/audio stream APIs so I can embed feeds from wingmates/youtube channels/whatever into an ingame display - useful for Rifters. Imagine custom FaceRig avatars for extra immersion!
Messaging API so I can talk to ingame commanders form a web interface.
details imported by popular trading tools or excel to either highlight over commodities (best buy) or the little screen between your legs.
At Station x? regulatednoise outputs to your in game screen the best trades within 20Ly.
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)

WalterHWhite · Jan 22, 2015

oAuth for player specific data to interact with 3rd party API's, to guarantee the player using the API is the player requesting (perhaps sensitive) data.

So some data can be 'public' and other data 'auth required'. You may want to state some rules about the storage of such info for 3rd party apps.

With oAuth you could even pipe player initiated commands back to the server, like plotting routes.
Example: There's already some popular "rares" trade routes, wouldn't it be great if you could go to their website, validate with oAuth, and click "plot route", and the in-game route planner is mapped for you.

Armour · Jan 22, 2015

I presume there will be some kind of API key that will be provided to developers whose apps have been given the okay by FD, so that unauthorised shady apps can't hog API resources by spamming requests, causing problems for apps that do play by the rules?

Canthor · Jan 22, 2015

"Physical Data Provisioning"
Does Elite-Dangerous provide an API function(s) that report the state of the ship?
e.g. is the COBRA accelerating, turning, yawing, ... or are there forces inflicted on the ship by rocks, ship crashes, cannon hits,....

Whats the purpose?
Providing an API or data stack about the ships status may enable a HARDWARE developer in making some "supportive" hardware tools that can display, render or make physical effects.
Using a microcontroller board or other selfmade electronics would enable the developer to retrieve such data to create EXTERNAL effects (motion, light, sound, movement simulating G-Forces during acceleration).
Not sure I will ever create something like that, but I envision this as some useful OUTPUT from the game data (which might be available already anyway) that can be interpreted by external hardware.

Whats the benefit?
"Physical Data Provisioning" allows the creation of supportive hardware, like a real simulator cabine or cockpit, with G-Force and movement simulation.

bambam_ofc · Jan 22, 2015

Michael,
I'm the developer of the most popular (I think) admin tool for the Medal of Honor / Battlefield series of games, and before that did a significant amount of programming on the Microsoft FSX api. It would be good to have an API to the Elite : Dangerous 'series', but please note the following comments from first-hand experience:

* This thread is a wonderful crowd-sourced resource, but note the main content of it is 'information I'd like to get from an API' which is important but doesn't reflect the main issues in getting the fundamental capabilities of an API right.

* There is absolutely no way you will be able to have a single API for both client and system data, even if they are both presented via a local API on the client. So if you want to be successful you will need to design these as separate packages (and there is no need for them to be delivered simulataneously). Ultimately you might call it a single API (the Dangerous API) but in design it will have two parts architected differently.

* Microsoft FSX has a mature 'client aircraft status' api in SimConnect. It does what it does ok (e.g. you can receive roll rate events) but it's only one api that does a particular thing, and is completely client-centric. However you can efficiently both receive real-time data and send control inputs as they thought carefully about that bit. The api does very little for 'world' information though (e.g. you can't directly ask "what elevation is a particular point on the map?") so that illustrates how an api can do one thing well but be unsuitable for other types of access.

* The Battlefield series has a mature 'server status' api see BF4 PC Server Remote Administration Protocol.pdf. This is fundamentally driven by events spewing out of the server anyway, against which addon modules can respond, including with command inputs. So it's efficient, and actually in ascii so supports the lowest-common-denominator viewing in a console. It's really amateurish though.

* Work out what are the fundamental assets of the game (players, NPCs, ships, ship-types, stations, systems, station-types, weapons, weapon attributes, ammunition, commodities, commodity-types etc etc) and try and have reliable identifiers for them. There's nothing wrong with the api calling Beam Lasers "Beam Lasers" if that can be relied upon, but it is a total pain in the ass for add-on developers if you have identical "Green Beam Laser", "Blue Beam Laser" etc, or even worse the name changes in German.

* Do not, and I cannot emphasise this enough, make the API 'binary', i.e. functions and data as hexadecimal gobbledegook. I know the developers are from Cambridge, but in the real world of *free* addon module development there are very few of us core api programmers and a much larger population of slightly more hacky types who appreciate a Beam Laser being called a "BeamLaser" not a 0x4655363. I have a PhD in Computer Science from Cambridge but I do know the difference between theory and optimal industry practice. An example of why you'd do this is FD will inevitably add (e.g.) new weapons, and nearly ALL freeware addon modules just crash when they're presented with an unrecognised identifier. If you use binary you are radically increasing the chances of this happening, but if you use ascii the addon can say "you were shot with a MegaThrob" as a fallback for the addon failing to translate the new weapon key.

* Start with a limited and simple event API, user commands. Writing an efficient and robust api means seriously compromising the capabilities you provide. For example, I'd advise *against* implementing the version-1 of any api where the user can directly request data and then get it. E.g. "What system am I in" -> "Sol". You might not intend it but the majority of developers will end up polling this api, thinking it's ok because they chose a reasonably wide polling interval, but you end up with addons polling more and more frequently as the method is fundamentally flawed.

* it seems the most successful practical method for providing client status data is event driven, i.e. this is what both FSX and the Battlefield series uses. The addon registers a callback that receives suitable update events, like "you've just switched your lights on". It does not directly ask for immediate light status. As a tweak you *can* send the 'lights on' status (or off) when the client registers for the event, so the addon has a good initialisation.

* An addon needs an in-game way of communicating with the user, both user commands in and game status out. This does not prevent in any way the addon having its own Windows window, or indeed routing information to a completely separate machine, but for your average, typical, useful, simple addon you either tell the user something, they tell something to the addon, or both. The lowest-common-denominator for this (also the most common) is by hijacking the chat window. I.e. the game api already supports event-driven client status, and this includes "user has just chatted '!lights'", plus it has a command-capable api "turn lights on". This basically works, with negligible effort on the part of the game developers, but it isn't very elegant particularly in terms of *output*, i.e. the chatbox output is limited in terms of format. Might not sound fancy but the multi-billion-dollar Battlefield franchise would absolutely cease to function without the freeware addon in-game admin chat "!kick player" functionality.

* it is helpful to have public 'cross-reference' data that can be used in the addons (like a reference list of ships and weapons) but there's an issue that most addons have perpetually out-of-date reference data and don't handle that very well. Put your Cambridge boffins to think about that.

As an example of how the event driven market data api could be implemented:
(1) Game launches, addon automatically initialises
(2) Addon subscribes (e.g. registers callback) to the 'market update' event.
... time passes
(3) User docks in station, enters 'Commodities Market' screen
(4) 'market update' event fires, game calls addon (in a separate thread) passing it the current market data in some defined format.
(5) Addon sends chat message to user "Market data loaded"

kayahr · Jan 22, 2015

Inhumierer said:
but I think API data will (and should) be limited to anything we already have at the client, so actual system name, commodity prices & availability and stuff like this, and from the System Map only the known part, if it is not explored completely.

I don't think this will work. There are already tools out there which use manually entered (or OCR'd) market data shared between the tool users. So when Frontier adds an API to access market data then it doesn't matter if they restrict it to the data known to the player or not. The tools will share the data so in the end all players using these tools will have access to all market data, no matter if they ever visited the system before or if they bought the trade data or not. This already works impressively precise with the current trade tools and it will be even more precise when the trade data must not be entered manually anymore.

Frontier has to made a decision here:

1. They accept the fact that they can't prevent trade data sharing anyway (Because its already done even without an API). Then they should add an API to access all this data with no restrictions because these restrictions are completely useless in a connected world. Buying market data in-game is pretty much useless then (Not that it made sense anyway) so this "feature" should be removed.

2. They don't want public trade data. Then they will not add an API for market data at all. Because no matter what they publish through this API, it will be community-shared if it makes sense.

Inhumierer said:
From the Galaxy Map it sure would be nice to get the real coordinates ready packed. The actual GM does only show the direction & distance to other systems

If you have enabled the grid then you can read the coordinates from the grid labels when you move the grid so the star is directly on it. So all the information is there and there should be no reason why the coordinates should not be made available through the API as well.

But: The galaxy has billions of stars. You can't request them from the API to display them in your own map. This is simply too much data. This data is proceduraly generated in the game. So if you want to display the whole galaxy in your own tool then you need to know the algorithm how to generate the galaxy.

I would recommend implementing API calls like this:

getSystemNames(x, y, z) -> Returns a list of system names from the specified sector. This will only be a handful, sometimes none at all. What a "sector" is must be defined first. A sector could be a cube of size of 10LY^3 for example with the specified coordinates in the center.

getSystem(name) -> Return the system base information (Coordinates, Description, Star Type, ...).

This API would be enough to calculate even very long hyperspace routes because only the sectors between the source and the destination system must be read from the API.

Cmdr Sharky · Jan 22, 2015

kayahr said:
... So when Frontier adds an API to access market data then it doesn't matter if they restrict it to the data known to the player or not. The tools will share the data so in the end all players using these tools will have access to all market data,

No, they will only have access to the data that has been shared by other players. Bear in mind here that one of the original purposes of the Pilot's Federation is to share market data with each other. Maybe they should integrate that, provide an in-game mechanism for players to share their market information with each other. But since the external tools exist, it's not a priority.

This way, a player who earns a permit to a system has the choice as to whether they keep their discoveries secret or not. I think that's reasonable.

Andargor · Jan 22, 2015

bambam_ofc said:
Michael,
I'm the developer of the most popular (I think) admin tool for the Medal of Honor / Battlefield series of games, and before that did a significant amount of programming on the Microsoft FSX api. It would be good to have an API to the Elite : Dangerous 'series', but please note the following comments from first-hand experience:

* This thread is a wonderful crowd-sourced resource, but note the main content of it is 'information I'd like to get from an API' which is important but doesn't reflect the main issues in getting the fundamental capabilities of an API right.

* There is absolutely no way you will be able to have a single API for both client and system data, even if they are both presented via a local API on the client. So if you want to be successful you will need to design these as separate packages (and there is no need for them to be delivered simulataneously). Ultimately you might call it a single API (the Dangerous API) but in design it will have two parts architected differently.

* Microsoft FSX has a mature 'client aircraft status' api in SimConnect. It does what it does ok (e.g. you can receive roll rate events) but it's only one api that does a particular thing, and is completely client-centric. However you can efficiently both receive real-time data and send control inputs as they thought carefully about that bit. The api does very little for 'world' information though (e.g. you can't directly ask "what elevation is a particular point on the map?") so that illustrates how an api can do one thing well but be unsuitable for other types of access.

* The Battlefield series has a mature 'server status' api see BF4 PC Server Remote Administration Protocol.pdf. This is fundamentally driven by events spewing out of the server anyway, against which addon modules can respond, including with command inputs. So it's efficient, and actually in ascii so supports the lowest-common-denominator viewing in a console. It's really amateurish though.

* Work out what are the fundamental assets of the game (players, NPCs, ships, ship-types, stations, systems, station-types, weapons, weapon attributes, ammunition, commodities, commodity-types etc etc) and try and have reliable identifiers for them. There's nothing wrong with the api calling Beam Lasers "Beam Lasers" if that can be relied upon, but it is a total pain in the ass for add-on developers if you have identical "Green Beam Laser", "Blue Beam Laser" etc, or even worse the name changes in German.

* Do not, and I cannot emphasise this enough, make the API 'binary', i.e. functions and data as hexadecimal gobbledegook. I know the developers are from Cambridge, but in the real world of *free* addon module development there are very few of us core api programmers and a much larger population of slightly more hacky types who appreciate a Beam Laser being called a "BeamLaser" not a 0x4655363. I have a PhD in Computer Science from Cambridge but I do know the difference between theory and optimal industry practice. An example of why you'd do this is FD will inevitably add (e.g.) new weapons, and nearly ALL freeware addon modules just crash when they're presented with an unrecognised identifier. If you use binary you are radically increasing the chances of this happening, but if you use ascii the addon can say "you were shot with a MegaThrob" as a fallback for the addon failing to translate the new weapon key.

* Start with a limited and simple event API, user commands. Writing an efficient and robust api means seriously compromising the capabilities you provide. For example, I'd advise *against* implementing the version-1 of any api where the user can directly request data and then get it. E.g. "What system am I in" -> "Sol". You might not intend it but the majority of developers will end up polling this api, thinking it's ok because they chose a reasonably wide polling interval, but you end up with addons polling more and more frequently as the method is fundamentally flawed.

* it seems the most successful practical method for providing client status data is event driven, i.e. this is what both FSX and the Battlefield series uses. The addon registers a callback that receives suitable update events, like "you've just switched your lights on". It does not directly ask for immediate light status. As a tweak you *can* send the 'lights on' status (or off) when the client registers for the event, so the addon has a good initialisation.

* An addon needs an in-game way of communicating with the user, both user commands in and game status out. This does not prevent in any way the addon having its own Windows window, or indeed routing information to a completely separate machine, but for your average, typical, useful, simple addon you either tell the user something, they tell something to the addon, or both. The lowest-common-denominator for this (also the most common) is by hijacking the chat window. I.e. the game api already supports event-driven client status, and this includes "user has just chatted '!lights'", plus it has a command-capable api "turn lights on". This basically works, with negligible effort on the part of the game developers, but it isn't very elegant particularly in terms of *output*, i.e. the chatbox output is limited in terms of format. Might not sound fancy but the multi-billion-dollar Battlefield franchise would absolutely cease to function without the freeware addon in-game admin chat "!kick player" functionality.

* it is helpful to have public 'cross-reference' data that can be used in the addons (like a reference list of ships and weapons) but there's an issue that most addons have perpetually out-of-date reference data and don't handle that very well. Put your Cambridge boffins to think about that.

As an example of how the event driven market data api could be implemented:
(1) Game launches, addon automatically initialises
(2) Addon subscribes (e.g. registers callback) to the 'market update' event.
... time passes
(3) User docks in station, enters 'Commodities Market' screen
(4) 'market update' event fires, game calls addon (in a separate thread) passing it the current market data in some defined format.
(5) Addon sends chat message to user "Market data loaded"

Quoted in entirety, as Dr. bambam_ofc speaks the truth. It is nice to see these comments coming from someone with real API experience, thank you!

I wholly support the concept of using an existing API framework, as it simplifies implementation and allows for experienced community feedback.

Nuadusp · Jan 22, 2015

Things I would like to know so that they can be sent to other things like apps or programs are:

Prices at commodities market, low/med/high demands or supply

Current location would be nice (would be nice if you could make an app or something that would show your ship in space like galaxy view does, but on another screen/mobile phone

Any information on screen like shield status and so on (specially for things like apps)

think thats the main things I would like anyway

zzzornbringer · Jan 22, 2015

to give an example for a good third party app i would like to point you to this site:

http://www.elitetradingtool.co.uk/

it's not really a app, it's completely web based which i actually prefer.

if you can give these guys the tools to improve this further, this thing could be your go to address for everything trading.

-----------------------

what i personally would like to see is a app that tracks player population/activites. like, search for systems where players are most active. active player trade routes etc... stuff like that. this is an online game and i would like to be able to find other players.

Lustan · Jan 22, 2015

Bounty rewarded when wanted target is destroyed
Bounties redeemed to know that all bounties have been "cashed in"
Current Credit Balance
Current Rebuy Cost
Currently stowed cargo including purchase price
Current ship loadout data
Information above could be fed to a twitch channel while playing.

API's that allowed altering/replacing the UI. Not saying yours is bad.

API's would have to provide access to data in all current UI screens so as to allow full replacement of those screens.
Also ability to alter radar and targeting reticles based on target info including player vs NPC/ship model/shield status/FSD status
Ability to replace weapon status on HUD including weapon temp/amunition/loading or other status.

LARY STARKEEPER · Jan 22, 2015

I think commodities prices should not be communicated unless you have visited the station or buy trade data, the displayed price should be the one it was on your last visit (or trade data). It's not the same thing that sharing the price with friends or community than have the good price directly from the game anywhere you are. I'm absolutely not for it !

Every informations should be provided that way. Other way, it will be useless to buy Trade Data or System data ! Please do not make a casual game.

Data should be stored inside the phone or send on request (request = data buying, 1 times every 24h or on station's visit) like on the galaxy map (to avoid technical difficulties by storing them on server for every user). Data should expire to avoid overload.

I'm sure your designers have everything under control, I trust you to not make this game a casual game once you have a mobile phone !

Piasecznik · Jan 22, 2015

I do not know if already mentioned but I would love Voice Attack (and/or speech recognition) two way integration. To be able to say: open commodity market, sell cargo, buy Gold, Launch

And to have Text-to-speech engine able to read my system status, specified commodity price etc.

kayahr · Jan 22, 2015

PhilHibbs said:
No, they will only have access to the data that has been shared by other players.

Yes, that's right. But it will be effectively the same. The current trading tools (With manually entered data) already have lots of data (Surely not ALL) and the data is exact enough to plan profitable routes. When there will be an API for fetching the market data (Even if it is only for the currently visited systems) then tools can auto-share this data without any effort of the players and this will fill the community databases with much much more data than before. This might not be the same as "all data" but it is close enough.

I have no idea how many ED players are out there and how many of them would use these trade tools but I guess it won't really matter if I decide against sharing market data for a specific exclusive star system. There will always be someone else who does.

But on the other hand I like the idea to make the community-sharing a part of the elite universe. Indeed it would be lame if anyone could read ALL the data anonymously from the game or the frontier servers. It is more fun if players can only access the shared data if they are actively participating in the market data sharing community by using one of their tools. I really like the leveling system at elitetradingtool.co.uk for example.

So in the end, I'm convinced. If Frontier plans to let the player access market data via the API then it should only return data already known to the player. But it should be officially allowed to share the data or otherwise this will just cause trouble between Frontier and players.

giacdegiac · Jan 22, 2015

Ship status
-Weapons and ammo
-Modules Healt and status (on/off)
-Cargo with details (illegal, etc...)
-Insurance cost and %
-Switch weapon groups
-Hardpoints management
-Landing Gear
-Silent Running

Galaxy Map
-Route Planner
-Systems Details
-Bookmarks
-Sticky Notes(with voice note option)
-Screenshots with direct upload to some service ( touch a button, get a screenshot, upload, opens in browser on mobile)
-Complex filters with LISTS ( e.g.: show me a list with all the system of the federation within 15ly )

Whole Transaction Tab

Whole Contacts Tab

Whole Cargo Tab

Communication
-Possibility to read and send text messages
-Possibility to use the smartphone microphone as a voice communication device
-Request Docking

Owned Ships Positions

Possibility to use the smartphone's gyroscope in order to look around

GalNet

Friends list

Share sticky notes(with voice note option) about systems with friends

I'll add more later...

Mosher · Jan 22, 2015

Building on the earlier suggestion around friend and group management, notifications when friends come online/offline would be well-suited to mobile devices.

Are you already thinking about providing a webhooks and/or eventing infrastructure around the API?