Discussion External API Requirements Thread

[CMDR Kekkon]

Simply speaking in terms of functionality, I would like the following:

• A fully functioning galaxy map (with synchronization to your current position in the game)
• Access to commodity market for the station you're currently docked at
• Friends/groups/wings management
• System and CMDR statistics (as in game)
• Ship and loadout viewer
• Ability send text messages from the app to CMDRs

To dive into the synchronised galaxy/system map:

Think Assassin's creed companion app. I want to be able to use the map on my Surface Pro 3 to calculate the route and send it to the game automatically. When I am not currently playing the route set on the app synchronizes to the game as soon as the universe is loaded.

You should have full access to the commodity market for the station you're docked at, this includes buying/selling goods.

Friends/groups/wings management is self explanatory I think.

The statistics are nice. You can either see how a war is progressing or show off your total assets to your friends. Ditto for the ship and loadout viewer. The loadout viewer can be a simple table, but the ship viewer should be a correct view of your ship in a hangar. With a free camera you can pan with touch events.

That being said, I am not a developer. I simply would like one app to provide all this functionality. I am willing to pay up to € 5 for a stable, well performing app that does all of this. Preferable a Windows Store app that works well on a Surface Pro 3.

 

[conradcn]

Oculus help

Here's a slightly unconventional one, but is there any way we could interact with a screen inside the ship? Supercruise can get boring, and it's a pain to leave the Rift to do other things while playing. I can think of a couple things I would do with that (An in-ship GalNet reader, in-universe text-based adventures, or a little asteroids game, to name a few).

 

[QziQza]

I'd certainly like the ability to utilise my tablet directly as an interface for all my ui menu's - comms, chat, status etc and definately for trading and map routing, would seriously help my immersion. not to mention very useful while refilling the coffee pot or on extended ablution breaks.. pilots gotta do what a pilots gotta do.

 

[StayFrosty]

As others have asked, I'd like to know whether we're talking about a hook into the game, or a web API, not to mention, the kind of response time that's to be expected from this API.

I'm myself kinda struggling to see what kind of interesting app could be made, and you're right to ask to use cases for that because it really takes one to even justify it, and I just don't see it. Most of what I think about, and what I'm seeing so far in this thread, are proposals for apps that aim to fix what's broken, to add what's missing, to simplify what's complex, but that's not really the role of an app to me, it's the game itself that needs to be improved.

But aside from routing, jump range calculation, friend lists and docking pad size considerations that stem from broken features, the important point seems to be the simplification and addition of features, though whether they're "missing", "complex" or not could be debatable. And that sounds problematic to me. Because I have plenty great ideas about that.

There's the obvious player log, that would list visited systems and stations, and the various events that occurred, and which I hope to see implemented in the game, but then, there are plenty other things that could be really cool, like a way for wings teams to tag targets and share information, which would allow access to the list of local targets, or a "criminal sighting" app, allowing people to locate player criminals so bounty hunters can find them easily, or an app helping players share trade data and trade more efficiently, or an app helping people to find stations in unexplored systems...

All of that is really cool, but there are two important and worrying problems:

• Those are very powerful tools
• They're part of an app, not the game

This will naturally split the community in many tiny parts, depending on which apps they use, and that gives unfair advantages over those that don't use them. It seems to me that anything that could allow to access data in realtime, and crowdsource said data, is a huge problem. Any kind of data you can access should be no more than what the game itself can give anyone easily and readily.
And I can see plenty ways this could be exploited, and the fragmentation of the community is nothing to take lightly. I'm definitely against allowing anyone to access data others can't, and affecting in with things that happen out of the game- either anyone can do it, or no one should.

Let's not fool ourselves, the crowdsourcing and sharing of game data is bound to happen, and it already began, but better not facilitate it- if anything, it needs to be tackled by making it into a feature so anyone can benefit from it. But most importantly, it needs to remain a game, not turn into a productivity simulator.

 

[dwengo]

great

I build APIs for "BIG DATA" companies, its always great to see a company pro active in building an API.

I think some people are forgetting a few things however.

API's that provide "near real time" information are incredibly heavy for the server. I've seen alot of API requests that provide data on minuscule things, and things that you can't really do anything with...

Some questions:
Will this be a restful api?

