Discussion External API Requirements Thread

Status
Thread Closed: Not open for further replies.
At the risk of being OT, but just to clarify - reading some of the above posts, any being slightly cynical, will this be intended to farm out some of the design archive proposals (e.g. better trading tools and captain's log)?

While I'm all for 3rd party apps, I'm slightly suspicious of the timing and of the number of unfilled plans we have in the DDA. I really hope we don't see "back burner, already covered by 3rd party app xyz" as I'd really rather have this stuff directly in the game without using second screens, etc.
 
Sounds like a good idea. Whilst I do not have the skills to create an app, I would like the ability to better filter through the galaxy information.

Where is the nearest black hole? System with over 8 stars? Nebula? Moon orbiting a moon? Exoplanet?

As you can see, I'm a bit of an explorer.

I would also like to see a filter for player named entities.
 
I'm eagerly waiting for an official API. I already have played around a bit with the 'inoffcial' one from the iOS App: https://forums.frontier.co.uk/showthread.php?t=64947

Maybe we should start with what kind of 3rd party tools are there at the moment and how they can profit from an api?

Wolverine2710 has a nice list of popular tools and in my opinion there are three main types of tools:

- trading tools
- routing tools (including map visualization)
- captains logs

So what data would these tools need?

When i look at the output from the iOS App api, i notice that there is much stuff in it, that can be used by the tools already, at least the trading and log tools, like commodities list, prices, available ships and modules at the last station. Or your commander stats like money earned and spent, killnumber, elite ranks, or the last visited stystems.

But there is also stuff in that output that i don't think is necessary, especially in the commodities section, like the update rates.

And there is data missing that could be useful: official coordinates of the visited systems.
 
- Information about our friends : location, current ship, current credit balance, current ranks... Each player would ideally have the option to hide or display each information to people in his friend list.

- Ship status : current hull points, ammo, speed, G force, state of landing gear/lights/cargo scoop, etc. This could be use for plugins for Voice Attack for example, one could parameter the program to warn you when your health becomes low. Or you could ask for a status report and would hear how much ammo you have left. Programs like SimVibe for Buttkicker could use information like speed and G force to finely tune the vibration feedback depending on your maneuvers.
 
It would be great if there was an API which allowed the construction of the galaxy & system maps outside the game.

In fact, this would probably be best served by the official app having a copy of the in-game galaxy/system map implemented in it. This would be so useful. I'd love to be able to check distances and relative positions of systems, plan trade routes, search for locations mentioned in Galnet news (when using the web/rss version) whilst I'm at wor... er, in my spare time. This would make the official app a must have imho.

Also, friends information. Are they online, where are they etc. If they are online, it would be great to be able to send a text message to their in-game comms from a tablet/phone app
 
I'd like to be able to do the following via an API:

- track influence data in the inhabited regions (Faction name, faction influence, faction allegiance); to monitor the efforts of my group and groups that I am a friend of

- identify potential target systems (station names, station economy, station ownership, system population, distance of planets to main star)
Clicking the system map for every star is so much more complicated than using a database filter (e.g. show me all high tech systems with an Alliance Faction)

- read outfitting data from stations (low priority, I know where to get my stuff)

- read commodity data at current station to build up a database (can do this manually with EliteOCR, would be more convenient otherwise)

- read and store data of occuring trades, to be able to store and pool the amount of goods delivered to a system to analyze the economic system (e.g. can we import more Bioreducing Lichen to extract more Bertrandite?)
 
Last edited:

Slopey

Volunteer Moderator
Yay!!! At last! :)

Most of the stuff I'd be interested in is covered by the above - primarily in the BPC scenario, I'm interested in prices and stock levels at particular places. Information about those places would be useful to, which could be limited to specific station information, pad sizes, which system it's in etc. For systems, coordinates of a specific system would be useful.

What would also be useful is access to a commander's public stats, or to the current status of a particular commander authenticated by email address/password (in the same way as the login for the game).

As for getting the data into the grubby little hands of the people who are after it - how are you proposing to do it? Will there be a queryable API whereby a tool would simply query a system/station combination to get market data (as an example), or would it work in the same way as the current companion app with some sort of authentication - i.e. a JSON dump of current data. I would imagine the latter is more easily achievable as it already exists (although the confirmation code nonsense could do with being dropped out).

That way, at tool like the BPC can simply poll the API at intervals to get the market data where the commander is. There's no real need to have a queryable API on the FD side, as that'd make it trivial to get all the data everywhere, and push the load back to FD's infrastructure.

I'd be happy with the ability to officially hit the companion tool JSON/XML feed on a regular basis with a simple authentication model. As far as sharing or storing data goes, tool authors such as myself can maintain their own backend infrastructure, and continue to use ZeroMQ solutions to share the updates from all the various commanders running tools which can poll the API.

However, as much as I'd love an API and all the market data goodness that may entail, the BPC functionality should really be incorporated into ED itself in the form of a trade computer or similar. Ultimately I'd prefer that FD implement such tools into the game, rather than expose an API for 3rd parties to use to provide that data.

