Orbiter BETA Lua development

[kuddel]

LuaScript 2017-10-30 DLLs

Hi folks,

another small increment in providing full Vessel API in Lua (see 1st post for source and new methods)

And it seems that I completely missed the whole point of this development, providing just the sources
People interested in Lua might not have fun in compiling C++ code, so I've attached the compiled DLLs here.

Make a backup of your original files if you like, 'cause the ZIP will overwrite these 4 files:
- \LuaInline.dll
- \LuaInterpreter.dll
- \Modules\Plugin\LuaConsole.dll
- \Modules\Plugin\LuaMFD.dll

Strictly speaking only LuaInterpreter.dll is needed, but the others have some minor bugfixes and enhancements (DEL Key in console... yeah!) as well.

These are compiled and linked against Orbiter BETA (rev. 71), so don't expect them to work with 2016.

Have fun,
Kuddel

 

[4throck]

Great! Yes, the .dlls are useful for many people. :tiphat:

 

[kuddel]

Hello again,

here's a question to all the Lua users (I am not ):
While documenting all the new features I asked myself whether the OAPI function get_viewport_size should really return a table, or if a Lua developer would expect it to return distinct values?

The difference in usage would be:

[COLOR="Green"]-- table ---[/COLOR]
data = oapi.get_viewport_size() [COLOR="Green"]-- data.w, data.h & data.bpp[/COLOR]

[COLOR="Green"]-- individual ---[/COLOR]
w = oapi.get_viewport_size() [COLOR="Green"]-- just the width[/COLOR]
w,h = oapi.get_viewport_size() [COLOR="Green"]-- width & height[/COLOR]
w,h,bpp = oapi.get_viewport_size() [COLOR="Green"]-- width, height & (optional) bits per pixel[/COLOR]

So here's your chance of influencing your API! :thumbup:

 

[BEEP]

Kuddel,

Thanks a lot for all you have done.I did a quick try but none of my codes worked so I have to do it more thoroughly when I have more time. Hope it is a deprecated function or something easy I'm able to solve.

By now I'd like to show my personal wishlist.

1. When used for a while and entered lines accumulate the terminal behaves erratically. This is a problem that the new version didn't solve. I'd like also to have a kind of 'cls' or 'term.out( string.char(12))' to clear the buffer and declutter the screen.

2. I'd like to have a mesh (or meshes) exclusively for pilot view, with their own animations, in order to be possible to do virtual 3D cockpits in Lua vessels.

3. We need a keyboard input callback for the Lua vessels as well so that we can activate animations ( gear, flaps ) and functions for these vessels.

With 2 and 3 above we're in the path for a 'scriptcraft' open source vessel that could use the legacy meshes and descriptors available and avoid obsolescence for this valuable material.

Beep

---------- Post added at 06:49 PM ---------- Previous post was at 09:03 AM ----------

Hello again,

... OAPI function get_viewport_size should really return a table, or if a Lua developer would expect it to return distinct values?


So here's your chance of influencing your API! :thumbup:

I'd say the better option is the one that more closely resembles the original C++ API. But any available (thanks) and documented (thanks thanks) one would be nice.

 

[kuddel]

1. When used for a while and entered lines accumulate the terminal behaves erratically. This is a problem that the new version didn't solve. I'd like also to have a kind of 'cls' or 'term.out( string.char(12))' to clear the buffer and declutter the screen.

I think my notes on oapi.get_annotations (see first post) are exactly what you need.

 

[BEEP]

Lua Console Window

I think my notes on oapi.get_annotations (see first post) are exactly what you need.

I think my reference to "declutter the screen" had you misleaded. Sorry!:facepalm:

I'm not talking about simulation onscreen messages ( the so called "annotations" ) but the lines and cluttering in the Lua Console Window itself.

This seems to be a problem related to keyboard input command lines and does not affect output lines generated by a term.out(XXXX) command. Try to type some lines and press <Enter> several times ( at least 30). You can type anything as receiving an 'Execution Error' response does not make any difference. You'll reach a point when the input line and cursor cannot be seen anymore and the terminal is useless. Then you press <Enter> dozens of times more and it appears again only to disappear after a line or two has been typed. What I'd like to clear is the memory of typed lines and reset its index ( and clear the display of earlier lines in the Lua Console Window). Or better still have an adequate console terminal behaviour. Also there's a point where the previous entered commands sequence memory disappears and cannot be called back with the 'arrow up' key which stands without action.

 

[kuddel]

I think my reference to "declutter the screen" had you misleaded. Sorry!:facepalm:

Yes it did :lol:

The issue you've described never came to me as I don't program Lua
I'll take a look at the terminal (LuaConsole) code and see what can be done.

