Discussion External API Requirements Thread

[Bewilderbeest]

^^ nice, however that was explicitly forbidden by FD, you naughty boy!!! Tut Tut!!!

(Why do you think we're not all ripping the Companion App API to shreds for our tools?).

Ok, so the way I saw it was this. The companion app is out there, and is likely getting next to no use whatsoever, as it's not particularly brilliant at the moment. I figured a script which made one call to the JSON data every five minutes was very unlikely to cause a load issue.

Now for what you're doing with the (excellent, btw) trade tool, you'd need to facilitate everyone who uses your tool to hammer the API, rather than just for you alone, and this is why Frontier didn't want it to become widespread. The moment you shink-wrap this for anyone to use, THEN it would cause a problem, and by the API's nature, you need many calls to aggregate useful data.

Anyway, better to do something and seek forgiveness than ask permission in my book (sorry Michael!!)

My point with posting a basic graph to this thread is that there's a lot of supposition of what would make a good API, and having some material exploration of the data would be hugely beneficial in sorting out what would and wouldn't work.

My friend Tom and I are knocking around with the code at the moment, and it's up on Github at https://github.com/infovore/ed_investigation , minus the scraper, which is being kept closed for the reasons above.

 

[Bewilderbeest]

This is what I had in mind earlier in the thread. Bang it all into ES and chart whatever events we like.

Yeah ES makes graphing data over time definitely easier. There's also a large amount of work which needs on the presentation layer too. We were looking at D3, given how flexible it can be, to provide interesting visualisation of correlated data.

Those of us creating apps need to think about what we're trying to relate with the queries. Infoporn is all very well, but to make a truly useful app takes a lot of effort. But I 100% agree that using something like Elastic Search makes life a lot easier when you're iterating.

 

[stampy]

1. As a application developer,
I want to programmatically access information that can be read within UI elements on the game,
So that I can develop companion applications to better record and organize that information

2. As a player,
I want programmatic access only to information that can currently be read on screen within UI elements,
So that I am not required to use companion applications to obtain the full game experience

3. As a player,
I want programmatic access to data to require T&C acceptance forbidding the uploading of fully detailed data to public aggregators
So that discovery elements of the gameplay are not replaced by public aggregators

4. As a developer,
I want a simple restful API returning JSON
So that development with common tools is easy

5. As a developer,
I want authentication to be via a revokable authentication token
So that companion apps can authenticate without compromising player security

6. As a player,
I want authentication token-IP statics to be tracked
So that public aggregators using authentication tokens provided by players can be identified and closed

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

For #1, relevant information:

System information should only be available when the player is in the system*. System information should include name, government, economy, population, factions, discovered celestial bodies, and faction statuses (boom, lockdown, etc).

Station information should only be available while the player is docked in the station. Station information should include name, facilities (including a list of factions paying bounties), market data, black market prices for any commodities the player is currently smuggling, available ships for purchase, and available modules for purchase.



For #2, care should be taken to avoid exposing game mechanics and information that are not readily available in-game. For example, obtaining exact fuel tonnage may make it much easier to determine the fuel per jump distance formula. While this might not be a bad thing, exposing other information in more precise detail that in the game UI may lead to unintended consequence (if something CAN be min-maxed, it WILL be min-maxed; and this is not always in the best interests of fun).


For #3, people might hate this and it will likely be unenforceable on a player scale, but it will hopefully have the teeth to slow down public aggregator sites. The general gameplay strategy should not be search for the most profitable known trade, and then fly between point A and point B until the market changes; and it should not be to search for a list of earth-like planets to scan. When these mechanics are allowed, the game is more grind than play, and gameplay mechanics may have to be adjusted in non-fun ways to account for the over-availability of information.

The big challenge here might be a drawing a good line on what sharing the _API_ data means... it's one thing to post "wow look at this system I found!" on /r/eliteexplorers, its another to stream all market data to a public site for searching.


* Or if the information is available to my character in the galaxy map, if performance considerations can accept large-scale scans from players populating local databases.

 

[frkydeakybeatbox]

When targeting a ship, being able to get a list of shield, hull, and all sub systems, with the percentage of integrity of each would be nice. That way if touchscreens or tablets were interfaced better it would allow easier and quicker targeting.

 

[Cmdr Sharky]

When targeting a ship, being able to get a list of shield, hull, and all sub systems, with the percentage of integrity of each would be nice. That way if touchscreens or tablets were interfaced better it would allow easier and quicker targeting.

No way! APIs should not give combat benefits.

 

[frkydeakybeatbox]

I believe API's should be designed to help in all matters. Help traders trade and fighters fight. If we could get each of the systems we normally have to take our forward view away to use it would be amazing. Much like you see with more advanced flight sim setups with all of their instruments being able to be separated onto multiple individual screens. Would be cool to be able to select and control the modules on the fly as well.

 

[AstroZak]

Here's my 2p's worth. Note: I deliberately have not read the rest of this thread as I do not want to have my thoughts altered by others ideas, as the same time, I simply want to throw my ideas into the melting pot so that the FD can review and take in account as much as they wish.

So, here's my thought, there are several aspects of the game that I'm immediately interested in - Exploration, Mining and trading. An API will be extremely helpful as I can build tools/a multi tool to help me.

Let me deal with each in turn. Exploration - currently, I'm using the galaxy map and the system view to work out if I that system is completely explored. I think the game has this fairly well covered.

Mining. - finding the places to mine can be a problem, basically it means heading to each system and trying it out - great, but I'd like to accumulate data to help me build up maps of places where I can mine, and what I will get.
Trading - I want to be able to find trade routes. This is something that is currently completely lacking in Elite. it's 1000 years in the future, Stations are not currently advertising their prices lists - really? You tap a ship with a lazer and you get set to wanted, but a station cannot send it's price list out for 100 light years? - This is what I'm looking at.

So, to solve these problems, I'd love to get API access to be able to get the following information.

Commander information
1. Current ship - by Type "Sidewinder", "Type 7", "Hauler" etc. Also, full details of the loadout of the ship, basically a list of the hardpoints, internals, paint job and decals.
2. Current SystemName
3. Current Station (if docked)
4. Funds available (my current credits)
5. My cargo hold contents

Information that I'd like to be able to query
1. Get information about Systems - System Name, Co-Ordinates (they're in the log file already)
2. List of objects in the system - same as the system view, this will allow me to list the systems with asteroid belts and ringed systems for mining. A breakdown of each object would be great so that I know where to try for mining - I'd try a metal asteroid belt, even if it turns out to be a dud, it's a starting point.
3. List of stations in the system - Station Name, distance from jumping in point (how far so you have to fly when you enter the system), information on what the station offers - black market, commodity list, shipyard, outfitting services each detail here will allow people to easily answer questions like "where I can purchase an Orca?", or, "I need to find an A class power plant for my Anaconda, does Cleve Hub in Eravate sell them?"
The commodities data would be a representation of the data that you see on the commodities screen, with a datetime (utc) of when the pricelist was set, the same should be for each piece data that could change.
It would also be useful to have a breakdown of the pads that station offers. This allows an answer to the question "Is my Type-9 going to be able to dock?"

All of this could be made available as XML/json representations, using IP requests from the servers. Whilst I don't recommend having people type in their usernames and passwords into third part apps, there could be a token system where once you've logged with the official launcher a session key is made available that third part applications can use to authenticate (this way FD can retain control of the logging in ability) this key can then be used to allow access to commander data. As it will change with every log in, it should be secure enough.

I would love to be able to take lots of the in game things out of the game.
for example, take the whole comms panel from the top right out into my own program for text, voice calls still come into the game, but the content of the text could be routed to an application that I put on a second screen/tablet. This would allow that part of the screen to become a notification area and actually completely disappear when I've got the chat program running externally. Same can be said for all the comms and systems panels too. Just imagine a cockpit builder with far too much money putting building a full cockpit and using a couple of high end tablets - on their left to act as the comms panel, and one of the right for the systems panel. They'd be able to do things like request docking using a touch screen interface rather than through the games UI.
For the combat fighters, the systems panel could be tapped so they can quickly choose their fire groups, no cycling through them, just look over and tap their choice.

I'd suggest that rather than rush on the API front, take the time to deliver the things that people are crying out for first. From my perspective and looking at the tools that are already being written, that pretty much means the information that I started out with. System info, station info, commodity lists. Then building things up from there. Take the time to get the API right, even if that means limiting it initially.

 

[Cmdr Sharky]

I believe API's should be designed to help in all matters. Help traders trade and fighters fight. If we could get each of the systems we normally have to take our forward view away to use it would be amazing. Much like you see with more advanced flight sim setups with all of their instruments being able to be separated onto multiple individual screens. Would be cool to be able to select and control the modules on the fly as well.

There's a difference - when you're fighting, you've got to be there in the cockpit. The only resources available to you should be in the cockpit. When you're figuring out a trade route, looking at system stats, checking through your travel log, etc. those systems could be in the back of the ship, in the cabin or ship's mess.

I suppose you could rationalize it as being that little screen down between the pilot's knees that provides this added functionality. And I appreciate the idea of separating out the virtual screens into real world screens, I guess that's not much different to having a multi-screen system with head tracking. Having this external device (iPad, android tablet, etc.) being a functional part of the ship is a whole different ball game, though, if the API allows control of ship's components then it could be automated and that's not a good road to go down. I don't think that they are contemplating anything like this though.

 

[AstroZak]

When targeting a ship, being able to get a list of shield, hull, and all sub systems, with the percentage of integrity of each would be nice. That way if touchscreens or tablets were interfaced better it would allow easier and quicker targeting.

I believe that it should only show the information that you can get from the game client. The API should allow you to augment what the game is capable of. I believe that the game client does allow you to cycle through the list of sub systems - I've not used that personally. So if each system also lists the percentage, I'd have no problem with that. If however the game client does not list the percentage on the screen, then it should not be available in an API. In a game, the API should allow you greater immesion into what is already there, it should not allow you see information that other people cannot see. I choose, not to look a the sys-system screen. If I did, I would know what is there, that's my choice. but if I looked on the syssystems list and did not see a damage percent, I would not expect it to be included in an API - that gives people using the API an advantage.

 

[rudidev08]

Here to second that API should not give out data that's not available to the player.

And while lots of data is player dependent, some is universal (Galaxy map data), so I wonder if those can skip authentication part? Although auth keeps track of who's who in case of API abuse.

As for the app I'd make, it'd be simple explorer stat overview. Number of explored systems, number of neutron stars scanned, farthest scan from sol, farthest scan "vertically", etc.

Only unusual request that would help is ability to request link to assets, so if player is Ranger as explorer, JSON should give me few links (various colors and sizes) for Ranger icon to use within app.

 

[tankbob]

This has probably already been mentioned, but it would be useful to be able to access anything that the ships computer can display on the side panels with the ability to feed back inputs.

I would like to write an app that runs on my touch screen tablet to act as an additional screen, allowing me to select navigation points, view the extra information that the KWS gives you.

Additionally the ability to get my shield strength so that I can display a big warning / play a warning siren, change the colours of my joystick buttons.

 

[natte hond]

an ap that would send damage or deaths received by team-mates would be great.
and or maybe promotions made by team-mates.

think something like this would draw allot of attention.

 

[Sporadisk]

I'd like any API that allows the player to get data for the station that they are currently docked at:

• Market buy / sell prices
• Galactic average prices (if these are subject to change)
• Items in stock
• Station type
• Station galactic coordinates (for distance calculation)
• Parts available for outfitting
• Ships available via shipyard
• Station allegiance / ownership

This reflects the data that we're already manually typing into collaborative spreadsheets in order to map good trade routes and resource availability.

 

[tankbob]

No way! APIs should not give combat benefits.

The information is already available on the left view screen, it's merely asking to allow us to glance left to see that rather than using the appropriate key mapping. Combinations of Voice/headlook already achieve similar effects so why shouldn't a companion app provide it.

 

[BakerTheChef]

It would be nice if the app had the ability to find asteroid belts near me and display the contents of those asteroids. It's the only statistic that Thrudd's EliteTradingTool doesn't provide.

 

[Ben Ryder]

Please dont get side tracked with an API for a game that still is in development and still buggy and incomplete.

You're potentially building another stick to get beaten with when you could be fixing bugs and making stuff that all the players want from the game that they have paid for and was in the kick-starter.

 

[cutzer243]

Ship Status Info

- 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.

To echo this, I have been creating my own AI application similar to Voice Attack. I would love to have access to the state of ship components so that I could better tune the AI commands and responses.

• Ship Settings: Report Crimes, Turret Mode, ets.
• State of toggle-able components: hardpoints, landing gear, cargo scoop, lights, etc.
• % Throttle
• Consumables supply: fuel, ammo/weapon, heat-sinks, etc.
• Cargo Manifest

 

[tankbob]

How about having an internal fitting for the cockpit, allowing you to purchase different layouts for the cockpit, which may please some of the players wanting different information on the main screen. One of the layout packages could include an "External Interface Link" this link then provides information to the API to allow a companion app to utilize.

On top of that you could then add additional units into the ship taking up ship space that have long range price list scanners - these could operate at ranges from 100 LS to several light years. The higher class / rating versions of this could support a link to the "External Interface Link".

This price data could also become another item you could sell at a space station like exploration data. The space station could then sell it to other players. Having this feature could reduce the impact of people using public scraping server - there is incentive to gather the trade info and pass it on.

 

[Movian]

another useful output would be to determine if a target has a dock option.

and as an extension an option to bind a key to request docking from targeted station so that we can use voice commands with voice attack or similar to request docking and determine if the request was accepted or denied without having the application look to the screen on the left.

 

[Cmdr Sharky]

Please dont get side tracked with an API for a game that still is in development and still buggy and incomplete.

I hope that it will always be in development, and always incomplete, and I expect that it will always be buggy (just from personal experience of computers and games).