New Orbiter SVN commit (r.71, Oct 14 2017)

[kuddel]

O.K. Now I've got some things done to the LUA code, I would like to ask how would I test the oapi.deflate() & oapi.inflate() functions in Lua?
Testing oapi.rand() & oapi.getcolor() was easy:

term.out(oapi.rand())
term.out(oapi.getcolor(1,2,3))

but how would a lua script look to test whether oapi.deflate() & oapi.inflate() work?
Something like this "pseudo-code"

inp = 'Hello World!' // input buffer
pak = '' // packed buffer
out = '' // re-inflated buffer
r1 = oapi.deflate(inp, sizeof(inp), pak, 255)
r2 = oapi.inflate(pak, sizeof(pak), out, 255)
term.out(r1)
term.out(r2)
term.out(in == out)

Please help, 'cause I'm not going to spend much time learning LUA in depth.
When I've managed to get this running I'll try to add further functionality.


@martins: I think LuaMFD hass two files missing (resource.h & LuaMFD.rc).
I took the liberty and re-created them as I think they were
Would be nice if they would be added in the next commit (yours, not mine)


---- EDIT ----
Attachment removed due to post #438

 

[4throck]

I arbitrarily chose some OAPI functions that were not present in LUA

From what I've worked on using LUA / Orbiter Script, the crucial functions would be:
- new landing points definition (only the older one is supported)
- simultaneous key-presses can't be sent from Lua to a vessel (ex: SHIFT+G does not work, but G does)
- get relative terrain altitude
- oapi.load_meshglobal seems to be missing.
- realtime keyboard reading

These are things that I tried to do, and as far as I can tell, are not implemented.

 

[kuddel]

Sure, there are more useful functions to implement, but as I took the liberty to start, I will chose the functions As I have *no* experience in implementing a LUA API I usually start with the simple things.
Everybody who likes to extend the LUA-API is free to do the same



By the way:

• vessel.get_touchdownpoints_new() for the new landing points definition was easy, but for vessel.set_touchdownpoints() I need to wrap my head around a bit more.
• another thing I need to learn is how to implement "polymorphism" for those functions, so they can be used with "old" and "new" parameters.
  At least for the set function it should be possible, but for the get function it might not be possible (how would I know what the script would expect as a return value)
  So maybe I'll have to stick to vessel.set_touchdownpoints_new() & vessel.get_touchdownpoints_new()...

---------- Post added at 01:56 ---------- Previous post was at 00:26 ----------

For all the others that are eager to work on lua API too:thumbup:, here's what I've been working on so far (to avoid double work) and its status:

// OAPI utility functions
- oapi.get_orbiter_version       [tested  ]
- oapi.get_viewport_size         [tested  ]
- oapi.rand                      [tested  ]
- oapi.deflate                   [untested]
- oapi.inflate                   [untested]
- oapi.getcolor                  [tested  ]

// Vessel
- vessel.get_touchdownpointcount [tested  ]
- vessel.get_touchdownpoints_new [tested  ]
- vessel.set_touchdownpoints_new [in work ]

---------- Post added at 13:48 ---------- Previous post was at 01:56 ----------

- get relative terrain altitude

Are you sure you've checked this (with current BETA)?

My results (Orbiter BETA r71):

v = vessel.get_focusinterface()
term.out( v:get_altitude() )                // => 15.531250386329 (defaults to ALTMODE.MEANRAD)
term.out( v:get_altitude(ALTMODE.MEANRAD) ) // => 15.531250386329
term.out( v:get_altitude(ALTMODE.GROUND ) ) // => 2.469

Or do you mean something different?

 

[kuddel]

Minor LUA-source changes

Hello Martin,

while diggin' into lua I've stumbled over some minor issues that should not stop anyone else from trying

Attached are (convenience) changes, to make life easier.
Note: These changes do not contain any additions to the lua API.

- changed Solution configuration, so that Debug and Release really do what they should.
- added missing resource files (resource.h and LuaMFD.rc)
- added DEL key handling to LuaConsole (nice to have)
- fixed term.out() issue when printing tables twice or more ('static char *' and 'strcat' need special care)

Regards,
Kuddel

 

[4throck]

I will chose the functions

Sure! :tiphat:

Are you sure you've checked this (with current BETA)?

Nope, I'm working based on the release version. :facepalm:

Thank you VERY MUCH for looking into this.
Eventually we will have all those spacecraft.dll vessels migrated into native Orbiter Script + LUA and that would be great.

 

[indy91]

New commit #71 is now available. As mentioned, this includes the fix for the PMI computation of docked assemblies, as discussed here and described in Doc/Technotes/composite.pdf. This one is probably mainly for indy91 to test, but other vessel developers might want to make sure that their docked vessels do reasonable things.

