Discussion External API Requirements Thread

Status
Thread Closed: Not open for further replies.
This excites me! APIs are not only awesome to me in how they expand the gaming experience, but they are also something I am passionate about professionally, as I run the Developer Relations team for the Riot API for League of Legends. I'm sort of "reserving" this comment so I can take some time to sit down and really think through this a bit more and come back to you guys in a day or two with a Big Ole List of feedback!
 
Expected to find an endless wall of requests for extreme personal gain based numbercrunching, was not disappointed.

Apart from maximising your wallets, please all consider the benefits of expanding the game's universe beyond the limits of the executable. Rather than throwing out an endless stream of spreadsheet friendly min/max data, it could be put to much better use providing dynamic overview information such as highest bounties in the region/galaxy, number of players online by region or time of day, better news updates (the Galnet RSS feed is such a structural disaster I don't think the word RSS should be used within ten miles of it) and enriching overview information that is useful in more contexts than you taping a bespoke Android tablet to the arm of your chair to give you constantly updating profit values for the 521st instance of your captivating solo mode rare run.
 
I'd like to see the API data to not be risk free, it should require Commander activity to maintain it.

For example the API should _not_ give information on systems that have not been explored or stations that have not been visited. Astronomical objects should have incomplete data if they've not been scanned.

Station distance from Nav point, this will change depending on how elliptical the station (or it's parent body) orbit is. This means that depending on how variable an orbit is, the accuracy of this number may vary wildly.
 
Local API via interprocess communication

  • API Example
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574%28v=vs.85%29.aspx​

  • Why?
A cleaner way to receive in-game information than file/log scrapping.​

  • Where?
Mapped File, local Named Pipes, local UDP queries.​

  • Usage examples
    [*=1]Application A wants to read ship telemetry; connects to local Named Pipe and requests the information directly to the client. Client replies with JSON payload.
    [*=1]Application B wants to receive notifications when the ships enter a system. It emits a request to notify to the client. The client emits a UPD packet to the local application every time the current system changes.


Inbound/Outbound audio-video streaming


  • API Example
https://developers.google.com/youtube/v3/live/​

  • Why?
It would allow for immersive device users (e.g. Oculus Rift) to access external media content.​

  • Where?
Put the screen between the pilot's legs to good use.​

  • Usage examples
    • Video comms between CMRDs. Push-to-Talk would start video broadcast from CMDR A to B. Downsampling (for performance) and post-processing (for effects - ex. transmission noise, background replacement) done on client to keep server processing low - mostly routing.
    • Non-targeted, deep-space comms. Push-to-talk would start a faint, noise-ridden, low-res broadcast. Uses Emergency Comm Battery Cell. Only one each 10 mins allowed per CMDR. Appears as targetable marker on the hud.
    • Voice Command integration. External speech-to-text app parses this content: "Ship, google for 'where to buy class two gimbaled burst lasers'" and finds a video, starts to play it on the in-game screen, no server processing needed.
 
Last edited:
It looks like many of us are calling for the same thing. The current iOS App gives us accurate Market data at the station we're docked at and Shipyard access. That's a fantastic start, especially now that GalNet is web accessible.

Like everyone else, some variation of Galactic Map data and possibly route planning would be great, but definitely access to System View via a tablet or phone would be awesome. If this could even be used while playing the game, another bonus: the goal there being that looking at the Map wouldn't disconnect you from flying your ship. Limiting this to System View or a 2D or 100Ly range in some way is acceptable, as that Galactic Map data is probably massive, and I wouldn't want to accidentally trigger that over LTE. Having access to the System View would also cover the bases for standard landing pad size, facilities available, and faction information.

Another wonderful addition would be a means to bookmark locations or add notes to your galaxy map, via the tablet. Essentially adding a feature that would let us update/keep/maintain a Commander's Log. At best it could function like a StickiesDatabase that would leave 5-10 line notes for each entry, at worst, just a link to a TextFile that auto-pastes the Date and Location of each entry. That isn't really a call for data, but if we get an API version of the Galactic or even System Map, having a means to add a bookmark that would be both visible from the App and within the Game itself would be wonderful.
 
What I really wanted to see is an API on the game itself.

The ability to trigger control impulses from an external application via quick HTTP calls, and receive data from it in return.

I would love the ability to write scripts for something like VoiceAttack that let you plot courses with your voice ; which would require the app report a list of systems that were in jump range.

An API on the game that let you trigger controls, such as the ones on side panels, would be wonderful too.

Before all this talk of improving the in-game course plotting to 1000 LY what I also wanted was cartesian coordinates for stars ; I wanted to write my own course plotting algorithm (tied in with fuel consumption and the increase in jump range that causes to try and win a BuckyBall run... lots of people are also asking for station distance from star and I reckon that ties in with that desire.)
 
Desired API methods/functions for my apps

I have a few ideas for apps that I would like to develop for iOS, and the external API functions these would call for would likely help many others in their endeavors. Many might be a little too hopeful.... Most of which would call for player credentials and authentication. This is all in pseudo php using a REST/Oauth interface. Could be implemented in other ways.

First and most importantly is a basic galaxy map/route planner which would call for these basic functions:

connection= new connection(playerAuthenticationStringArray); //
system = connection->get('system'); //System data transparent to current cmdr (coordinates, government, allegiance, star type, stations (and size), trade data if visited/bought)
location = connection->get('location'); //Get current system name
jumpRange = connection->get('jumpRange'); //Get jump range
fuelRange = connection->Get('fuelRange'); //Get current fuel range
distance = connection->get('distance', system1, system2); //Convenience method, not necessary (provided galaxy data is made available and local to app)
connection->post('setroute', routeStringArray); //Plot this rout for current commander

Note that it would be helpful to have a galaxy map file in whatever format that has all of the system names and coordinates.

I don't believe this system would be open to exploitation. Even if you attempted to plot strange routes the game engine prevents you from making those jumps. The simplicity of this of course depends on the current implementation of navigation mechanics. If too difficult, alternatively you could implement:

connection->post('setDestinationTarget', system); //Set the ships destination target for jumping


Another app idea is a privateer app which would track war zones and most wanted players. I'm not sure how much you could expose, but it would be nice to be able to do.

playerArray = connection->get('wantedFederation'); //String pairs of (online?) most wanted federation players and their bounty
system = connection->get(wantedPlayer); //This is questionable, Seeing the last system where they were scanned or charged with additional bounty in? Or some variation
systemArray = connection->get('FederationWarZones'); //List of current federation war zones
 
OAuth2
It would be golden if there was some way of having people login their cmdrs, and oauth2 is like made for this. This allows to have people link their game accounts to websites (comment with your character, create a profile with your character) and avoids the possibility of impersonation in other cases.[/QUOTE]


SO MUCH!
 
Thinking about what I would like on the app would give clues about what needs to be exposed in an api. I basically want to be able to sit on my tablet and be able to do the none flight elements. So I can sit on the sofa with my tablet planning what I do when I play.

1) The galaxy map and its related data as well as every system known to my commander so I could plan my route from the current location and upload to the main game (could be limited to the bubble available to the route planner). ie Jump to x system, fly to x station. (for an explorer obviously just system jumps would generally be available in most systems).
2) A commanders log, kills,deaths, where visited, date and time.
3) My current ships their load outs and location.
4) Current information known by my commander about what other ships are available to purchase and their possible load outs.
5) If docked at a station the current station information about cargos/outfitting
5) My commander stats/rankings

