I think lua could be very useful for assisting pilots both by displaying information about the ingame environment to the pilot, and by giving the pilot advanced ship control input methods.

Unfortunately, lua could also be used to create autopilots and other things that take the human out of the loop. The following concept is designed to allow lua to be useful for displaying information, and assisting piloting controls, while disallowing things like autpilot.

Lua sensor thread:

I would like lua to be able to create a thread that had complete access to all ingame information and be able to output a user display, but could not pass any information to the main thread. The thread could be used to create alternative representations of information for players.

By limiting all sensory information to a sub thread that can not pass information to the parent thread, the parent thread could be allowed to have complete access to the ship controls. Thus the parent thread could be useful for alternative pilot input methods. Things like macros, keybinds, etc...

The parent thread would be allowed to send information to the sensor thread, so that the user can select display options. In fact, as a matter of sound programming, while the sensor thread is active, all lua user display data should be routed through the sensor thread.

I think you lack an understanding of how threads work, and how data can be passed between them (or blocked) and workarounds for passing data between your silly imaginary implementation of said threads.

[-1] [fail]

Drazed: You are at least in part very correct. I do not understand lua. I understand assembly. Perhaps what I suggest is not practical in languages more limited than assembly, or there are not any programmers sufficiently skilled in lua to accomplish it. It was just an idea. If you do not know anyway to make it work, or you believe such a system is beyond lua's capabilities, then say that.

Skill has nothing to do with it. Think of it this way, if your "locked" thread is making the data visible to the user (via UI or any other way) another thread can read that data from where the user would see it, no need to talk to the thread directly. Your understanding of lua (or lack thereof) has nothing to do with it, you're lack of understanding basic data structures and access restrictions DOES.

The idea is potentially implementable, however just about any possible implementation would be complicated and hugely exploitable, or completely useless and would not provide the data to the user as you requested.

drazed doesn't know anything about lua anyway.

Only one player has ever produced a successful autoaim or autopilot plugin...

My apologies drazed. As I have said, I only understand assembly. In assembly, anything I can imagine, and that the hardware will support, are at my disposal, if I can create the program to do it. In assembly, I could write the program that monitors and limits the users program, I could limited it to anything I wanted. To suggest that something that is well within the capability of the hardware is not possible, for reasons of "basic data structures and access restrictions", demonstrates your own ignorance of computer science.

If what I am suggesting is not practical in lua, then say that, but please limit your cometary to your area of expertise.

What you said sounds to me like having 2 types of plugins:
- ones that can read and display stuff (ie can only create/modify UI elements?)
- ones that can't read some stuff, but can control ship, get input from keyboard/mouse (and doesn't have access to any UI it didn't create itself, else it can just read off whatever previous plugin type added)

[edit] nvm

It won't happen, i bet, no time etc.

Roda, I'm not saying it's not possible. I fully agree ANYTHING IS POSSIBLE, and I'm not gonna argue that point. Please re-read my last reply and not "The idea is potentially implementable, however just about any possible implementation would be complicated and hugely exploitable".

Hence maq's nvm comment, no time etc... Threads talking to each other is not very hard to block, however since both threads still need to be useful to some extent they will need to access UI variables, config varibles, or just variables of some sort in general. Whatever implementation this took would be a huge pain in the ass to prevent exploitation because the threads don't need to talk to each other, they just need to have access to a particular variable they can pass data through.

Also, stop talking about your l33t assembly skills dude! You're not fooling anyone except the fools and I very much doubt you could implement a plugin interface around whatever hobby assembly project you jerk off to, let alone one that didn't provide everyones grandmother a rootkit for whatever box your code was placed on.

maq: two types of plugins could be one solution, if plugins can not talk to each other. That is not really what I meant, but if it is a potential solution, then ok.

drazed: if your objection is strictly technical, then so noted. However, I would prefer technical objection come from the devs.

The support and objections I seek from the player base is if they would like to see the idea implemented, technical issue aside.

As far as my leet assembly skills go, I do not see the point in trying to prove anything to you. My point was that I could accomplish my suggestion in assembly, and thus any technical difficulty would have to be blamed on lua or programmer skill.

I have no idea what a plugin interface is (beyond what it obviously sounds like). I would have to look up what it is and how it is supposed to work to even comment on if I could do it. With out having actually looked anything up, I have some difficulty imagining any great complexity.

As far as me actually programming anything in assembly for vo, I doubt you could afford me.

drazed wins the thread.

Actually i don't think it'd be prohibitively hard to do.
We already have plugins running in one somewhat restricted environment, so adding 2nd type should not be that hard.
But it would take some work atm.

I actually like the idea somewhat, but i still doubt it'll happen.

Essentially this thread can be summed up as:
'Can we have ship control functions back, but in a way that doesn't let us make autopilots with it. I think it's possible.'

(i think all the 'threads assembly and stuff' talk is clouding the issue here, if devs want to do it i'm sure they'll find a way, if not the time to do it)