The Future of Lua with Orbiter? Is it at a Dead-End?

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,339
Reaction score
3,262
Points
138
Location
Massachusetts
The second argument isn't compelling to me at all...
Some folks may want to maintain creative control over their add-ons, which I think is a valid concern that some developers might have. I don't know of any way one could lock down a script file to prevent it from being taken and modified.
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,691
Reaction score
1,345
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Some folks may want to maintain creative control over their add-ons, which I think is a valid concern that some developers might have. I don't know of any way one could lock down a script file to prevent it from being taken and modified.
The same is true of textures and config files though.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,852
Reaction score
2,114
Points
203
Location
between the planets
I don't know of any way one could lock down a script file to prevent it from being taken and modified.
It's called licensing. True, no add-on developer is going to go through the trouble of hiring a lawyer to send out a cease-and-disist, but the community in general takes a dim view on unauthorised re-use, so I think that's enforcement enough for our purposes.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
229
Reaction score
263
Points
78
Location
On my chair
Nobody mentionned the big win portability-wise, in lua there is no orbiter2010/orbiter2016/openorbiter, 32bit/64bit, release/debug, binary compatibility issues. You have your script, it keeps working as long as the OAPI is compatible.
We see different people keep on trying to reimplement similar addons time and time again just because the old libraries are not working anymore.
It would be nice if the OAPI support from lua was on par with the C++ side of things. We could have addons that work across several releases/architectures and lessen the burden on modders.
Of course "total conversion" projects like NASSP are another kind of beast that may not be practicle to code in lua but I don't think that's the case for a majority of the addons available here.
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,339
Reaction score
3,262
Points
138
Location
Massachusetts
I am still not seeing what the complication is. A complete 1:1 match to C++ callbacks isn't necessary - we just need equivalent functionality. All that is missing in Lua is a way to get the scenario file name that was used to initiate the simulation session. If that can be done, then a read function can be written in pure Lua. If the handle for the scenario file can be properly passed to Lua, the scenario file could potentially be read using only Lua code at the start of the simulation using a run-once flag in the pre-step callback. If simt == 0, read stuff from the scenario file.

I don't know if a similar write could happen automatically at the end of the session, but there the file handling is easier - it gets written to (Current State).scn. What is needed there is a write function that runs last when the simulation is triggered to end.

I tried semi-continuously updating the (Current state).scn file with MFD state variables, which works...until the simulation ends and Orbiter overwrites (Current state).scn, blowing away all the state variables. Writing to another scenario file isn't a fix either as you need the vessel states from the (Current state).scn file in addition to the MFD status variables. No way to do it except for manually editing the script files every time you run Orbiter. :(