As an aside for a start mode (maybe Ironman) I think it would be great to have the galaxy unexplored from your starting position. You have to discover systems and fly to them. I think that would make exploring significantly more challenging.
 
Expected to find an endless wall of requests for extreme personal gain based numbercrunching, was not disappointed.

Agreed, *however* I think an approach that allows a certain amount of crowdsourced trade/bounty/mining information would make sense... Say, prices good for 24 hour period beginning when the last CMDR left -- then the data is considered old and deleted.
 
LIFX for ambient lighting

Have you heard of LIFX? I am not allowed to post a link yet because new account, just search for LIFX.

It's a bluetooth-controller light bulb, full RGB, variable intensity. I have one in my game room and it's a bit of a gimmick right now. But what would be amazing is if games supported ambient lighting using LIFX. You could change the color of the light based on what kind of star you are near, intensity on how close you are. Choose another intensity and color for station interiors. When another ship passes close by use the light to enhance the drive flare effect. When you are hit by weapon fire use the light to increase the sensation of impact.

There are so many parts of the game you could enhance with addressable room lighting!
 
* ship data
* * cargo scoop state
* * landing gear state
* * stealth run state
* * set velocity, actual speed
* * heading data
* * shield and hull data
* * current target with applicable stats including subsystem integrity
* * yaw, pitch, roll, thrust amounts
* * collision warnings
* * detailed ship damage data
* * present cargo

