SDK Question Lua vessel script learning thread

[DaveS]

I thought I would start this thread to document and provide a central thread for discussing problems with creating vessels using Lua.

Right now my main problem is with an attachment point. It consistently makes the scenario that uses this vessel CTD whenever it is attached to a parent.

Here's the script file as it is right:

--[[
: This LuaScript vessel is used in the interim to simulate the 6 floodlights in the payload bay
: The lights are named after their positions in the bay
ClassName = SSU_PLB_floodlights
Module = ScriptVessel
Script = SSU_PLB_floodlights.cfg
END_PARSE
--]]

-- Basic Lua script section
function clbk_setclasscaps(cfg)
  vi:set_size(22.0)
  vi:set_emptymass(0.0001)--Dry empty mass
  vi:set_pmi({x=0.0001,y=0.0001,z=0.0001})
  vi:set_crosssections({x=0.0001,y=0.0001,z=0.0001})
  vi:add_mesh('Carina')
  hattach1 = vi:create_attachment({true,{x=0.0,y=0.125,z=3.15},{x=0,y=0,z=1},{x=0,y=1,z=0},{'XS'})
le = v:add_spotlight({x=10,y=1,z=0},{x=0,y=0,z=1},{range=200,att0=1e-3,
                      att1=0,att2=2e-3,umbra=0.3,penumbra=0.5},{r=1,g=0.8,b=0.7}) 
end

 

[Urwumpe]

The final parameter, the {'xs'} looks malformed, you wrap the string into a table with that syntax. Remove the { and }.

{ } Always initializes a new table.
{1,2,3} creates a table with the numbered elements 1, 2, 3 : if you set a variable x = {1,2,3} x[1] = 1, x[2] = 2, x[3] = 3.
{x=1, y=2} creates table with non-numbered elements x["x"] = x.x = 1

You can mix happily numbered and non-numbered elements, but x[1] is not the same as x["x"] then for example.

 

[DaveS]

The final parameter, the {'xs'} looks malformed, you wrap the string into a table with that syntax. Remove the { and }.

{ } Always initializes a new table.
{1,2,3} creates a table with the numbered elements 1, 2, 3 : if you set a variable x = {1,2,3} x[1] = 1, x[2] = 2, x[3] = 3.
{x=1, y=2} creates table with non-numbered elements x["x"] = x.x = 1

Thanks, fixed the CTD. Now it attaches just fine. For the "le" part of the light emitter definition, that's just the handle right? I can rename it without losing functionality of the light emitter?

 

[Urwumpe]

Yes.

Note that "le" is now local and not global. you can also define the variable as vi.le, this should add the variable as element to the table that acts as vessel interface.

 

[DaveS]

Now I have a problem activating the light emitter through the Terminal Console.

Here's the commands I use:

fv=vessel.get_focusinterface('SSU_PLB_floodlights')
spot=fv:get_lightemitter(0)
spot=activate(true)

It balks at spot=activate(true) with an execution error. Have I done something wrong here?

 

[Lucy]

You'd want to access the function of spot, rather than reset it to something else.

I'd try spot: instead of =, but I know no LUA at all.

 

[Urwumpe]

Yes, use

spot:activate(true)

instead, it is a simpler version for "activate(spot, true)", to imitate object orientation.

 

[DaveS]

Yes, use

spot:activate(true)

instead, it is a simpler version for "activate(spot, true)", to imitate object orientation.

No joy. Still balks even with spot:activate(true).

Here's the definition:

spot = vi:add_spotlight({x=10,y=1,z=0},{x=0,y=0,z=1},{range=10,att0=1e-3,att1=0,att2=2e-3,umbra=0.3,penumbra=0.5})

Is the definition incomplete or corrupted?

 

[Lucy]

Looks like you've got a ] on the end there, where did that come from?

 

[DaveS]

Looks like you've got a ] on the end there, where did that come from?

Well, it isn't in the actual script file, so possibly I accidentally included an extra "]" when I posted it between the code tags.

---------- Post added 08-21-10 at 12:13 AM ---------- Previous post was 08-20-10 at 11:44 PM ----------

Is there any other commands I can run it just to verify the integrity of the definition? Like checking the pos/dir of the spotlight?

 

[computerex]

I am getting a lot of issues with the lua interface myself. Random crashes, slow response, hardly any documentation, and essentially no feedback in what is wrong. I have been trying to mess around with the spotlight functions myself, but I just simply get a crash every time I try to invoke a emitter method.

 

[DaveS]

I am getting a lot of issues with the lua interface myself. Random crashes, slow response, hardly any documentation, and essentially no feedback in what is wrong. I have been trying to mess around with the spotlight functions myself, but I just simply get a crash every time I try to invoke a emitter method.

Well, I guess I should raise the issues in the beta forum on all things Lua for the next beta.

 

[computerex]

Well, I guess I should raise the issues in the beta forum on all things Lua for the next beta.

Yes, please. We at least need some documentation of the exposed API. And we need some feedback. There is nothing more annoying then seeing the most unhelpful execution error message.

 

[DaveS]

Yes, please. We at least need some documentation of the exposed API. And we need some feedback. There is nothing more annoying then seeing the most unhelpful execution error message.

Agree fully. I have posted a link to this thread in the beta forum, so hopefully it will get the attention it needs.

 

[martins]

Yes, please. We at least need some documentation of the exposed API. And we need some feedback. There is nothing more annoying then seeing the most unhelpful execution error message.

Excuse me, but I spent a fair amount of time writing the API documentation. What is missing?

Regarding error messages, you are welcome to modify the code to provide more evocative messages. However, this probably means that you need to bypass the Lua API parser and write your own, because all you get from the Lua parser is an error flag without any details. Rewriting the parser somewhat defeats the purpose of using a canned script interpreter.

 

[martins]

Well, it isn't in the actual script file, so possibly I accidentally included an extra "]" when I posted it between the code tags.

---------- Post added 08-21-10 at 12:13 AM ---------- Previous post was 08-20-10 at 11:44 PM ----------

Is there any other commands I can run it just to verify the integrity of the definition? Like checking the pos/dir of the spotlight?

Check that "spot" is a valid object (at least non-nil). Check that "vi" is a valid object. For example, your call to vessel.get_focusinterface has a superfluous argument. It probably doesn't hurt, but you never know. Did you check that the focus vessel has actually any light emitters defined? If you use an invalid index, it will return nil. Did you really want the focus object, or an object called 'SSU_PLB_floodlights'? In that case, you need a different function. Always read the documentation.

In general, if you hit a problem, check that your input arguments are valid. From just looking at your code it's hard to tell what is wrong, because we can't check the values of your parameters.

 

[computerex]

Excuse me, but I spent a fair amount of time writing the API documentation. What is missing?

Hi. I did not mean the Orbiter API documentation, which I think is fantastically documented. I meant that there is no lua specific documentation that I know of. That is to say, the lua interface to the Orbiter API. Currently I have been looking inside the Interpreter.h header to see which functions are exposed and to approximate their names. I don't know if such a documentation exists.

Regarding error messages, you are welcome to modify the code to provide more evocative messages. However, this probably means that you need to bypass the Lua API parser and write your own, because all you get from the Lua parser is an error flag without any details. Rewriting the parser somewhat defeats the purpose of using a canned script interpreter.

Ouch. I see your point, I didn't know this was the case. But it is going to be painful scripting for Orbiter without having any debug information. For instance, adding an extra t at the end of set_cameraoffset in the ScriptPB sample causes a crash to the desktop, without any feedback whatsoever. I don't know what could be done at this point, but I'll try to see if more information can be acquired from the interpreter. Something as simple as a line number will be enough.

 

[martins]

Hi. I did not mean the Orbiter API documentation, which I think is fantastically documented. I meant that there is no lua specific documentation that I know of. That is to say, the lua interface to the Orbiter API. Currently I have been looking inside the Interpreter.h header to see which functions are exposed and to approximate their names. I don't know if such a documentation exists.

$orbiterroot/Html/orbiter.chm (chapter "Orbiter scripting"). Also accessible via help(api) from the console.

Ouch. I see your point, I didn't know this was the case. But it is going to be painful scripting for Orbiter without having any debug information. For instance, adding an extra t at the end of set_cameraoffset in the ScriptPB sample causes a crash to the desktop, without any feedback whatsoever. I don't know what could be done at this point, but I'll try to see if more information can be acquired from the interpreter. Something as simple as a line number will be enough.

The problem is that the script is fed to the parser in its entirety, so when it fails with an error, there is no way of knowing where it tripped, as far as I can make out. Maybe you can figure out a way.

Note that certain types of error (e.g. arguments missing or wrong type) are caught by the corresponding orbiter script functions, but basic syntax errors fail directly in the parser and never make it to the function implementations.

 

[computerex]

$orbiterroot/Html/orbiter.chm (chapter "Orbiter scripting"). Also accessible via help(api) from the console.

Thanks for the hint, I thought it was strange to see no documentation. I looked in the wrong places :thumbup:

... but basic syntax errors fail directly in the parser and never make it to the function implementations.

As far as I know, lua is a fairly popular scripting language, it is hard to believe that it provides such little debugging capability. In any case, this seems interesting: http://www.lua.org/manual/5.1/manual.html#5.9

 

[Urwumpe]

Little debugging capability? :huh:

http://www.lua.org/manual/5.1/manual.html#5.9

It is a whole lot better than many other embedded languages.

Syntax errors can be caught and described... luaL_loadfile fails with a non-zero return value and you have a error number and a error string on the Lua stack.