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

Hlynkacg

Aspiring rocket scientist
Tutorial Publisher
Donator
Just a heads up, found a possible new bug

Code:
double man_pitch = GetManualControlLevel (THGROUP_ATT_PITCHUP, MANCTRL_ROTMODE, MANCTRL_JOYSTICK);
Moves with the joystick x-axis even when linear control mode has been selected

Eduard

New member
That would be quite an essential piece of information. Can you try without the D3D9 client to see if you can reproduce the crashes? If it is reproducible, can you post a scenario?

Also, what makes you think that the problem is down to a memory leak? Do you crash due to running out of 32-bit address space? (which has been observed before, though this happens without memory leak, but because of over-enthusiastic application of memory-greedy render settings).
Ok, I have tried some things again now, I have created three scenariofiles and tested them. I have uploaded this files here:

> Eduard.scn: Standing on brighton beach, when using timewarp for a while at high speed, I get a CTD in the D3D9Client.

> Eduard1.scn: Transfer from Earth to Moon, using DG-S. When repeating I sometimes experience a CTD, but it's difficult to reproduce.

> Eduard1A.scn: A modified version of the previous scenario: I replaced the DG-S by Shuttle-A (and checked very well that I did it in the correct way).
Now I get much more CTD's, when using the D3D9Client with setting "linear interpolation".
To reproduce: 1. move the vessel with the RCS. 2. Killrot. 3. timewarp 1000x or 10000x.
With 1000x, I am still very far away from the moon and I already get a CTD.

I have tried to reproduce exactly the same CTD with the stock client orbiter.exe, but I do not see it there anymore.
But I still think it's very strange that the problem occurs much more frequently with the Shuttle-A version than with the DG. So I am not shure if we can say that it's only a problem of the D3D9Client.

And finally, I also noticed this: Sometimes when coming very close to the moon, the stock client also crashes sometimes, at least when using "linear interpolation". This could be a purely terrain related problem of course. I don't know. But it's important to know that this also happens with the stock client.

I hope this information helps you.

Attachments

• 2.9 KB Views: 7
• 4.1 KB Views: 0
• 4.1 KB Views: 3

jarmonik

Beta Tester
I suppose, you could zip and post the D3D9ClientLog.html from /Modules/D3D9Client/ right after a CTD has occurred. It might give some ideas about what's going on.

Eduard

New member
I suppose, you could zip and post the D3D9ClientLog.html from /Modules/D3D9Client/ right after a CTD has occurred. It might give some ideas about what's going on.
Ok. See the attachment, I have zipped the D3D9ClientLog.html together with the Orbiter.log here.

Attachments

• 10.2 KB Views: 3

jarmonik

Beta Tester
Ok. See the attachment, I have zipped the D3D9ClientLog.html together with the Orbiter.log here.
I get a log like that when Orbiter hits the 2GB memory limit. We would need to reduce a distant terrain resolution to bring down the memory consumption.

martins

Orbiter Founder
Orbiter Founder
I just realised that I had set the LARGEADDRESSAWARE flag for orbiter.exe, but not for orbiter_ng. This may explain why you get crashes with the D3D9 client, but not with the inline client. You could verify that by running the external D3D7 client, which should then be afflicted by the same problem.

I'll compile both orbiter.exe and orbiter_ng with the LARGEADDRESSAWARE flag for the next beta to see if that cures the problem (at least until somebody also hits the 4GB ceiling).

martins

Orbiter Founder
Orbiter Founder
New Orbiter Beta Released (r.53, Mar 23 2016)

Change log:
1. Both orbiter.exe and orbiter_ng now have been compiled with the LARGEADDRESSAWARE flag to provide a larger address space.
2. DeltaGlider: re-instated the atmospheric autopilot interface on the 2D panel (currently not yet accessible in VC)
3. Camera: ground mode should now again refer to local elevation instead of mean radius
4. Scenarios: Dissolved the 2010 Edition folder, added more 2016 Edition scenarios, including a re-recorded "Shuttle to ISS" tutorial (but need to finish annotations)
5. Bug fix: vessel-specific MFD modes did not load from scenario file
6. Bug fix: Playback scenarios: docked assemblies are now rigid relative to each other
Point 1 might have an effect on the problem in the preceding discussion.
Point 3 should address this issue.

This is the last update before the holidays. After Easter, I hope to upload the first release candidate fairly soon.

Loru

Moderator
Donator
Any plans of updating particle emmiters per this thread?

jarmonik

Beta Tester
There appears to be very rare CTD originating from elevation interpolation after all. Crash occur due to reading memory from offset -258 to pelev. I checked the interpolation mode after the crash and it was set to 'linear'. This occured with Orbiter rev. 52

Attachments

• 67.5 KB Views: 37

martins

Orbiter Founder
Orbiter Founder
Ok, thanks, I'll check it out. Shouldn't be too difficult to find. The 258 offset sounds like I subtracted a padding edge twice or subtracted padding from an unpadded pointer.

Any plans of updating particle emmiters per this thread?
Yes, but I think I'll leave it for a later update. If I keep adding features this release isn't going to happen, and i wanted to take advantage of the (relative) lull in bug reports. I hope this is down to the beta getting stable, but it's probably just because everybody is getting sick of bug reporting.

4throck

Enthusiast !
I hope this is down to the beta getting stable, but it's probably just because everybody is getting sick of bug reporting.
Not so sure. I'm in love with the Beta's terrain, but after I land I miss UMMU+UCGO. So I end up spending more time on Orbiter 2010.