Lua really does need the readstatus(scn) and writestatus(scn) methods to actually work for MFDs, and something similar for vessel scripts. Extended missions really aren't possible in Lua unless this is implemented unless you want to run the mission continuously in real time.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Hey @Thunder Chicken ,
I really would love to help you, but I am not 100% sure what to do.
  1. Providing readstatus(scn) and writestatus(scn) coild be possible, but I don't know how Orbiter could detect whether there is such a callback function defined in a Lua Script or not. In C++ it's easy: The base class has a virtual function that is essentailly empty and can be called by Orbiter anytime. Only if a derrived Vessel-Class has an actual implementation of these they get called. This happes automatically through the compiler / runtime.
    Maybe some kind of "registration" function needs to be provided (like bind_readstatus_func(<func>) and bind_writestatus_func(<func>) that must be called once in the Lua script).
    I'm not sure if that's the best way of doin' it however - since I'm not a Lua user.
  2. Regarding your "MFD-States" issue:
    Why don't you just use any file for your states? Just read the things you need from it on start and write/update the things whenever appropriate.
    That file (e.g. "temp/myMFDstates.txt" will never be overwritten by anyone (except your own code).
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,339
Reaction score
3,262
Points
138
Location
Massachusetts
Hey @Thunder Chicken ,
I really would love to help you, but I am not 100% sure what to do.
  1. Providing readstatus(scn) and writestatus(scn) coild be possible, but I don't know how Orbiter could detect whether there is such a callback function defined in a Lua Script or not. In C++ it's easy: The base class has a virtual function that is essentailly empty and can be called by Orbiter anytime. Only if a derrived Vessel-Class has an actual implementation of these they get called. This happes automatically through the compiler / runtime.
    Maybe some kind of "registration" function needs to be provided (like bind_readstatus_func(<func>) and bind_writestatus_func(<func>) that must be called once in the Lua script).
    I'm not sure if that's the best way of doin' it however - since I'm not a Lua user.
Well, it can detect prestep and poststep callbacks in the Lua script even if one or the other isn't implemented. How is that done?
  1. Regarding your "MFD-States" issue:
    Why don't you just use any file for your states? Just read the things you need from it on start and write/update the things whenever appropriate.
    That file (e.g. "temp/myMFDstates.txt" will never be overwritten by anyone (except your own code).
Certainly possible, but then those states aren't associated with a particular scenario. If you switch scenarios that has another MFD instance, you would need a separate file for every instance.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Well, it can detect prestep and poststep callbacks in the Lua script even if one or the other isn't implemented. How is that done?
I don't know :)
As you see, I am only very slightly interested in the Lua interface - still I like to help you out. Maybe glimpsing over the source-code might give me an idea.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
After looking at the code...(Open-Orbiter that is) I think readstatus & writestatus are implemented!

C++:
const int NCLBK = 13;
const int SETUP               =  0;
const int BUTTONLABEL         =  1;
const int BUTTONMENU          =  2;
const int CONSUMEBUTTON       =  3;
const int CONSUMEKEYBUFFERED  =  4;
const int CONSUMEKEYIMMEDIATE =  5;
const int UPDATE              =  6;
const int STORESTATUS         =  7;
const int RECALLSTATUS        =  8;
const int WRITESTATUS         =  9;
const int READSTATUS          = 10;
const int PRESTEP             = 11;
const int POSTSTEP            = 12;

const char *CLBKNAME[NCLBK] = {
    "setup", "buttonlabel", "buttonmenu", "consumebutton", "consumekeybuffered", "consumekeyimmediate",
    "update", "storestatus", "recallstatus", "writestatus", "readstatus", "prestep", "poststep"
};
Maybe the signature of your callback unctions is just not correct?
readstatus & writestatus expect a function with one parameter (the FILEHANDLE; I don't know what that translates to in Lua)
C++:
// Read MFD status from file
void ScriptMFD::ReadStatus (FILEHANDLE scn)
{
    if (bclbk[READSTATUS]) {
        lua_getfield (L, LUA_GLOBALSINDEX, CLBKNAME[READSTATUS]);
        lua_pushlightuserdata (L, scn);
        lua_call (L, 1, 0);
    }
}
Can you provide a minimal Lua script for me to try?
Please make it as simple as possible so no one gets distracted. Best would be just a demo with prestep, poststep, readstatus & writestatus
that does not depend on any other add-ons (if possible)
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,339
Reaction score
3,262
Points
138
Location
Massachusetts
Nobody mentionned the big win portability-wise, in lua there is no orbiter2010/orbiter2016/openorbiter, 32bit/64bit, release/debug, binary compatibility issues. You have your script, it keeps working as long as the OAPI is compatible.
We see different people keep on trying to reimplement similar addons time and time again just because the old libraries are not working anymore.
It would be nice if the OAPI support from lua was on par with the C++ side of things. We could have addons that work across several releases/architectures and lessen the burden on modders.
Of course "total conversion" projects like NASSP are another kind of beast that may not be practicle to code in lua but I don't think that's the case for a majority of the addons available here.
Seriously. There are so many dead add-ons because of this.
After looking at the code...(Open-Orbiter that is) I think readstatus & writestatus are implemented!

C++:
const int NCLBK = 13;
const int SETUP               =  0;
const int BUTTONLABEL         =  1;
const int BUTTONMENU          =  2;
const int CONSUMEBUTTON       =  3;
const int CONSUMEKEYBUFFERED  =  4;
const int CONSUMEKEYIMMEDIATE =  5;
const int UPDATE              =  6;
const int STORESTATUS         =  7;
const int RECALLSTATUS        =  8;
const int WRITESTATUS         =  9;
const int READSTATUS          = 10;
const int PRESTEP             = 11;
const int POSTSTEP            = 12;

const char *CLBKNAME[NCLBK] = {
    "setup", "buttonlabel", "buttonmenu", "consumebutton", "consumekeybuffered", "consumekeyimmediate",
    "update", "storestatus", "recallstatus", "writestatus", "readstatus", "prestep", "poststep"
};
Maybe the signature of your callback unctions is just not correct?
readstatus & writestatus expect a function with one parameter (the FILEHANDLE; I don't know what that translates to in Lua)
C++:
// Read MFD status from file
void ScriptMFD::ReadStatus (FILEHANDLE scn)
{
    if (bclbk[READSTATUS]) {
        lua_getfield (L, LUA_GLOBALSINDEX, CLBKNAME[READSTATUS]);
        lua_pushlightuserdata (L, scn);
        lua_call (L, 1, 0);
    }
}
Can you provide a minimal Lua script for me to try?
Please make it as simple as possible so no one gets distracted. Best would be just a demo with prestep, poststep, readstatus & writestatus
that does not depend on any other add-ons (if possible)
Readstatus() and writestatus() are both "implemented" in Orbiter 2016, but there is something wrong with the passing of the scn handle so reading and writing can't happen.

I can forward a test script when I get back to my laptop later today.
 
Last edited:

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,691
Reaction score
1,345
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Nobody mentionned the big win portability-wise, in lua there is no orbiter2010/orbiter2016/openorbiter, 32bit/64bit, release/debug, binary compatibility issues. You have your script, it keeps working as long as the OAPI is compatible.
We see different people keep on trying to reimplement similar addons time and time again just because the old libraries are not working anymore.
It would be nice if the OAPI support from lua was on par with the C++ side of things. We could have addons that work across several releases/architectures and lessen the burden on modders.
Of course "total conversion" projects like NASSP are another kind of beast that may not be practicle to code in lua but I don't think that's the case for a majority of the addons available here.

I see it filling the niche, that SC3 did circa 2006-2010. There were a lot of simple, but fun addons, the development of which had a very low barrier to entry.
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,339
Reaction score
3,262
Points
138
Location
Massachusetts
Can you provide a minimal Lua script for me to try?
Please make it as simple as possible so no one gets distracted. Best would be just a demo with prestep, poststep, readstatus & writestatus
that does not depend on any other add-ons (if possible)
Here you go. Assuming OpenOrbiter works like Orbiter 2016, you should be able to unzip this to the main Orbiter folder, then re-enable ScriptMFD under Modules, and start the scenario DG MFD Script Test.scn. Note that I am on a Linux box, but I don't think there is anything OS specific here. I left prestep and poststep callback functions in the script, but nothing is done in them other than outputting messages to the MFD display.

If it runs, it should read var1 ( a number) and var2 (a boolean) from DG MFD Script Test.scn and write them to (Current state).scn when the session is closed. The MFD will display messages if these variables were read from the scenario file.

This does NOT run on Orbiter 2016 due to the attempts to read and write to scn in the readstatus()/writestatus() methods. It simply crashes the session. However, if I comment out all of the lines inside these methods, or do anything else, Orbiter runs, which seems to indicate that it is attempting to run them.

EDIT: I just verified that Orbiter 2016 can access these callbacks, at least readstatus(scn) anyway. A message put in the readstatus() callback is sent to the MFD display, and readstatus() isn't explicitly called anywhere in the script. But it crashes at any reference to scn.


EDIT2: I'm downloading this build...is this OpenOrbiter or another fork?

 

Attachments

  • MFDScriptTest.zip
    2.9 KB · Views: 2
Last edited:

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,339
Reaction score
3,262
Points
138
Location
Massachusetts

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Hey @Thunder Chicken,
why do you thing these methods do exist?
Code:
scn:lines()
scn:write(...)
The scn parameter given is just a handle! You can only use it with OAPI functions that take that handle!

Don't you have a Debugger for Lua? I think when you debug-print values (scn in this case) it gives some more information....

I am currently trying to give you at least some of those functions (Namely: "writescenario_string", "writescenario_int", "writescenario_float", "writescenario_vec" and "readscenario_nextline")

I'll take your Lua exmple as a stepping-stone to do the tests.
This taks some time however - it's already 00:19 and time to go to bed
:sleep:
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,339
Reaction score
3,262
Points
138
Location
Massachusetts
Hey @Thunder Chicken,
why do you thing these methods do exist?
Code:
scn:lines()
scn:write(...)
The scn parameter given is just a handle! You can only use it with OAPI functions that take that handle!
Maybe, but there are no oapi read/write functions that I am aware of. These are Lua syntax lines() function iterator and write statements. If scn were truly a file handle they should work.
Don't you have a Debugger for Lua? I think when you debug-print values (scn in this case) it gives some more information....
I already did so:


As far as I can tell scn is an empty table. If it was actually passing a file handle the above Lua methods should work. The thread that I linked to shows others haven't been able to read or write using these callbacks.
 
Last edited:

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,339
Reaction score
3,262
Points
138
Location
Massachusetts

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
That FILEHANDLE is a C/C++ FILEHANDLE ! As such this is NOT an Object! It is just a "number to identify what file it belogs to"!
This handle is just to be passed along to other functions like:
Code:
function readstatus(scn)
    line = readscenario_nextline(scn)
    -- ...do something with the string "line"
    -- or...
    writescenario_float(scn, "wherever'" 3.141592)
end
As those two functions do not yet exist, you have to wait a bit.

A "file handle" in Lua might mean something completely different. But this scn FILEHANDLE is not that!
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,339
Reaction score
3,262
Points
138
Location
Massachusetts
That FILEHANDLE is a C/C++ FILEHANDLE ! As such this is NOT an Object! It is just a "number to identify what file it belogs to"!
Yes, I understand file handles. The usage of scn:lines() and scn:write functions are correct Lua statements assuming scn is a valid file handle.
A "file handle" in Lua might mean something completely different. But this scn FILEHANDLE is not that!
OK. Can we get information from scn as-is that would let us get access to the file? If a valid file handle can be passed to Lua, is there any reason why read and write statements could not be implemented in pure Lua?

It seems rather crazy that readstatus(scn) and writestatus(scn) appear to be valid callback functions, are documented, but are absolutely unusable without helper functions that don't exist and haven't been developed in over 10 years. Especially since these functions are critical to really making Lua usable for addons.
 
Top