Orbiter beta 121129

[martins]

A new Orbiter beta is available:

http://www.orbithangar.com/orbDownload.php?file=orbiter121129-100830diff.7z

This is a 7-zip diff to the 100830 release version. Install it by extracting over a (preferrably pristine) 100830 installation using 7zip, and overwite files when prompted.

A few notes to this beta:

• It contains an extensive rewrite of the internal state propagator code.
• This allowed to provide support for dynamic surface interactions, and replacement of the old 3-point touchdown definitions with "impact hulls".
• This in turn finally allows docked assemblies on the ground, by simply merging the impact hulls of all the components.
• The Atlantis code has been rewritten as an example for a docked assembly. It's not complete yet (amongst other things, ascent autopilot isn't supported yet)
• Using docked assemblies should make code for complex launch stacks simpler (no need for deleting/reassembling meshes, CG shifts, re-spawning jettisoned components as new vessels)
• It also makes writing autopilots a bit more challenging (and realistic), because the CG of the composite vessel will now shift continuously as fuel is consumed in the component vessels. Have a look at the "AutoGimbal" function in the Atlantis code for an example
• Various other changes and bugfixes. See patch.txt

Please note that the changes to the propagation engine were extensive and are still ongoing. As a result, this beta is not very stable yet (so consider it an alpha). A number of things may be broken, and backward compatibility with existing vessel code is not (yet) guaranteed.

I know a number of things that still require fixing, but I think it is at a stage now where input from addon developers and users will become useful, so here it is.

 

[sorindafabico]

Using docked assemblies should make code for complex launch stacks simpler (no need for deleting/reassembling meshes, CG shifts, re-spawning jettisoned components as new vessels)

Great!

 

[Zachstar]

Using docked assemblies should make code for complex launch stacks simpler (no need for deleting/reassembling meshes, CG shifts, re-spawning jettisoned components as new vessels)
It also makes writing autopilots a bit more challenging (and realistic), because the CG of the composite vessel will now shift continuously as fuel is consumed in the component vessels. Have a look at the "AutoGimbal" function in the Atlantis code for an example

Wow this sounds like it can make Velcro Rockets even better!

This is just my opinion and wishing out aloud here but Martins is it possible (Of course if Sputnik would allow so) by chance to use this to merge Velcro into the standard install and make it so config vessels can be built as Velcro?

I may be just getting overly excited here. However, With the new Orbitersound's system for defining sound events and this and of course the potential of the new OVP clients. I imagine a Renaissance of the add-on arts for Orbiter.

 

[SpaceShuttleFan]

Awesome... we'll soon be able to land Arrows with DGIVs/XR2s inside!

 

[n122vu]

Awesome... we'll soon be able to land Arrows with DGIVs/XR2s inside!

Agreed! Very exciting! :thumbup:

 

[IronRain]

Awesome, many thanks!

 

[N_Molson]

Many many thanks for your awesome work ! :hail:

This is just my opinion and wishing out aloud here but Martins is it possible (Of course if Sputnik would allow so) by chance to use this to merge Velcro into the standard install and make it so config vessels can be built as Velcro?

Velcro works with attachments which is quite different. Creating multistage rockets should be a child play now : basically you only have to assemble (in-simulation with the scenario editor if you want) different rocket parts à la KSP, then undock for stage separation ! I think this is pretty much a revolution.

 

[martins]

A few more details to the state propagator/surface impact updates:

The regime of the surface impact model is quite different to the "freeflight" mode. Forces change rapidly on a much smaller time or state vector scale. Surface impacts are therefore inherently unstable and require high sampling density. I've implemented time step subsampling support, and Orbiter will automatically switch to the highest order integrator and highest subsampling rate defined by the user (by default RK-8 and 100 steps by frame), as soon as a vessel is in ground proximity. This could lead to significant reduction in frame rate and may need some more tuning. Even so, at high time accelerations the dynamic impact code will deteriorate. I may have to switch back to the old "semianalytic" hack for surface impacts in these cases.

Since the impact events are so sensitive to state vector changes, linear and rotational state vectors are now always updated in sync, to make sure the intermediate states required by the integrators are valid. Therefore the linear and angular integrator stages can no longer be defined separately.

 

[RacerX]

Thank you Doctor Martin! :thumbup:

 

[sorindafabico]

I tried to run the beta (DG and Atlantis scenarios), but got a CTD.

Here's the log:

**** Orbiter.log
Build Oct 21 2012 [v.121021]
Timer precision: 6.98413e-008 sec
Found 0 joystick(s)
Devices enumerated: 4
Devices accepted: 3
[ ] RGB Emulation (SW)
[x] Direct3D HAL (HW)
[x] Direct3D HAL (Mobile Intel(R) 4 Series Express Chipset Family) (HW)
Module AtlantisConfig.dll .... [Build 121021, API 121021]
Module AtmConfig.dll ......... [Build 121021, API 121021]
Module DGConfigurator.dll .... [Build 121021, API 121021]
Module ScnEditor.dll ......... [Build 121021, API 121021]
Module Rcontrol.dll .......... [Build 121021, API 121021]
Module FlightData.dll ........ [Build 121021, API 121021]
Module ExtMFD.dll ............ [Build 121021, API 121021]
Module EarthAtm2006.dll ...... [Build 121021, API 121021]
Module EarthAtmJ71G.dll ...... [Build 121021, API 121021]
Module EarthAtmNRLMSISE00.dll [Build 121021, API 121021]
Module MarsAtm2006.dll ....... [Build 121021, API 121021]
Module VenusAtm2006.dll ...... [Build 121021, API 121021]

**** Creating simulation session
DirectDraw interface OK
Direct3D interface OK
Graphics: Viewport: Fullscreen 1280 x 800 x 32
Graphics: Hardware T&L capability: No
Graphics: Z-buffer depth: 32 bit
Graphics: Active lights supported: -1

 

[Spacethingy]

Active lights support = -1
Mobile Intel chipset

Try disabling local lights. That works for me; I'm on the same chipset as you I think...

 

[orb]

I tried to run the beta (DG and Atlantis scenarios), but got a CTD.

I can't reproduce your issue on a very old laptop not supporting hardware T&L, neither in windowed nor in full screen, with or without local light sources enabled (this works just fine for me with -1 supported lights since 100905). Did you run it on default settings? Does it close with some error dialog box, or just CTD?

 

[Urwumpe]

Epic!

(Sadly, this means more work for SSU to use the new features, but then, the new features feel worth it)

 

[4throck]

... basically you only have to assemble (in-simulation with the scenario editor if you want) different rocket parts à la KSP, then undock for stage separation ! ...

That's the logic behind many sc3 implementations of things like the Soyus / Shenzou with it's 3 modules. Each component is a separate vessel and should be treated as such.
The fact that you can land docked also makes things simpler.

Just hope that compatibility with multistage / sc3 is not broken. I understand that everything needs to move forward, but on a small community such as ours, time is limited to redo/fix things that were already done and functioned OK. :thumbup:

 

[boogabooga]

So, does this mean that if you impact, say, the moon, at high speed, you will stop, instead of bouncing and scraping along the surface indefinitely?

 

[Izack]

So, does this mean that if you impact, say, the moon, at high speed, you will stop, instead of bouncing and scraping along the surface indefinitely?

With the new higher sampling rate and inherent instability, my guess is that even more 'fun' will occur in extreme situations like that.

 

[orb]

It all now depends on stiffness and dumping of the new touchdown points. Vessels using the legacy touchdown points will most likely still bounce like they did, but I haven't checked that yet (I only used stock vessels).

 

[dansteph]

Maybe there is something wrong in my install (Installed over previous beta which was installed on a fresh 2010+P1) but in all scenario the Atlantis ready on launchpad Sky rocket without any command turning like a mad at mach 3 as soon as I launch the scenario. Also many "old style" ground object start to slide or sky rocket.

When the Atlantis land after some "elastic bounce" however it stop more realisticly than before.
UMmu slide on ground at 20km/h without stop on earth (2023 scenario) and sky rocket with any command. Cars make exactly the same. (2001 scenario slide without stop and sky rocket with any command issued)
The DeltaGlider and ShuttleA work fine. Landing on one side gear is much more realistic (but a bit rough given DeltaGlider's weight)

I had a computer freeze trying a side landing with an old style vessel with contact point.
It started to sunk in ground then complete computer freeze. (FullScreen)

 

[RacerX]

ok a couple of issues I have found. I read somewhere that the new beta may "break" some addons (using vanilla install with the typical ucgo,sound,ummu and ALL XR vessels)
1: XR1,XR2 crashes. Suspect it is the Dll's modules
2: (Orbiter beta specific) Go to any scenario and run then use scenario editor and change the "HOUR" in the date tab. Instant CTD

 

[dbeachy1]

1: XR1,XR2 crashes. Suspect it is the Dll's modules

I tested the XRs with the new beta last night and fixed the CTD. The cause was that Orbiter now invokes clbkLoadPanel before invoking clbkPostCreation, and the current XRs don't initialize their instrument panels until clbkPostCreation. The fix was to move the XR panel initialization code up to clbkSetClassCaps.

There is one more issue involving SetTouchdownPoints that is being worked on (landed XRs get bounced into deep space), but I'll upload some beta-compatible XR DLL zip files to my site once that is sorted out. :tiphat:

I'm also getting errors trying to play custom wav files in the beta using OrbiterSound 3.5. RequestLoadVesselWave3 succeeds, but then trying to play it with PlayVesselWave3 always fails (returns false). The default OrbiterSound sounds (e.g., base radar) work, though -- it's only sounds loaded with RequestLoadVesselWave3 that won't play. I'll retest that when the new OrbiterSound version is released, though.