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

[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
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 Code:

/***
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]

Quote:

Originally Posted by Abloheet

 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...
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....

PHP Code:

**** 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]

Quote:

Originally Posted by GLS

 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]

Quote:

Originally Posted by jacquesmomo

 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.

[GLS]

Quote:

Originally Posted by indy91

 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.

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º (just tested it with DG). So I also think the Earth is "too spherical".

[dbeachy1]

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

[indy91]

Quote:

Originally Posted by dbeachy1

 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]

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]

Quote:

Originally Posted by GLS

 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]

Quote:

Originally Posted by indy91

 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.