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

[Hlynkacg]

Two questions regarding the new beta.

1 is it possible to find out how far the touchdown points are compressed so that I may animate my shock absorbers rather than deal with my landers legs sticking through terrain?

Further more what do the compression and dampening coefficients do and how do they relate to real world units.

2 How exactly does the panel text illumination work in the DG's vc I was under the impression that the inline client did not support transparent textures or local light sources for cockpits.

 

[martins]

Two questions regarding the new beta.

1 is it possible to find out how far the touchdown points are compressed so that I may animate my shock absorbers rather than deal with my landers legs sticking through terrain?

Not currently.

2 How exactly does the panel text illumination work in the DG's vc I was under the impression that the inline client did not support transparent textures or local light sources for cockpits.

It supports both. The floodlights are implemented with local light sources (won't work if you disable local light sources in the launchpad). The panel texts are done with transparent textures.

 

[Hlynkacg]

So with the panel text. Do you have 2 mesh groups overlapping? one for the background and one with the transparency. Or are you blitting the transparent texture onto the panel?

 

[Eduard]

Since the DG airbrakes are now working at two levels (1/2 and full) a single key function to deploy and retract didn't really work anymore.

Now it is Ctrl-B to deploy by one step, and Alt-B to retract by one step.

This should already be reflected in the DG manual, but maybe I forgot to push the latest revision of the manual to the repository.

Thanks, Alt+B works indeed. And I see the 2 step system now, that's usefull.
Maybe it's also a good idea to also make it visible in the HUD when the airbrake is set at 50%?

DirectX-7 doesn't support more than 2048x1536 (I think), so for larger resolutions you indeed need to use a different client.

Oh, alright. So it's a limitation of DirectX itself. That sounds logic to me. So Microsoft didn't make things compatible with the future.


To make clear what I meant about the MFD texts, see the following screenshot:


And now I remember that the same text problem also exist with some other texts, such as the orange texts in the "Challenge 4 - Entry and landing" and "DG to the moon" scenarios.
So I have to run Orbiter at a low resolution in order to make these scenarios working correctly, unless the fact that I am using the D3D9 client.
The SketchPad settings change didn't help against this problem, it only affects the MFDs.

I don't now it this is a problem of only the graphics client or Orbiter itself or both programs together, but hopefully this information is usefull for the developers of both programs.

 

[jarmonik]

To make clear what I meant about the MFD texts, see the following screenshot:

This issue will be fixed from the next release of the client.

 

[martins]

New Orbiter Beta Released (r.48, Feb 13 2016)

Change log:

1. SurfTile: bug fix: static array index overflow: could lead to visual artefacts and CTD during scene buildup
2. SurfManager2: bug fix: wrong mask bitflag for INT16 mod elevation tiles, resulting in visual artefacts
3. oapiCreateSurfaceEx: bug fix: attributes are now passed through to client
4. tileedit: some bug fixes related to propagation of elevation mod data to lower resolution tiles

There is also a new OVP commit (r.47) to go with this beta, which implements points 1 and 2 above.

I have also uploaded an updated diff file for the 10/08 high-res Earth texture tile: http://mirror.orbiter-radio.co.uk/orbiter/assets/packages/Earth/EarthHi_10_08_diff.7z. This contains a larger area of support for the KSC microelevation data, including flattening most (but not all) of the crawlerway from VAB to 39A and B. Also some of the spurious bumps at various launchpad locations have been flattened. More remains to be done (second KSC runway is still a rollercoaster). If you downloaded the previous version of this texture diff file, you should upgrade to this one, because the previous version contained a few corrupt elevation mod tiles at lower resolution that could lead to visual errors (related to point 4 above).

If you didn't download the previous diff, you can still install this one, but be aware that the high resolution Earth textures must be present in your Orbiter installation beforehand (either the full highres package, or the 10/08 tile from the map picker).

 

[martins]

New Orbiter Beta Released (r.49, Feb 14 2016)

Change log:

1. SurfTile::ElevationData: bug fix: incorrect ancestor query at 64-node tile resolutions for low-resolution tile requests
2. Tile::CreateMesh_hemisphere: bug fix: incorrect elevation indexing for non-32 node tile resolutions

Some more bug fixes I just spotted, related to the new higher-resolution surface patch meshes. This time the bugs created visual artefacts particularly evident for lower-resolution objects (Phobos, Deimos, Vesta).

OVP r.48 implements these bug fixes in the D3D7 client.

 

[SolarLiner]

Maybe a known issue, but TransX doesn't work on my end on the latest revision, as well as the one before it.

 

[Ripley]

Latest Enjo's TransX?

 

[jroly]

Maybe a known issue, but TransX doesn't work on my end on the latest revision, as well as the one before it.

It still works fine with the latest Orbiter beta, but it is the updated version which you probably do not have. Not sure if it is an update for just for the beta but an number of MFD's were upgraded to work with the beta including areobreak and basesync etc if I remember correctly.

 

[Ripley]

Enjo's goodies for Orbiter beta:

http://enderspace.de/orbiter/addons-beta/
http://www.orbiter-forum.com/showthread.php?p=514516&postcount=7

 

[SolarLiner]

It still works fine with the latest Orbiter beta, but it is the updated version which you probably do not have. Not sure if it is an update for just for the beta but an number of MFD's were upgraded to work with the beta including areobreak and basesync etc if I remember correctly.

Enjo's goodies for Orbiter beta:

http://enderspace.de/orbiter/addons-beta/
http://www.orbiter-forum.com/showthread.php?p=514516&postcount=7

Oh so it's not an official update then. Thanks! it is working now
EDIT: Actually not working. Checked them in the Modules tab, but no MFD appearing on the list, except for HUD Drawer, which CTD's after I press a button.

 

[Eduard]

This issue will be fixed from the next release of the client.

Oh, I see, I am running your posted D3D9ClientBeta17f-forRev47 in the D3D9Client Development thread now.
It's working great: all MFD-texts are visible. Also all of the on screen orange texts are visible now.

I have yet one other question:
Are certain bugfixes still made to the version for Orbiter 2010-P1 too?
I don't know how the development process exactly works with this, but it would be great if this text problem could also be solved in the version for Orbiter 2010-P1.

 

[martins]

New Orbiter Beta Released (r.50, Feb 20 2016)

Change log:

1. Recompiled transx.dll
2. Session startup: change in callback sequence: Module::clbkSimulationStart is now called after VESSEL::clbkPostCreation to avoid dirty docking state parameters during clbkSimulationStart (caused CTD with OrbiterSound when starting with docked focus vessel)
3. Session shutdown: skip unregistering external camera controls if camera instance has already been deleted (caused hangup when TrackIR module was active)
4. tileedit: fixed typo that would cause errors during elevation mod tile writing

To point 1: this refers to the original transx code that hasn't changed since Orbiter 2010. It should no longer crash, but you may still want to replace it with a more recent transx version for bug fixes and any new features.

To point 2: With this beta, OrbiterSound should no longer crash when starting with a docked focus vessel. The problem had been caused by dirty docking parameters during Module::clbkSimulationStart. I fixed this by changing the callback sequence during session start so that VESSEL::clbkPostCreation (which initialises the docking references) is now called before Module::clbkSimulationStart. Note that this change could potentially have side effects for other addons, although that shouldn't be likely. But check anyway if your favourite addons behave differently with this beta.

The Orbitersound callouts for the default DG are still wrong ("Gear down" on full throttle, etc.) but since these callouts are probably generated via hooks into the executable, this can only be fixed by the Orbitersound author.

 

[fort]

Change log:
With this beta, OrbiterSound should no longer crash when starting with a docked focus vessel.

Thank you.

:tiphat:

fort

 

[jedidia]

Perhaps this is the wrong place to post this, but could you make a setting that makes the physics rate completely separate from the display rate so that lags in the display does not affect simulation stability?

Given that by necessity the only moment when you can actually do calculations is when you're not rendering anything, that sounds nearly impossible. There is an option to use fixed time steps, which is essentially a fixed framerate when your computer can process the number of frames alright, but as soon as it can't, it means time passing asynchronous to reality... i.e. 0.033 seconds might pass although your computer needed 0.04 seconds to render the frame.

---------- Post added at 10:38 PM ---------- Previous post was at 10:23 PM ----------

Note that this change could potentially have side effects for other addons, although that shouldn't be likely. But check anyway if your favourite addons behave differently with this beta.

I couldn't currently think of any add-on more sensitive to callback sequence than IMS2, and I was a bit worried, but am glad to report that the change has left it unaffected for as far as I can tell.

 

[martins]

New Orbiter Beta Released (r.51, Mar 04 2016)

Change log:

1. Scenarios: started adding 2016 Edition scenarios
2. Camera: more camera control options from C++ and Lua API (demonstrated in 'Welcome to Orbiter 2016' scenario)
3. Bug fix: Glass cockpit: MFD button pressed status was carried over to new MFD mode after mode change
4. Vessel: Idle test now less sensitive and less framerate-dependent, should fix vessels failing to set idle status
5. Playback: if system event stream switches to the cockpit of a non-focus vessel, the vessel is now made the focus vessel (otherwise the cockpit was not correctly initialised)

 

[Hlynkacg]

Is it possible to set polar vector for cameras now?

 

[martins]

Is it possible to set polar vector for cameras now?

I am not 100% sure what you are referring to. Depending on camera mode, you can define the camera direction, or the position of the camera relative to a target, via azimuth and polar angle. If you are referring to additionally rotating the camera around its longitudinal axis, that isn't possible.

Effectively, the beta hasn't changed any of the underlying capabilities of the camera, but access to these capabilities from the API. So I would tentatively answer no to your question.

 

[martins]

There shouldn't be any change while it is moving, but maybe you reset the subsampling frequency when installing the beta.