Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Beta Topics related to Beta releases of Orbiter and Orbiter development.

Reply
 
Thread Tools
Old 10-14-2017, 09:50 PM   #436
4throck
Enthusiast !
 
4throck's Avatar
Default

Quote:
Originally Posted by kuddel View Post
 
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.
4throck is offline   Reply With Quote
Old 10-15-2017, 11:48 AM   #437
kuddel
Donator
Default

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, here's what I've been working on so far (to avoid double work) and its status:
Code:
// 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 ----------

Quote:
Originally Posted by 4throck View Post
 - get relative terrain altitude
Are you sure you've checked this (with current BETA)?

My results (Orbiter BETA r71):
Code:
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?

Last edited by kuddel; 10-15-2017 at 12:55 AM.
kuddel is offline   Reply With Quote
Thanked by:
Old 10-15-2017, 01:44 PM   #438
kuddel
Donator
Default 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
Attached Files
File Type: zip r71 based changes (LUA).zip (33.5 KB, 2 views)
kuddel is offline   Reply With Quote
Thanked by:
Old 10-15-2017, 04:04 PM   #439
4throck
Enthusiast !
 
4throck's Avatar
Default

Quote:
Originally Posted by kuddel View Post
 I will chose the functions
Sure!

Quote:
Originally Posted by kuddel View Post
 Are you sure you've checked this (with current BETA)?
Nope, I'm working based on the release version.

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.
4throck is offline   Reply With Quote
Thanked by:
Old 10-15-2017, 04:28 PM   #440
indy91
Addon Developer
Default

Quote:
Originally Posted by martins View Post
 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.
indy91 is offline   Reply With Quote
Thanked by:
Old 10-15-2017, 10:17 PM   #441
kuddel
Donator
Default

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

---------- 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...
PHP Code:
int Interpreter::v_get_touchdownpoints (lua_State *L)
{
    
VESSEL *lua_tovessel (L,1);
    
ASSERT_SYNTAX(v"Invalid vessel object");
    
VECTOR3 pt1pt2pt3;
    
v->GetTouchdownPoints (pt1pt2pt3);
    
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.
kuddel is offline   Reply With Quote
Thanked by:
Old 10-16-2017, 02:04 PM   #442
4throck
Enthusiast !
 
4throck's Avatar
Default

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:

Code:
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.
4throck is offline   Reply With Quote
Old 10-16-2017, 02:55 PM   #443
martins
Orbiter Founder
Default

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).

Quote:
Originally Posted by kuddel View Post
 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.
martins is offline   Reply With Quote
Thanked by:
Old 10-16-2017, 03:08 PM   #444
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by martins View Post
 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.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 10-16-2017, 06:13 PM   #445
kuddel
Donator
Default

Quote:
Originally Posted by martins View Post
 t1,t2,t3 = get_touchdownpoints();
Yes! That was it

Quote:
Originally Posted by martins View Post
 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:
Code:
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
kuddel is offline   Reply With Quote
Thanked by:
Old 10-16-2017, 09:55 PM   #446
llarian
Orbinaut
 
llarian's Avatar
Default

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.
llarian is offline   Reply With Quote
Old 10-16-2017, 10:52 PM   #447
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
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
jedidia is offline   Reply With Quote
Thanked by:
Old 10-17-2017, 12:10 AM   #448
llarian
Orbinaut
 
llarian's Avatar
Default

Quote:
Originally Posted by jedidia View Post
 Try integrating python into C++, and you will see very quickly why Lua is usually prefered
So I've heard. I was just being selfish, I guess. Besides, it is an opportunity to learn more.
llarian is offline   Reply With Quote
Old 10-17-2017, 06:55 AM   #449
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 Try integrating python into C++, and you will see very quickly why Lua is usually prefered
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.
Urwumpe is offline   Reply With Quote
Old 10-17-2017, 07:59 AM   #450
kuddel
Donator
Default

Quote:
Originally Posted by Urwumpe View Post
 ... 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...
Code:
	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!
kuddel is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 04:34 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.