Orbiter beta 121129

[martins]

A new Orbiter beta is available:

http://www.orbithangar.com/orbDownlo...-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]

Quote:

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]

Quote:

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]

Quote:

Originally Posted by SpaceShuttleFan

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

Agreed! Very exciting!

[IronRain]

Awesome, many thanks!

[N_Molson]

Many many thanks for your awesome work !

Quote:

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!

[sorindafabico]

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

Here's the log:

Quote:

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

Quote:

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]

Quote:

Originally Posted by sorindafabico

 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]

Quote:

Originally Posted by N_Molson

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

[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?