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

[Zach121k]

My only asking is that you add the other shuttle pad in

 

[martins]

My only asking is that you add the other shuttle pad in

How different were they in reality? I guess as a 0-th order approximation I could just replicate the 39B mesh in 39A.

 

[DaveS]

How different were they in reality? I guess as a 0-th order approximation I could just replicate the 39B mesh in 39A.

There's some differences in the hardstands as well as the FSS/RSS. For example, currently the new beta FSS/RSS is a blend of the two. The lightning mast structure is from the 39A post-2003 to 2006 mod period. The 39B lighting mast was still mounted over the remains of the old hammerhead crane.

39A lightning mast:

39B lightning mast:

The hardstand differences are quite obvious on Google Earth/Maps.

 

[Zach121k]

How different were they in reality? I guess as a 0-th order approximation I could just replicate the 39B mesh in 39A.

I always duplicated the mesh manually.

Any way to fix the inconsistency between 06 and 10/15 with coordinates?

The earth kinda shifted to the right

 

[martins]

Uploaded r.18 which allows to select the texture size for VC MFDs manually via Extra | Instruments and panels | MFD parameter configuration.

In the DX7 client, 512 x 512 is just about ok at 1920 x 1080 with 40deg FOV in the DG. 1024 x 1024 looks bad unless you zoom right in to fill the screen.

But maybe the DX9 client does a better job at interpolating / automatic mipmap filtering?

PS: There is also an update to the DX7 client on sourceforge fixing a bug causing crashes on rendering empty mesh groups.


Edit: Erm, committed too soon. I just noticed some problems displaying the MFD mode selection and button help pages. Will be fixed in the next commit.

 

[DaveS]

Is there still a 10 MFD limit in play?

 

[martins]

Submitted r.19. This should fix the aforementioned problems on the mode list pages. Also took the opportunity to replicate the LC39B meshes on LC39A. Eventually they should be individualised, but I guess for now it's ok (especially since as Dave pointed out, the structures are currently a mixture anyway)

Is there still a 10 MFD limit in play?

Yes, probably. Nothing has changed in that respect.

 

[DaveS]

Submitted r.19. This should fix the aforementioned problems on the mode list pages. Also took the opportunity to replicate the LC39B meshes on LC39A. Eventually they should be individualised, but I guess for now it's ok (especially since as Dave pointed out, the structures are currently a mixture anyway)


Yes, probably. Nothing has changed in that respect.

Could the limit be increased? The shuttle has 11 MDUs, 9 FWD and 2 aft and we need all of them working.

 

[martins]

Do they all have to work from every VC position? Wouldn't it be sufficient to activate those that can reasonably be operated from a given position? After all, updating MFDs does affect performance.

 

[Urwumpe]

Do they all have to work from every VC position? Wouldn't it be sufficient to activate those that can reasonably be operated from a given position? After all, updating MFDs does affect performance.

Well, if you need to display 9 during launch for the forward panels, the CRT4 is no longer a big penalty. The 11th MFD though is mostly needed for the transition from launch to orbit or from orbit to landing.

I think one big problem we had was related to switching MFDs on/off, which caused problems. The status of one MFD was suddenly transfered to others, making them show different display modes, because one MFD linked to one MDU suddenly became displayed in position of another and we can't control this right now.

Having 11 MFDs would make our job much simpler and could save us a lot of already existing black magic there. But as an almost working solution exists, it has no high urgency.

What could be more interesting for us for really improving performance would be a way to "scale" the MFD refresh rate - so MFDs further away from the camera could be rendered less often than the MFDs closer to the camera.

The DPS screens are for example updated only twice per second in the real Shuttle, while the PFDs and subsystem status displays have a much higher refresh rate. The vessels knows of course best, what MFD has a higher priority to rendering.

 

[martins]

Committed r.20.

- Max number of MFDs increased to 12. Untested, so please let me know if it works.

- Added oapiSetMFDRefreshIntervalMultiplier to modify the refresh rate of an MFD instrument. Also mostly untested. Note that currently there is a hard limit of 10Hz on the refresh rate (system clock). This is to avoid MFDs refreshing at every frame when using time acceleration.

Let me know of any problems with these features.

Well, if you need to display 9 during launch for the forward panels, the CRT4 is no longer a big penalty. The 11th MFD though is mostly needed for the transition from launch to orbit or from orbit to landing.