I haven't been able to do much testing yet, but the first docked burn I tried with the Descent Propulsion System of the LM was very stable. So pretty much as expected. The behavior of the CSM+LM is very close now to what the AGC expects and so it can control the vehicles much better. Other NASSP users have reported the same. Thanks so much for fixing this so quickly! This change will also have a few more effects for NASSP. Attitude maneuvers by the Digital Autopilot in the AGC will be interesting to observe while docked. And thrusting maneuvers controlled by the SPS such as the Lunar Orbit Insertion maneuver should also be a bit better. I usually create a video to showcase a new feature in NASSP, so I will probably create one for docked DPS burns as well. And I'll check if the new PMI are actually what I calculated in my scripts.

 

[kuddel]

Question:
A I have gained some experience in programing the lua API, I have a decision to make.
For the vessel.set_touchdownpoints() I could

1. "polymorphism" style: vessel.set_touchdownpoints() automatically detects new or old API according to the given parameter signature.
   This should keep full backward compatibility for older lua-scripts.
   Unfortunately the according "companion" setter is named vessel.set_touchdownpoints_new(), so not so intuitive.
2. "_new" style: vessel.set_touchdownpoints() and vessel.set_touchdownpoints_new().
   This should also keep full backward compatibility for older lua-scripts
   and would be the fitting "companion" of vessel.get_touchdownpoints_new().
3. "config mode" style: vessel.set_touchdownpoints() with an extra parameter 'config' (either TDPOINTS.NEW or TDPOINTS.OLD).
   This will break older scritps and would be my most disliked option as the 'config' parameter makes most sense if it is the first, therefore breaking backward compatibility

As this is mainly a design decision I would love to hear Martins opinion:tiphat:

---------- Post added 16-10-17 at 00:17 ---------- Previous post was 15-10-17 at 22:08 ----------

...just when I thought I understood how that lua <-> C interfacing works, I am confused again

Shouldn't this (original) C code...

int Interpreter::v_get_touchdownpoints (lua_State *L)
{
	VESSEL *v = lua_tovessel (L,1);
	ASSERT_SYNTAX(v, "Invalid vessel object");
	VECTOR3 pt1, pt2, pt3;
	v->GetTouchdownPoints (pt1, pt2, pt3);
	lua_pushvector(L,pt1);
	lua_pushvector(L,pt2);
	lua_pushvector(L,pt3);
	return 3;
}

...return a table of vectors? Something like this:
%[ [1,2,3], [4,5,6], [7,8,9] ]

All "term.out(v:get_touchdownpoints())" prints is just one vector:
%[1,2,3]

Or how do I access the 2nd and 3rd returned value in LUA.
%arr = {}
%arr = v:get_touchdownpoints()
%term.out(arr)
This didn't get me any further... 'arr' seems to be ONE vector

I am neither familiar with LUA nor do I really like to dig any deeper into this confusing C API...

Has anyone with experience ever used get_touchdownpoints() ?
Please enlighten me.

 

[4throck]

I don't think backward compatibility is an issue.
One can simply edit the script on Notepad and change what needs changing.

______

I used this to angle a normal vessel at launch:

pt1,pt2,pt3 = v1:get_touchdownpoints()
pt1.z=-18
v1:set_touchdownpoints(pt1,pt2,pt3)

I also don't care much about LUA, but some experimentation gets you on the right track.

You have z, y and z already defined. On my head it's like they are dictionary keys.
Don't know if that's 100% correct, but makes sense to me that way.

 

[martins]

I'm going to look into the issues you raised. To be honest, I am not all that familiar with Lua either, but at least I got into it deep enough at one point to implement my own virtual class framework (Lua doesn't have a native virtual class construct).

Shouldn't this (original) C code...
...return a table of vectors? Something like this:
%[ [1,2,3], [4,5,6], [7,8,9] ]

All "term.out(v:get_touchdownpoints())" prints is just one vector:
%[1,2,3]

Or how do I access the 2nd and 3rd returned value in LUA.
%arr = {}
%arr = v:get_touchdownpoints()
%term.out(arr)
This didn't get me any further... 'arr' seems to be ONE vector

I think to retrieve all 3 return values, you need to explicitly set 3 lhs parameters to receive them, i.e.

t1,t2,t3 = get_touchdownpoints();

Lua allows to call the function with fewer return parameters than are assigned by the function (similar to Matlab), in which case the unassigned ones are simply dropped.

Matlab has a method to check inside the function how many return parameters the function is called with, so that unnecessary computation can be avoided. I don't know if Lua provides the same functionality.

Edit: maybe we should open a separate Lua coding thread for this.

 

[Urwumpe]

Edit: maybe we should open a separate Lua coding thread for this.

What about having a dedicated subforum about Lua in Orbiter? I am pretty sure, this could also spark interest of more Orbiter users for this feature and its possibilities. Especially, its easier to search for help in a whole forum, than have a single thread.

 

[kuddel]

t1,t2,t3 = get_touchdownpoints();

Yes! That was it :thumbup:

Edit: maybe we should open a separate Lua coding thread for this.

Why not if might be more focused there.

I'll stick to the "polymorphic" approach(1), as it is most convenient and provides full backward compatibility.

So my current implementation will work like this:

v = vessel.get_focusinterface()

// ----------------------------------------------------------------
p1,p2,p3 = v:get_touchdownpoints()  // OLD, 'cause no index provided
v:set_touchdownpoints(p1, p2, p3)   // OLD, 'cause three vectors provided

