Discussion Real-Time Flight Data API Possibilities?

I know this is a long shot, but it surely can't hurt to put it out there ...

I'm interested in building custom control surfaces for ED - as in real flight-simulator-type toys - using programmable USB modules such as Teensy boards (http://www.pjrc.com/teensy/index.html).

Obviously, the APIs that this forum are dedicated to aren't really what I'm looking for.

A very basic example of the type of data I'm interested in getting my hands on in real-time in-game would be current velocity, distance to target, pitch/roll/yaw values, etc ...

What do you think my chances might be of getting Frontier developers interested in making a basic scripting tool available?

I'm not talking a full-blown modding suite ... the ability to read values alone would be AWESOME though.
 
This is a different beast from the API, in that to obtain this data in any useful fashion you should be talking to the local client rather than the remote server.

I'd love to see a simple way of asking the local client for basic information. Full details about the operational status of your ship/SRV (landing gear up or down, velocity, current target (although no more than shows up on the scanner as that could lead to scripting), health of modules, etc.) would be fantastic for many reasons. Personally I'd use it to enhance my VoiceAttack scripts, which currently rely in internal variables to track this information but can stray from reality in any number of situations.
 
We're on the same page.

There's little difference between your VoiceAttack scripts and the scripts I'm talking about except for the hardware that's providing the interface.

Talking directly to the client and not the server would not only provide exactly the data we're looking for - it would also prevent any kind of game exploitation.

I'm totally on board with Frontier not providing us with the ability to produce mods for the game. I just think that this kind of API would provide the possibility of an extra level of immersion that would take ED from being an amazing game, to being an AMAZING simulation!

So ... who do we have to nag?
 

Robert Maynard

Volunteer Moderator
This is a different beast from the API, in that to obtain this data in any useful fashion you should be talking to the local client rather than the remote server.

I'd love to see a simple way of asking the local client for basic information. Full details about the operational status of your ship/SRV (landing gear up or down, velocity, current target (although no more than shows up on the scanner as that could lead to scripting), health of modules, etc.) would be fantastic for many reasons. Personally I'd use it to enhance my VoiceAttack scripts, which currently rely in internal variables to track this information but can stray from reality in any number of situations.

I'd really like to be able to extract sufficient information to create active HUD displays external to the main display - some flight sims allow this functionality for use like this:

1004807.jpg


Well, maybe not exactly like that - but you get the idea - a screen behind the MFDs with the live video image for each HUD display in the correct place.
 
Exactly! X-Plane - for instance - provides enough of an API that you can actually create hardware switch panels that change the state of game variables ... radio and GPS interfaces ... MFDs like those above.

Ever since I was 5 years old I wanted to build my own 'spaceship simulator'. Elite Dangerous is the first game to come along that deserves that kind of effort!
 
Exactly! X-Plane - for instance - provides enough of an API that you can actually create hardware switch panels that change the state of game variables ... radio and GPS interfaces ... MFDs like those above.

That bit is easy enough, in that you can build pretty much anything and use it is a control input for Elite.

The harder bit is pulling information from the game to know current state.
 
True ... UNLESS there's a dev on the team who has also wanted to build a spaceship simulator since he was 5 ...

Comparatively, this would be a VERY simple feature to build in to the game - there are several flight simulators out there which provide exactly this.

And I'm not asking for the ability to mod stuff ... I just want to be able to read a few values ... maybe add a few more "controllable" variables (a few more event listeners and observers).

Make a simple LUA Client Scripting Interface a FEATURE of ED, and it could take this 'game' to a whole new level !!

So ... what do I need to do to annoy a developer enough to take the idea to the next dev meeting? Who can I present the idea to? Do the devs lurk here?
 

Robert Maynard

Volunteer Moderator
The apertures in the Thrustmaster MFDs are 108mm x 108mm and the bezel width is 16.6mm. If both were to be placed right beside each other then the screen width would need to be 249.2mm - for a 16:9 screen that equates to a height of 140.2mm (i.e. greater than the 108mm aperture height and just less than the height of the MFD including bezel of 141.2mm). I found a bare 11.6", 1920x1080 screen on ebay that would fit the bill (256.3mm x 144.2mm active area) for c.£81.

Now that would be an interesting project....
 
With the right amount of client data access and a little tenacity, you could fill those MFD Frames with appropriately-sized TFT Screens driven by a Teensy (or other USB development board) ... 100%, fully-working MFD for Elite Dangerous.

Imagine that !! Then blow your mind by imagining the frames with TOUCH TFT screens !!!

I REALLY want LUA Client Scripting for ED. When I get home from work I think I'll put together a more detailed proposal for the "Comments and Suggestions" forum (which I just managed to find)

:D
 
There is an interim solution available in the form of Roccat's Power-Grid (see this thread) that will let you use an android or iOS device as a button panel. There are already several downloadable panels available.

I'd really like to be able to move the left and right panels to tablets that could link with the game running, as well as having a simple API to pull various info from the game for various indicators, like landing gear, cargo scoop, hardpoints, etc.
 
a simple API to pull various info from the game for various indicators, like landing gear, cargo scoop, hardpoints, etc.

Clarification: I'd like an API for that, preferably implemented like a subset of the one used for X-Plane, as there are tools out there making implementation of instrumentation quite easy. Like the Teensy boards combined with Teensyduino and the TeensyControls X-Plane plugin.
 
The Teensy boards are exactly the widget I've been investigating to help make switch panels (and more) for flight sims ... but imagine what could be accomplished with Raspberry PI ?!!?