something like the build-in 'help' command might be the way to go. But I would suggest something like 'clear-history' & 'clear-terminal' instead of 'CLS' (which would confuse not only me but many others as being CLear Screen).

When executed in a non-terminal context, these might perform as NO OPERATION.

Let's see what I come along with...

 

[kuddel]

LuaScript 2017-11-29 DLLs

Here's a test release.
Only change:
- added term.clear() function.

This is just a quick proof-of-concept build to see if you (BEEP) can use this.

Have fun,
Kuddel

 

[kuddel]

Sorry, but the last attachment contained a wrong LuaConsole.dll
I've exchanged it in this new attached pack.

 

[BEEP]

Thanks a lot, Kuddel.

I tested it ( the LuaConsole.dll only ) and the 'term.clear()' command works like a dream and helps a lot if you remember to enter it BEFORE the amount of entered lines lead to the problem I described ( cannot see the input line anymore , the vertical scroll becomes erractic a.s.o.).

If you enter the 'term.clear()' command AFTER your terminal is cluttered and the input line and cursor cannot be seen anymore it makes the whole sim crash and return to Windows.

If the input line is hidden how do you do it? Well,I typed 'term.clear()' carefully despite I could not see it. I repeated this procedure several times with the same result.

I hope this experience brings some light and leads to the solution of the bug.


Anyway, we are in a much better situation than the one we had before. Thanks!


Beep

 

[kuddel]

The issue with the current Terminal (LuaConsole) is, that is uses one single buffer for the screen and history storage

 0| term.out('a') << marked as 'input' & therefore considered 'history item'
 1| % a           << marked as 'output' & therefore *not* considered 'history item'
 2| ...
99|

The buffer is implemented as ring buffer, so when 100 lines have been added to the buffer, the "oldest" ones will be lost. Even for the history!

This is the current state. Maybe I'll separate history- and screen-buffer to see if that helps.

In the meantime I've tried to reduce the likelihood of crashes a bit, but that's definitely not the final solution!

Note: The attached DLLs were build using Visual Studio 2017, so if they don't run on XP or totally fail to load or ..., don't be alarmed
Although I hope these work as good (or bad :lol as the previous one.

/Kuddel


P.S.:
The ring buffer behavior can be easily "visualized" by these two:

term.out('-')
for i=1,90 do term.out(i) end
-- both commands will stay in history

term.out('-')
for i=1,100 do term.out(i) end
-- no more commands in history

 

[BEEP]

Despite I'm running on XP it didn't ask for VS2017 runtime pendencies ( I do not think I already have them) or anything and ran smoothly.

The crash to desktop problem is solved as far as I could investigate. So Lua Console operation and behaviour can always be reset to normal now because even if you can't really see the input line you can still blindly type 'term.clear()' and restore things back to functionality. Not an elegant solution but a solution where there wasn't any until this moment which is a nice and quickly achieved improvement. Thanks a lot.

 

[kuddel]

Another minor change ( Lua MFD now also understands term.clear() )

 

[kuddel]

@BEEP: Do you mind if I rename term.clear() into (even shorter)term.clr() ?
As I have to merge all my code into the new rev.73 of Orbiter BETA, I stumbled upon this one and thought "shorter might be better"...

 

[BEEP]

I myself do not mind but I sincerely think that, in this case where the word is already short, the benefit of having the whole, meaningful word is far more advantageous than the one achieved by just two characters less. I'd keep it term.clear() for semiotic and aesthetic reasons.

 

[kuddel]

LuaScript 2017-12-05 DLLs

Here's the result after porting to "Orbiter BETA rev.73"

No intended functional changes
I hope I didn't mess up to much during the porting.

Have fun,
Kuddel

 

[BEEP]

Following Lua API inclusions and exclusions

Another batch of vessel functions added.

A question to those who have experience in writing Lua C API (martin?):
Do you have any recommendation how to implement "reference types" (I mean structures that can be changed anytime and will immediately effect the Orbiter-Core.)
Like the BEACONLIGHTSPEC structure used with VESSEL::AddBeacon()
I think "metatables" and "__index" and all its voodoo ( ) is the way to go, but I don't feel I could do this at the moment...
A working (AddBeacon) C++ example would be perfect

---------- Post added 25-10-17 at 00:05 ---------- Previous post was 24-10-17 at 23:47 ----------

....aaaand as I wrote a script for myself to clearly overview all missing / not missing VESSEL API methods. Here's the result:

Legend:
1st column:
[ ] not (yet) available in Lua
[x] available in Lua
[-] depricated or obsolete (may or may not be available in Lua)
2nd column:
Orbiter C-Method name
3rd column:
Lua vessel function name


Should this maybe added to the 1st post?

Yeeeees please and keep it updated as I'm already having issues with the latest releases ( the carrier I just uploaded doesn't work anymore ).

I'll keep you informed as soon as I clarify the problems ( If I manage to do it ).