I think one big problem we had was related to switching MFDs on/off, which caused problems. The status of one MFD was suddenly transfered to others, making them show different display modes, because one MFD linked to one MDU suddenly became displayed in position of another and we can't control this right now.

Having 11 MFDs would make our job much simpler and could save us a lot of already existing black magic there. But as an almost working solution exists, it has no high urgency.

What could be more interesting for us for really improving performance would be a way to "scale" the MFD refresh rate - so MFDs further away from the camera could be rendered less often than the MFDs closer to the camera.

The DPS screens are for example updated only twice per second in the real Shuttle, while the PFDs and subsystem status displays have a much higher refresh rate. The vessels knows of course best, what MFD has a higher priority to rendering.

 

[martins]

Huh, I always thought that was only for 2010 p1 and preceding versions...

Well, there won't be any more updates to the 2010-P1 version, and any bugs still present there will remain forever. So de-facto the bug tracker now is for the beta version (which makes the title of the issue list a bit confusing, admittedly). By the way, to save me a bit of wild-goose-chasing, it would be good if anybody who finds a bug in the 2010 version can check if it is still present in the latest beta before posting a bug report.

Anyways, since updating I'm getting a worrying amount of random ctds while debugging. My code is certainly not without flaws, but it did run decently stable on the previous build.

