Discussion External API Requirements Thread

Thread Closed: Not open for further replies.
Hi all
We already support motion simulation on xsimulator.net.
You can see a test setup here:
[video=youtube_share;1kkFRvCfJf8]http://youtu.be/1kkFRvCfJf8[/video] (Thanks to Wanegain for sharing!)
The data we extract from the simulation is pitch, roll and yaw speed and surge, sway and heave acceleration.
The plugin must be updated for each new releas of the simulation.

Therefore having this data available in the API would make my life much easier
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.


+1 for access to flight data for home cockpit builders would be fantastic. Would allow users to build retro style cockpits with analogue gauges for displaying temp speed etc or glass displays running on separate tablets or multi-monitors over FTP.
Read/write access to all controls, switches etc thru a dll or similar would be fantastic.

Currently building a submarine control system for Silent Hunter 3 that is based around custom built arduino systems.


The most important would be that the API can be accessed with some sort of token and not require the username/password from this site or the game. I do not want 3rd party apps stealing user credentials. So we would create a token on this site and provide this to the 3rd party tool... and be able to revoke the token. (Or something similar.)
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.

I agree; Information about other players should be limited/restricted to CMDRS on your friendslist.
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!


Hi Michael,

I would be interested in seeing coordinates used to create a schematic map of local systems, the equivalent of the London tube map to conflate attainable distances, plus the usual trade (or other) parameters.

Best regards

The most important would be that the API can be accessed with some sort of token and not require the username/password from this site or the game. I do not want 3rd party apps stealing user credentials. So we would create a token on this site and provide this to the 3rd party tool... and be able to revoke the token. (Or something similar.)

I agree; Information about other players should be limited/restricted to CMDRS on your friendslist.

I do hope that both Fed Devs involved make this the minimum security standard for API developers... As with most thing the most harmless and seemingly handy app will have those looking to exploit security weakness to have their Lulz...
I still haven't seen anything to indicate that this API will have anything to do with their servers. I don't see why it can't all run locally via the game client.
Someone else might have already suggested this, i haven't read the entire thread yet, but why not make it two API's? One api being a JSON REST API, giving access to star system locations, and make user information with account authentication. Then make a second real-time API for things like custom controllers, force feedback systems, home-made cockpits and stuff like that.
personally i have a few ideas which could really use a REST api, and also some ideas for different types of navigation tools which might need a combination or REST API data and some real-time data.

Also as a separate idea, it would be really interesting to have some sort of onboard programmable flight computer, allowing you to customize the control system in something like LUA or Python or something. I don't think that would count as part of the API though. I would love to be able to directly control individual RCS jets with a programmable flight computer, but i think thats out of scope for now.
Probably buried elsewhere in the 30 pages of this thread. But it would be great to interrogate an API to get the aspect of the cockpit panels i.e. the tab and the line that currently has focus and if it is 'toggle-able' the state of the toggle. This would be great to allow tools like Voice Attack to work properly. Right now these panels retain the focus where you last left it (apart from coming out of HS), so a VA macro does not have a reliable start point.
My requirements are pretty specific (on top of the fanttastic trading/exploration etc requirements I've already seen in this now quite lengthy thread)

I'm working with a few others to build a gladiatorial combat events community, and it occurs to me that something that'd really help increase player buy-in and involvement is a way of generating in-event statistics. That way we can have players and teams competing for the bets stats, sports-team style.

Specifically, I'm looking for

  • Kill confirmation
  • Killed by confirmation
  • Kill assist confirmation
  • Friendly Fire confirmation
Yay dev input

I'd like access to these read-only stats:

System and station info:


This info is already available in-game, but recording it all is tedious and not in the good way.

Radar & System data:

Output of radar and position data so that dogfights can be examined more closely. An external, recreated view can show you what happened in that last fight. It's hard to see that the other guy got a split s on you just from reviewing captured video.

Live flight data is essential to any kind of powered-chair simulator. Even a little 2-axis chair is great for immersion, but I need live turning data to feed it or it will feel off. Seat rumble would be nice too, though I don't know if you track events like being hit and bumping into something right now, so there may be no data to read.

Combat and flight data available for logging. After logging for a while, I can see how often my shields get low, whether that flak cannon is doing any good, if my engagements were quicker while I had that plasma accelerator. Diagnostic data like that can be quite revealing, and is similar to what you might see in training for actual combat.

Switch positions and data from any of the multipurpose screens. I'd like to set up a couple tablets to display the in-cockpit data screens without having to turn the characters head away, it's more natural than the built-in cockpit look, and the rift isn't available yet commercially. Air remaining in particular would be a nice value to have on one of my actual displays, since it disappears once you restore power, but as of now the value remains if power disconnects again. Also, a REVERSE LIGHT. Cannot tell you how many times I hit the gas in station with the dang thing in reverse, the indicator just isn't obvious - especially at full throttle. Those things make for the actual flying experience to be more enjoyable and immersive.

Active API:

Switches and buttons. Making my own controls sounds wonderful, but less satisfying if I can't flip switches to change things. There are buried controls I'd like more access to as well, especially the turret controls and flight assist. I need to turn off my turrets sometimes in combat, and don't have much time to do it - I can't be rummaging through the function menu in a dogfight. Switching flight assist between toggle and hold is currently done in the pause screen, I'd like to be able to do both in the space of one dogfight, and backing out to the controls menu during that is completely impractical.
Net-based inputs, all of them. Not always the best way, but occasionally it is more convenient to have custom hardware sharing your wifi and interfacing that way, rather than writing some crazy usb driver or hacking something into the audio track. I can make a holder for a cell phone and use it with an app as a 6-DOF flightstick, but that data is a pain to convey over anything but wireless.
Local control api still has plenty of value, I want so badly to write something for my leap motion to do in-game, but unless I can control something from outside, it's a no-go.

This Is Awesome, Guys!
I love seeing devs caring about external modding enthusiasts and fellow, external app developers! Multiple controller and net support make life so much nicer for us :)
Trading data seems like the most obvious draw. I do, however, like the fact that you have to go to a station to find out prices etc.. If we're logged into the API using our commander details (hopefully using something like Hawk or oAuth2) then a call to get commodities prices could just return the prices for the station in which we are currently docked. This would mean the tablet app I've knocked up could simply request it rather than me having to type it in by hand, it's not mechanic breaking but simply saves me from having to do the typing.

