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

[fred18]

I am not really entirely sure I understand the program flow applied here, but from your description of the problem it seems that there is an inherent numerical instability somewhere.

One possible cause of the problem you describe could arise if you recalculate the touchdown points according to the rotation matrix for your vessel you retrieve from Orbiter. Note that due to the compressibility of the touchdown points, the touchdown points you define in the code do not coincide exactly with the surface in the vessel frame, but will end up slightly below the surface. And if the mass distribution is not exactly symmetrical with respect to the arrangement of the touchdown points (which it will never be in practice), then this will also result in a small tilt (i.e. some touchdown points more compressed than others.)

If you now recompute the touchdown points according to the vessel rotation matrix to place them exactly back onto the surface (i.e. undoing the compression), Orbiter will then reapply the touchdown point compression, including the resulting tilt. If you do this repeatedly, the touchdown points will be displaced further and further, until the rocket topples over. Is it possible that this is what happens?

Thank you very much for your reply!

Unfortunately that's not the cause but you pointed me in the direction of managing touchdown points and mass distribution. Now I'm experimenting with it. Mass is considered anyway concentrated in the baricenter, which is the origin 0,0,0 in local vessel frame, right?

Just to be clear I can say now that there were two separate issues (i thought they were totally the same, but it's not true):

The liftoff instability issue, which can be solved with what said above, if so, that was probably my fault, sorry to have bothered you.

But now after a lot of testing I can say that there is another sure issue, which is that the old methods of SetTouchdownPoints(VECTOR3 Pt1, VECTOR3 Pt2, VECTOR3 Pt3) simply doesn't work anymore.

If you use it the vehicles simply doesn't use the points you provided. When callig clbkSetStateEx it seems to forget the touchdown points specified and try to use something like the old method and that's related on the issue of the picture I posted yesterday.

 

[martins]

TUnfortunately that's not the cause but you pointed me in the direction of managing touchdown points and mass distribution. Now I'm experimenting with it. Mass is considered anyway concentrated in the baricenter, which is the origin 0,0,0 in local vessel frame, right?

Yes, but keep in mind that the ground is no longer guaranteed to be level, so the normal projection of the origin on the touchdown plane may not end up in the centre of your touchdown points.

But now after a lot of testing I can say that there is another sure issue, which is that the old methods of SetTouchdownPoints(VECTOR3 Pt1, VECTOR3 Pt2, VECTOR3 Pt3) simply doesn't work anymore.

If you use it the vehicles simply doesn't use the points you provided. When callig clbkSetStateEx it seems to forget the touchdown points specified and try to use something like the old method and that's related on the issue of the picture I posted yesterday.

Ah yes, this could point to a problem. The old version of the SetTouchdownPoints method, providing three individual vectors, is only retained for backward compatibility for older vessel code. It doesn't modify the first three points of an existing longer list, but completely replaces the entire list. It also substitutes default values for the elastic parameters of those three points, since the previous Orbiter version didn't have a concept for those.

So you should always use the new version of the SetTouchdownPoints function, providing the entire list for the complete convex hull. I don't currently have a method to selectively modify individual points within the existing list, but I guess this could be added if required.

I'll edit the documentation for those methods to make it clearer.

 

[fred18]

Just to close the loop I managed to have also the vehicle reset working: the key was to force the restoring of the status as active and not landed. In this way the equilibrium with the touchdown points was forced to be found again.

I therefore found out that if you have a vessel status with the flag status=1 (landed) and you use it for creating a vehicle with oapiCreateVesselEx or setting a vesselstatus with clbkSetStateEx touchdown points are ignored and the vehicle sits on its baricenter with a (random) rotation. If status is forced to be = 0 then equilibrium is found again.

I think that it is a useful information.

Thanks again for your availability!

 

[martins]

Committed r.39

Change log:

1. More tweaking of reentry stream parameters
2. DeltaGlider: modified undock lever in 2D PanelMouseEvent
3. Bug fix: DeltaGlider: CTD in 2D overhead panel
4. DeltaGlider: moved scramjet logic and scram throttle controls into scramjet subsystem
5. Bug fix: DeltaGlider: more uninitialised variables in FuelMFD with potential crashes

 

[martins]

Committed r.40

Change log:

1. MFD: old-style MFD modes (using HDC) now request HDC directly from surface, rather than via Sketchpad. Surface is allocated with OAPISURFACE_GDI flag. [issue #1208]
2. DeltaGlider: retro-cover and nosecone ladder switches added to 2D panel
3. DeltaGlider: 2D panel layout rearranged

 

[Matias Saibene]

A question: a bug related to Orbiter_ng.exe may also be published in the section of bug reports of Orbiter project?

 

[orb]

Yes, but of course if it's related to Orbiter core and not the graphics client (unless it's D3D7Client).

 

[jedidia]

MFD: old-style MFD modes (using HDC) now request HDC directly from surface, rather than via Sketchpad. Surface is allocated with OAPISURFACE_GDI flag. [issue #1208]

While you're tinkering with that, could you also take a look at #967?

 

[Matias Saibene]

Thank you for your quick response, in this case the bug is with the Atlantis shuttle, that does not work in Orbiter_ng.exe with D3D9 module activated.
But, when I retesting without the attached graphical client, now I think it is D3D9 client problem.

Has anyone experimented this?

In the event that is my mistake, someone can delete the report to maintain order?

Thank you.

 

[fred18]

Thank you for your quick response, in this case the bug is with the Atlantis shuttle, that does not work in Orbiter_ng.exe with D3D9 module activated.
But, when I retesting without the attached graphical client, now I think it is D3D9 client problem.

Has anyone experimented this?

In the event that is my mistake, someone can delete the report to maintain order?

Thank you.

I did. I was about to report it after a couple of further checks!

 

[Matias Saibene]

I did. I was about to report it after a couple of further checks!

Now, I'm sure that is not a problem Orbiter. Sorry for the inconvenience. I already denounced.

 

[Abloheet]

There is a problem in the Earth Hi 07_08 tile. A big white patch. Where did it come from?

 

[Abloheet]

 

[Weirdo Earthtorch]

It's cloud, which will be in the original dataset, and therefore 'baked' into the texture. You can see other straight lines along some of the other tiles showing less dense cloud in your screenshots. If you look at some of the Google Earth historic imagery, you see a lot of cloud captured. Particularly so in tropical areas where there is presumably a lot of cloud much of the time.

 

[martins]

Unfortunately, getting cloud-free Landsat imagery for certain areas isn't easy. I'm already sifting through the available scenes trying to find ones with low cloud index, plus some manual inspection. Also, my mapping algorithm tries to vote down contaminated pixels from overlapping scene areas. But in some places, all this still leaves cloud cover. It's called tropical rain forest for a reason.

For the Earth textures I am currently using the Landsat-7 (SLC-on) data set, which covers 1999-2003. Possibly with Landsat-8, in a few years there will be enough of a database to find scenes with lower overall cloud index in those areas.

 

[martins]

Committed r.41

Another small update:

1. MFD: fixed mismatched fonts for old style MFD definitions [issue #1208]
2. DeltaGlider: various 2D panel layout changes: updated navprog buttons, angular rate indicators
3. DeltaGlider: general code cleanup, added avionics subsystem as container for various instruments
4. Bug fix: DeltaGlider: one allocated surface was not correctly freed

 

[Abloheet]

oh ok. then that must be cloud. As the white patch is very very big, and it follows the mountain edge, also it is completely white, there are no variations in the white shade,... i thought that some tiles in my download were missing....

 

[4throck]

I'm already sifting through the available scenes trying to find ones with low cloud index, plus some manual inspection.

You need to use data from multiple scenes to clean up clouds + cloud shadows.

 

[Abloheet]

Ok. The Orbiter Core is now very stable. The only problem left seems to be about proper rendering of base objects through terrain. But what about the dg autopilot. Lua console and terminal mfd take inputs, but there are no outputs

 

[fred18]

If I may suggest one thing: would it be possible to have something similar to a parking brake, like the fsx one? If terrain is even a bit uneven it maybe difficult to stop vehicles. Or, on the other hand, a way to force the IDLE status of a vehicle. I think it can be useful now that the world is not flat anymore.

Thanks in advance for your attention.