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,253
Reaction score
3,147
Points
138
Location
Massachusetts
@Thunder Chicken : The PR has been merged. So you can now enjoy the new Lua functions by downloading the latest build.

Changes:​

  • added following file i/ofunctions to Lua interface:
    • openfile(fname,mode,root)
    • closefile(fname,mode)
    • savescenario(name,descr)
    • writeline(f,line)
    • writescenario_string(scn,item,str)
    • writescenario_int(scn,item,i)
    • writescenario_float(scn,item,d)
    • writescenario_vec(scn,item,vec)
    • readscenario_nextline(scn)
    • readitem_string(f,item)
    • readitem_float(f,item)
    • readitem_int(f,item)
    • readitem_bool(f,item)
    • readitem_vec(f,item)
    • writeitem_string(f,item,str)
    • writeitem_float(f,item,d)
    • writeitem_int(f,item,i)
    • writeitem_bool(f,item,b)
    • writeitem_vec(f,item,vec)
  • added following utilityfunctions to Lua interface:
    • formatvalue(val,prec)
All new functions are "oapi" module functions, so to be called with oapi. prefix.
The documentation-sources are available, but currently no new documentation artifacts are generated.
If you like to get some detailed information on these new functions, I would recommend looking at the source code (mainly somewhere around here).

Have fun
Just a quick question - will the readscenario and writescenario functions work in a vessel script as well as a MFD script? I am trying to sort out how to read and write vessel states to/from the scenario file. I am not sure if equivalents to clbkSaveState and clbkLoadStateEx exist for Lua yet.

EDIT: I looked through Interpreter.cpp in the code base and it seems Lua still only has four callbacks available: prestep, poststep, setclasscaps, and postcreation.
 
Last edited:

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,055
Reaction score
499
Points
83
I have no definitive answer here, but for the readscenario_nextline(scn) function all you need is a valid "scn" file handle.
Same goes for the writescenario_xxx(scn,item,value) functions.
So once you got that they work!
I do not know if the callbacks, that provide that handle, are implemented to be called for Vessel scripts.
They might not.
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,253
Reaction score
3,147
Points
138
Location
Massachusetts
I have no definitive answer here, but for the readscenario_nextline(scn) function all you need is a valid "scn" file handle.
Same goes for the writescenario_xxx(scn,item,value) functions.
So once you got that they work!
I do not know if the callbacks, that provide that handle, are implemented to be called for Vessel scripts.
They might not.
It does not seem that any such vessel callbacks exist. It's rather the reverse problem that we had with ScriptMFD trying to write MFD states - we had the callbacks, but not the necessary read/write functions. For vessel scripts, we have the read/write functions, but can't get the scn handle through callbacks to read at the start of the session and to automatically write at the end of the session.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
211
Reaction score
241
Points
58
Location
On my chair
So, I've been working on a port to lua of the original Atlantis Shuttle to see how far we can go with this.
The first thing to note is that it's really annoying to debug, the errors are sometimes logged in orbiter.log, sometimes in the console (when starting with no GC), sometimes they are nowhere to be seen... You often have to revert back to "printf" style debugging and launch the process from a command line to see the output.
That being said, I could get the VC working and the autopilot is able to start the gravity turn and drop the SRBs and the ET.
Performance-wise, I could not see much of a difference with the C++ version (both range from 400 to 1000fps during an ascent in x64-debug mode).
The WIP is here if you're interested, there's a LuAtlantis scenario in the Atlantis folder on this branch ; you can start the autopilot from a LuaMFD with a "V:launch()" command.
The next major roadblock is the AscentMfd because in the C++ version it's embedded in the same module as the vessel so it has direct access to its functionnalities. I'll have to figure something out with the ScriptMFD and see how they can play together.
We could promote the ScriptMFD from a plugin to a module but I don't like having every MFDs showing even when their vessel is not loaded so a dynamic registration is still a must have IMHO.
Also some APIs are using references (e.g. CreateVariableDragElement) so we'll have to find a solution for that as well (maybe doing some kind of explicit boxing).
All in all, my main concern is with the debuggability issue, it's too easy to misspell a variable somewhere and having a nil silently inserted that will bite you in the butt on the other side your codebase...
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,253
Reaction score
3,147
Points
138
Location
Massachusetts
Performance-wise, I could not see much of a difference with the C++ version (both range from 400 to 1000fps during an ascent in x64-debug mode).
This has been my experience as well. My converted add-ons seem to run as well in Lua form as they did as C++ modules. I haven't clocked them, but I haven't noticed any particular lagginess.
Also some APIs are using references (e.g. CreateVariableDragElement) so we'll have to find a solution for that as well (maybe doing some kind of explicit boxing).
The folks managing the Orbiter code-base have been pretty helpful in getting the remaining C++ API methods mapped into Lua. I've used add_force in Lua to work around this particular missing method but it probably should be raised as an issue in Github. https://github.com/orbitersim/orbiter.
The first thing to note is that it's really annoying to debug, the errors are sometimes logged in orbiter.log, sometimes in the console (when starting with no GC), sometimes they are nowhere to be seen... You often have to revert back to "printf" style debugging and launch the process from a command line to see the output.
I'm an old fart engineer who learned to diagnose code in FORTRAN 77 with print statements so I am not so horrified by this, but folks used to modern full-featured IDE capabilities and debugging might be. There is the oapi.dbg_out(msg) method that can display output to the screen in Orbiter.

But, on the flip side, Lua can be implemented with nothing more than a text editor, which is a win for those who don't program professionally or frequently and struggle to set up compilers, especially if they are on Linux like me. I've found that VS Code with a Lua plugin that annotates and catches basic syntax errors is a good setup that lets me get coding with a minimum of fuss.
All in all, my main concern is with the debuggability issue, it's too easy to misspell a variable somewhere and having a nil silently inserted that will bite you in the butt on the other side your codebase...
That's an intrinsic bug (or feature) of Lua - rather loose data typing and assignment. I don't know if there are script languages that are better in this regard. I am aware Lua is used for add-on development in other simulator and games so it might be the most suitable ecosystem for those who do a lot of gaming.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
211
Reaction score
241
Points
58
Location
On my chair
To improve the robustness in case of errors in Lua code, I'm trying to use luaL_error inside the C functions handling the Lua interface.
Currently there are lots of different macros/functions to check the validity of arguments but none is using this API.
Does anybody know if there is a reason for that ?
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,055
Reaction score
499
Points
83
No, I just looked at it and when I needed some new, I did a similar thing Martin had done.
Whether this is good / best practice, I have absolutely no idea.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
211
Reaction score
241
Points
58
Location
On my chair
No, I just looked at it and when I needed some new, I did a similar thing Martin had done.
Whether this is good / best practice, I have absolutely no idea.
lua_error is different from the error macros currently existing in that it does a longjump so care must be taken to free eventual resources that have been allocated since the stack will be unwinded quite brutally. That's why I'm wondering if there may be a reason it's not been used. As far as I can tell if we're careful there should be no problem but I wanted to be sure...
 
Top