Discussion Advanced command inputs

[nrage]

So, we have voice attack and it is cool and all but I was always a bit bummed that I could not say something like "target power plant" and end up with the power plant targetted 100% of the time regardless of the starting state. I am aware you can get fairly close if you assume no subsystem is targetted and use prev subsystem X number of times. But, I want to do better.

What would be truly awesome is a way to plug in a DLL which could access an advanced control/command API to do .. well, everything you could imagine. The most important tasks would be things not currently possible using existing key bindings.

If a DLL is too technical or rules out too many developers then perhaps a custom scripting language could be used instead. We would provide scripts in that language which could then be triggered by a bound key (each script "function" would appear at the bottom of the control bindings screen). The scripts would themselves have access to the complex tasks not currently accessible with bound keys.

 

[wolverine2710]

If I've interpreted your post correctly you are talking about a way that an API (in which form however, like DLL, scripting language) could control some of the functions in ED. Ie two way communication. Not just reading data from the server or ED client but also sending data to the ED client.

This did ring a bell wrt to the "[PROPOSAL DISCUSSION] External API Requirements Thread" by Michael Brookes. It looks as if they are not going to implement something like that.

It's safe to assume that communication is one way - we're not going to allow direct interaction or injection of the live data.

Michael

Source.

 

[nrage]

Thanks, now that you mention it I do recall that comment/discussion.

The example given there was to provide text to display on screen. This is definitely trouble as it is a vector for injection style attacks (similar to SQL injection). The idea proposed here would not necessarily suffer from this problem, assuming of course that the scripting language implemented by Frontier sanitized the input from our scripts.

In addition that idea proposed pushing data to the server via the HTTP API, so would have affected the 'live' data (as mentioned by Michael) via a separate route other than the game client. This would mean there was a syncing issue to resolve between that secondary route and the game client. Whereas the scripting idea would push changes from the game client itself, which avoids the syncing issue.

So, I think what I am asking for here is more tightly coupled and would be both easier to implement and safer.


If I was to really dream big here, I would be dreaming of a day where we can write our own ship AI in scripts and turn Elite into a game where both your piloting and programming skills were put to the test