Why this is needed: One of the things I want to do is design plugins for various MFD displays and warning/status light banks to allow for cockpit construction. I'd also like to connect lighting and possibly even a smoke machine (yeah, it's overboard, but fun!) to fire at specific events. Presently this is restricted to sending keystrokes in to the game with no feedback.

Why it could be a problem: Having this data can and almost certainly will lead to botting. In my opinion you will always have "credit farmers" regardless of whether or not elite sells currency through the store. No matter how cheap you make it, someone will undercut you.

* Station data
* * Known market data for stations being visited, or where data has been purchased
* * Black market availability
* * Ship and equipment availability
* * Station pad sizes

Why this is needed: Presently people are going about getting market data any way they can. This has lead to people doing everything from memory scraping to screen OCR, to straight up manual entry. People will automate finding good routes regardless of what blocks are put in place to discourage it. It makes it easier for the programmers to make tools to support the game. Tools they'll make anyway.

Why it could be a problem: These tools almost certainly trivialize the entire trading portion of the game - a portion of the game which is presently more profitable and scalable than any other profession.

API technical considerations:

I see this falling under 3 different categories:

1) a stream for event data changes and state queries (custom protocol backed by TCP?)
2) a store for non-event data that doesn't change often (market data, system data, station data) (local sqlite tables?)
3) an optional query interface (lots of ways to do this, stateless is probably best, basic HTTP/Rest/JSON would likely be an easyish way to go and would make it very accessible to people with web language knowledge)
 
Last edited:
In general, I think it's safe to assume that any information that is directly available to the player in-game ought to also be available via the API, and until it is, developers are going to keeping asking for it. But conversely, you should be hesitant to provide anything via API that is not directly visible in-game, because third-party tools should always be a matter of preference and convenience, without any material advantage over people who play the game by itself.