From a technical usability point of view it'd be nice to see the API using a HATEOAS approach so that we only need to remember a single entry point that can be navigated around in software. Hypermedia seems like a no-brainer for something like this where we'll want to navigate around the service from one piece of data to another. The auth would be important too, schemes such as Hawk and oAuth make securing single page apps (in my case phonegap apps) a breeze.

Tangential to the API would be the ability to embed tools into the system, for example WoW allows user to write in Lua/XML and it hosts the app in their client - no screen switching. Being able to add our own tabs to the left and right screens would be incredible.

Fly safe.
Location of all friends' ships (both stored in dock, and current one in use) so that you can travel to the system to link up with them when the new "wings" grouping update happens.
Ok, I'm a bit late to this discussion and there are 30+ pages of backlog, so I haven't read existing suggestions.

One major use case for me is creating something to play with the X52 Pro's MFD. There's lots of data that would be great to have on the MFD, including:

* Information about the current *navigation* target, regardless of what the current ship target is (so players can cycle through possible Interdiction threats while flying to a station, for instance)
* Comms information, *especially* the ability to select a CMDR and initiate voice or text comms. In fact, extend this to general targeting as well... being able to scroll through a list of targets to find potential bounties would be nice.
* Useful tactical information about allies (once Wings is out), particularly shield and hull health, and distance to ally.
* Number of jumps left and number of light years remaining in currently plotted route! Hell, having this on the HUD would be nice, too.
* Subsystem/power control, cargo management, etc. Basically anything that requires a round-trip to the UI panel could be offloaded to either the MFD or an external app. This would make my second monitor pretty useful.
I would request that non-immediate game data be treated as a game object.
(Note, I see some people talking about building cockpits and external controls, or about polling where friends are, or where their own Commander character is. I'm specifically not talking about those items, which I would call "immediate" game data.)

That is to say, I request that market data be treated like cartographic data is treated. You have it, but it needs to go somewhere before you get the full benefit of it.

For non-immediate data of all sorts, I would like to see a Data tab, next to our Cargo tab. This would list:
  • Cartographic data
  • Trade data
  • Mission data, such as from a data courier mission
  • etc.

Data of these sorts may be given by NPCs who want us to do something with it (deliver it), we can buy it, or we can go acquire it ourselves.

Specifically for the API, I would ask that non-immediate data can only be downloaded to player PC at places with the right sort of service. In other words, downloading stellar data would require a Universal Cartographics office. Downloading trade data would require either UC or some sort of trade guild. These might not exist at every station!

I know this part will be controversial, but before you down-rep me, please hear me out: I would also ask that every download-to-PC have a small cost in Cr associated with it. The reason for that is that other players will be acquiring this data for free, replacing the in-game remote purchase of data.

However, having game data as an ingame object also would allow a bounty to be paid for data which is gathered and delivered.

Let me suggest some examples of how this could become gameplay!

In a simple example, a Commander is wanting to begin some trade runs for a play session. There are five systems nearby that he's interested in. He could choose to purchase the data remotely (which should be cheap for lawful systems with major stations), save it to PC (also cheap) and then let Slopey's BPC upload it. At this point, if it's 100Cr to buy nearby trade data and 100Cr to save it to PC, he's spent 1000Cr, but has access to optimized trade routes. If he'd rather, he can go visit those star systems, getting the trade data for free. When he arrives, he could sell the trade data for 100Cr. Being data, he would still have a copy, so the 100Cr download service fee would be a wash.

A slightly more interesting example could be that our Commander flies to a dangerous Anarchy system, or one that requires a Permit, in order to gather data. The acquisition price on that data might be more like 1000Cr. So if he makes the trip himself, and then downloads the data to donate to BPC, he's still up 900Cr.

While our Commander is flying around, he would also be gathering up-to-date stellar cartographic data. UC might be interested in updates as well as discoveries. Temporary navigation items like "Seeking Luxuries" or conflict zones would definitely be good to deliver back to UC or to a GalNet office.

In a future development, having fresh cartographic data might enable "pirate-point" jumps. Data <24 hours might get you near a secondary star or a large planet. Data <1 hour might deliver you right into a conflict zone. The major factions would certainly pay well for this sort of data.

In other future developments, reconnaissance data might be a hot item to be given, or to gather yourself, and deliver. Some of it may make sense to download, some not. (embargoes, legality changes, etc)

Why am I bringing this up in the API discussion?
Specifically, I'm asking for non-immediate game data to be a game object, to enable these cool ideas in the future. To act like a game object, the data must:
  • require some investment of Cr or effort to acquire
  • require a sensible starport service to deliver to
  • require a sensible starport service and a small service fee to download to PC, where applicable, because it's going out freely to other Commanders after that

Thanks for reading!
Let me explain my suggestion with a user story!

This is meant to explain my suggestion, using speculative possible future gameplay, to highlight how data as a game object could be useful.

Simon Darkstep, intrepid (and handsome) commander of USS ACME, has just docked at Derrickson's Escape in Keries. His ship's computer only has current data from his current location. He taps up the commodity trade interface to see what the market is looking like.
+ Data: Keries cartographics
+ Data: Derrickson's Escape commodity data

He checks in with the station's spacers' bar. (Contacts - Lounge) Six other NPC spacers are present. One of them seems chatty, so he buys a round of good stuff for everybody. (Round of drinks; 6 patrons x 20Cr for quality hooch this far out = 120Cr; gives a chance for a data item) The chatty spacer's name is Lucien, and he has a hot tip. One of the daughters of the Aulin Enterprises dynasty is about to announce her upcoming wedding. The family's executive chefs are gathering up the very best rare foodstuffs. The whole company is expected to celebrate as well, so other items will be in high demand too.
+ Data: Community event: Aulin Family wedding
+ Data: High demand and bonus price on Rare foodstuffs. Witchhaul Kobe Beef, Diso Ma Corn, Lavian Brandy, etc. (Trade data for Aulin system)
+ Data: High demand and bonus price on normal foodstufffs. Wine, liquor, beer, animal meat, fruits & veg, etc. (Trade data for Aulin system)

Derrickson's Escape is in an Anarchy system, so no GalNet, Stellar Cartographics, or other services such as email, FTL chat, etc.
+ Mission available: Carry high priority email to/from Derrickson's
+ Data as Commodity available: Carry normal space-mail parcels back to civilized space and return.

Simon will have to go back to civilized space to check on the situation. He flies back to Chemaku, and lands at Crampton Port. He's got a lot of bonus faction with them, so the news he gets is reliable and cheap.
+ Data: System cartographics updates along the way. Trade data as well if he stops. 10Cr each for updated discovery scans.
- Data: Cartographics and trade data sold to the contacts at Crampton. 1000Cr for trade data at a dangerous Anarchy system.
+ PC Data: Simon saves to disk the data that he wants to update to Slopey's. 100Cr each for the Aulin and Keries data updates. 100Cr for the hot tip about the upcoming Community event.

Simon's download and subsequent publication-via-third party tool will ensure that the Community event at Aulin will get a bit of attention, and help drive the success Tier higher. He's down 420Cr so far, on drinks and downloads, but up 1200Cr+ for providing data updates for NPCs.

He goes to take a look at the updated data for Witchhaul, Lave, and Diso. Diso has already been updated in a third party tool, so that is free! Witchhaul is in an economic boom. Lave is being interdicted by the Empire! Oh no! :eek:
+ Data: Witchhaul and Lave data. Costs 100Cr each to buy remotely.

Simon talks to a Commander friend, Raven, who's got good faction with the Empire, but has no qualms about skirting around the law. They're both at major stations with FTL communication, so they can chat. Raven goes to Lave, while Simon goes to Witchhaul, to pick up enough beef for both of them. When Raven gets to Lave, he sees that the system is, indeed interdicted. The Empire has deployed capital ships near the arrival point, and is using capital scale FSD interdictors to immediately pull all smaller ships out of frameshift. Raven passes the inspection with no problem, and proceeds to Lave Station. The station, being interdicted by the Empire, has no FTL communication at all, and so is isolated.
+ Data: Raven has cartographic information about the location of the Imperial fleet ships, plus fresh cartographic data about Lave system itself. He soon has market data too.
+ Mission available: smuggle messages out of Lave and to Lave, for Commanders with the trust of the Alliance.

Raven meets back up with Simon. They dock at nearby Diso. Simon gives Raven a load of Witchhaul beef, in exchange for the stellar data at Lave. Simon plots course for Lave, and launches!
-> Data: Raven trades <1hour old data to Simon

Simon plots course, using the very current data to arrive at a pirate jump point 25 Ls polar-north of Planet Lave. Before the Imperial patrols realize what's up, he makes a run for Lave Station, avoiding interdiction and destruction. Supply on Lavian Brandy is very high, because few ships are able to get through. (Allows extra ticks of Rares to be bought.) Simon stocks up on party hooch, takes several missions to deliver messages to frantic loved ones worried about their Lavian relatives, sells off the data he's acquired (at bonus prices) and leaves for Aulin!
- Data: Simon already sold the data for Derrickson's, which is a shame. It would be very profitable to sell here. He does sell the data for Chemaku and Diso, gaining a tidy profit.
+ Data: He picks up several data objects of messages and mail, to deliver to any major station in a civilized system.

Simon launches once again, loaded up with brandy and data! Onward to the next stops!

Thanks for reading!
I don't think I'm bringing anything new to the thread, but wanted to add my voice for the API features I believe would allow 3rd party developers create add-ons to the game that would take this game to a new level of enjoyment.

1) Real-time ship telemetry data - For 3rd party hardware and software that use transducers and other means for tactile feedback, bass-shakers and ambient lighting, 6DOF rigs, and also could be used for external control panels and indicators.