All we need is the data (yeah, ok, this was a shameless bump)
 
MFD Frames with appropriately-sized TFT Screens driven by a Teensy (or other USB development board) ... 100%, fully-working MFD for Elite Dangerous. Imagine that !! Then blow your mind by imagining the frames with TOUCH TFT screens !!!

Drool! I actually wonder why someone hasn't come up with a display to fit the TM MFD. I bet they could make a killing. That would be so cool. I've seen quite a few using oversize USB displays behind the MFD for DCS, but that's a kinda crude solution. It would be cool to have the target display on a MFD screen.

The Teensy boards are exactly the widget I've been investigating to help make switch panels (and more) for flight sims

Yep, but it is going to take some goodwill from Frontier to make the client read and respect external switches. But to get even a small subset of the functionality from X-Plane or DCS ... Wow!

what could be accomplished with Raspberry PI ?!!

Yep, interesting! Puts me in the mind to do a few searches to see, if someone has already come up with some cockpit solutions using the Pi's.

But, as mentioned previously, my personal favorite, is linking the left and right screens to external panels with touchscreens - like an app running on a tablet, connected by the local network to the client in much the same way Roccat connects their Power Grid to the main app. Now that's immersion, and convenience! And yes, I would imagine that something based on the Raspberry Pi would really shine in this role.

IMG_26212.jpg
 
Last edited:
Obviously the client itself has a communication protocol with the game servers, but there's a portion of it which uses an HTTPS connection to api.orerve.net, and it seems to be fairly real-time. This is different from the mobile API on companion.orerve.net which is not real-time. I have bits of information in this thread, but no response from the devs for my request for information.
 
Last edited:
Obviously the client itself has a communication protocol with the game servers, but there's a portion of it which uses an HTTPS connection to api.orerve.net, and it seems to be fairly real-time. This is different from the mobile API on companion.orerve.net which is not real-time. I have bits of information in this thread, but no response from the devs for my request for information.

This is AWESOME info - thank you. How much trouble do you think we might get ourselves in if we tried to reverse engineer this though? I mean, it looks totally feasible ... but would Frontier can my account?
 
Last edited:
This is AWESOME info - thank you. How much trouble do you think we might get ourselves in if we tried to reverse engineer this though? I mean, it looks totally feasible ... but would Frontier can my account?

Honestly I don't know. I don't think they have banned anyone other than for the most serious offenses (e.g. harassment or outright black hattery). Poor in-game behavior usually gets shadow-banned (i.e. you are no longer in the same instance as anyone, even in open, essentially solo).

This said, ethical exploration should be OK. The other tool developers and I have been campaigning for an API ever since Beta, with the result that the Companion (mobile) API is now "tolerated". From Michael's reactions to our posts, there seem to be two main concerns for FD:

- Any use of an API must not affect the game servers or other players' game experience
- FD cannot provide support for an API at this time

Hence, when we started to "hack" the Companion API, they grumbled a bit, but didn't outright tell us not to do it, and also we didn't get any sanctions (thanks to people being reasonable about how it was used). There was a side-effect though: Michael had instructed the moderators to close any threads about third-party tools "accessing the servers". This wasn't specifically aimed at the Companion API work, but was enough to shut down any discussions about the subject, which moved to Reddit and EDCodex.

Sorry about the historical detour, but the point is this: FD aren't mean, they really want to do this, but it isn't on their priority list yet. But they also don't want people messing up the servers, so if you do experiment, just be careful not to flood or otherwise affect them. You should be fine.

And also, hence why I posted that thread so that devs can give us a "safe" way to use it, if they are willing.
 
Last edited:
Please allow me to hook into this thread and show my support for an API that would allow to pull state information from the game (speed, g-forces, orientation, switch states, telemetry data, etc.). I'd be building panels like no tomorrow!
 
Sorry about the historical detour, but the point is this: FD aren't mean, they really want to do this, but it isn't on their priority list yet. But they also don't want people messing up the servers, so if you do experiment, just be careful not to flood or otherwise affect them. You should be fine.

And also, hence why I posted that thread so that devs can give us a "safe" way to use it, if they are willing.

No - thank you for the historical detour. It's made all the difference. OK, I'll start experimenting. I've got a heavy workload (I lead a dev team at a small tech startup with an impending launch), so there's not going to be any lightning progress here - but I'll be sure to keep you informed of whatever progress I do manage to make.
 
Last edited:
True ... UNLESS there's a dev on the team who has also wanted to build a spaceship simulator since he was 5 ...

Comparatively, this would be a VERY simple feature to build in to the game - there are several flight simulators out there which provide exactly this.

And I'm not asking for the ability to mod stuff ... I just want to be able to read a few values ... maybe add a few more "controllable" variables (a few more event listeners and observers).

Make a simple LUA Client Scripting Interface a FEATURE of ED, and it could take this 'game' to a whole new level !!

So ... what do I need to do to annoy a developer enough to take the idea to the next dev meeting? Who can I present the idea to? Do the devs lurk here?

Actually, it would be enough to make the client to LOG more stuff - thinking about for example:
- hardpoints deployed status
- landing gear status
- current space (normal / supercruise / hyper )
- modules status (disabled / enabled / damaged % / destroyed / assigned group )
- selected firing group

This would allow to creat status screens at least, or for example backlighting buttons or switches (landing gear button red/green, hardpoints red/green)
We could work with that data logged locally .)
 
Back
Top Bottom