But an API would be a very useful resource ;)

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

I'd like to be able to do the following via an API:

- track influence data in the inhabited regions (Faction name, faction influence, faction allegiance)

- identify potential target systems (station names, station economy, station ownership, system population, distance of planets to main star)

- read outfitting data from stations (low priority, I know where to get my stuff)

- read commodity data at current station to build up a database (can do this manually with EliteOCR, would be more convenient otherwise)

- read and store data of occuring trades, to be able to store and pool the amount of goods delivered to a system to analyze the economic system (e.g. can we import more Bioreducing Lichen to extract more Bertrandite?)

You wouldn't necessarily use the API to do some of that directly most likely, you'd use the data exposed by the API to then mine the dataset for the information you were interested in. You'll still have to cache it on your end. I would imagine that it would be unlikely that FD would give you sales volumes over time for example for a known commodity from the API - you'd need to store the volume data yourself by timestamp and then interrogate it.
 
I am planning to make a combined status and matchmaking ala twitter.

I would like to query based on Pilots name (example: CMDR Jens Eriksen):
1) System (example: Lave)
2) If docked, station name.
3) Instance ID (to match in same instance). Also nice if pilot is using solo, open or group.

Everything else doesn't matter. The idea is to update status about whereabouts and how to find each other.

Will it be possible to send messages to Pilot, can the pilot receive messages through the API? example: CMDR JAMESON would like to meet you in DISO.

/Jens
 
Last edited:

Slopey

Volunteer Moderator
Additional API items which move away from the more traditional requests above, would be telemetry.

Being able to export statuses of cockpit indications (gear/scoop/mass locked/shields/power balance %/velocity/ammo) etc would open the way for cockpit builders and 3rd party display devices (think flight sim cockpit builders) etc.

Something along the lines of a Microsoft SimConnect equivalent, or Pete Dowson's FSUIPC which is simply a dll utility which holds data from Flight Sim in defined memory addresses (you just query the dll for a specific offset for the item you're interested in), would be perfect.

Interaction between hardware is already catered for by the vast number of input emulators/key binding apps, but having something which could check a particularly memory location for a value, then toggle an LED via USB would be perfect. All that stuff already exists within the market place - all we need is something to read (and it would be read only), the telemetry from the game in an approved manner.

If you took the above to the fullest implementation, the side panels within the cockpit in-game could be replicated on external devices (without the game having to do anything particular aside from expose the data).

But intially - the hud/indicator information would likely be sufficient.

:)
 
Last edited:
I am planning to make a combined status and matchmaking ala twitter.

I would like to query based on Pilots name (example: CMDR Jens Eriksen):
1) System (example: Lave)
2) If docked, station name.
3) Instance ID (to match in same instance). Also nice if pilot is using solo, open or group.

Everything else doesn't matter. The idea is to update status about whereabouts and how to find each other.

Will it be possible to send messages to Pilot, can the pilot receive messages through the API? example: CMDR JAMESON would like to meet you in DISO.

/Jens

Hm, i don't like the idea that i can be found by someone else through an api call, or if i'm currently playing in open or solo (or at all). It has at least to be restricted to commanders on your friendslist.
 
You wouldn't necessarily use the API to do some of that directly most likely, you'd use the data exposed by the API to then mine the dataset for the information you were interested in. You'll still have to cache it on your end. I would imagine that it would be unlikely that FD would give you sales volumes over time for example for a known commodity from the API - you'd need to store the volume data yourself by timestamp and then interrogate it.

Yes, I just wanted to show the user stories.

I need the API to access my own trade data at the time I do it.
Or some other way of just saving it. Doesn't have to be an API.
 
Agree, export status to twitter it other social media would be useful. Different formats for status alerts could be used dependant on players career choice.

Edit: this would be useful for cooperation between like minded players who would otherwise be unknown to each other #elitepirate_PvE or #elitepirate_PvP etc.
 
Last edited:

Slopey

Volunteer Moderator
And what would you use these for? It's useful to see what problem you're trying to solve rather than just a list of information - thanks!

Michael

System/Name/Type/Coordinates obviously allows for 3rd party route finding across greater distances. It also allows for accurate distances to be calculated between systems, so for example in my BPC, I can only show a distance, and filter based on that, for those systems which have coordinates which you've already graciously provided. That leads to lots of zeros and missed results when trying to do something like the best price for semiconductors within 50 LY of Zaonce etc.

If it was possible to interrogate any system for its coordinates, that would be allow the distance data to be available, and accurate across the board.

I'd suggest route planning is more important however. Most efficient trading drops off after a certain distance because the time it takes makes it more profitable to do shorter runs at lower profit more frequently, so unless you're hauling rares, you're unlikely to take a normal commodity 200LY+.

