New Orbiter Beta Released (r.44, Dec 5 2015)

[martins]

Worse: when I open the simulation I find the atlantis some 50 meters above ground falling back, like it had bounced up to that height

Does this happen for all default Atlantis scenarios? There may be a few older scenarios still referencing the previous (single-vessel) version of the launch stack, but at least this one works for me:

Space Shuttle Atlantis | Atlantis Satellite Launch

Do you get the "50 meters above ground" problem also for this specific scenario? If so, there is something seriously out of sync. I haven't committed any of the Atlantis dlls to recent commits, since nothing should have changed for these, but maybe I need to do a complete commit next time.

Just to confirm: Your own vessel that experiences these problems - is that a single vessel, or a composite vessel consisting of multiple docked vessels?

Do you dynamically change the touchdown points during vessel setup, e.g. in clbkSetClassCaps?

What happens if you do this:

- Use the scenario editor to lift the vessel a few metres above ground
- Let it drop to the ground under its own weight
- Wait until the vessel settles on the ground, and its status goes to IDLE (Ctrl-I, section "State propagation")
- Then engage the engines for launch

 

[jedidia]

Does this happen for all default Atlantis scenarios?

I'm not getting this problem with any scenario.

 

[fred18]

Does this happen for all default Atlantis scenarios? There may be a few older scenarios still referencing the previous (single-vessel) version of the launch stack, but at least this one works for me:

Space Shuttle Atlantis | Atlantis Satellite Launch

Do you get the "50 meters above ground" problem also for this specific scenario? If so, there is something seriously out of sync. I haven't committed any of the Atlantis dlls to recent commits, since nothing should have changed for these, but maybe I need to do a complete commit next time.

ok sorry: the default atlantis scenarios work fine, I was trying this with the hst launch scenario inside the satellite and probes folder (for which I confirm the issue)

Just to confirm: Your own vessel that experiences these problems - is that a single vessel, or a composite vessel consisting of multiple docked vessels?

Single vessel

Do you dynamically change the touchdown points during vessel setup, e.g. in clbkSetClassCaps?

this is the touchdown point definition, it is done after setclasscaps because the module needs to read the initialization file first, so it is done in the loadstate.
this is the only part of the code where settouchdownpoints is called

VECTOR3 intdpts[3],tdpts[3];
intdpts[0]=_V(0,100,-stage[0].height*0.5-CogElev);
intdpts[1]=_V(86,-50,-stage[0].height*0.5-CogElev);
intdpts[2]=_V(-86,-50,-stage[0].height*0.5-CogElev);
 
 for(int j=0;j<3;j++)
 {		
tdpts[j].x=intdpts[j].x;
tdpts[j].y=intdpts[j].y*cos(VerticalAngle)+intdpts[j].z*sin(VerticalAngle);
tdpts[j].z=-intdpts[j].y*sin(VerticalAngle)+intdpts[j].z*cos(VerticalAngle);
 }

// this was for the Orbiter2010P1 
//SetTouchdownPoints(tdpts[0],tdpts[1],tdpts[2]);

//the following is for the beta
 TOUCHDOWNVTX td[3]={
	 {tdpts[0],3e7,3e2,3,3},
	 {tdpts[1],3e7,3e2,3,3},
	 {tdpts[2],3e7,3e2,3,3}
 };
 
SetTouchdownPoints(td,3);

What happens if you do this:

- Use the scenario editor to lift the vessel a few metres above ground
- Let it drop to the ground under its own weight
- Wait until the vessel settles on the ground, and its status goes to IDLE (Ctrl-I, section "State propagation")
- Then engage the engines for launch

with the above numbers for stiffness and damping the rocket falls into the terrain, turns itself upside down (with the nose pointing the center of the earth) and keeps bouncing "from downside terrain" never getting back to IDLE.

with the coefficients taken from atlantis the rocket does the same at the beginning: falls into the terrain. then it starts bouncing but this time on the correct side of the terrain, but still it never stops and never gets back to idle.

