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

[JMW]

RadioMfd crashes

Apologies if this has already been posted (thought it had, but can't find anything on search)
Straight ctd of RadioMfd on selection in mfd.

SORRY:
Durh!! ORBITERSOUND PROBLEM.... Obviously.:facepalm:

 

[fort]

Yes,

On a quicksave with a DG, entering the simulation, flying at 200 km altitude, a voice informs me that the ladder is returned ( or retracted ).:hmm:

( I hoped no less )

 

[martins]

Committed r.42

Change log:

1. Bug fix: ElevationManager: INT16 overflow/underflow possible during cubic interpolation of elevation grids [issue #1213]
2. DeltaGlider: Added CoolingSubsystem and FailureSubsystem classes, all top-level panel elements now moved into subsystems, 2D overhead panel now functional, ongoing DeltaGlider vessel class cleanup

You may have noticed the ongoing code cleanup for the DeltaGlider sample over the recent beta updates. I wanted to get this code sample into shape before the next release. While not complete, it's slowly taking shape. The main objective is to split the monolithic vessel class into a structure of subsystems, each of which has its own set of callback functions to respond to user interaction, reading and writing states to scenarios, etc. The top level vessel class essentially just distributes the incoming callback events to the appropriate subsystems. It's already a lot leaner than the 2010 version.

If you are a vessel developer, you may want to have a look sometime. It may provide a useful template for complex vessel implementations (although of course other developers have already implemented frameworks for structured vessel code - this is just one more option).

 

[fort]

Hello,

Something not very important but if i can zoom with the mouse wheel on the 2d panel of the dg in 1024 768, i can't when i set the display with 1280 1024. Is there a reason for that ?

Thank you again and again for Orbiter and good day.

fort

 

[jedidia]

While not complete, it's slowly taking shape. The main objective is to split the monolithic vessel class into a structure of subsystems, each of which has its own set of callback functions to respond to user interaction

Oh, now you're doing that, when I already implemented it myself on top of the vessel class? :lol:

I see some major refactoring coming my way...

 

[martins]

Something not very important but if i can zoom with the mouse wheel on the 2d panel of the dg in 1024 768, i can't when i set the display with 1280 1024. Is there a reason for that ?

Yes, the reason is that the panel texture itself is actually 1280 pixels wide, so at 1280 viewport width the panel is displayed in its "natural" pixel resolution. At higher resolutions it is stretched, at lower resolutions it is shrunk to fit the viewport. The mouse wheel simply switches between the two states "shrink to fit" and "display at 1-to-1 viewport pixel resolution". This only applies to the low resolutions.

I'll probably eventually redesign the DG panel at HD resolution (1920), but this is going to be tedious work, so for the next release it'll remain at 1280.

 

[Urwumpe]

Oh, now you're doing that, when I already implemented it myself on top of the vessel class? :lol:

I see some major refactoring coming my way...

Not just you. I also remember writing a very simple algorithm for daisy-chaining clbkGeneric handlers. :lol:

 

[martins]

I see some major refactoring coming my way...

I should probably also mention that this subsystem mechanism isn't part of the Orbiter API. It's been defined in the Common folder of the Orbitersdk directory, and the vessel-specific parts are directly implemented in the DeltaGlider project. It lives in user-space, so to speak. As such, it is subject to frequent changes, and with no guarantees for backward compatibility. If you want to make use of it, it's probably best to copy the relevant files into your vessel project rather than referencing the original files directly (unless you want to keep on the bleeding edge and are happy follow all design changes).

 

[schr75]

DG switches

Hi Martin

You probably already know this, but I couldn´t find it on the forum so I´ll just report it to be sure.

The retro door, lights and radiator switches on the DG doesn´t work.

Running Beta v.42

Søren

 

[Pipcard]

Would an SSD provide a major benefit when loading the high-res textures within the simulation? Like, real-time texture loading?

Because I saw this post on reddit:

It's easier to say what not to put on an SSD: videos, music, and documents.

Edit 01: And photos. If a files does something, it belongs on an SSD. If a file is accessed by something, you're wasting space.

I doubt you can put Orbiter.exe on the SSD and the textures it will access on the HDD. Unless, you can?

 

[jroly]

Would an SSD provide a major benefit when loading the high-res textures within the simulation? Like, real-time texture loading?

I doubt you can put Orbiter.exe on the SSD and the textures it will access on the HDD. Unless, you can?

That's my plan, when the new one is released, I am going to put it on my 256GB SSD, I have noticed quite abit of HD activity when orbiting an object under time acceleration.

Pipcard, what the person said is true, things like music and movies do not belong on a SSD, but software that is used often esp the OS benefit from SSD.

 

[jedidia]

Would an SSD provide a major benefit when loading the high-res textures within the simulation? Like, real-time texture loading?

Yes, definitely. rapid access to data that is too large to keep in memory is exactly what SSDs are good at.

That said, the dynamic loading procedures of the new orbiter textures already show a significant improvement over Orbiter 2010 without a faster disk. It sounds weird, but Orbiter 2015 has signifficantly shorter loading times with much larger textures than 2010 did, simply because it it has a lot less to pre-load.

 

[Pipcard]

What would affect the texture/terrain render speed within the simulation (not load time) the most?

An SSD over an HDD (can anyone test that)? The CPU? GPU?

 

[jedidia]

An SSD over an HDD

No. I imagine it is possible that your harddrive becomes a bottleneck if it is really slow, but you don't need SSD speeds to solve that.

As to whether CPU or GPU, I can't tell without knowing more about the internals. I can well imagine either being a bottleneck if it is significantly underpowered.

 

[Dantassii]

What would affect the texture/terrain render speed within the simulation (not load time) the most?

An SSD over an HDD (can anyone test that)? The CPU? GPU?

One of the things I look forward to 'testing' in Orbiter 2015 is are there any limits/problems caused by having LOTs of 'ships' in a scenario file. I am building a large spacestation using IMS 1.0 in Orbiter 2010 P1 and discovered that once you have over a certain number of 'ships' (in the form of IMS modules) in a scenario, certain things (like picking a ship from a dropdown list in 1 of the built-in MFDs for example) stop working or in the rare case cause a CTD. How many 'ships' are we talking about? Anywhere from 1,200 to 1,700 or more.

Anyway, this is the only 'bug' I've discovered in Orbiter 2010 P1 that I haven't heard anyone else talk about that I hope gets fixed in Orbiter 2015.

Just call me,

Dantassii
HUMONGOUS IMS shipbuilder

 

[Hlynkacg]

I'm not sure if this is the place to post this but...

I was experimenting with the vessel specific MFD feature introduced in the New Atlantis but encountered the following errors when trying to compile the project.

1>------ Build started: Project: AtlantisConfig, Configuration: Release Win32 ------
2>------ Build started: Project: Atlantis, Configuration: Release Win32 ------
1>AtlantisConfig\AConfigurator.rc(10): fatal error RC1015: cannot open include file 'afxres.h'.
1>  
2>  Performing Custom Build Tools
2>  'C:\Program' is not recognized as an internal or external command,
2>  operable program or batch file.
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 255.
========== Build: 0 succeeded, 2 failed, 2 up-to-date, 0 skipped ==========

I get the same errors when trying to compile the new Deltaglider but the other projects in the Beta's OrbiterSDK/samples folder all compile fine.

 

[GLS]

I'm not sure if this is the place to post this but...

I was experimenting with the vessel specific MFD feature introduced in the New Atlantis but encountered the following errors when trying to compile the project.

1>------ Build started: Project: AtlantisConfig, Configuration: Release Win32 ------
2>------ Build started: Project: Atlantis, Configuration: Release Win32 ------
1>AtlantisConfig\AConfigurator.rc(10): fatal error RC1015: cannot open include file 'afxres.h'.
1>  
2>  Performing Custom Build Tools
2>  'C:\Program' is not recognized as an internal or external command,
2>  operable program or batch file.
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 255.
========== Build: 0 succeeded, 2 failed, 2 up-to-date, 0 skipped ==========

I get the same errors when trying to compile the new Deltaglider but the other projects in the Beta's OrbiterSDK/samples folder all compile fine.

I had that problem sometime back in SSU, but it went away on its own during one of the re-installations of the "dev folder". Somehow I didn't have that file.
Went searching for the fix I used, but it predated my current backups.... but luckily I had an old backup in an ExtHD with the changes.
So, just open the AConfigurator.rc file and change from:

#include "afxres.h"

to

//#include "afxres.h"
#include "windows.h"
#include "OleDlg.Dlg"

and it should compile (at least it worked for me when I needed).

 

[martins]

Committed r.43

Change log:

1. Bug fix: DeltaGlider: retro thrusters not working after opening retro doors [issue #1215]
2. DeltaGlider: VC: AOA and vertical speed tapes installed
3. DeltaGlider: major redesign of subsystem classes: subsystems now can recursively contain subsystems; most of the DG-specific subsystem implementation has been propagated to the base class. Introduced convenience class "ComponentVessel" which provides subsystem support. DeltaGlider class is now derived from ComponentVessel.
4. Camera: interface change: mouse wheel now controls aperture (both in cockpit and external view). Radial camera movement in external views now with right-click + mouse wheel.
5. Planet textures: new textures for Jupiter, Tethys and Iapetus. (removed from repository, and moved into external MinorBodies package).

Please note that you _must_ install the latest MinorBodies package from here for this beta. This now contains textures for Jupiter, Tethys and Iapetus, plus updates for a few other Saturn moon textures.

There has been a change to the user interface (point 4): The mouse wheel can now be used to control camera aperture in cockpit views, which is useful to quickly get a particular part of the VC into view (and is a fairly standard feature in other flight simulators, so should be reasonably intuitive.

For consistency, the mouse wheel now also controls aperture in external views (instead of radial distance to target). Radial distance is now instead controlled with right mouse button+mouse wheel. This might take some getting used to. Let me know what you think (of course, radial distance can still be controlled instead with PgUp/PgDn).

 

[fort]

Change log:

Doctor,

Thank you for the Eiffel tower logo for the september 13. Thank you.

Change log:
...change to the user interface (point 4): the mouse wheel can now be used to control camera aperture in cockpit views, which is useful to quickly get a particular part of the VC into view

But not anymore in a 1024 x 768 2D panel ? At least, via keymap.cfg ?

 

[Ripley]

...There has been a change to the user interface (point 4): The mouse wheel can now be used to control camera aperture in cockpit views, which is useful to quickly get a particular part of the VC into view...

Please, somebody help me in better understanding this "aperture" thing:
is it FOV?
Is it zoom?

(I can't obviously d'load it now and check it for myself)

Thanks