What will your response be? XML? JSON? I'm really hoping you'll expose the response schema so we can see what objects we will get back.

I'm soo excited.

The following things are items i've been wanting to build in a "Would be good if i could" sense.


Resources:

News:
Galnet news, with the ability to filter by news type. For example if I fancy dropping in on a conflict zone, then the API "Galnet" resource would have a "listNews" action and some filter queries, like newsType, dateFrom ect.

Usages:
I was planning on building a push notification app that will notify you of news that you want in on. depending on how far away you are from where its occuring.

Use Case:

1. I'm keen on selling some slaves. I open up the app and set the newsType to trade. I then recieve a notification alerting me to trade news.
2. Website that list Galnet news, can filter by ect.

Next

Personal Trade Resource:
Now this is more personal and would depend on whether you store this information in the db.
a personal trade assistant that records your trades from, to and profit. that way you can build up your own personal trade routes, prices fluctuate obviously, but I could then take this data and the more different trades you do the more I can say: Well hey, your trading with this in this area, but in this other port you visit, they also wants that commodity and will pay more.

Now this one would be harder to implement given RESTful nature, I'd have to poll periodically to get whats currently in the users cargo holds, where they bought it from and -when they sell it- how much he sold it for.

Use case:

1. User goes about his normal trade routes, APP (tablet, phone) makes periodic requests to the server to get user information last(current) port user is/was in, items in cargo hold, user money. The user then goes to a port sells cargo. The APP sends the same request, stores the changes on localDb. The APP doesn't need to poll very often given how long it takes to get from port to port, it just needs to check that when it next polls, the current/last port has changed, the cargo holds is empty/are has changed, and there's a change in amount of money the user has. So its essentially a request for any changes to userstate.

The potential for this however makes me giddy

 

[randeroo]

Something a little bit different....
I quite like the Galnet news - seeing which senator is doing what and where etc. However, the problem I have is knowing who is who and which side they are on - I don't have much time to play (maybe once or twice a week) so find it hard to track who the senators are etc. I think it would be useful to have some way of seeing a 'major players' within the empire and federation - sort of like a family tree - maybe the list is ordered by their current influence. Then maybe you can select one of these and it gives you the latest information about what they are doing (which system they are attacking/defending). And still have another way to view the news in general time-line order. Maybe it can show you how away each of the warring systems is from your current position.

Also....
Ideally I'd like to add some notes next to a planet/ space station on the map - e.g. Black market here. Problem I have at the moment is there are sooo many systems that I forget where I've been and what is available at that system. If smuggling then quite often I know there is a nearby station with a black market but can't remember where it is. But maybe an app would help solve this if this sort of data was automatically collected (in game) for each system you visited. Then the app would show you where you've been and what is available (like a log) but only showing you information as known at that time (e.g. if there was a black market there when you last visited but it has since gone then you wouldn't know and so it would show in the app that 'as of 5 days ago there was a black market here'). Then if this was searchable - e.g. where is the nearest black market that I know about - or where is the nearest station selling an Anaconda. This is the sort of information that can be useful (to me) in game. It is information that was known by the player so if it could be retrieved without the player having to record it all themselves then that would be great. However I don't agree with the ability to find out real time information about planets/ systems/ stations that you are not currently in.

Also...
Ability to see your friends list - who is online/offline and how far away they are. Ability to text-chat to them as well.

So, any APIs that would give that sort of information would be great I think. Thanks.

 

[Burnzoire]

lighting data

I have a slightly odd use case. I want to be able to send Elite: Dangerous lighting information to Philips Hue lights. For that, I'd need to know the player's proximity and orientation to a star, and use the star's data to illuminate the Philips Hue lights. Other light sources might include the red proximity alert, gun fire, nearby ship destruction, friendship drive jumping, etc. Not sure if this is a reasonable thing to achieve - alternatively I could just use an external app that takes the average color of the video output and sends that to the lights instead (message me if any .NET devs are interested).

 

[QBiG1970]

I would like to get an App for Windows Phone 8.1
I understand there is an app for Google as well for iPhones...

Why not for WP8.1 and have it a extra screen with game-info mentioned above..

my2cr

 

[ebnewt]

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

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

Couldn't agree with you more. I wrote pretty much this exact list (with some unlikely additions).

 

[xetura]

It would be nice to have the ship information(HUD) be able to display on a tablet or phone. Things like:
1.) Ammo
2.) Speed
3.) Cargo scoop target
4.) Landing pad target
5.) System Map
6.) Galaxy Map
7.) Loadout Menu