If I am the only one who has this sort of issues then I'll try to change something and solve it myself, I don't want to keep Mr Schweiger away from further developing the beta!

Thanks in advance for your time! :tiphat:

 

[martins]

I see that you are defining only 3 touchdown points, so not the entire convex hull (or an approximation thereof). This is the reason that the vessel sinks into the ground once it's upside down: its only connecting points to the surface are these three touchdown points, so it clings to the surface with its feet, so to speak, and lets the body dangle into the surface.

A complete convex hull (even adding just a few more points) should cure at least that problem, even if it may not do anything for the bouncing problem.

I'll check if resetting the touchdown points in the loadstate callback would cause problems.

 

[fred18]

I see that you are defining only 3 touchdown points, so not the entire convex hull (or an approximation thereof). This is the reason that the vessel sinks into the ground once it's upside down: its only connecting points to the surface are these three touchdown points, so it clings to the surface with its feet, so to speak, and lets the body dangle into the surface.

A complete convex hull (even adding just a few more points) should cure at least that problem, even if it may not do anything for the bouncing problem.

I'll check if resetting the touchdown points in the loadstate callback would cause problems.

one question: Let's say that I define the entire hull details as touchdown points, so some 50 points for examples. When I start the simulation for the first time, how does orbiter know which to use to make the vehicle sit properly on the ground?

 

[martins]

In general, there isn't an intrinsic "proper" orientation for a vessel to sit on the ground. Orbiter uses the rotation matrix stored in the scenario to determine how to place the vessel on the ground. If you save a scenario after you left a vessel upside down, it will still be upside down after you restart.

However, if no information about orientation is stored in the scenario, then Orbiter uses the first three touchdown points to define the plane (and normal vector) for placing it on the ground (the same way it was done in 2010-P1).

The first 3 points are special also because they allow to define two friction coefficients (longitudinal and transversal) for implementing landing gear. The other touchdown points only support a single (isotropic) friction coefficient.

 

[fort]

Hello,

Moon v2 (LRO LROC-WAC)

http://mirror.orbiter-radio.co.uk/orbiter/assets/moon.html

High-resolution pack for a small area of the planet surface:

MoonHi_05_00.zip
MoonHi_05_01.zip

are corrupted


Good day

:tiphat:

 

[martins]

Thanks. I've uploaded those again now. Let me know if you find any more corrupt ones.

 

[fort]

Let me know if you find any more corrupt ones.

Hello,

