There is a third option. FD can make the prices more player dependent so it will be less accurate to use a 3rd party tool. E.g. you get a discount on the fraction you are allied with or get a connection from a mission which sells computer components for a better price. The important point for me is the data have to come from a commander (even if you give your api key to a 3rd) and it should not be possible to "scan" the universe for any (hidden) data. I think this is a common opinion.
Discussion External API Requirements Thread
- Thread starter Michael Brookes
- Start date
- Status
There is a third option. FD can make the prices more player dependent so it will be less accurate to use a 3rd party tool. E.g. you get a discount on the fraction you are allied with or get a connection from a mission which sells computer components for a better price. The important point for me is the data have to come from a commander (even if you give your api key to a 3rd) and it should not be possible to "scan" the universe for any (hidden) data. I think this is a common opinion.
I'd prefer it if all the apps I used were in-game, either shown on the HUD or on that screen "down there".
The devs could implement a VM/API combo, so that 3rd party app developers could get only the data that the pilot and ship should have access to, and the player could see the results in-engine without clunky overlays or 2nd screens or alt-tabbing.
Such a combo could be throttled in terms of requests per second and CPU/memory usage, so that they don't cause the actual game to suffer any performance issues.
This also offers multiple access control levels. FD can approve/deny the apps. App authors could restrict access to their app to only those within a certain range of faction loyalties, combat/trading/exploration ranks, criminal status, or current location. They could even charge pilots credits to download the app to their ships.
Pilots would access the app store from the station computers, and download the apps to their current ship.
It's probably far too complex for the devs to consider, but I think it would be a cool way to go.
The devs could implement a VM/API combo, so that 3rd party app developers could get only the data that the pilot and ship should have access to, and the player could see the results in-engine without clunky overlays or 2nd screens or alt-tabbing.
Such a combo could be throttled in terms of requests per second and CPU/memory usage, so that they don't cause the actual game to suffer any performance issues.
This also offers multiple access control levels. FD can approve/deny the apps. App authors could restrict access to their app to only those within a certain range of faction loyalties, combat/trading/exploration ranks, criminal status, or current location. They could even charge pilots credits to download the app to their ships.
Pilots would access the app store from the station computers, and download the apps to their current ship.
It's probably far too complex for the devs to consider, but I think it would be a cool way to go.
Historical travel data (anonymised, and possibly in aggregate) would be nice to help visualise the spread of players throughout the galaxy.
It could be used to make a rather nice visualisation that would be good for marketing i guess - but primarily just looks cool
Much like something along the lines of the video shown here - http://nats.aero/blog/2014/03/europe-24-air-traffic-data-visualisation/
Something along these lines showing the paths taken by players over a period of time - which if you are logging instance creations/joins can be extracted I hope
It could be used to make a rather nice visualisation that would be good for marketing i guess - but primarily just looks cool
Much like something along the lines of the video shown here - http://nats.aero/blog/2014/03/europe-24-air-traffic-data-visualisation/
Something along these lines showing the paths taken by players over a period of time - which if you are logging instance creations/joins can be extracted I hope
I would really like for your ship to be able to record data from commodities from all the different markets that you have been to and you could bring this data up, but the prices wouldn't change unless you go to the market again.
I've got a bunch of professional software engineering experience, compsci degree, and at my job for a "major search engine" I support APIs (admittedly for ads, not computer games) and external developers using the APIs.
Based on my experience may I please please please please request that any API you deploy:
1 - Please strongly consider the user's privacy & access-controls
2 - Please use JSON REST service for the "offline" data (systems, game metadata etc - not client-data)
3 - Keep client-side data real time
Oh and because no-one else specifically mentioned it - please can you export the nav-compass relative coordinates so that I can stop using OpenCV for my supercruise autopilot
Based on my experience may I please please please please request that any API you deploy:
1 - Please strongly consider the user's privacy & access-controls
Cannot state this enough. Please do not allow anyone with an API to search for players based on name/location-radius and then see everything about them.
If you want to enable something that would let people publish forum signature images, or let a third-party website access their data please use something like OAuth2 where each users has to explicitly grant the application permission to access their own personal data.
If you want to enable something that would let people publish forum signature images, or let a third-party website access their data please use something like OAuth2 where each users has to explicitly grant the application permission to access their own personal data.
2 - Please use JSON REST service for the "offline" data (systems, game metadata etc - not client-data)
XML has been mentioned a lot already on this thread. Please avoid it. Apart from the obvious size problems (yes you can gzip it, but you can gzip json too so you're back to where you started), you inevitably end up with developers tying themselves in knots over schemas, namespaces, validation, data types and so on.
Half the time, developers don't even bother using XML "properly" and end up doing hacky things like searching for the <startTag> they are interested in, find the </startTag> and then do string-ops/substrings rather than parsing the XML and doing it "right" because its too much of a head-ache to bother doing properly when you just need to get one or two values out of a string.
The consensus appears to be that JSON has "won" against XML for web services (unless you are IBM/Oracle/some-other-"enterprise"-business-that-makes-its-money-by-selling-consulting-services-who-set-up-your-complex-XML-based-web-service-products-that-they-just-sold-you) purely on its simplicity and developer-friendlyness.
Half the time, developers don't even bother using XML "properly" and end up doing hacky things like searching for the <startTag> they are interested in, find the </startTag> and then do string-ops/substrings rather than parsing the XML and doing it "right" because its too much of a head-ache to bother doing properly when you just need to get one or two values out of a string.
The consensus appears to be that JSON has "won" against XML for web services (unless you are IBM/Oracle/some-other-"enterprise"-business-that-makes-its-money-by-selling-consulting-services-who-set-up-your-complex-XML-based-web-service-products-that-they-just-sold-you) purely on its simplicity and developer-friendlyness.
3 - Keep client-side data real time
There seems to be quite a ground-swell here for people wanting to do commanders logs, and talk of spitting data out to a text file or even a sql database on the local machine. This approach is great for those just wanting to keep a record of what has happened, but would be unflexible for other uses (e.g. real-time updates of an external display etc).
If you go for a live stream of data from the client, people wanting a record can collect it and store it themselves, whilst those wanting real-time data can use it too. May I suggest that client-side data is broadcast from the client using UDP? Lightweight, one-directional, well-understood and supported.
If you go for a live stream of data from the client, people wanting a record can collect it and store it themselves, whilst those wanting real-time data can use it too. May I suggest that client-side data is broadcast from the client using UDP? Lightweight, one-directional, well-understood and supported.
Oh and because no-one else specifically mentioned it - please can you export the nav-compass relative coordinates so that I can stop using OpenCV for my supercruise autopilot
Oh and I didn't mention it directly but I hope it goes without saying that the API would be great if written with cross-platform & multiple languages in mind. It would be nice if people can use C/C++/C#/D/Java/Javascript/Haskel/Lisp/OCaml/PHP/Ruby/Rust/whatever on their Linux/Mac/Windows/RiscOS/Arduino device to consume the API.
I.e. please use open standards that are easily consumed by anything No DLLs or windows pipes please!
I.e. please use open standards that are easily consumed by anything
No DLLs or windows pipes please!
Last edited:
The GalLink and ShipLink API
Here are my ideas for an Elite API:
Protocol and Format
The API should be based on HTTP and CORS to allow third-party software to be developed in any programming language, even as browser-based applications. Transport format should be XML and/or JSON. One format would be enough, every programming language has libraries to process both formats easily but if possible it would be cool to provide both so the client can tell the server which format it prefers (HTTP Accepts header).
Two APIs
Actually there should be two different APIs. A GalLink API to access public and global information from the Frontier servers and a ShipLink API to access local and private data directly from the game.
GalLink
The GalLink is a public API provided by the Elite Game Servers. Third-party applications can access this API anonymously to fetch global public stuff from the game. I will list some ideas what kind of information can be provided through this API in the next section.
The GalLink should ALWAYS be anonymous, there should be no way to authenticate a player because this would be a large security problem because third-party applications will then ask for the players login and password to be able to display player-based information. That's a no-go.
ShipLink
The ShipLink is an API which is provided by the game itself on a custom TCP port (But still using HTTP protocol). This API should be disabled by default and can be enabled in the settings menu in the game. For security reasons there should be two additional settings (But it is not that important because this is simply an API to a game and not to your bank account and there should be no API calls for bad things like reading/changing account passwords, self destruction and so on):
Here are some scenarios how different types of applicatons can access the API:
To prevent TCP port conflicts it might be useful to allow changing the port in the game settings. But this means that all applications must also ask for the port number and that's annoying. So I would prefer a port range technique. The game starts on port 20000 for example and when this port is already occupied then it tries the next port (20001) until it finds a free port. The applications can do the same, connecting to port 20000 first and when no Elite is answering there then they try the next few port. When all ports in the defined range do not work then they abort.
Provided information
This section lists some ideas what kind of information the two APIs could provide and how it could be used by a third-party application:
GalLink
ShipLink
Read-only information:
Modifiable information:
Here are my ideas for an Elite API:
Protocol and Format
The API should be based on HTTP and CORS to allow third-party software to be developed in any programming language, even as browser-based applications. Transport format should be XML and/or JSON. One format would be enough, every programming language has libraries to process both formats easily but if possible it would be cool to provide both so the client can tell the server which format it prefers (HTTP Accepts header).
Two APIs
Actually there should be two different APIs. A GalLink API to access public and global information from the Frontier servers and a ShipLink API to access local and private data directly from the game.
GalLink
The GalLink is a public API provided by the Elite Game Servers. Third-party applications can access this API anonymously to fetch global public stuff from the game. I will list some ideas what kind of information can be provided through this API in the next section.
The GalLink should ALWAYS be anonymous, there should be no way to authenticate a player because this would be a large security problem because third-party applications will then ask for the players login and password to be able to display player-based information. That's a no-go.
ShipLink
The ShipLink is an API which is provided by the game itself on a custom TCP port (But still using HTTP protocol). This API should be disabled by default and can be enabled in the settings menu in the game. For security reasons there should be two additional settings (But it is not that important because this is simply an API to a game and not to your bank account and there should be no API calls for bad things like reading/changing account passwords, self destruction and so on):
- A "remote access" checkbox. When disabled (default) then the server listens only on localhost so no other machine on the LAN can access the API. When enabled then the server listens on all addresses so it is possible to connect other devices (Android tablets, Notebook, whatever) to the API. I think it is not necessary to implement an IP white list or authentication to allow only access from specific devices. A gaming PC should normally be operated in a trusted LAN and if this is not the case then the player should use firewall rules on the machine anyway so further security is in the responsibility of the player, not the game.
- An "allowed domains" input field. This field can contain a comma-separated list of domain names which are allowed to access the API. This is needed for CORS to allow web browsers to send cross-domain-requests to the API. By default this field should be empty which means that CORS is disabled (In that way the browser can't use the API, only normal applications can).
Here are some scenarios how different types of applicatons can access the API:
- Someone wrote an Android application which displays ship statistics (Shield strength, Hull strength, whatever...) in a nice way. To use it the player has to enable the ShipLink API and the remote access to it in the game settings (And if a firewall is installed then the correspding TCP port must be opened there, too). Then the Android application can scan the LAN to find the game PC (Or let the player enter the IP address of it) and connect to the custom HTTP port. Link is established, the App can access the information. When the game is closed then the connection will be lost.
- Someone wrote a web site which displays some player-based in-game information. The website will use JavaScript and Ajax requests to access the API on localhost. The player has to enable the ShipLink API and has to enter the domain name of the website into the "Allowed domains" field in the game settings. The website (And only THIS website because only this domain was white-listed in the settings) can now send cross-domain requests (CORS) to the ShipLink API (For example http://localhost:20000/).
- A local windows application reads ship/player data from the game and displays it on the display of a gaming keyboard for example. For this kind of application the player only needs to enable the ShipLink API in the settings. Remote access is not needed because the local application connects to localhost.
To prevent TCP port conflicts it might be useful to allow changing the port in the game settings. But this means that all applications must also ask for the port number and that's annoying. So I would prefer a port range technique. The game starts on port 20000 for example and when this port is already occupied then it tries the next port (20001) until it finds a free port. The applications can do the same, connecting to port 20000 first and when no Elite is answering there then they try the next few port. When all ports in the defined range do not work then they abort.
Provided information
This section lists some ideas what kind of information the two APIs could provide and how it could be used by a third-party application:
GalLink
- The GalNet news (To implement a simple news feed on a website for example)
- Top-100 lists for lot of different stuff (Money, Kills, Visited systems, and so on). See the UPLINK statistics in Egosoft's X3 for example.
- Global game statistics (How many players are online, which ships are used by how many players, how many ships were destroyed in the last hour, and so on)
- Public player data. Stuff like the current fight/trade/explore rank should be public (Or maybe a player can decide in the game settings if he wants the data to be public). Then the GalNet API can be used to access the public state of a specific player. This kind of API can be used by applications to provide automatic rank icons for forum websites for example. I could simply include an image with the URL http://servername/kayahr/fightrank for example to display a nice "Competent" rank image wherever I want and it will automatically update when I gain a new ranking.
ShipLink
Read-only information:
- Player statistics. Used to compare myself against the top-100 lists provided by the public GalLink API.
- Current state of the ship (Type, Outfitting, Shield, Hull, Gear down, Cargo scoop active, Weapons deployed, Mass lock, ...) This can be used to display nice ship stats on an external device like an Android tablet or a notebook or show the data on the display of a gaming keyboard or joystick.
- Current state of the player (Name, Money, Ranking, Current position (Star system, station), wanted status, ...). This kind of stuff is also useful for displaying on an external device or to see my own status on a website allowed to access the data.
- Galaxy-Map data. Divide the galaxy into sectors and allow applications to query the star system names and positions in a specific sector and let them query all information about a specific star system which is accessible to the player. Such an API will work even for the 400 billion star systems because there is no API call to request ALL star systems. So the API can not be used to display the whole galaxy (Simply too much data) but it can be used to access the interesting parts of it (Like the sectors/systems in the near vicinity or along a specific path (To calculate a hyperspace route). When someone has a lot of time then he can iterate over all sectors and fetch the whole galaxy for whatever reason. But that's ok because this only affects the local machine, not the game servers or other players.
- Market data. Let applications access the market data of the current system and the bought trade data. I guess this is the most wanted API because lot of people want to calculate profitable routes. But be warned: This data will be shared between the players. If Frontier has a problem with this then market data should not be accessible by third-party applications (But this will not prevent the trade tools which already exists and which work with manually entered or OCR'd trade data).
Modifiable information:
- Power-management: Allowing an application to read and modify the power management (System power states and priorities) would allow us to create applications to select different power profiles for example. But this feature would not be necessary if the game would allow this already.
- Controls: All the simple stuff which is controlled by keyboard (like lowering the landing gear for example) can already be automated by third-party tools by simply simulating the corresponding key-press. So it would not harm the game if some stuff can be controlled by an application through the ShipLink-API so players can create fancy input gadgets for controlling the landing gear, turning on the ship lights and so on. I don't think this kind of API can be used for cheating. Instead it might bring some interesting features like morse code signaling apps for the ship lights ;-)
Greetings,
I think the ideas that have been posted are great, my ideas are slightly more controversial....
I am not sure if the information I am about to ask for is currently available either:
All three could be used to record/report on PVP mechanics for the purpose of kill boards.
I know this isnt going to be something everyone wants but as its a mechanic in the game I see no reason why this cannot be added into an API
Cheers,
Kro
I think the ideas that have been posted are great, my ideas are slightly more controversial....
I am not sure if the information I am about to ask for is currently available either:
1. Distinction between NPC and Commander kills (we had this in Alpha/Beta)
2. Loadout information
3. Combat/kill logAll three could be used to record/report on PVP mechanics for the purpose of kill boards.
I know this isnt going to be something everyone wants but as its a mechanic in the game I see no reason why this cannot be added into an API
Cheers,
Kro
I'd like to see cockpit-based information, such as shield/hull integrities and also current status for FSD, landing gear, hardpoint deployment. I'm currently toying around with developing an Android-based control plane so being able to change the state of the controls based upon real-time cockpit info would be fantastic.
P.S. Definitely not happy that you've decided to pause companion app development AFTER you've given the Apple minority their app. It smacks of favouritism.
P.S. Definitely not happy that you've decided to pause companion app development AFTER you've given the Apple minority their app. It smacks of favouritism.
Yes support of the Gxxx Logitech Gamerkeyboards will be wonderfull... e.g. Changing Color of display according Standing to the Fraction.
@Slugsie...your Tool works good on the G13 .....
Last edited:
I wouldn't have done seperate apps at all, but i.e. used Xamarin to build a single-source app for all platforms at once.
On the other hand, if the team includes experienced Objective C developers that know iOS and not so many Java/Android devs or C#/WP devs (while the Launcher is .NET, so WP should be easy for them ;-) ), it could be a quick win to build an Apple-only app and see how it works out while getting feedback on what could be improved.
It's better than wasting time and money on apps you probably go to re-write otherwise.
Hello Citizens of the Frontier,
First, Thank you for caring about the community request, this request for an external API was really important to me and it is very pleasant to see you guys take it seriously.
What I would like to see appear in the external API is:
- Systems' Information: Allegiance, Government, Position, Stations... (everything you can add to this would be useful).
- Most Importantly I would like to see what's happening in Systems: How many Commanders went by in the last 24h, its 5 biggest bounties, what supplies are scarce...
Basically what I would like to do is to create a small Elite Social Network where player groups could plan activities like hunting, trading, pirating... They could for example decide to meet at a Specific Station and go hunt the System's Biggest Bounty or if they know that a Special Convoy (another player group trying to supply big amounts of cargo to a System in need) is taking place, they could try to meet and pirate them...
This game has so much depth in its world that It would be really awesome to be able to plan these kinds of events.
Regards,
CMDR ANAS
First, Thank you for caring about the community request, this request for an external API was really important to me and it is very pleasant to see you guys take it seriously.
What I would like to see appear in the external API is:
- Systems' Information: Allegiance, Government, Position, Stations... (everything you can add to this would be useful).
- Most Importantly I would like to see what's happening in Systems: How many Commanders went by in the last 24h, its 5 biggest bounties, what supplies are scarce...
Basically what I would like to do is to create a small Elite Social Network where player groups could plan activities like hunting, trading, pirating... They could for example decide to meet at a Specific Station and go hunt the System's Biggest Bounty or if they know that a Special Convoy (another player group trying to supply big amounts of cargo to a System in need) is taking place, they could try to meet and pirate them...
This game has so much depth in its world that It would be really awesome to be able to plan these kinds of events.
Regards,
CMDR ANAS
Oh and because no-one else specifically mentioned it - please can you export the nav-compass relative coordinates so that I can stop using OpenCV for my supercruise autopilot
LOL, where's the download link
That's a good idea.
I would agree with all this but be very careful with allowing the API to control the ship. Landing gears, lights are all fine but it should stay away from targetting, manouvering the ship, deploying and firing the hardpoints.
I'd prefer XML personally rather than JSON but that is me. In reality either would be fine. No binary api's and on a client/server model I think every one agrees on basically.
I'm sure both are in here but I'm going to add it as well.
Bounty Boards:
List of player and NPC bounties, to promote player interactions and PVP.
* NPC name
* NPC Last Location
* NPC Last Location Time
* NPC Bounty Amount
* NPC Bounty Type (Fed, Emp, Loc)
* Player Name
* Player Last Location
* Player Last Location Time
* Player Bounty Amount
* Player Bounty Type (Fed, Emp, Loc)
* Player Status (On Line / Offline) We could also use the players last server connection time.
* Player Connection Type (Open, Private, Solo)
Astrolabe:
Galaxy, Station, Ship, and Trade info
Can help plot a rout, status of a system (fed, Emp, Ind, Anch...) (Boom, WAR...) (how close to transferring faction or war it is). I think this one will follow in line with the dream of ED, this will help players find an have an impact on a system and the Galaxy as a whole.
Ok, there is a lot in this one so I'm not going to list every feed we would need, just some high level stuff.
Career Info: All about you!
* Need every thing you have on the status screen in game.
* Your NPC Kills
* Your Player Kills
* Deaths by NPC
* Deaths by Station
* Deaths by Player
* Other Death..... VoiceAttach boost when docking....
* Total LY traveled
Server Info: All about everyone.
* Need every thing you have on the status screen in game but for the server as a whole.
* Total NPC shot down
* Total Player shot down
* Total Deaths by NPC
* Total Deaths by Station
* Total Deaths by Player
* Total Other Death..... VoiceAttach boost when docking....
* Total LY traveled
Hanger: Your Ships Info
* Your current/stored Ship Type
* Your current/stored Ship installed modules
* Your Current/stored Ship details (Mass, Power, jump rang,....)
* Your Current/stored Ship Cargo Details
* Your Stored Ships Locations
NavAI: the GPS of 3301
* Your Location
* System Details (Station Names, Goods to sell/buy, Prices, what services it has.)
* System Faction Detail (Current Faction, how close to war or any other event...)
In short, we need every bit of info you have on a system.
Player Finder: Find friends or even an enemy
* Player Names
* Player Last Location (Could limit this to system or even sector only. )
* Player Faction Status
Bounty Boards:
List of player and NPC bounties, to promote player interactions and PVP.
* NPC name
* NPC Last Location
* NPC Last Location Time
* NPC Bounty Amount
* NPC Bounty Type (Fed, Emp, Loc)
* Player Name
* Player Last Location
* Player Last Location Time
* Player Bounty Amount
* Player Bounty Type (Fed, Emp, Loc)
* Player Status (On Line / Offline) We could also use the players last server connection time.
* Player Connection Type (Open, Private, Solo)
Astrolabe:
Galaxy, Station, Ship, and Trade info
Can help plot a rout, status of a system (fed, Emp, Ind, Anch...) (Boom, WAR...) (how close to transferring faction or war it is). I think this one will follow in line with the dream of ED, this will help players find an have an impact on a system and the Galaxy as a whole.
Ok, there is a lot in this one so I'm not going to list every feed we would need, just some high level stuff.
Career Info: All about you!
* Need every thing you have on the status screen in game.
* Your NPC Kills
* Your Player Kills
* Deaths by NPC
* Deaths by Station
* Deaths by Player
* Other Death..... VoiceAttach boost when docking....
* Total LY traveled
Server Info: All about everyone.
* Need every thing you have on the status screen in game but for the server as a whole.
* Total NPC shot down
* Total Player shot down
* Total Deaths by NPC
* Total Deaths by Station
* Total Deaths by Player
* Total Other Death..... VoiceAttach boost when docking....
* Total LY traveled
Hanger: Your Ships Info
* Your current/stored Ship Type
* Your current/stored Ship installed modules
* Your Current/stored Ship details (Mass, Power, jump rang,....)
* Your Current/stored Ship Cargo Details
* Your Stored Ships Locations
NavAI: the GPS of 3301
* Your Location
* System Details (Station Names, Goods to sell/buy, Prices, what services it has.)
* System Faction Detail (Current Faction, how close to war or any other event...)
In short, we need every bit of info you have on a system.
Player Finder: Find friends or even an enemy
* Player Names
* Player Last Location (Could limit this to system or even sector only. )
* Player Faction Status
- Status