Many of these have been mentioned already, but I thought I'd just throw in my two cents.

 

[Maximus]

Has anyone built a continous microphone parser (via google stt)? Like you mentioned in the last paragraph?

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.

 

[Wurz]

Eerm, so you're now shipping out 3rd party apps because you can't be bothered to make them work in game? Or am I wrong?

 

[DirtGambit]

as a user id like to be able to view my profile, check out a specific market, provide functionality to allow me to raise my landing gear and enter FSD from pressing a button on my app, similar stuff has been done with FSX.

as a developer id like to see database cloud access, a good webapi, please stay away from xml, JSON is much better.

Im not worried about putting the social aspect into the api, that can be done app side.

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

once the api is done ill be working on a windows 8.1 app, ive developed many apps for windows desktop and windows phone.

 

[E-Rock]

I have my own market tool and this is the data I would want out of an API and what I would want to do with it. I do not want people to be able to dump market data remotely. I do want to be able to accurately get the data for a station where I'm docked. That way you need to go there to get the data, but it isn't such a grind to store it.

Commodity Information - a grid dump of what's on the screen. We can do it with OCR, but I don't see why I shouldn't be able to make an authenticated API call. Again, not for remote markets, but where I am.

Station Data - Per system, from anywhere - give us the data on the system map screen. When docked - does it have a black market, what ships it sells, what modules it sells, current distance from Sun.

 

[Tovrin]

The market stuff has already been mentioned.

To add to that, I'd like to know where I've been on the star chart. Presumably, that means:

* System Name
* System Galactic XYZ coords (in case someone is game enough to plot this on a map)
* Time Jumped In
* Time Jumped Out
* Station Name
* Time Station Docked
* Time Station Left

One thing I would note is that I wouldn't want to see an external tool affect anything in game. Query only? Yes.

Another thing I'd like to see is that it's not a direct database query of ED market values, but only showing the market that YOU'RE currently at. By that I mean, you can't see other markets from the tool. Sure that means that market data could be crowd sourced, but it's only as good as the last person there. We still should have SOME guesswork.

 

[Meeze]

There is only one major thing I'd encourage you to offer as, for want of a better term, an "API":

Combat/Ship log a-la World of Warcraft's combat log. Ask your studio's resident WoW raider and they'll understand the spec immediately.

In short, a simple, external, free/formatted text feed of all damage and important events. For example, even without combat, log my trade run jumps, log what i bought, and where, and for how much. Log what mission i accepted and so on. Log the galactic coordinates of the primary star in each system I visit on jumping in.

Ideally realtime but if not, a simple flushed text file is fine. It's pure raw data in a single outbound feed from the game world. People can build on it what they want. Collated traffic patterns, galactic heatmaps, trade route analysis etc? All possible with a simple low effort feed from you. There are many external tools and systems which leverage this sort of functionality on other games (google worldoflogs, as a noob i can't paste a link here) and I suspect many people would love to be able to parse this and turn it into various external feeds.

Data nerds will love it. Even the most introductory programmer will be able to load a text file and do string manipulation on it. It's immensely powerful for such a low-hanging fruit.

Cheers.

 

[redoctober]

I just want a flag, or boolean, that indicates whether the system was visited or not by the current user/player. That little piece of information alone could lead to some very cool mods!

 

[Andrew Sayers]

Posting with mod hat off and have a lot to get through - apologies for the essay

Real-world projects

I have three projects that could provide some inspiration for a public ED API. They're all rather tangential, but might give you some ideas.

• I maintain an index of Elite-related content, which gathers information from many sources and displays it in a common format. Sites like this could be a good way to publicise information about game events in real-time. For example, say Emperor Duval died and his funeral procession was touring the Empire - sites like this could keep people updated about his journey and any events that occurred along the way.
• I maintain a browser extension to improve people's forum experience (which I've previously forgotten to announce in the public forums). This mostly just smooths out the rough edges with vBulletin, but could be used to integrate Elite: Dangerous with the wider world. For example, it could detect a URL like elite://CMDR/Michael%20Brookes and use a web API to send a friend request to that commander name.
• Other people have mentioned a desire to write diary-type apps. I waste a few weekends a year playing FreeCiv, and like to use a save-game analyser to look back on my games after I finish them. I'll bare my soul a little and show you the results of a game from some time ago and a more recent game. The graphs remind me both of the story that played out in my head and the tactics I tried (and often failed) to use in the engine. Like FreeCiv, I'd want an Elite: Dangerous API to provide raw information about my commander (e.g. reputation with different factions over time) that another app could visualise and I could look back on (e.g. my character's sphere of influence expanding across space).

And since wolverine2710 is too polite to mention it, you might want to check out the Complete list of all third party tools, spreadsheets, manuals and other data sources.

---

What type of API?

As others have said, a client API and a server API are two different beasts. Both very useful, but in very different ways.

Server-side API - the official client must use an API to talk to the server, so I would strongly advise against writing a redundant second API for community developers. The end result will be a well-documented public API where vulnerabilities are discovered by the white-hat community and disclosed responsibly, and a poorly-documented private API where the black-hat community distribute cracks for months before you hear about them. Instead, spend that time documenting the existing API and figuring out ways to secure it against attack. In the short-term, that might might be as simple as putting a proxy server in front of the real servers and exposing a safe subset of the full API.

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.

Server-side protocol - I'd like to create mashups using the server API, such as the Elite URL example above. Sadly, the only solution that allows all modern browsers to access data from different domains is JSONP over HTTP. Other people have mentioned the WebSocket standard, which isn't supported by IE8 (very common browser, default in Windows 7, mainstream support ended on Tuesday) or IE9 (supported but not that widely used) - this is worth investigating if you want to support complex web apps and don't mind asking people to install a modern browser. It's increasingly common for mobile apps to be written as web pages with thin platform-specific frontends, so a complex WebSocket-based solution might be particularly interesting when you restart work on the Android and Windows Phone Companion App.

Client-side protocol - I'd prefer HTTP (so I could write a web-based mobile app to rotate my ship and grab a screenshot "photo" of where it was looking), but to be honest it's probably better to just write whatever's easiest. So long as it's well-documented, it shouldn't take us that long to write proxy servers that translate the ED protocol to HTTP, ZeroMQ, COM, or whatever protocol is trendy tomorrow.

---

Relationship with the community

Several people have talked about how community projects would relate to Frontier's work. I don't think we can answer this now, but here are some big questions:

• How will Frontier deal with projects that are controversial or damage your idea of "fun" in the game? For example, could an aimbot be banned if someone managed to write one?
• To what degree is this about giving Frontier a bazaar of community projects to use as inspiration? For example, would you want to lift ideas from Slopey's tool?
• How official would you like community tools to look? For example, would you want to publish a style guide (colour schemes, assets, interface issues etc.) for people to use?
• What attitude would you take to commercial projects? For example, would you want a cut of the €5 app CMDR Kekkon wants to buy?

 

[Aikanar]

Not to my knowledge, unfortunately. I imagine it would be easy to use bindings to invoke a MS Speech API STT session, though.

Has anyone built a continous microphone parser (via google stt)? Like you mentioned in the last paragraph?

 

[Aequitatis]

What an excellent opportunity to be involved. I'm a Windows Phone, Windows and web developer myself.

My ideal app companion would effectively work as one of the side screens in the game. So:

• Contacts local to you are important with the appropriate accompanying data such as distance and perhaps relative vector.
• Ship subsystem report
• Target ship subsystems and damage / shield display
• Navigation list (as a side note, a pseudo 3d system map would be useful to show relative positions of items in the system as if it were a 2D plane).
• Ability to add sticky targets - so you can keep your navigation target, combat target and 'curiosity' targets pinned for easy access.
• I understand that having saved station market data is something you are dubious about - but current galactic averages of all goods and perhaps current system goods legality would be useful in a comprehensive list without breaking any mechanic - available when the game is not being played as well.
• Galactic news, obviously ;-).
• Communications with friends and wings.
• A list of saved players - so you can remember who that pirate was that attacked you or that hunter to avoid.

Many of the other posts have said pretty much everything else I can think of at this stage.