// ----------------------------------------------------------------
arr = {}
arr[0] = v:get_touchdownpoints(0) // NEW, 'cause index provided
arr[1] = v:get_touchdownpoints(1) // NEW,   "     "     "
arr[2] = v:get_touchdownpoints(2) // NEW,   "     "     "
v:set_touchdownpoints(arr)        // NEW, 'cause table with at least 3 TOUCHDOWNVTX tables given

 

[llarian]

I quite agree with Urwumpe and Kuddel on an Orbiter Lua forum. I was quite surprised that MartinS went with Lua rather than Python. Of course I know Python quite well (through working with Blender) so I went out and bought the latest Lua manual to try to come to grips with it. I think a dedicated forum might help with discussing Lua in Orbiter.

 

[jedidia]

I was quite surprised that MartinS went with Lua rather than Python.

Try integrating python into C++, and you will see very quickly why Lua is usually prefered :lol:

 

[llarian]

Try integrating python into C++, and you will see very quickly why Lua is usually prefered :lol:

So I've heard. I was just being selfish, I guess. Besides, it is an opportunity to learn more.

 

[Urwumpe]

Try integrating python into C++, and you will see very quickly why Lua is usually prefered :lol:

Also Lua has a much smaller footprint (smaller libraries and less dependencies) AND as somebody who is constantly confronted with Python: A more user friendly syntax. A small change can already mean your program behaves much different than it should in Python and its far too easy to get those kind of changes by accident. And its rarely reported as a syntax error.

 

[kuddel]

... A small change can already mean your program behaves much different than it should in Python and its far too easy to get those kind of changes by accident. And its rarely reported as a syntax error.

Sorry to rain on your parade here, but that has nothing to do with LUA per se!

If asserting code like this...

	ASSERT_SYNTAX (lua_islightuserdata (L,1), "Argument 1: invalid type (expected handle)");
	ASSERT_SYNTAX (hObj = lua_toObject (L,1), "Argument 1: invalid object");
	ASSERT_SYNTAX (lua_istable (L,2), "Argument 2: invalid type (expected table)");
	lua_getfield (L,2,"lng");
	ASSERT_SYNTAX (lua_isnumber (L,-1), "Argument 2: missing field 'lng'");
	lng = (double)lua_tonumber (L,-1); lua_pop (L,1);
	lua_getfield (L,2,"lat");
	ASSERT_SYNTAX (lua_isnumber (L,-1), "Argument 2: missing field 'lat'");
	lat = (double)lua_tonumber (L,-1); lua_pop (L,1);
	lua_getfield (L,2,"rad");
	ASSERT_SYNTAX (lua_isnumber (L,-1), "Argument 2: missing field 'rad'");
	rad = (double)lua_tonumber (L,-1); lua_pop (L,1);

...wasn't added all over the place(*) in Interpreter.cpp, you wouldn't have any error check at all

(*) and is has to! All those stack operations the lua <-> C interface is build upon are a constant source for error!
All exported functions looks exactly the same:
"int method_name (lua_State *L)"; all of them! There's absolutely no chance to detect any assignment errors at compile time
...but that's
a) something on the developers side
b) something for the new Lua thread

Lua isn't "cleaner" or "faster" or "whatever", it's just easy on the user level side.

Nevertheless, when I'm back home I'll continue to complete the Vessel interface and see what happens.
The hardest part is yet to be done by someone else: ...Documentation!
As all method implementations use exactly the same signature, nobody knows what exactly is to expect from/for a function

The "vessel.get_status()" function in Lua could be implemented in many ways:
- take a parameter to be filled (like the C++ API)
- return a table (like some other functions do)
- return multiple values on stack (like some other functions do)
- ...
You see, the signature of Lua functions is purely documentation!

 

[Urwumpe]

Sorry to rain on your parade here, but that has nothing to do with LUA per se!

Lua? I mean Python! Defining scopes by indentation alone sounds nice at first, but turns out terribly error prone in larger projects.

 

[jedidia]

as somebody who is constantly confronted with Python: A more user friendly syntax.

I must confess this surprises me. I have found LUA synthax to be a bit tiresome, while python is built on a "write as you think"-paradigm. But I have never worked in python for prolonged periods, so I really can't judge how that worked out. The only thing I use it for is when a helper script gets too complicated to comfortably write in bash (which basically means as soon as it needs function calls... :shifty

 

[Urwumpe]

I must confess this surprises me. I have found LUA synthax to be a bit tiresome, while python is built on a "write as you think"-paradigm. But I have never worked in python for prolonged periods, so I really can't judge how that worked out. The only thing I use it for is when a helper script gets too complicated to comfortably write in bash (which basically means as soon as it needs function calls... :shifty

I have it right now as pyQt implementation of a GUI client and used it in the past for scripting CFD data post processors... in both cases, it was great to get started and suicidal to edit.

 

[Face]

in both cases, it was great to get started and suicidal to edit.

I can second that. Even in a well-designed Python-project like Mercurial, that statement above holds true for me. But I guess this is something many weakly-typed languages have in common.