2) Access to Commander’s present and historical data – Commodity and trade data, system data, station data, exploration data, factions relationship and reputation, Permits, Rankings and Statistics, Financial info, Current Cargo info. Pretty much any data required for a detailed commanders log. New/updated data should only be available when entering a system or station, depending on the data type, and be unique to your commander. Ideally this info should be expanded and/or made available in-game, but I’d also like to have access to it out of game.

3) Galaxy Map/System Map data – I think it would be great to have access to the Galaxy Map and the System Map data, but not live or in-game enabling quick route plots or jumps. Instead, I would like the maps available for out of game virtual exploration and planning. I also believe it could open up a plethora of 3rd party astronomy and educational tools.

Thanks for your consideration.
Just adding my priorities to a great set of ideas.
I would like a decent Pilot's Log. The bare minimum would be: date, ship/craft type, time of launch, launch station (system), time of docking, docking station (system), fuel used. That could be added to at the time of next launch by recording the differences in summary data at launch time between the summary data at the last launch time such as: number of kills, bounties claimed, profits made, objects found/surveyed and so forth.
The Log should be downloadable in .csv format.
Next I would like a route planning tool. It is not so useful now we have the 1000 ly mod - but it is still nice to have. I have used the one on the Internet (Elite Dangerous Trader) which is pretty good. It lists the route for you so you can anticipate what you are going to find or modify it slightly to check out places that you want to visit. As part of the route planner it would be nice to find out where certain factions and/or stations are. I have several bounties from obscure factions that seem to have moved on owing to local difficulties.
Finally, I would like the financial news going back a few days.

A criticism of the current \Ipad app is that the trading data is often wrong. A list of galactic averages of all the major trade-able commodities with trends should be the very least we have available offline.

It's probably suggested already somewhere in this large catalogue but I'd love to write an interface for co-pilot controls. Have a friend ( or enemy ) who could plot routes on the galaxy map, request docking, select targets to scan, deploy landing gear etc. Basicallty, something similar to Artemis.
This may already have been suggested in one form or another but... Journey log last 25 - 50 SC jumps with ability to then annotate with own notes...
Thread Closed: Not open for further replies.
Top Bottom