Don't wish to discuss backward compatibility (specially since most issues are down to badly designed add-ons**) but I think it does have an influence on the amount of feedback.

** - Ex: Spacecraft4 example DG lands OK, but not other existing vessels. Copy/paste of landing points to the affected vessels gets stable landings with the craft "upside down". So.. those add-ons might be reversed regarding vessel coordinates, meshes, engine direction vectors, etc. This is not beta related, but it may show itself only now...

Eduard

New member
Let's report some bugs:
- When pressing Ctrl+0 or Ctrl+ to control the auxiliary pods of the Shuttle-A, the slide button on the 2D panel is not updated. I need to use F8 to switch to the other cockpitviews and back to get it refreshed. This is an old bug already present in Orbiter 2010.
- Radiator of the Deltaglider automatically closes after (re)starting a scenario.
- Parashutes of the Shuttle-A Payloads do not always close (go away) after landing.

Something else:
When starting Rev 53 with the Welcome to Orbiter 2016 scenario (first time start or later), it crashes inmediately. This scenario is not working anymore.
I already copied the hi-res textures to it before starting.

Last edited:

Face

Beta Tester
** - Ex: Spacecraft4 example DG lands OK, but not other existing vessels. Copy/paste of landing points to the affected vessels gets stable landings with the craft "upside down".
I've heard that vinka already has SC5 in stock, but it is not released yet. Perhaps he just waits for Martin to release Orbiter, which produces a cute little deadlock of sorts: SC4 not compatible with O2016 means less bug reports, but O2016 not being released means no SC5 which might fix problems as shown above, or even displays bugs that could be show-stoppers.

Maybe that scheme is also true for other projects?

jarmonik

Beta Tester
I'll compile both orbiter.exe and orbiter_ng with the LARGEADDRESSAWARE flag for the next beta to see if that cures the problem (at least until somebody also hits the 4GB ceiling).
Thanks for adding the LARGEADDRESSAWARE flag. I can confirm that it's working as expected, there is at least 3GB of memory available now and we should be doing fine with that pretty long. I also noticed that we had an implementation error in D3D9, the resolution bias range was -3 to 3 instead of -2 to 2 which pushed the memory consumption higher on maximum settings.

I also tried to designed my own LOD control function and quickly realized that there aren't any room for control since the tile levels must be matched with texture levels to get the textures appear nice and clear.

jarmonik

Beta Tester
Tile Resolution Bias

Based on what I have learned about the LOD control, I would say that the "tile resolution bias" setting is mostly about a calibration of the tile distance based LOD control function to match the texture resolutions. I have also added this slider in the D3D9Debug Controls from where it can be adjusted in realtime, although the setting isn't saved.

Here are three screen shots:

1st) The bias slider is in left most position: textures appear blurry due to under biasing.

2nd) When the bias is increased the yellow "arrows" behind the delta-glider as well as the far-end of the runway will appear naturally sharp.

3rd) The bias slider is pushed to right most position; the far-end of the runway is over sharp, the lines in a runway have partially disappeared and they are flickering/tearing due to over biasing like the terrain all around. If a mipmaps are enabled, then the far terrain is rendered using the second mipmap and the flickering/tearing won't appear.

Mipmaps will significantly increase loading times and runways may appear blurry when viewed from a very shallow angle.

In the screen shots, anisotropic filter is set to 16 and tile mipmaps are disabled. Mesh resolution is 32. Mesh resolution shouldn't have any effect to the resolution bias. The resolution bias will greatly effect in performance but as far as I can tell that's merely a side effect.

Attachments

• 164.9 KB Views: 77
• 347.1 KB Views: 65
• 368.7 KB Views: 191

jarmonik

Beta Tester
D3D9ClientBeta 22

Here is a new build for Orbiter Beta rev 53. Compiled with the LARGEADDRESSAWARE flag. There are some animation, MFD, configuration fixes as well as code optimizations. Also the statistics panel has been cleaned up Ctrl+Shift+C, nothing major.

EDIT: Report D3D9 related issues in the D3D9 thread.

Attachments

• 1.7 MB Views: 67

jarmonik

Beta Tester
There is a report of anomalous panel behavior in D3D9 thread. Seems to be effecting in inline and D3D9 in latest Beta and Orbiter 2010-P1. When the panel scale from a parameters tab is set to 2.0 some of the panels in XR2 and DGIV are not working. They are stretching instead of scrolling. Based on how it looks it's likely a problem in target rectangle while blitting a panel on screen. There's no change in target rectangle only in source rectangle.

Also, in stock delta-glider the main panel doesn't scroll up far enough to become fully visible (in that configuration panel scale 2.0)

DaveS

Donator
Beta Tester
One bug I have noticed with the default Atlantis is that the nose landing gear doesn't fully extend. I have checked things over and it seems to be due to a misplaced rotation point that causes this. Currently it seems to be at the mid-pöint of the actual NLG strut when it should be further aft, at the aft points of Y-branch.

Eduard

New member
Oke, I still have two questions:

- Is there a new way in the new beta how I can set the target base of the Surface HUD? Because changing the target base on a map MFD does not affect the HUD target base anymore. Or is this still something which yet has to be fixed?

- After a travel from Brighton to the Luna-OB1, I found this Wheel spinning extremely fast in all directions instead of rotating as it should do. So something clearly goes wrong with it.
And when I restart some other of my saved scenerio's and I select the Luna-OB1, i see the same problem.
Maybe it's onother a timewarp problem, I don't know.
Is this a known problem for anyone else?

B.t.w. still many, many thanks for all the work on Orbiter. It becomes more and more magnificent.