For some specific examples:
  • Since the player can see the name and location of every star in the galaxy via the in-game galaxy map, that should also be available via API (or static data dump). At a minimum, there should be methods to query a system's coordinates by name, and to get all systems and coordinates within a given voxel of space; i.e. GetSystemsInSector(3,5,9) could return every system inside the cube (30,50,90) to (40,60,100).
  • But, since the player cannot normally see star types, orbital bodies or other system data (without exploring or buying it), that information should not be available via API.
  • Since the player can see the buy/sell prices and supply/demand levels of all commodities at their current station, that should also be available via API.
  • But again, since the player cannot see detailed trade data for other stations, it should *only* be available via API for their current station (which would necessitate some kind of API authentication to verify the player's location, which may have to come later).
  • Since the player can see their ship's status in their various cockpit panels (installed modules, current cargo, cargo capacity, current fuel, fuel capacity, hardpoint status, landing gear/cargo scoop status, module power status and priority, etc), all of this should also be available via API.

Besides these read-only examples, there are also a few things that would be nice to be able to control via API (but again, this would necessitate careful authentication; CCP's API keys for EVE are a great example of how to do this in a relatively flexible and secure way). When considering whether to let the API take actions in the game on behalf of the player, the guideline should be whether such automation would give an advantage in PVP combat. For example:
  • The API should not be able to change ship or subsystem targeting, weapon groups, power priorities, power distributor levels, etc. since these functions are things pilots must manage in real-time during combat, so automating them would give a material combat advantage.
  • However, the API could safely be allowed to lay in a (multi-jump) navigation route, because that's a non-combat function that the player could still do manually, it would just be convenient to have it automated in some cases.
 
  • But, since the player cannot normally see star types, orbital bodies or other system data (without exploring or buying it), that information should not be available via API.
  • Since the player can see the buy/sell prices and supply/demand levels of all commodities at their current station, that should also be available via API.
  • But again, since the player cannot see detailed trade data for other stations, it should *only* be available via API for their current station (which would necessitate some kind of API authentication to verify the player's location, which may have to come later).


Ok, I agree. However, you should at least be able to view trade info / system data for systems you have visited in the last 24 hours... the data may be slightly out of date, but surely an 'in game' computer can hold that much info without being considered an AI.
 
Ok, I agree. However, you should at least be able to view trade info / system data for systems you have visited in the last 24 hours... the data may be slightly out of date, but surely an 'in game' computer can hold that much info without being considered an AI.
If Frontier wanted to support that, sure -- my thinking was that it would just be extra work for them to store every place you've been in the last 24 hours just to decide whether you're still allowed to see it now. Much easier to only ever let you see what you can see right now, and if your API-using app wants to store the stuff you've seen before, that's up to you.
 
If Frontier wanted to support that, sure -- my thinking was that it would just be extra work for them to store every place you've been in the last 24 hours just to decide whether you're still allowed to see it now. Much easier to only ever let you see what you can see right now, and if your API-using app wants to store the stuff you've seen before, that's up to you.

Nice! I'm with you.
 
I guess something like OAuth might open up not just apps to development, but websites too. I'm sure there are players out there who would like to write about their experiences in-game, and this would allow them to log in and post as their commander rather than creating separate accounts. Or make an out-of-game interface for GalNet submissions. I guess it's something that Frontier will need to carefully control as any app or website that allows you to login using your game credentials would probably need to be sanctioned.
 
Here is what I would personally like to build apps for. I will break it down into categories and give you an example of how I would use the data. These are just rough at this point since I'm at work but more detail can be provided upon request. The field names are just comma delimited to save space.

Market Data
1. Trade route finders: We have all seen them. I even wrote something to speed up the entry into one. The basics of this tool are simple. Type in two station names and it will show you the commodity with the highest profit margin. You can also use it to find a specific commodity at a station near you. This is useful for those missions where you need to bring 2 slaves back and you have no idea where to find slaves.
Direct Required Data: Commodity Name, Buy price, Sell Price, Demand, Supply, System, Station
Secondary required data: System x,y,z positions
"Nice-to-have" data: Station LS distance from the star, Station factions and their influence, station type (outpost, orbital, etc), Economy, System population
2. Trading activity/Economic Boom heat map: The current galaxy map can show some basic trading lines, but the data only reflects NPCs and doesn't scale based on activity. I want to create a galaxy map that will show where systems are experiencing economic booms due to large amounts of player trading. No lines showing routes, just overlaid color blobs on the stars. The larger the blob the bigger the economic boom this system is experiencing. Color coding to indicate what type of trading is driving this boom would be nice, e.g. Metals, Technology, Drugs, etc.
Why is this useful? It will make a nice circle of space life. Trader finds good route, does lots of trades, tell friends, more people trade. System experiences economic boom. Pirates get wind, start looting traders. Bounty hunters get wind, start hunting pirates. Traders get tired of pirates and combat, move to new system, circle starts again. This will force people to expand and explore rather than get cushy in the core systems. You will get a nice rotation of activity across the galaxy.
Direct Required Data: Faction name, System name, Commodity type, Economic boom status (preferably a numeric scale 0.1 to 1.0 or something. 1.0 being a system that is in the highest level of economic boom.)
"Nice-to-have" data: System government
Player Stats
1. Killboard: A web based tool to view player combat record aggregates. System kill leaders. Region leaders, Faction leaders, Ship type leaders, Big game hunter (kills of ships that outweigh you), Murder leaders, Bounty collection leaders, System Authority kill leader, etc
Direct Required Data: Player name, system where kill occurred, region where kill occurred, faction of system where and when kill occurred, ship used during kill, ship type killed, was killed ship wanted
2. Traderboard: Web based tool to view aggregate player trade stats. Best system Trader, Region trader, Faction trader, ship type trader, rare trader, best smuggler, etc
Direct Required Data: self explanatory
3. Explorerboard: Blah blah. web tool.,. you get it. Most explored systems, Most black holes found, Most neutron stars, Farthest total distance travel
Direct Required Data: self explanatory
4. Darwin Awards: Most times running out of fuel, Most deaths inside a station, most deaths from ship to ship collision ,Most deaths from overheating near a star, Asteroid collisions, Deaths from cockpit breach aka space popsicle.
Faction Stats
1. Another web site to show certain faction based information such as: How many systems currently owned by the federation, alliance, empire. How many combats zones per faction, Count of stations gained or lost over a time frame,commodities produced per faction e.g Federation controlled stations produce 5.5 billion tons of Palladium a day while Empire produces 3.9 billion. We could have some nice fancy graphs and all.
Direct Required Data: TBD
 
Last edited:
I'm not sure how detailed the physics are, but I'd love to see access to in-game ship state information:


  • Acceleration and velocity in all directions, Surge/Sway/Heave
  • Pitch,Roll,Yaw angles
  • Perceived gravity/acceleration forces on the pilot

My objective is motion simulators.
As an Oculus Rift user, the bass shaker I have in my seat is great, but it would be even better to be able to feel myself pushed back into my seat when I boost.

Some form of access to the in-game Comms would be great too, I'd like to be able to send other CMDRs text messages via voice attack or something to that effect.
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom