Discussion External API Requirements Thread

[Archvillain]

The API could allow access to a RGB value of the current ambient light in the cockpit - we can then hook this value to RGB LED lamps in the room (or simpit) so for example, the whole room will flash when laser-fire zings overhead; a low-cost way to extend the game beyond the screen and make the environment seem to fill your peripheral vision.

When you fly with a huge orange sun overhead in your canopy, you and your cockpit (the room) really are flooded in the orange light, you barrel-roll and the room darkens as the sun goes under the wing, etc.

The cockpit RGB value offers a cheap-hardware way to increase immersion, basically. Using peripheral vision can make experiences significantly more "real".

 

[sir_bacharach]

1. Owned Ships with locations and loadouts
2. Route planner that links into the game and uodates next time you log on.
3. All statistics that can be seen on the stats panel in game.
4. Various graphs such as money made from trade over time, money made from fighting over time, money made from piracy over time, money lost in fines over time. (Using the data from stats screen)
5. Browse galaxy map and system map with live info as in game.
6. Galnet news
7. Purchase outfitting for any of your ships from the stock of their related station.
8. Order a ship in your inventory to be delivered to a system and station of our choosing. (Takes time for transfer).
9. View trade info on galaxy map and enable us to buy trade info so we can plan routes in downtime.
10. View heatmaps in galaxy view, some info could include player hotspots, trade hotspots, piracy hotspots, locations where key story influences are taking place, mining hotspots.
11. View a history of your locations as a trail on galaxy map.
12. Leaderboards are a must for any companion app, competing with other players is addictive, i would put on a world leaderboard but also enable people to narrow it down to people they have on their friends lists as that's when we get really competitive you could pretty much use the stats from the stats screen with rows and columns showing the scores of you and those from friends lists. My favourite companion app hands down was call of duty elite, some great ideas on that. Weapon loadouts and stats and heat maps. Destiny has some good stats but I find has an awful user interface and it seems a bit disjointed.

Hope this helps.

Rob.

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

Oh and applying and buying new decals and paint schemes and having a 3d model of your ship to see them on.

 

[RickDangerous]

Thanks for asking! The question has two aspects: what the API should deliver and the design of an API. Other people have already provided lots of ideas for what to deliver, so I'd like to focus on the design. This is what most companies, governments, and other projects seem to screw up.

Assumptions:
* FD has data to share
* Reason for sharing is that others can denormalize it in various ways, and mash it up with other data sources
* Current state ("what systems are at War") as well as historical denormalizations ("what states have this system had over time") are useful in different ways

Therefore:
* do NOT offer a query API, but rather a state change API. Others will do the aggregation, denormalization, and end-user querying. If you make a query API, it WILL BE WRONG, no matter how you do it.

Hence:
* how to share state changes efficiently? Through a paged Atom feed, based on these ideas: https://www.peterkrantz.com/2012/publishing-open-data-api-design/

With an Atom feed (or multiple feeds for different data), FD does not have to track consumer subscriptions, can be easily scaled (Atom feeds are immutable, so put caching proxies with a load balancer in front, BOOM, instant scale), easily consumed (it's HTTP and XML, or JSON for items if you want, but please don't, because schema), new apps can catch up from beginning of history by traversing the pages (see "REST In Practice", Webber et al, ch. 7 and 8 for details!!!), and other aggregation and denormalization services can be built on top, easily. You can have one feed for all data, or split based on type (system info, market info, player info), or both.

This is the standard, scalable, simple way to do public APIs.

 

[digiminer]

commodities market data. Like Thudds

 

[Zeeman]

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

As an example, perhaps to be used in an app that, amongst other things, can also:

-Store history of last 50 (or whatever) stations visited, and the market data from that point in time.

-Store history of stations visited with black market. This way, if I come across an item I need to smuggle, at least I know the closest station with a black market...

Z...

 

[Mateodon]

I'd like to see api access to the in-game menu contents. For some examples of how this could be useful:

-Comms displayed on a smart phone.
-Contacts listed on an peripheral LCD.
-Galaxy map on a second monitor (this one's kind of a longshot).

 

[Aikanar]

This. No query-able data APIs, just state. To complement, make it client-side only, not server-side, eliminating the need to authenticate.

Therefore:
* do NOT offer a query API, but rather a state change API. Others will do the aggregation, denormalization, and end-user querying. If you make a query API, it WILL BE WRONG, no matter how you do it.

 

[The Gaming Bur]

My two cents.. just sayin

 

[Archvillain]

I'd like to see realtime ship-motion feeds, for driving motion-platforms like the RSeat simulators, but this is something that obviously should be low on the priorities!

 

[Dragonfyr]

Some great ideas, can't wait to see it finished!

I hope this will be on android!

 

[Jim Falcon]

For my own site what I'd be most interested in would be things regarding the system, station and market data at the players current location.
The system name, it's economic, political and background sim state and it's coordinates.
The station and available services.
The commodities, prices and supply/demand.

The reason for this would be for my users to do searches and plan their trades but really I'd prefer it if the in game tools were brought up to scratch. I've always felt that my site was just a stop gap while you folks worked on the game. Give us our pilots log and let us search our own data we've gathered in game and a lot of the need for an API would go away.

exactly this might be one of the reasons for this post. WHY do we need an API? So lets start a short brainstorm of the most crazy APPs. Whats about a taxi APP. You give it a route or some stations you frequently landing at and the APP search the board for (no cargo) missions on the way and automatically pick them.

Something also mentions when the API also allows actions (like pick mission, buy/sell stuff, toggle lights) the APP can do almost everything and you will become only a pilot. E.g. next step of the taxi App might be a manager who picks missions buy stuff set the course to the destination, give you a massage that you can start know. After you arrive in the system he will set course again and spam you with msg that you have to hurry and you will be fires when you will be late

 

[Jim Falcon]

(the API should not give more information than the game itself) This one is very important, especially with market data. As much as I credit Slopey for his work, there shoudn't be an automatic way to collect all market data from all Players as it's diametrically opposed to the idea of Elite. The market System definitlely needs an overhaul, but this should be done ingame (and slopey's proably the first who agrees on this). This essentialy means, that no market data should be exposed to the API!

(...)

Are you guys planning to implement a WebAPI or one hooked into the client?

I'd love to see a .NET / c++ api where I could subscribe to events (entering system, station etc) and then display all the info in real time on my second screen (and your webserver would probably love that too )!!

But an ingame solution to this, would always be better!

There will be data-mining and collecting data from many players will always give an advantage but there are ways to make it interesting again. The market data is one of the critical data here and an easy solution would be modify the prices by the player. You might get better prices when you are with the fraction allied also a high trader rang could help or maybe you are in a system where trader not that welcome and because you have enough you pay a bit extra. So making friend and finding connections would influence the prices and a slopey tool can help you find a good route but the best you have to find on you own.

I'm sure this is only a web API a client API or even a moding API would be nice but this is a MMO and it is difficult to ensure that no one can abuse the API, but I'm open for a lot even fully automated ships could be interesting

EDIT:
Note about live data. As I said, it would be nice to have a client API and live data but I assume the abuse of this API would harm the game so for me the only option is a web API also the ED-Server probably wound push any msg around but that doesn't mean we can get "live" data we need just an other approach. instate of write a request for every system if there is a conflict zone or a push if some new are available it might give a logger where you can register the 'logs' you want/need. From the logger you can get the last 100 entries with timestamps and msg/obj. It depends on the developer what they want to give us and what can be done in reasonably time/resources. E.g. a trigger on creditsChange fore every cr you get or spent there will be an entry in the log and most important it knows for what but because there can accumulate much data in short time (and the history is limited) you might also set a filter so only changes from bounty hunting will be listed.

Also there have to be restrictions. Requesting every second the status of your commander might not be necessary but more important it stresses the server also calculated data might not be given. You can collect the positions from thousands of stars - no prob but let them calculate the best route - probably not

 

[lefty1117]

I think in any case the API should be read-only, that is it shouldn't be able to be used to post data for the purposes of controlling actions within the game or otherwise making any data modifications. it should be purely to PULL data for informational purposes.

One thing I haven't seen mentioned is perhaps a way to pull a list of systems that have conflict zones, or perhaps a list of factions that are in state Civil War, a use case for this would be to display a map on a website of combat zones. A website may use that information to help direct players to the action, or arrange narrative content for roleplaying purposes, etc.

I don't know if this is on the drawing board at all, but if there was the ability to authenticate against the API using a key or something similar (like what Eve does) then that may make it possible to do things like list market prices for all systems that you've purchased trade data or visited in the last 24h; view system maps for systems that have been explored; view your ships, where they're located, your open missions (useful to check time remaining for example); and more.

 

[Robert Graham]

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.

To be honest I'd prefer something more akin to Simconnect only allowing .net languages FSUIPC even Pete himself admitted was made for Flightsim becauses ACE's didn't have a built in method to give the data that was needed at the time.

Honestly I'd like to see some way of being able to poll my personal data, My Stats as shown IN game, My Time played, My Ship Status and then the items Slopey's requested.

 

[Nicarras]

I'd like to build an app that maps out and saves data of systems/stations I visit to my local machine. So exposing the relevant data would be nice.

Things to expose

Features found at a Station
Commodity information
System Information

Would be great.

 

[Hastarin]

First please excuse me not reading the last dozen pages of posts. I'd like my initial feedback to be untainted by whatever discussion has taken place thus far.

As you can see by my signature I've written a route planning application for use with Elite Dangerous and so will be partially focussed on that.

Rather than just stating the data required please allow me to babble on a bit about the form I think the API should take as well.

API - To fit with the game universe or not?

---

You risk making data available beyond what is readily useable in the game and therefore breaking the immersion factor for those that insist on not using any crowd sourced data. There are two approaches to dealing with this. The simplest is just to allow anyone access to the data and forget about it. The other would be to integrate the API with the game universe via authentication.

To explain further. A user would authenticate with the API (via their app of choice) and would only have access to data their character has available in game.

The obvious downside of that is then policing how that data is used and if it gets made available to a crowd source solution. It would also involve policing existing style applications that scrape data from the game via OCR, etc

The advantage is you could add some for of in game explanation of the data feed. Eg the Commander is charged a monthly fee (in advance) for access to certain data via the API. Perhaps that's Galnet providing aggregated exploration data, or some market research group providing trade data beyond what the user has access to via buying Trade Data.

Now that's over with I'll cover the areas I would like to see the API cover whether it's authenticated or not.

---

General API Areas

• Navigation
• Trade
• Ship Fitout
• Friends

Navigation
Whilst trade is the most popular ATM I'll focus on Navigation first since that's what I've spent the last few weeks dealing with.

If the game were to have a better route planner (feel free to borrow my code) then this may not be needed, though it could still provide a user with added immersion via TTS, etc

Example applications

• HAST Elite Assistant
• Elite Copilot
• Elite Dangerous Central
• CMDR Club: Jump Routes

Community API efforts

• EDStarCoordinator - attempt to gather data via trilateration

Two options exist for this data.

1. Provide a dump of all 4 billion systems. Along with periodic updates for changes.
2. Provide an API to query a subset of the data (though you can expect folks to aggregate it anyway).
   I'd expect the subset to be in the form of a bounding box/sphere.

IMHO A dump with periodic updates would be simpler to implement.

Data Required for basic functions

• System Name
• System Coordinates

Bonus Data for extended functionality

• Scoopable Star
• Permit required
• Controlling Alliance
• Refuelling services available with any pad size restrictions
• Stations
  • Services
  • Pad sizes
• Bodies
  • Mineral deposits

Trade
Trade data is currently the most popular based on my observations. I'm sure one of the authors of the trade apps will have more input than myself on this, but I'll cover it in brief.

Example applications:

• Slopey's BPC Market Tool
• Quazil's Astro Analytics - uses EDDN
• RegulatedNoise - uses EDDN
• Cmdr's Log - intentionally avoids crowd sourced data!
• TradeDangerous -

Community API efforts:

• EDDN - an attempt to provide a relay for market data gathered from the game either manually or via OCR.

I'd envisage an API where you could query data for a single station. 3rd party sites would no doubt handle aggregation/relay of such data.

Data Required for basic functions
What you see in the commodity market screen!

• System name
• Station name
• Commodity Buy/Sell Demand/Supply etc

Bonus Data for extended functionality

• Stolen goods data
• Station pad sizes

Ship fitout
Example applications:

• Elite Shipyard

I'd suggest contacting the author directly if he doesn't reply to this thread.

Friends
Certain friends data is available in a log file now. Simply make that available via an authenticated API along with messaging support would allow 3rd party instant messaging.


Other
Handy thread for even more applications/community API references etc

 

[withnail]

As noted earlier, it seems to me that most of these ideas could be achieved in game with further development of the galaxy map, UI etc by Frontier.

Stuff like screensavers showing information on other players location is an example of something that could not be achieved by the game. On reflection, social media tools should also be separate, I would not want to see a twitter it Facebook icon in-game.,

 

[James Redshift]

Here's some ideas of how information can be used if it's made available to 3rd party app developers. The concepts described are simple ways to increase community involvement, encourage user generated content and create lore.

1. Player Information

• Name
• Rank
• Faction Standing
• Bounty Status
• Group Affiliation*

*Currently Groups can not be named

Application

• Player Identification
  
  
  
  An iOS/Android app could utilize the ship scanner to display community information on a player. For Example:
  
  A player scans another player's ship, lets call him "WeaselStew", the scanner information is checked with the app's online database. Since WeaselStew has been previously registered with the app, their CMDR-ID card pops up on the first player's smart device. Along with the standard information available in game, WeaselStew has customized their ID with a personal avatar. Scrolling down reveals that the last player to scan them has left a comment, "Saw him fuel scooping off of THX1138" and another person before that says they "Tried to engaged him in battle, but he escaped". The first player decides not to engage him, but leaves a message on WeaselStew's profile, "He has a new ship... it's a red Viper ".

2. Public Group Information

• Group Name*
• Group Rank
• Group Faction Standing
• Group Bounty Status

Application

• Group Profile
  
  

WeaselStew has joined the "Runaways" group. They have a profile on the app and have included their own custom emblem. When a player scans any member of Runaways, that's in the app's database, the group will show up on a separate tab with their aggregated data.

---

I hope this was constructive. The items that I've listed seem really simple and could be used in something as boring as a Leader-Board, but I wanted to describe ways the data could be used to better involve the community.

Oh, and Happy Hunting!
[video=youtube_share;ogsSQPZjW08]http://youtu.be/ogsSQPZjW08[/video]

 

[Bootsock]

Bulletin board information would be good too.

For example, check out the board at the station your ship is in to see if it's worth firing up the PC to take a mission. Alternatively, allow taking missions from the phone so that when I go to the PC I'm ready to go if there's a mission or two.

Similarly, allowing other local boards in system (or close) systems to see if it's worth going to one location more than another. Clearly missions might have been taken when you get there, but that's just part of the risk using it.

Trade data is the obvious other one which has been done to death by other people.

In short, if the companion app allowed the actions less than flying to be performed (namely stock the ship, take missions and route plan ready for firing up the PC client), it would be terrific (so long as it supported Windows phone and Android!)

 

[zeeZ]

Client-side API - the DDF player log thread is a great starting point here. Write that information to a text file or SQLite database and we'll be able to handle most requests in this thread. A protocol to interact with the game itself would be useful too (e.g. injecting text messages into the game or grabbing information that could later be rendered into a third-person screenshot), but for me that's a little way down the wish list.

Keep real time data in shared memory. An example would be mumble link that allows games to share avatar position for 3D audio in mumble. Guild Wars 2 for example also shares character name, server IP, current map and a few other things like that. It's not as easy as reading a text file or sqlite database, but I loathe seeing constant disk writes for those things