No, there is not. When i saw ( quand j'ai vu ) that there where two files corrupted, i made a test on all other files - the complete set - and everything is fine.

Good day

 

[martins]

Committed r.35

An incremental update, with most changes under the hood. However, one serious bug fix that could cause CTDs, so it should be worth the update.

Change log:

1. DeltaGlider: further code clean-up (obsolete methods and data removed)
2. DeltaGlider: VC: "dock seal" indicator added, nosecone ladder switch added
3. Bug fix: DeltaGlider: uninitialised variable in Fuel MFD could cause CTD on scenario start
4. Bug fix: base object shadows sometimes delayed after scenario start
5. Surface bases: launchpad textures now wrapped to surface elevation

 

[DaveS]

Martin could you take a look at this: http://www.orbiter-forum.com/showthread.php?p=506303&postcount=60

 

[martins]

Martin could you take a look at this: http://www.orbiter-forum.com/showthread.php?p=506303&postcount=60

Well, I agree that Vandenberg and Edwards would be nice to include, but these highres textures are extremely work-intensive (finding sources, map transformation, seam removal, colour-matching), and I don't think they are a show-stopper for the next release. So I'll put them down for a post-release update (unless somebody else does them as an addon).

 

[martins]

Committed r.36

Change log:

1. Bug fix: Atlantis: satellite attachment offsets were ignored
2. Bug fix: Atlantis: object attached to RMS arm in wrong position after simulation start
3. Atlantis: fixed RMS rotation references
4. Scenarios: fixed Satellites and Probes | Hubble Space Telescope | *
5. Bug fix: Launchpad video tab: GUI graphics corruption after entering non-numeric key in width or height field [issue #573]
6. Render window (windowed mode): minimum width and height set to 400 and 300 pixels.
7. DeltaGlider: airbrake control moved into aerodynamics subsystem

 

[Col_Klonk]

Not sure whether this has been mentioned.. and it might be a general 'flaw'.

In the Shuttle-A, if you dump/release the cargo containers, the surface friction is not high enough to keep them in position (moon/mars/anywhere).. and they move around - give them time they'll happily 'bounce' over the horizon :lol:

I've just noticed that releasing the containers is not recorded in the playback.. maybe missed the event.

 

[Topper]

I don't know if it's a bug in Orbiter or in Orbiter Sound, but the cockpit voices in the DG are swapped on my beta installation:
E.g., by retracting / extracting the gear, it calls "radiator deployed" and then "hatch open" or "radiator retracted" and then "hatch closed".

For "retrodoors open/closed" it calls "nosecone open/closed".
For...
Airbrake full it's saying "Ladder deployed" then "innerdoor open"
Airbrake retracted its "Ladder retracted" then "innerdoor closed" etc.

 

[jedidia]

ummm... I wasn't aware the DG had OrbiterSound support...?

 

[martins]

Committed r.37

Change log:

1. DeltaGlider: instrument lights and cockpit floodlights moved into light subsystem
2. DeltaGlider: elevator trim control moved into aerodynamics subsystem
3. Shuttle-A: overhead 2D panel reinstated (not fully functional yet)
4. Shuttle-A: added approximate touchdown convex hull for cargo pods
5. Shuttle-A: cargo release events now handled in playbacks

In the Shuttle-A, if you dump/release the cargo containers, the surface friction is not high enough to keep them in position (moon/mars/anywhere).. and they move around - give them time they'll happily 'bounce' over the horizon :lol:

I've now defined a convex touchdown hull for the Shuttle-A payload containers, and adjusted the parameters. It will still take some time for them to come to rest when released at speed and altitude over the moon, but they should now eventually settle.

I've just noticed that releasing the containers is not recorded in the playback.. maybe missed the event.

This should now be fixed.

ummm... I wasn't aware the DG had OrbiterSound support...?

Neither did I. Is this feature facilitated by an addon, or does OrbiterSound guess the DeltaGlider events directly? If so, how? I thought these customized cockpit sounds need to be explicitly defined and called by the vessel module.

 

[DaveS]

Martin, is ticket 601 of any priority? I believe this one dates all the way back to the Dec. '02 build as that was the first build that this was implemented in.

 

[jedidia]

Is it possible that DelAnimation() does not delete animation components in the proper order? If I use DelAnimation on a complex animation with parent child relations, I random-walk down memory lane.

If I manually delete all components using DelAnimationComponent() in the proper order (deleting children before parents) and then call DelAnimation, everything works fine.

The documentation of DelAnimationComponent mentions something along these lines (which gave me the idea to try it in the first place):

In the current implementation, the component must not have children belonging to other animations. Trying to delete such a component will result in undefined behaviour.

It is worded a little misleading, as "other animations" seems to talk only about parents that are in other animations, not in the same one, but it's still close enough to fit the bill.

If DelAnimation does not watch its parent-child relations when deleting its components, I'd suggest adding a note in the documentation.

Not really about the Beta, but since I'm already talking about animations, there's a little ambiguity as to whether an animation component takes ownership of its meshgroup pointer. I.E. can I count on it to delete it, or do I have to do that seperately if the group array is allocated on the heap?

 

[Matias Saibene]

I'm testing the sounds in the Shuttle-A, and these are my results:

Docking and undocking sounds: OK
Pods: OK
Thrust (main,hover,pod): OK
Gear: OK
Attitude switcher: OK
Dock port opening/closing voice: FAIL, plays the sound of "Outer door opening/closing"
Outer door opening/closing voice: FAIL, plays the sound of "Inner door opening/closing