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

[4throck]

Orbiter Lua sub-forum would be great.
Currently we can only add a LUA prefix to a threat inside "SDK".

 

[kuddel]

Hi,
the LUA enhancement discussion will continue here

To the moderator(s): It might be nice if the last X posts regarding LUA might get moved there. (...and the Python vs. C vs. Lua rant might go to the basement )

 

[GLS]

I've started to look at the terrain editing in SSU again, and noticed some potential conflicts with the "Elev_mod method" of changing the terrain elevation. Let's say in SSU we level a runway area somewhere, and then another addon has, for example a pyramid :shrug:, somewhat far away. If the terrain editing is done correctly, both changes are propagated up, and eventually they will be on the same time tile... which I guess would make the addons incompatible.

Wild idea (not claiming it to be original): why not extend the surface base "Context" scheme to the edited tiles, so that different addons with different tile edits could co-exist? Adding this to the existing Elev_mod architecture probably won't be easy. :uhh:

Another wild idea* (also might not be original): in addition to the "Elev_mod method", why not allow something like a "Elev_patch method"? The user would create a sort of mask of the changes, thus making those changes impervious to future base tile changes.
I could create my pyramid, and instead of the rest of my edited tile keeping the base terrain, it would have a sort of "NULL value" meaning those areas are unchanged. This could also work in conjunction the previous idea.

*) assumes tile architecture won't change

 

[martins]

Another wild idea* (also might not be original): in addition to the "Elev_mod method", why not allow something like a "Elev_patch method"? The user would create a sort of mask of the changes, thus making those changes impervious to future base tile changes.
I could create my pyramid, and instead of the rest of my edited tile keeping the base terrain, it would have a sort of "NULL value" meaning those areas are unchanged. This could also work in conjunction the previous idea.

This method may already be possible with the current elevation tile format.
The "Elev_mod" layer does support a mask flag in the elevation tiles. Any pixel containing a mask flag is ignored, and the original value from the "Elev" layer is used instead.

So if you have two separate edits that eventually end up on the same downsampled tile, these could be resolved without conflict by merging the tiles so that a non-mask value always takes precedence over a mask flag. Conflicts would only arise when trying to merge two non-mask pixels.

I'm not quite up to date as to the current status of tree-merging tools, if any (treeman?) It would be up to the merging tool to correctly merge masked tiles.

This only applies to elevation trees. For texture trees there currently isn't a mod layer with mask support.

 

[GLS]

So if you have two separate edits that eventually end up on the same downsampled tile, these could be resolved without conflict by merging the tiles so that a non-mask value always takes precedence over a mask flag. Conflicts would only arise when trying to merge two non-mask pixels.

From the user point of view this isn't very friendly, as one would have to list the tile conflicts and merge each pair when a new addon is installed. A system that could isolate each addon's changes would be much easier for the user to handle. Maybe something like this:

Earth\
----Elev_mod\
--------15\ << (existing) default mod, overwritten by any loaded context mod
------------000582\
----------------001739.elv
--------SSU\ << SSU context mod, loaded only when Context SSU is present in the scenario
------------15\
----------------000582\
--------------------001739.elv
--------NASSP\ << NASSP context mod, loaded only when Context NASSP is present in the scenario
------------15\
----------------000582\
--------------------001739.elv

This would also apply to surface textures.

About the mask bits in Elev_mod, tileedit doesn't do that, right?

 

[martins]

About the mask bits in Elev_mod, tileedit doesn't do that, right?

I thought it does. When you start modifying an elevation tile, tileedit would start with an Elev_mod tile completely masked out. Only the pixels that are overwritten have their mask flag replaced by an explicit value, and only if it differs from the original value.

 

[Face]

I'm not quite up to date as to the current status of tree-merging tools, if any (treeman?)

"treeman" doesn't support merging yet.

 

[GLS]

I thought it does. When you start modifying an elevation tile, tileedit would start with an Elev_mod tile completely masked out. Only the pixels that are overwritten have their mask flag replaced by an explicit value, and only if it differs from the original value.

For some reason I thought it made a copy of the tile and played with it. :facepalm:
Thanks! :thumbup:

 

[martins]

SVN commit #72+#73

I just uploaded a new commit. This is nearly entirely concerned with the Lua script interface. It contains the initial step of a restructuring of the interface code, by separating the vessel class methods in a separate module file.

I've also unified the checks for input parameters. For example, all vessel class functions fail now if they don't provide a valid vessel object (rather than returning nil), and consistently check for input parameter types.

All the documentation in the vessel class file is now inline, and formatted for ldoc (Lua documenting system). The output of compiling the help files can be seen in Orbitersdk\doc\orbiter_lua.chm.

If you want to compile the help files yourself, you have to install ldoc. Note that I had to hack the ldoc code a bit to suppress the output of function parameters in the function list at the top of the help page (which made the list look really ugly).

There is a unit testing script for the Lua interface in Scenarios\Tests\unit_test.scn. It's very incomplete so far, but should give an idea of a test format for the interface functions.

This commit is mainly for the benefit of people working on the Lua interface (that is to say, kuddel :thumbup, to provide a framework for documentation.

I haven't incorporated kuddel's work on the interface yet, but I am planning to work on that next.

 

[kuddel]

Hi Martin,

It contains the initial step of a restructuring of the interface code, by separating the vessel class methods in a separate module file.

That's nice. I love a clean structure. If you give me a little time, I'll "merge" my changes into the new file-structure...

I've also unified the checks for input parameters. For example, all vessel class functions fail now if they don't provide a valid vessel object (rather than returning nil), and consistently check for input parameter types.

Yeah, a consistent behavior is another thing that Orbiter-Lua beginners might benefit from.

All the documentation in the vessel class file is now inline, and formatted for ldoc (Lua documenting system). The output of compiling the help files can be seen in Orbitersdk\doc\orbiter_lua.chm.

O.K. One little note about the .chm file: If you click on a "basic" type link (e.g. 'string') you are lost in the Lua documentation, with no elements to navigate back. This might get annoying...Since you've already hacked the ldoc code, you might be able to fix this too.

If you want to compile the help files yourself, you have to install ldoc. Note that I had to hack the ldoc code a bit to suppress the output of function parameters in the function list at the top of the help page (which made the list look really ugly).

For general "ldoc syntax verification", I think the "un-hacked" version will be enough, right?

There is a unit testing script for the Lua interface in Scenarios\Tests\unit_test.scn. It's very incomplete so far, but should give an idea of a test format for the interface functions.

Great! I love unit- / regression-tests.
Not sure how to set up more complex tests, but the general "setup - assert - teardown" approach is very well suited for most of the functionality. Let's see if I add some tests, too.

This commit is mainly for the benefit of people working on the Lua interface (that is to say, kuddel :thumbup, to provide a framework for documentation.

Yeah right, more work for Kuddel ... :lol:
No really: It's better that I can (try to) document the parts directly where I've coded it. Most of the vessel API methods documentation will be a copy of the Orbiter-APIs documentation, except for some needed additional information specific for the Lua interface.

I haven't incorporated kuddel's work on the interface yet, but I am planning to work on that next.

As mentioned above: If you give me a little time, I'll "merge" my changes into the new file-structure. Although possibly not documented, but still more easy to incorporate then.

So to avoid "double work", I would like to merge my work on top of rev. 73 and upload that to the threads first post.
In case you've already started to do that, drop me a quick note.

/Kuddel

---------- Post added at 14:58 ---------- Previous post was at 09:14 ----------

Hi Martin,
it seems that proc.wait_sysdt() and proc.wait_simdt() are not (yet) available when I start the "Tests/unit_test" Scenario , right?
The "unit_test" script will not work well without them
I seems that oapi_init.lua is not working as expected anymore...
I get this error:
Script\oapi_init.lua:113: attempt to yield across C-call boundary

 

[martins]

[/COLOR]Hi Martin,
it seems that proc.wait_sysdt() and proc.wait_simdt() are not (yet) available when I start the "Tests/unit_test" Scenario , right?
The "unit_test" script will not work well without them
I seems that oapi_init.lua is not working as expected anymore...
I get this error:
Script\oapi_init.lua:113: attempt to yield across C-call boundary

Ah, ok. It did work for me, but admittedly that was from my development build, rather than the deployment build directory. Maybe something wasn't recompiled correctly. I'll check it out tonight.

Edit: I just checked out the latest commit to my PC at work, but didn't see the problem you describe. You do have to enable gravity gradient damping for the corresponding tests to pass, but other than that it seems to go through ok for me.

Did you check out a pristine version, or did you merge with your own edits? Is it possible that there could be a conflict with any of your modifications?

 

[kuddel]

gravity gradient damping is enabled, but that's not the issue here,
unit_test.lua stops as soon as it reached "proc.wait_sysdt(0.5)" in "function pass()".
I could work around this by just removing that proc.wait_sysdt()-call,
but as soon as the test comes to "wheels-down & wait 7 seconds",...that work-around was not an option anymore

I'll have to check a pristine version to be absolutely sure!
...I am pretty sure somewhere on my Drive I have something like that

---------- Post added at 19:46 ---------- Previous post was at 17:18 ----------

I've checked again and sure enough a pristine version worked :thumbup:
Pristine version always helps

I assume the issue originated from incompatibilities with some LIBs/DLLs I had installed to use this Lua Debugger.

---------- Post added 05-12-17 at 12:27 ---------- Previous post was 04-12-17 at 19:46 ----------

Hi Martin,

I've ported my changes based on rev. 73 of Orbiter BETA and uploaded it to the first post of the Orbiter BETA Lua development thread (LuaScript 2017-12-05.zip).
This hopefully helps.

Note, that the added functions do not contain any documentation (yet), as I am not 100% familiar with the ldoc syntax.
I'll add documentations as soon as I find the time.
Specifically I have not yet learned how to document "multiple" possible return values...

Maybe you could write as an example how the documentation for Interpreter::v_get_status should be, so that it looks O.K.

Here's my dumb approach:

/***
Returns the vessel's current status parameters in either a VESSELSTATUS structure or in a
VESSELSTATUSx structure (version x >= 2).

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)

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

A 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) // fields [1]...[9] from C-API are ignored
- "fdata" number)  //   "     "     "   "      "   "     "
- "flag" (number)  //   "     "     "   "      "   "     "

Example:
	v = vessel.get_focusinterface()
	v:get_status()  -- returns a VESSELSTATUS2 table
	v:get_status(1) -- returns a VESSELSTATUS table
	v:get_status(2) -- returns a VESSELSTATUS2 table

@function get_status
@see defset_status
*/
int Interpreter::v_get_status (lua_State *L)
{...}

Thanks in advance,
Kuddel

 

[Abloheet]

Won't the thread title get updated to r73?

 

[martins]

Won't the thread title get updated to r73?

Yes, thanks for reminding me.

 

[GLS]

Due to this issue I'm forced to use oapiEditMeshGroup() for animations (yes, I can tell it's very expensive), but performance aside, this introduces another "issue": when the original position of an animated group is outside of the screen, it disappears, even though it is very much in view... :facepalm:
Any chance one of these things gets fixed?
(didn't try MeshgroupTransform() as it only works in MOGE)

 

[JMW]

Hey Guys.

I'm coming in very late with this, but every revision after 65 (25/11/16) ctd on me at scenario startup.

Do I need to update VC Redistributable maybe ?

I have "Visual C++ Redistributable Packages for Visual Studio 2013" at present.

Orbiter log tells (me) nothing....

**** Orbiter.log
000000.000: Build Aug 27 2017 [v.170827]
000000.000: Timer precision: 4.27634e-007 sec
000000.000: Found 0 joystick(s)
000000.000: Devices enumerated: 6
000000.000: Devices accepted: 5
000000.000: [ ] RGB Emulation (SW)
000000.000: [ ] Direct3D HAL (HW)
000000.000: [x] Direct3D T&L HAL (HW)
000000.000: [ ] Direct3D HAL (Intel(R) HD Graphics 4000) (HW)
000000.000: [x] Direct3D T&L HAL (Intel(R) HD Graphics 4000) (HW)
000000.000: Module AtlantisConfig.dll .... [Build 170827, API 170827]
000000.000: Module AtmConfig.dll ......... [Build 170827, API 170827]
000000.000: Module DGConfigurator.dll .... [Build 170827, API 170827]

Thanks for any help

 

[GLS]

Question: could there be any issues in inputing, e.g., 2.71m elevation in tileedit when the elevation resolution is 1m (as in the released Orbiter 2016), or is it all rounded to the current resolution?

Request: could the tileedit "Erase modification" work with a continuous click (mouse pressed), like "Set value" does?

 

[jacquesmomo]

Request: could the tileedit "Erase modification" work with a continuous click (mouse pressed), like "Set value" does?

Yes, it works also with a continuous click

 

[GLS]

Yes, it works also with a continuous click

Here it doesn't....

 

[GLS]

I found what looks to be a 4 or 5m offset in the elevation data at about 78.88ºN, 33.88ºW. Several tiles show this offset starting at level 11 (39/71).
It's not that (visually) noticeable in the sim, but in tileedit the color contrast is very evident.