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

#### Face

##### Addon Developer
Addon Developer
Beta Tester
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

##### Addon Developer
Addon Developer
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

##### Orbiter Founder
Orbiter Founder
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

##### Donator
Donator
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

Last edited:

#### martins

##### Orbiter Founder
Orbiter Founder
[/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

##### Donator
Donator
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:
PHP:
/***
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

Last edited:

#### Abloheet

##### Addon Developer
Addon Developer
Won't the thread title get updated to r73?

#### martins

##### Orbiter Founder
Orbiter Founder
Won't the thread title get updated to r73?

Yes, thanks for reminding me.

#### GLS

##### Addon Developer
Addon Developer
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

##### Aspiring Addon Developer
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....
PHP:
**** 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

##### Addon Developer
Addon Developer
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

##### Addon Developer
Addon Developer
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

Addon Developer

#### GLS

##### Addon Developer
Addon Developer
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.

#### GLS

##### Addon Developer
Addon Developer
I have a question about Orbiter 2016 and I hope this is the appropriate place to ask it.

Does Orbiter 2016 accurately model the Earth as an oblate spheroid and if yes, is the atmosphere modeled to fit the spheroid? I am asking about the shape here, not the gravitational model.

While working on the Virtual AGC for NASSP we have noticed that multiple programs have trouble with the spherical Earth in Orbiter 2010. For example, the program 22 of the AGC is used to track a landmark on Earth. As an input the program wants geocentric latitude, longitude and altitude above the Fischer ellipsoid. The AGC then calculates the position vector of the landmark from these inputs. For a landmark on the Earth, we kind of have to trick the AGC to make it work. The longitude is fine, but latitude and altitude have to be adjusted so the AGC finds the correct position of the landmark on the spherical Earth. In NASSP we have set the radius of the spherical Earth to the radius at Cape Canaveral.

Similarly the entry interface is defined as 400k ft altitude above the Earth. Again, the spherical vs. ellipsoid Earth is relevant in some calculations the AGC does. The AGC actually has a program to calculate midcourse corrections itself. For low latitudes at entry interface, where the radius difference is more pronounced, the maneuvers the AGC is calculating become increasingly inaccurate.

I have set a Delta Glider at different points on the Earth on oceans and the radius always seemed to be identical. So if despite the awesome terrain models in Orbiter 2016 the average shape of the Earth is still not an oblate spheroid, consider this a feature request. :thumbup:

I've been thinking about this, as part part of figuring out how the shuttle launched to a 28.45º orbit from a pad at 28.6º, and found that the pad is at 28.6º geodetic latitude, and at 28.45º geocentric latitude.
Thus, launching east produces a 28.45º orbit... but I get a 28.6º :uhh: (just tested it with DG). So I also think the Earth is "too spherical".

#### dbeachy1

##### O-F Administrator
Administrator
Moderator
Addon Developer
Donator
Beta Tester
Do you have "Nonspherical gravity sources" enabled in the Orbiter launchpad settings?

#### indy91

##### Addon Developer
Addon Developer
Do you have "Nonspherical gravity sources" enabled in the Orbiter launchpad settings?

This only influences the gravitational field of the orbital bodies, not the actual shape of the e.g. Earth in Orbiter. So the Earth will behave gravitationally as if it was non-spherical, but it doesn't change its shape.

#### GLS

##### Addon Developer
Addon Developer
Also about the "missing oblateness" of the planets: Jupiter and Saturn should be visibly flat at the poles, but are shown as spheres. It's probably not a case of functionality, like mentioned above for the case of Earth, but more a "visual issue".

#### indy91

##### Addon Developer
Addon Developer
Also about the "missing oblateness" of the planets: Jupiter and Saturn should be visibly flat at the poles, but are shown as spheres. It's probably not a case of functionality, like mentioned above for the case of Earth, but more a "visual issue".

For NASSP it is a functionality issue. The Apollo Guidance Computer assumes the Earth to be an ellipsoid (hardcoded, not configurable). And that geometry is used for the star/horizon measurements that can be done with the sextant for onboard navigation. All that basically works in NASSP, just the shape of the Earth doesn't properly cooperate and so we haven't been able to do onboard navigation that is accurate enough to be autonomous without the need to update the state vector in the AGC with external tools (MFDs). This is more of a "nice to have" feature, because onboard navigation was always just a backup during Apollo. I hope the right shape of the planets and moons etc. gets implemented in Orbiter at some point though.

#### GLS

##### Addon Developer
Addon Developer
For NASSP it is a functionality issue. The Apollo Guidance Computer assumes the Earth to be an ellipsoid (hardcoded, not configurable). And that geometry is used for the star/horizon measurements that can be done with the sextant for onboard navigation. All that basically works in NASSP, just the shape of the Earth doesn't properly cooperate and so we haven't been able to do onboard navigation that is accurate enough to be autonomous without the need to update the state vector in the AGC with external tools (MFDs). This is more of a "nice to have" feature, because onboard navigation was always just a backup during Apollo. I hope the right shape of the planets and moons etc. gets implemented in Orbiter at some point though.

In the Earth case it is a functionality, but I was saying that for Jupiter and Saturn it's a visual issue.