Discussion External API Requirements Thread
- Thread starter Michael Brookes
- Start date
- Status
Not an API suggestion.
Dear Devs, my initial wishlist for an API was fairly basic in that I just wanted commodity price data. But in thinking about the potential for an API I think there would be great value in being able to interact with ED with tools - particularly interfacing devices such as tablets, lights, knobs, switches etc - to create virtual cockpits.
EG: say I want to be able to have a tablet that essentially replaces the NAV panel - a fully functional real nav panel. It could have customisable themes. Different ways to display and interact with the Nav/targeting/mission data. The tablet app would need to access the data it needed to display from ED and then also post commands back to lock targets/destinations.
So, my API feature wishlist is basically twofold:
1. any information available to cmdrs is available via the API and
2. any input from cmdrs can be input via the API
Some specific examples of this would be:
Information to CMDRs:
* Station Services data including:
* What services are available at this station
* News feed - items
* Munitions - modules, ammo levels, costs
* Repairs - modules, health, costs
* Bulletin Board - missions, details
* Outfitting - modules available, details/costs
* Ships - ships available, costs/details, ships parked
* Market - prices/supply/demand, average
* Cartographics - data to be sold
* Nav Panel Data
* location/distance for all nav panel items
* current location
* current destination
* Transactions list and details
* Contacts list and details
* subtarget list and details
* Cargo scanner results
* Sys Panel Data
* Status/Modules/Firegroups/Cargo/Functions - the whole bit
* refinery status
* includes module damage
* Ship status Data
* Hull level, shield status, Power distribution status, mass locked status, landing gear status, cargo scoop status, landing light status
* Alarms
* Ammo levels, fuel level, temperature level
* Sun(star) colour, direction (for virtual cockpit mood lighting)
* clanking sound
Input from CMDRs:
* Station Services transactions
probably don't need any API control here
* Nav panel inputs
* lock target
* lock/unlock destination
* request docking
* cancel docking
* select subtarget
* Sys panel inputs
* module toggle on/off
* functions controls
* refinery controls
* Ship control inputs
* scoop/gear/lights
* deploy chaff/ECM/heatsinks/shieldcell
* probably stick inputs is going too far
So apart from captains log type tools or trading tools to help advise cmdrs on where to go and what to do, we could also have different interfaces to our ships and use the ones we like or are themed to suit our type of ship.
I imagine a virtual cockpit with a Nav panel tablet, a Sys panel tablet (or possibly several for the various tabs in each). A heater in the seat to simulate critical temperatures, various alarm lights/sirens for different alarms, mood lighting depending on the system's star(s) . And a rusty old fan that can be turned on whenever a clanking sound is needed.
EG: say I want to be able to have a tablet that essentially replaces the NAV panel - a fully functional real nav panel. It could have customisable themes. Different ways to display and interact with the Nav/targeting/mission data. The tablet app would need to access the data it needed to display from ED and then also post commands back to lock targets/destinations.
So, my API feature wishlist is basically twofold:
1. any information available to cmdrs is available via the API and
2. any input from cmdrs can be input via the API
Some specific examples of this would be:
Information to CMDRs:
* Station Services data including:
* What services are available at this station
* News feed - items
* Munitions - modules, ammo levels, costs
* Repairs - modules, health, costs
* Bulletin Board - missions, details
* Outfitting - modules available, details/costs
* Ships - ships available, costs/details, ships parked
* Market - prices/supply/demand, average
* Cartographics - data to be sold
* Nav Panel Data
* location/distance for all nav panel items
* current location
* current destination
* Transactions list and details
* Contacts list and details
* subtarget list and details
* Cargo scanner results
* Sys Panel Data
* Status/Modules/Firegroups/Cargo/Functions - the whole bit
* refinery status
* includes module damage
* Ship status Data
* Hull level, shield status, Power distribution status, mass locked status, landing gear status, cargo scoop status, landing light status
* Alarms
* Ammo levels, fuel level, temperature level
* Sun(star) colour, direction (for virtual cockpit mood lighting)
* clanking sound
Input from CMDRs:
* Station Services transactions
probably don't need any API control here
* Nav panel inputs
* lock target
* lock/unlock destination
* request docking
* cancel docking
* select subtarget
* Sys panel inputs
* module toggle on/off
* functions controls
* refinery controls
* Ship control inputs
* scoop/gear/lights
* deploy chaff/ECM/heatsinks/shieldcell
* probably stick inputs is going too far
So apart from captains log type tools or trading tools to help advise cmdrs on where to go and what to do, we could also have different interfaces to our ships and use the ones we like or are themed to suit our type of ship.
I imagine a virtual cockpit with a Nav panel tablet, a Sys panel tablet (or possibly several for the various tabs in each). A heater in the seat to simulate critical temperatures, various alarm lights/sirens for different alarms, mood lighting depending on the system's star(s) . And a rusty old fan that can be turned on whenever a clanking sound is needed.
Sorry, jumping in at the final hour, but I think the API should basically give as much as possible that a player could record ingame. Important things are:
Player data:
1. Credits
2. Current ship, its outfitting and cargo in hold.
Galaxy/system data:
Anything on the galaxy/system map. Two calls:
1. All systems in the "inhabited zone" (including uninhabited systems within say 50LY of inhabited systems) OR
2. All systems within X light years of a point on the galaxy map.
Shall include: All data on the system maps of such systems, including
a. Any bodies and whether they have been scanned, also mining type/quality
b. Imports/exports, for each station.
Player history
History of player docking, each docking including prices and quantity of commodities on the market.
---
Obviously there's more ingame data than this, but I suspect the above (along with the jump fuel usage formula) will be enough for most people now.
I'd really like this, because I don't want to record a whole lot of information on paper, but on the other hand I don't want to cheat by getting information online I shouldn't have. The above info based on what I've found myself would be appropriate I think.
I don't think "live in-flight data" should be provided. Also, to keep it simple, there's no need to provide API's for "fastest route". App developers can do this themselves as long as you provide them the data.
Getting the data available should be the focus, leave the creativity of what to do with it to the app developers.
Player data:
1. Credits
2. Current ship, its outfitting and cargo in hold.
Galaxy/system data:
Anything on the galaxy/system map. Two calls:
1. All systems in the "inhabited zone" (including uninhabited systems within say 50LY of inhabited systems) OR
2. All systems within X light years of a point on the galaxy map.
Shall include: All data on the system maps of such systems, including
a. Any bodies and whether they have been scanned, also mining type/quality
b. Imports/exports, for each station.
Player history
History of player docking, each docking including prices and quantity of commodities on the market.
---
Obviously there's more ingame data than this, but I suspect the above (along with the jump fuel usage formula) will be enough for most people now.
I'd really like this, because I don't want to record a whole lot of information on paper, but on the other hand I don't want to cheat by getting information online I shouldn't have. The above info based on what I've found myself would be appropriate I think.
I don't think "live in-flight data" should be provided. Also, to keep it simple, there's no need to provide API's for "fastest route". App developers can do this themselves as long as you provide them the data.
Getting the data available should be the focus, leave the creativity of what to do with it to the app developers.
Last edited:
YES! To this please!
> Player Data
-Owned ships + their location
-Credit Balance
-Ship Loadouts
-Ship information (such as weight, speed, power etc)
>Galaxy Map
- Would be awesome to have a full galaxy map to check out all the systems, and plot routes on
>Market Information
-For the traders, market information for stations that your ship is currently stored in
-Owned ships + their location
-Credit Balance
-Ship Loadouts
-Ship information (such as weight, speed, power etc)
>Galaxy Map
- Would be awesome to have a full galaxy map to check out all the systems, and plot routes on
>Market Information
-For the traders, market information for stations that your ship is currently stored in
love to see a way of find out whom has discovered some thing and getting in touch with them, eg: some sort of in email faster than light email system
Having already done some work with the discovery data kindly provided a while back which I transformed into the very popular http://dump.bass-speaker.com/discovery.php site(speed to market was MySQL on this one having written a VBscript exporter from the XLSXM file... not ideal but did the job - and is still getting 300-400 hits a day!!), it’s given me some food for thought about what I would like to see available from the API, and what I also feel would be realistic to be available from the API (data size constraints etc.).
It would be nice if a query that allowed you specify CMDR name and it returned their list of discovered items, however I do feel that this would be unrealistic, since for example, OnePercent had 96831 objects in 8342 systems (and of course this will only have increased I’m sure), even trimming the data response by returning systems list and then object list with FK to system list, it does make it rather a heavy weight query.
Realistically, I do believe a system name query would be okay, as I believe the highest number of objects I saw was 124 (although I’d bet there are systems with more!)
A CMDR stats query (count(stellarobjects), count(systems) etc.) would be nice as well.
And a top 10/100 (or arbitrary number in-between) of CMDR’s would be helpful as well.
Now this may be controversial, but perhaps there could be some "Premium API", given to either trusted/approved/signed NDA or Disclaimer type developers that have an authenticated API that is above and beyond normal user level auth, that perhaps provides more detailed data that can be manipulated (as above for example) , but the query time is restricted/reduced so it's say once a day at 4am or similar when servers are under less load - or even to a dedicated server.
It would be nice if a query that allowed you specify CMDR name and it returned their list of discovered items, however I do feel that this would be unrealistic, since for example, OnePercent had 96831 objects in 8342 systems (and of course this will only have increased I’m sure), even trimming the data response by returning systems list and then object list with FK to system list, it does make it rather a heavy weight query.
Realistically, I do believe a system name query would be okay, as I believe the highest number of objects I saw was 124 (although I’d bet there are systems with more!)
A CMDR stats query (count(stellarobjects), count(systems) etc.) would be nice as well.
And a top 10/100 (or arbitrary number in-between) of CMDR’s would be helpful as well.
Now this may be controversial, but perhaps there could be some "Premium API", given to either trusted/approved/signed NDA or Disclaimer type developers that have an authenticated API that is above and beyond normal user level auth, that perhaps provides more detailed data that can be manipulated (as above for example) , but the query time is restricted/reduced so it's say once a day at 4am or similar when servers are under less load - or even to a dedicated server.
Last edited:
Hello,
With many great things already suggested, may i propose, that we could have some a bit more active data from the client. I'm talking about in-flight (or in-fight) data:
- current target
- attacker
- ship status
- ally status
- damage given/recieved, type of damage
Basically something like constant combat log. What i have in mind that let's say there could be an application that would give a player ability to set some additional visual and/or sound cues. A good example of that would be putting that data into a custom text synthesizer which would even further enhance player immersion:
"Alert! Commander Voyak, we're under attack by an Elite Viper. Recieving heavy plasma damage, shields are currently at 21 percent. Shall I deploy hardpoints?"
"Good work commander! You've destroyed him in 1m 32 seconds, that's 17 seconds better than the last fight. You've used two Shield Cell Banks and fired 474 shots from multicannons. Your aiming has improved by 2.5 percent."
Cheers!
Voyak
With many great things already suggested, may i propose, that we could have some a bit more active data from the client. I'm talking about in-flight (or in-fight) data:
- current target
- attacker
- ship status
- modules - online/offline/damaged/cooldown
- shields/hull status
- is it being scanned, etc.
- ally status
- damage given/recieved, type of damage
Basically something like constant combat log. What i have in mind that let's say there could be an application that would give a player ability to set some additional visual and/or sound cues. A good example of that would be putting that data into a custom text synthesizer which would even further enhance player immersion:
"Alert! Commander Voyak, we're under attack by an Elite Viper. Recieving heavy plasma damage, shields are currently at 21 percent. Shall I deploy hardpoints?"
"Good work commander! You've destroyed him in 1m 32 seconds, that's 17 seconds better than the last fight. You've used two Shield Cell Banks and fired 474 shots from multicannons. Your aiming has improved by 2.5 percent."
Cheers!
Voyak
wolverine2710
Tutorial & Guide Writer
I know it has been said before but I wanted to emphasize the what I feel is very important. I'm hoping that FD is going to implement OAuth, OAuth2, OpenId or some other authentication/authorization method - could be the hashkeys methode used by EVE online. Effectively FD becomes an authorization server. There currently are quite a few systems which allow uploading of data, coordinates, prices, station info etc. Those systems are vulnerable for "poisoning the well" - commanders uploading bogus/false information. Commanders could implement authentication to combat that but every tool author has to reinvent the wheel again. If FD would become an authorization servers things would become much easier for projects like EDDN, EDDB, EDSC etc etc.
Scalability - for coordinates. There are around 19K systems with an economy. Route planners (standalone or part of tools like trading tools) need the coordinates systems in the neighborhood to calculate efficient routes. When the FD api provides coordinates for systems they can be stored and shared in a database. I guess for efficient routes for the 19K systems we perhaps need 150K system coordinates. Totally doable. BUT what if commanders fly into the unknown. Its impossible to store the coordinates of 400 Billion stars. I'm hoping that the FD api gives us the possibility to dump the coordinates of systems in a radius of perhaps 100 LY from where you currently are - locally stored and not being uploaded to a database. The can be processed by route planners to calculate routes.
Scalability - for system info. The info for systems is quite a lot of info. To much to store in a database - for a very large numbers of systems. It would be nice if there would be a fd_systems_id which can be stored in a database. A tool retrieves that info, feeds that to ED and receives the PG info back. Ideally there would be an separate offline GM which gives you info about a system (not wasting at the FD servers). If that could be run on the windows server on a hosting service it would allow tool authors to give info about all systems - it would costs them bandwidth ofc.
For me the most important feature is an FD authorization server.
Edit: I'm really hoping that the FD api at least provide all the information which is currently shown in the misc screens, market, GM, systems map etc. If NOT the OCR-ing (and its problems with it) will continue. Not to mention that their is the risk that authors will restart scraping data from the game - when the FD api is out and its nerfed to much to be really usefull. So far most (if not all commanders have played ball).....
Edit 2. In the above examples/suggestion I'm taken the assumption that FD doesn't want to spill BW and that most data will be provided locally - as retrieved from Ed rather then from the servers. The P2P was done to preserve BW so I can imagine they don't want to spill BW for the FD-api either.
Scalability - for coordinates. There are around 19K systems with an economy. Route planners (standalone or part of tools like trading tools) need the coordinates systems in the neighborhood to calculate efficient routes. When the FD api provides coordinates for systems they can be stored and shared in a database. I guess for efficient routes for the 19K systems we perhaps need 150K system coordinates. Totally doable. BUT what if commanders fly into the unknown. Its impossible to store the coordinates of 400 Billion stars. I'm hoping that the FD api gives us the possibility to dump the coordinates of systems in a radius of perhaps 100 LY from where you currently are - locally stored and not being uploaded to a database. The can be processed by route planners to calculate routes.
Scalability - for system info. The info for systems is quite a lot of info. To much to store in a database - for a very large numbers of systems. It would be nice if there would be a fd_systems_id which can be stored in a database. A tool retrieves that info, feeds that to ED and receives the PG info back. Ideally there would be an separate offline GM which gives you info about a system (not wasting at the FD servers). If that could be run on the windows server on a hosting service it would allow tool authors to give info about all systems - it would costs them bandwidth ofc.
For me the most important feature is an FD authorization server.
Edit: I'm really hoping that the FD api at least provide all the information which is currently shown in the misc screens, market, GM, systems map etc. If NOT the OCR-ing (and its problems with it) will continue. Not to mention that their is the risk that authors will restart scraping data from the game - when the FD api is out and its nerfed to much to be really usefull. So far most (if not all commanders have played ball).....
Edit 2. In the above examples/suggestion I'm taken the assumption that FD doesn't want to spill BW and that most data will be provided locally - as retrieved from Ed rather then from the servers. The P2P was done to preserve BW so I can imagine they don't want to spill BW for the FD-api either.
Last edited:
I'd like to do an x52 MFD app, to display some read-only data
1. Basic ship status (for both player ship & current target): Current shield %, current hull %, module health
2. Session status:
a) Session playtime
b) Liquid credits at start of session
c) Credits earned / spent since session begin, broken down:
-> Profit from missions (and # of successful / failed missions)
-> Profit from combat bonds / bounty (and # of each)
-> Profit or loss from trading / smuggling (and # of sales)
-> Loss from insurance (and # of deaths)
-> Money spent/gained by ship or module purchases/sales
3) Basic combat stats for the session (and for the player's entire career if you will share it): wanted targets killed, warzone targets killed, clean targets killed, deaths
4) Net reputation gain/loss for the current system's factions this session
1. Basic ship status (for both player ship & current target): Current shield %, current hull %, module health
2. Session status:
a) Session playtime
b) Liquid credits at start of session
c) Credits earned / spent since session begin, broken down:
-> Profit from missions (and # of successful / failed missions)
-> Profit from combat bonds / bounty (and # of each)
-> Profit or loss from trading / smuggling (and # of sales)
-> Loss from insurance (and # of deaths)
-> Money spent/gained by ship or module purchases/sales
3) Basic combat stats for the session (and for the player's entire career if you will share it): wanted targets killed, warzone targets killed, clean targets killed, deaths
4) Net reputation gain/loss for the current system's factions this session
Last edited:
well its been awhile since my last post, but I wanted to post my thoughts. I been trying a trade-helper, which currently relies on manual submission at the moment (single or CSV). What id like to do is to query the server about a location, say;
/get_locaction.php?=sol
This would then return a file (either JSON or XML), the contents of a system with information on each station such as ware-prices.
After-which I could process the file into my own database, so it can be used to compare prices, find ships for sale, equipment etc.If a whole system is too much, what about querying just single station for stock and prices.
Over the past week or so had a lot of problems with performance, but finally got it sorted now. The API however would make the whole process much quicker and easier. If there is any testing, id be willing to help.
Id also like a way to query the server for a certain commander, so maybe a leader-board? or offer suggestions etc. not sure, but I could think of things.
/get_locaction.php?=sol
This would then return a file (either JSON or XML), the contents of a system with information on each station such as ware-prices.
Code:
<system id='sol' name='Sol' x='0.0' y='0.0' z='0.0'>
<object type='planet' name='Earth' x='' y='' z=''/>
<object type='station' name='Abraham Lincoln' x='' y='' z=''>
<wares>
<offer id='1' ware_id='hydrogen-fuel' demand_price='0' supply_price='113' demand_level='0' supply_level='2'>
</wares>
<outfitting>
<offer id='1' eq_id='burst-laser' price='4400' class='1' rating='f' type='fixed'>
</outfitting>
<shipyard>
<offer id='1' ship_id='cobra-mk3' price='379718' allegiance='none' allegiance_rank='0'>
</shipyard>
</object>
</system>After-which I could process the file into my own database, so it can be used to compare prices, find ships for sale, equipment etc.If a whole system is too much, what about querying just single station for stock and prices.
Over the past week or so had a lot of problems with performance, but finally got it sorted now. The API however would make the whole process much quicker and easier. If there is any testing, id be willing to help.
Id also like a way to query the server for a certain commander, so maybe a leader-board? or offer suggestions etc. not sure, but I could think of things.
Last edited:
Michael Brookes
Game Director
Michael Brookes
Game Director
Thread closed so I can begin the internal process reviewing the input on this thread. Thanks to everyone who has participated. We obviously have a lot of work going on so I anticipate it being a few weeks before the next update on this. I'll post when we have something.
Thanks!
Michael
Thanks!
Michael
- Status