Beep

---------- Post added at 01:34 PM ---------- Previous post was at 12:10 AM ----------

Regarding your package for BETA r.73

I cannot extend now but my investigations pointed to a problem in the

vi:create_thrustergroup() ( going CTD)

that may be the reason none of my vessels work.

Could you check?

I may supply more info later.

Beep

 

[kuddel]

[Regarding your package for BETA r.73

I cannot extend now but my investigations pointed to a problem in the

vi:create_thrustergroup() ( going CTD)

that may be the reason none of my vessels work.

Could you check?

I may supply more info later.

Beep

Thanks for looking into that.
Could you provide a simple Lua script that used to work but crashes now?
As I can not find any real difference in (martins)0 implementation of create_thrustergroup between rev.64 and rev.73

/Kuddel

---------- Post added at 18:10 ---------- Previous post was at 18:00 ----------

...and the Example for the method...

v = vessel.get_focusinterface()

h1 = v:create_thruster({pos={x=-1,y=0,z=0}, dir={x=0,y=0,z=1}, maxth0=1e5})
h2 = v:create_thruster({pos={x=1,y=0,z=0}, dir={x=0,y=0,z=1}, maxth0=1e5})
hmain = v:create_thrustergroup({h1,h2},THGROUP.MAIN)

...works fine here

 

[BEEP]

Thanks a lot for your quick reply.

Entering your suggested code line after line in the Lua Console Window:

a) If using LuaInterpreter.dll and LuaInline.dll that come with the r73 BETA package everything works fine.

b) If using LuaInterpreter.dll and LuaInline.dll that come in the LuaScript 2017-12-05(dlls).zip you provided the sim hangs and shutdowns with the usual Windows message after pressing <Enter> at the last ("create_trustergroup" ) line.

Please try to run a scenario with the following (invisible) "vessel" with and without the last line.

--[[
ClassName = crashtest
Module = ScriptVessel
Script = crashtest.cfg
ImageBmp = 
END PARSE
--]]

function clbk_setclasscaps(cfg)

	hsmkprop = vi:create_propellantresource(1e6, 1e6 ,1.0)

	smkthr_prm = {
	pos = {x = 0 , y= 0  ,z= 0},
	dir={x=0,y=-1,z=0},
	maxth0 =1e-12,
	isp0 = 1e-3, 
	ispr = 0,
	hprop = hsmkprop
  }
  
	hsmkthr_0 = vi:create_thruster(smkthr_prm)

	vi:add_exhaust(hsmkthr_0,.01,.01,{x = 0 , y= 0  ,z=0},{x=0,y=0,z= 1})

	--Stream for the exhaust above
    exhaust_smk = {
		srcsize = 1,
		srcrate = 100,
		v0 =30,
		srcspread = .5,
		lifetime = 1,
		growthrate =5,
		atmslowdown = 0,
		ltype = PARTICLE.EMISSIVE,
		levelmap = PARTICLE.LVL_SQRT,
		atmsmap = PARTICLE.ATM_PLOG,
		amin = 1e-5,
		amax = 0.1
  }
	vi:add_exhauststream(hsmkthr_0,{x = 0 , y= 0  ,z= 0},exhaust_smk)

	
	--**PROBLEM  :-(    PROBLEM   :-(   PROBLEM**
	--Comment and uncomment with a '--' the line below
	hsmkthgrp = vi:create_thrustergroup({hsmkthr_0},THGROUP.MAIN)
end

Also the TGT_Fct_1.cfg from my Makeshift targets

https://www.orbithangar.com/searchid.php?ID=6793

makes a good example on this.

Remember I had already commented about problems with my addons in the past but I'm looking at them only now and so this problem may be not really new and appearing in r73 but may be in earlier versions and around for some time.

 

[kuddel]

Entering your suggested code line after line in the Lua Console Window:

Really? As copy and paste doesn't work, it's a recipe for failure
Nevertheless, I tried and it works (no crash)

a) If using LuaInterpreter.dll and LuaInline.dll that come with the r73 BETA package everything works fine.

b) If using LuaInterpreter.dll and LuaInline.dll that come in the LuaScript 2017-12-05(dlls).zip you provided the sim hangs and shutdowns with the usual Windows message after pressing <Enter> at the last ("create_trustergroup" ) line.

That simple test does not present the issue here, sorry

Please try to run a scenario with the following (invisible) "vessel" with and without the last line.

I have tried your code (just called the function and also stepped through the C-code with the debugger)

vi = vessel.get_focusinterface()
clbk_setclasscaps()

...but nothing failed / crashed. Even tried it several times (to find issues with previous created thrustergroups)

I would recommend to 1st try my attached DLLs and if they don't change the behavior, try a pristine Orbiter install (that fooled me, too)