I can't really make any rhyme out of the ctds since they happen pretty much anywhere in my code or in orbiter code (as I said, reeeeally random, rarely ever twice in the same location), but from the timing of their occurence I'd venture a guess that they have something to do with blitting textures or the panel redraw event in general (really not sure here, but it's the best I have).
Has anyone else expierienced a sudden peak in instability since the update when they were clicking around in a pannel, possibly while debugging?

Any news on the CTDs? Are they still present in the latest beta? I did fix one bug that could have caused crashes in the render engine (submitting zero-length vertex buffers to the renderer), but this would probably have caused problems directly at the program start.

Do you get similar problems both with the inline client (orbiter.exe) and the external clients (orbiter_ng + DX7 or DX9)? Did you spot any pattern that could help me homing in on the problem?

 

[jedidia]

Any news on the CTDs? Are they still present in the latest beta? I did fix one bug that could have caused crashes in the render engine (submitting zero-length vertex buffers to the renderer), but this would probably have caused problems directly at the program start.

I haven't noticed any unusual crashes anymore when working on it yesterday. It's possible you fixed it, or it's possible that something in my code was the problem after all. It was really more of a question whether other people experienced the same, because it started so suddenly after the update.

 

[aldarion]

Two graphics platforms and DirectX

Is it possible to add the additional ComboBox in the Video Tab to select not only the device but also the platform.

I have for example system with standard intel HD GPU and also the AMD Radeon 8870M.

On Video Tab I can only see and select the Intel HD.

Additionally, why do I have problems with Orbiter DirectX checking procedure?
I am using Windows 10 64bit.

Test 3: Checking DirectX
	Scanning dxdiag output:


Processor: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz (4 CPUs), ~2.4GHz
Memory: 16384MB RAM
DirectX Version: 12
Card name: Intel(R) HD Graphics Family
Card name: AMD Radeon HD 8870M
DirectX version >= 7 required!
For full DirectX diagnostics, see file dxdiag.log.
-----------------------------------------------------
Moving Orbiter executable into place.
Overwriting existing Install\testinstall.exe
-----------------------------------------------------
Orbiter installation verification complete.
Potential problems found.
Please examine the installation log file (install.log)
and fix the problems before launching Orbiter.

 

[Ripley]

...

...
Please examine the installation log file (install.log)
...

What does this file say?
Post it and let's have a look.

 

[aldarion]

Not much / the same as Orbiter.log

Orbiter installation verification.

w tests to verify a valid
Orbiter installation. Normally, this test needs to be executed
only once after installation. To run it again, execute the
'testinstall' utility in the Install subdirectory.
-----------------------------------------------------
Test 1: Directory structure
	Orbiter root directory:	F:\Gry\Orbiter beta
	Folder Config	 found.
	Folder Meshes	 found.
	Folder Textures	 found.
	Folder Scenarios	 found.
	Folder Doc	 found.
	Folder Script	 found.
	Folder Modules	 found.
	Folder Flights	 found.
	Folder Html	 found.
	Folder Install	 found.
-----------------------------------------------------
Test 2: C++ runtime libraries
	Runtime libraries ok.
-----------------------------------------------------
Test 3: Checking DirectX
	Scanning dxdiag output:


Processor: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz (4 CPUs), ~2.4GHz
Memory: 16384MB RAM
DirectX Version: 12
Card name: Intel(R) HD Graphics Family
Card name: AMD Radeon HD 8870M
DirectX version >= 7 required!
For full DirectX diagnostics, see file dxdiag.log.
-----------------------------------------------------
Orbiter installation verification complete.
Potential problems found.
Please examine the installation log file (install.log)
and fix the problems before launching Orbiter.

 

[MaverickSawyer]

Was running the into replay... is the shuttle supposed to topple over and scoot along the ground with only the SSMEs running? It's hysterical, but rather pointless...

 

[JMW]

Seems to be a problem with the checker.
Windows 10 64bit too.

Test 3: Checking DirectX
	Scanning dxdiag output:

Processor: Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz (4 CPUs), ~2.4GHz
Memory: 6144MB RAM
DirectX Version: 11.2
Card name: Intel(R) HD Graphics 4000
DirectX version >= 7 required!
For full DirectX diagnostics, see file dxdiag.log.
-----------------------------------------------------
Moving Orbiter executable into place.
Overwriting existing Install\testinstall.exe
-----------------------------------------------------
Orbiter installation verification complete.
Potential problems found.
Please examine the installation log file (install.log)
and fix the problems before launching Orbiter.

Here is my dxdiag.exe output

System Information
------------------
      Time of this report: 9/9/2015, 20:46:51
             Machine name: ASUS
         Operating System: Windows 10 Home 64-bit (10.0, Build 10240) (10240.th1.150819-1946)
                 Language: English (Regional Setting: English)
      System Manufacturer: ASUSTeK COMPUTER INC.
             System Model: X75A
                     BIOS: X75A.415
                Processor: Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz (4 CPUs), ~2.4GHz
                   Memory: 6144MB RAM
      Available OS Memory: 6030MB RAM
                Page File: 2161MB used, 4828MB available
              Windows Dir: C:\WINDOWS
          DirectX Version: 11.2
      DX Setup Parameters: Not found
         User DPI Setting: Using System DPI
       System DPI Setting: 96 DPI (100 percent)
          DWM DPI Scaling: Disabled
                 Miracast: Available, with HDCP
Microsoft Graphics Hybrid: Not Supported
           DxDiag Version: 10.00.10240.16384 64bit Unicode

------------
DxDiag Notes
------------
      Display Tab 1: No problems found.
        Sound Tab 1: No problems found.
          Input Tab: No problems found.

--------------------
DirectX Debug Levels
--------------------
Direct3D:    0/4 (retail)
DirectDraw:  0/4 (retail)
DirectInput: 0/5 (retail)
DirectMusic: 0/5 (retail)
DirectPlay:  0/9 (retail)
DirectSound: 0/5 (retail)
DirectShow:  0/6 (retail)

All works fine EXCEPT ctd f8 to generic view all craft................ Aha !! ???????
Ng client ! Reverting to Beta r15 cured that. (sorry)

 

[martins]

This error message appears to arise from a parsing error of the dxdiag.log file. It looks like dxdiag.exe has recently changed its output log format, confusing the installation checker's parser.

I am thinking about throwing out the DirectX check anyway. I guess these days there are no Windows PCs around anymore without DX installed anyway.

Should the installation checker be discarded altogether? It's a bit of a hack, in particular the fact that the orbiter.exe executable is replacing itself with a different file (in fact I am surprised that virus scanners don't get troubled by this).

I suppose the one useful function performed by the installation checker is for the presence of the runtime dlls. If you tried to run Orbiter without the correct runtimes, you'd probably get a cryptic error message that wouldn't help most people. So checking for that is probably fairly important (although the current VS2008 runtimes should probably be present on most people's machines).

 

[kuddel]

Should the installation checker be discarded altogether?

Yes. If you ask me.

By the way, it seems that the map MFD does not display the ground-track / orbital-plane of the TARGET...
I'm not sure since when, but r20 does not show it.
The attached scenario should show the orbital-plane of the Moon (Target), but doesn't.
The TARGET setting in the scenario also does not seem to be recognized, so you might need to select it manually after run.