On several occasions in the last two weeks however, I've found myself wanting to move around 200LY in the universe to go check out stuff people have mentioned on the forum. Doing this on the current galaxy map is a bit of a pest with the distance limitation. It's also quite tricky to see the best route using the map in game. A 3rd party tool could make that much easier.

But again, most of this stuff would be best in the game itself.
 
Not an API per se but I would like a file to read that I could programaticaly determine Switch States. Landing Gear, Cargo Scoop deployed etc. Silent Running, Ship Lights. I'm building a switch board and I want to use LEDs to indicate the state of of a switch.
 
Last edited:
  • Like (+1)
Reactions: Rog

Slopey

Volunteer Moderator
Agree, export status to twitter it other social media would be useful. Different formats for status alerts could be used dependant on players career choice.

Edit: this would be useful for cooperation between like minded players who would otherwise be unknown to each other #elitepirate_PvE or #elitepirate_PvP etc.

But that doesn't need an API per se, all it needs is an in-game chat function. If FD are going to expose an API for people externally to chat/collaborate, would that not be better accomplished in game with better social tools?
 
Additional API items which move away from the more traditional requests above, would be telemetry.

Being able to export statuses of cockpit indications (gear/scoop/mass locked/shields/power balance %/velocity/ammo) etc would open the way for cockpit builders and 3rd party display devices (think flight sim cockpit builders) etc.

Something along the lines of a Microsoft SimConnect equivalent, or Pete Dowson's FSUIPC which is simply a dll utility which holds data from Flight Sim in defined memory addresses, would be perfect.

Interaction between hardware is already catered for by the vast number of input emulators/key binding apps, but having something which could check a particularly memory location for a value, then toggle an LED via USB would be perfect. All that stuff already exists within the market place - all we need is something to read (and it would be read only), the telemetry from the game in an approved manner.

If you took the above to the fullest implementation, the side panels within the cockpit in-game could be replicated on external devices (without the game having to do anything particular aside from expose the data).

But intially - the hud/indicator information would likely be sufficient.

:)

This raises an interesting point:

Is the propsed api a server side api, like the one used by the companion app?
Or will it be build into the game client, so that all interaction with the servers is controlled by the game client?
 

Slopey

Volunteer Moderator
This raises an interesting point:

Is the propsed api a server side api, like the one used by the companion app?
Or will it be build into the game client, so that all interaction with the servers is controlled by the game client?

I'd imagine telemetry would have to come from the client - a web API wouldn't be suitable for more realtime data (you don't want a landing gear LED to light up 20 seconds after you put the gear down for example), and you'd have to keep hitting it constantly. That could be done better locally via various methods.

For market info, where you only really need to get it once per docking, and it can persist until the user changes station or jumps to a different system, it's not time critical, so you can poll a web based API every few mintues.
 
Depending on how you develop the Bounty Hunting mechanics, I would like to see API support for that type of data.
.
For example, I would like to be able to track high-level Player and AI bounties to their last known system(s), possibly by buying data from "shady" salesmen. (this was someone else's suggestion, i'm not claiming it as my own)
.
API data would include:
  • Online status (for players)
  • Last dock location recorded
  • Last system location and closest celestial object for reference (i.e. seen in Lave around Lave 1a x minutes ago)
  • Last recorded bounty size
  • Known players/AI with active missions for the bounty
.
All of this should also factor in faction strength, both for and against target and hunter.
.
As for what this information would be used for.....I think you can probably guess :D
 

Slopey

Volunteer Moderator
Depending on how you develop the Bounty Hunting mechanics, I would like to see API support for that type of data.
.
For example, I would like to be able to track high-level Player and AI bounties to their last known system(s), possibly by buying data from "shady" salesmen. (this was someone else's suggestion, i'm not claiming it as my own)
.
API data would include:
  • Online status (for players)
  • Last dock location recorded
  • Last system location and closest celestial object for reference (i.e. seen in Lave around Lave 1a x minutes ago)
  • Last recorded bounty size
  • Known players/AI with active missions for the bounty
.
All of this should also factor in faction strength, both for and against target and hunter.
.
As for what this information would be used for.....I think you can probably guess :D

But why expose that through an API, rather than a "Wanted" list in game in a station "Galactic Sheriff" office?
 
My own project mines the verbose net log for the current system name and provides contextual access to other tools (navigation, market data search, etc.)

API features I would love to make it more useful:
- Push-notified when (and to where) the pilot jump systems, docks at/undocks from stations.
- The above could include local system navigation targets (IE: the left "navigation" pane)
- Push notification of changes to the "contacts" pane

Also lovely would be the ability to send input to the game, such as:
- Target one of the navigation targets/contacts
- Request docking (especially until a proper docking queue is set up for the smaller outposts...)

Basically, nothing that the commander doesn't already have access to, just streamlining certain procedures from a second screen (or from hardware, for those cockpit builders).

A websocket communicating with JSON for this would be lovely, but I would of course be happy with a binary TCP socket... or, well, anything really :)
 
Status
Thread Closed: Not open for further replies.
Top Bottom