- Joined
- Apr 1, 2008
- Messages
- 1,985
- Reaction score
- 468
- Points
- 83
Finally here's the Lua (sub-)Forum!
My current progress and questions regarding the Orbiter Lua API will be posted here.
I will update this 1st post with the current state, as soon as it changed.
New items (since last edit of this post) will be marked green
The attached file represents the current "work in progress" and might still contain some "todo"s.
The attached ZIP contains only files with changes to keep the ZIP-size small.
Almost all the added functions in the current ZIP (2021-03-30) have documentation.
Some of the documentation might not fit the 'LDoc-rules', 'cause I haven't installed LDoc.
2019-07-11: New source ZIP added, DLL package added
2019-07-08: As per request I've added builds (and sources) for Orbiter 2016, too
2019-07-11: New source ZIP added
2021-03-30: New build (fixes VESSEL::set_touchdownpoints issue)
2021-03-31: New build (and sources) for Orbiter 2016
For the time being, here are some documentation snippets/hints/details here.
Current status:
Terminal:
- term.clear()
OAPI:
Vessel-API:
// Coordinate transformations
Documentation details:
term.clear() :
This method clears the terminal window.
get_touchdownpoints :
This method uses a polymorphic approach.
If the function is called without any parameter, it will return three vectors representing the three touchdownpoints as per the "old" API.
If the function is called with an index as parameter, it will return the "new" TOUCHDOWNVTX table.
The TOUCHDOWNVTX table contains the following key value pairs:
set_touchdownpoints :
This method uses a polymorphic approach.
If the function is called with three vectors, it will perform the "old" API action.
If the function is called with one list (table) containing at least 3 TOUCHDOWNVTX tables, it will perform the "new" API action.
Example:
get_status :
This method can be used to get either the "version 1" VESSELSTATUS or the "version 2" VESSELSTATUS2 table.
The first parameter can be used to distinguish between these two:
The VESSELSTATUS2 table contains the following key value pairs:
The VESSELSTATUS table contains the following key value pairs:
Example:
defset_status :
This method can be used to set either a "version 1" VESSELSTATUS or a "version 2" VESSELSTATUS2 table.
The method distinguishes the type just by checking if the value of the ["version"] field in the given table equals 1 or 2.
This method only changes the values that are given in the table, any not mentioned values will not be changed!
Any "unknown" fields will be ignored.
Example:
oapi.deflate :
This function deflates (or packs) a string.
This function is called with one string (a bytes array, as Lua strings can contain binary zero as well)
oapi.inflate :
This methods inflates (or unpacks) a packed string that was packed by oapi.deflate() or by the according Orbiter core function.
The new tree-data files for example are packed this way.
This function is called with one string (a bytes array, as Lua strings can contain binary zero as well)
Example:
oapi.get_annotations :
This method returns a list of all currently created annotation handle objects.
This was added mainly as an option while debugging, as newly created annotation handle objects are not automatically deleted when running a script via the "run()" command. So each time a script was run ("run 'script'" rsp. "run('script')") the previous annotations were not cleared.
Here's an example how this method can be used:
This is functionally equal to the following code:
...just written a bit more 'cool' 
Another way of usage (to clear all 'old' annotation objects) would be:
Note: Current implementation in Orbiter BETA cannot print (via term.out) some of the "more complex" structures, so you might have to explicitly access sub-members like "term.out(vesselstat2.fuel[1])" or "term.out( #vesselstat2.thruster )"
My current progress and questions regarding the Orbiter Lua API will be posted here.
I will update this 1st post with the current state, as soon as it changed.
New items (since last edit of this post) will be marked green
The attached file represents the current "work in progress" and might still contain some "todo"s.
The attached ZIP contains only files with changes to keep the ZIP-size small.
Almost all the added functions in the current ZIP (2021-03-30) have documentation.
Some of the documentation might not fit the 'LDoc-rules', 'cause I haven't installed LDoc.
2019-07-11: New source ZIP added, DLL package added
2019-07-08: As per request I've added builds (and sources) for Orbiter 2016, too
2019-07-11: New source ZIP added
2021-03-30: New build (fixes VESSEL::set_touchdownpoints issue)
2021-03-31: New build (and sources) for Orbiter 2016
For the time being, here are some documentation snippets/hints/details here.
Current status:
Terminal:
- term.clear()
OAPI:
- oapi_get_orbiter_version()
- oapi_get_viewport_size()
- oapi_rand()
- oapi_getcolor()
- oapi.get_annotations()
Vessel-API:
- get_COG_elev()
- get_touchdownpointcount()
- get_touchdownpoints()
- set_touchdownpoints()
- get_clipradius()
- set_albedoRGB()
- set_clipradius()
- set_surfacefrictioncoeff()
- get_status()
- defset_status()
- get_angularacc()
- get_linearmoment()
- get_angularmoment()
- get_globalorientation()
- set_globalorientation()
- is_orbitstabilised()
- is_nonsphericalgravityenabled()
- get_surfaceelevation()
- get_surfacenormal()
- get_smi()
- get_argper()
- get_pedist()
- get_apdist()
- toggle_navmode()
- toggle_rcsmode()
- get_hoverholdaltitude()
- set_hoverholdaltitude()
- version()
- get_dragvector()
- get_forcevector()
- get_torquevector()
- add_force()
- edit_airfoil()
- dockingstatus()
- get_animation()
- del_animationcomponent()
- register_animation()
- unregister_animation()
- set_cameradefaultdirection()
- get_cameradefaultdirection()
- set_cameracatchangle()
- set_camerarotationrange()
- set_camerashiftrange()
- set_cameramovement()
// Coordinate transformations
- shift_centreofmass()
- shiftCG()
- get_superstructureCG()
- get_rotationmatrix()
- set_rotationmatrix()
- globalrot()
- horizonrot()
- horizoninvrot()
- local2global()
- global2local()
- local2rel()
- set_thrusterlevel_singlestep()
- set_nosewheelsteering()
- get_nosewheelsteering()
- set_maxwheelbrakeforce()
- set_wheelbrakelevel()
- get_wheelbrakelevel()
- trigger_panelredrawarea()
- trigger_redrawarea()
Documentation details:
term.clear() :
This method clears the terminal window.
get_touchdownpoints :
This method uses a polymorphic approach.
If the function is called without any parameter, it will return three vectors representing the three touchdownpoints as per the "old" API.
If the function is called with an index as parameter, it will return the "new" TOUCHDOWNVTX table.
The TOUCHDOWNVTX table contains the following key value pairs:
- "pos" (vector)
- "stiffness" (number)
- "damping" (number)
- "mu" (number)
- "mu_lng" (number)
set_touchdownpoints :
This method uses a polymorphic approach.
If the function is called with three vectors, it will perform the "old" API action.
If the function is called with one list (table) containing at least 3 TOUCHDOWNVTX tables, it will perform the "new" API action.
Example:
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[1] = v:get_touchdownpoints(0) -- NEW, 'cause index provided
arr[2] = v:get_touchdownpoints(1) -- NEW, " " "
arr[3] = v:get_touchdownpoints(2) -- NEW, " " "
v:set_touchdownpoints(arr) -- NEW, 'cause table with at least 3 TOUCHDOWNVTX tables given
This method can be used to get either the "version 1" VESSELSTATUS or the "version 2" VESSELSTATUS2 table.
The first parameter can be used to distinguish between these two:
- 1: Return "version 1" table
- 2: Return "version 2" table (default if no parameter is given)
The VESSELSTATUS2 table contains the following key value pairs:
- "version" (number) // always 2
- "flag" (number)
- "rbody" (OBJHANDLE)
- "base" (OBJHANDLE)
- "port" (number)
- "status" (number)
- "rpos" (vector)
- "rvel" (vector)
- "vrot" (vector)
- "arot" (vector)
- "surf_lng" (number)
- "surf_lat" (number)
- "surf_hdg" (number)
- "fuel" (list of tables) each containing a "idx" (number) and a "level" (number) member
- "thruster" (list of tables) each containing a "idx" (number) and a "level"(number) member
- "dockinfo" (list of tables) each containing a "idx" (number), "ridx" (number) and a "rvessel" (OBJHANDLE) member
- "xpdr" (number)
The VESSELSTATUS table contains the following key value pairs:
- "rpos" (vector)
- "rvel" (vector)
- "vrot" (vector)
- "arot" (vector)
- "fuel" (number)
- "eng_main" (number)
- "eng_hovr" (number)
- "rbody" (OBJHANDLE)
- "base" (OBJHANDLE)
- "port" (number)
- "status" (number)
- "vdata" (vector) // ignored [1]...[9]
- "fdata" number) // "
- "flag" (number) // "
Example:
Code:
v = vessel.get_focusinterface()
v:get_status() -- returns VESSELSTATUS2 table
v:get_status(1) -- returns VESSELSTATUS table
v:get_status(2) -- returns VESSELSTATUS2 table
This method can be used to set either a "version 1" VESSELSTATUS or a "version 2" VESSELSTATUS2 table.
The method distinguishes the type just by checking if the value of the ["version"] field in the given table equals 1 or 2.
This method only changes the values that are given in the table, any not mentioned values will not be changed!
Any "unknown" fields will be ignored.
Example:
Code:
v = vessel.get_focusinterface()
vect = { x=1, y=2, z=3 }
v:defset_status("dummy") -- <= results in error
v:defset_status({}) -- <= results in error (no ["version"] specified)
v:defset_status({ version=2 }) -- <= OK, but does not change anything
v:defset_status({ version=1 }) -- <= same as above (with "old" VESSELSTATUS)
v:defset_status({ version=2, port=666 }) -- <= will only change the port
v:defset_status({ version=2, port=666, foo="bar" }) -- <= same as above, all unknown fields will be ignored
v:defset_status({ port=666, arot=vect, version=2 }) -- <= OK as long as vect is a VECTOR; the order of the fields is irrelevant
oapi.deflate :
This function deflates (or packs) a string.
This function is called with one string (a bytes array, as Lua strings can contain binary zero as well)
oapi.inflate :
This methods inflates (or unpacks) a packed string that was packed by oapi.deflate() or by the according Orbiter core function.
The new tree-data files for example are packed this way.
This function is called with one string (a bytes array, as Lua strings can contain binary zero as well)
Example:
Code:
local inp = "Hello World!\nHello World!\nHello World!\nHello World!" -- input buffer
local pak = oapi.deflate(inp)
local out = oapi.inflate(pak)
term.out(#inp .. ' => ' .. #pak .. ' => ' .. #out)
term.out("Result: " .. tostring(inp == out))
oapi.get_annotations :
This method returns a list of all currently created annotation handle objects.
This was added mainly as an option while debugging, as newly created annotation handle objects are not automatically deleted when running a script via the "run()" command. So each time a script was run ("run 'script'" rsp. "run('script')") the previous annotations were not cleared.
Here's an example how this method can be used:
Code:
-- re-use 1st 'old' annotation object (if available)
local noteTop = oapi.get_annotations() or oapi.create_annotation()
Code:
local noteTop = oapi.get_annotations()
if noteTop == nil then
noteTop = oapi.create_annotation()
end
Another way of usage (to clear all 'old' annotation objects) would be:
Code:
-- delete any 'old' annotation objects
for key,value in pairs({oapi.get_annotations()}) do
oapi.del_annotation(value)
end
Note: Current implementation in Orbiter BETA cannot print (via term.out) some of the "more complex" structures, so you might have to explicitly access sub-members like "term.out(vesselstat2.fuel[1])" or "term.out( #vesselstat2.thruster )"
Attachments
Last edited: