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

[starcraftman]

Pressure on the surface od Mars

Hello all !

I just landed on Hellas Planitia on Mars. The terrain should be about 5-7 km below the medium surface height - and it was on surface MFD. But the reason why I picked up this area was pressure that should be about 1,2 kPa. It will be easier to fly and easier landing on the surface. But it was around 600 Pa like on medium Mars height just like in old orbiter version where the surface was completely flat. Will it be fixed ? Please ^^ : )

The pressure and temp could also vary in day/night or season cycle. But I heard temp right now does nothing and it will cost effort so ... I'm not even asking about this.

PS Great Job I'm with you guys from 2004 and I never dreamed about that 3D surface and such resolution will be ever implemented. Many thanks !!!

 

[Ripley]

And while we're speaking of textures, on this page
http://mirror.orbiter-radio.co.uk/orbiter/assets/moon.html#full

The files are 3, but the displayed names are wrong:
Moon.7z.001
Moon.7z.002
Moon.7z.002

Underlying files have good names though!

 

[martins]

The files are 3, but the displayed names are wrong:

Thanks! Fixed now.

 

[kuddel]

Committed r.22.

This should fix all issues with the Map MFD I was aware of:

• Orbit plane was shifting for idle vessels
• Custom marker sets were never displayed
• Toggling custom marker sets on/off was offset by one line, and last line was skipped [issue #1202]
• Terminator lines/shading could not be switched on once it was off

Thanks. All issues I was aware of (plus X) are fixed! :thumbup:

... post bugs/fix reports here, but if I don't reply within a few days and the problems are not fixed, it's better to also log them in the bug tracker [...]http://orbiter-forum.com/project.php?projectid=1 to make sure they don't get lost in the clutter.

Very good - makes a lot of sense.

---------- Post added 12-09-15 at 00:04 ---------- Previous post was 11-09-15 at 23:32 ----------

A bit delayed for this post, but..

There is now a new texture set for the Moon available at http://mirror.orbiter-radio.co.uk/orbiter/assets/moon.html.
[...]
Note that the old and new texture sets can't be mixed. If you want to try the new set, you should rename your Textures/Moon directory to something else (e.g. Textures/Moon_Clementine) before installing the new set.

Shouldn't it work if one puts the new textures into the "Textures2" folder?
As far as I remember, Orbiter (the Graphics-Client) looks first in "Textures2", then in "Textures".
Or is this only true for Vessels?

 

[martins]

Shouldn't it work if one puts the new textures into the "Textures2" folder?

It probably should, but I have never tested it for the new planet texture format. There is a certain ambiguity here, since the textures are no longer contained in a single file, but spread over a large number of files and directories:

If an individual texture file is not not found in Textures2, should Orbiter look for it in Textures?

Or should this mechanism only work for a planet's texture set as a whole? I.e. if Textures2/Moon exist, should Orbiter never look in Textures/Moon for missing files?

 

[martins]

Committed r.23.

This should fix two bugs:

1. Atmospheric parameters were referenced to true altitude instead of altitude above mean radius, :facepalm: as spotted by starcraftman. Please let me know if atmospheric parameters now behave as expected.

2. Camera should now always snap to default direction after VC position switch, without transition [issue #1147]

I just landed on Hellas Planitia on Mars. The terrain should be about 5-7 km below the medium surface height - and it was on surface MFD. But the reason why I picked up this area was pressure that should be about 1,2 kPa. It will be easier to fly and easier landing on the surface. But it was around 600 Pa like on medium Mars height just like in old orbiter version where the surface was completely flat. Will it be fixed ? Please ^^ : )

 

[kuddel]

It probably should, but I have never tested it for the new planet texture format.

Me neither. I will check as soon as download of the new textures is complete...I'll report back

There is a certain ambiguity here, since the textures are no longer contained in a single file, but spread over a large number of files and directories:

If an individual texture file is not not found in Textures2, should Orbiter look for it in Textures?

Not sure if it should, but the API documentation of oapiLoadTexture says so:

    /**
    * \brief Load a texture from a file.
    * \param fname texture file name
    * \param dynamic allow dynamic modification
    * \return Surface handle for the loaded texture, or NULL if not found.
    * \note Textures loaded by this function should be in DDS format and conform to the
    *  DirectX restrictions for texture surfaces, typically square bitmaps with
    *  dimensions of powers of 2 (128x128, 256x256, etc.).
    * \note File names can contain search paths. Orbiter searches for textures in the
    *  standard way, i.e. first searches the HitexDir directory (usually Textures2),
    *  then the TextureDir directory (usually Textures). All search paths are relative
    *  to the texture root directories. For example, oapiLoadTexture()
    *  ("myvessel\mytex.dds") would first search for Textures2\\myvessel\\mytex.dds, 
    *  then for Textures\\myvessel\\mytex.dds.
    */

...but that might only be true for .dds files, not for .tex files ...

Or should this mechanism only work for a planet's texture set as a whole? I.e. if Textures2/Moon exist, should Orbiter never look in Textures/Moon for missing files?

Let's see what my test will show.
It was by the way just an idea that came into my mind. I thought I could save me some work, by only renaming Textures2/Moon into Textures2/Moon_dontUse to switch back to the old, instead of having to rename two folders in Textures folder

 

[jangofett287]

Why do we have 2 textures folders in the first place?

 

[kuddel]

Why do we have 2 textures folders in the first place?

Textures2 could store high-res textures that are optional for "build-in" Meshes for example. So no need to backup and overwrite those.
At least that is what I suspect it is useful for

---------- Post added at 02:11 ---------- Previous post was at 01:29 ----------

Regarding my tests about using Textures2 folder for planetary (Moon) textures and elevation sets: It does not work that way!
So: Do not follow my proposal. "Always listen to what the doctor told you!" :thumbup:

 

[jroly]

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	orbiter.exe
  Application Version:	0.0.0.0
  Application Timestamp:	55f35650
  Fault Module Name:	DeltaGlider.dll
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	55ecafa4
  Exception Code:	c0000005
  Exception Offset:	0001ed30
  OS Version:	6.1.7601.2.1.0.256.4
  Locale ID:	1033
  Additional Information 1:	0a9e
  Additional Information 2:	0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:	0a9e
  Additional Information 4:	0a9e372d3b4ad19135b953a78882e789

I keep getting crashes in the DG with reentry into Earth, crashes when alt gets to 30km.

(Edit: it crashes with the failure simulation turned on, turned it off and now doesn't crash)

 

[aldarion]

For me, the secondary card is visible only after enabling a "second" screen in the Display Preferences, which corresponds to my secondary GeForce. Have you tried this?

I do not have any second screen to enable. I simply have laptop with two graphics cards. I have added high graphics profile for orbiter which should add as the default the AMD card.
Other 3D apps/games does not have any problems with the second card.

The D3D9 client, however, detects the AMD card without the problem. It however does not detect Intel HD Card :lol:

 

[Enjo]

I do not have any second screen to enable. I simply have laptop with two graphics cards.

I understand. I have the same setup. I have to enable a second virtual screen nevertheless to power up the GeForce.

 

[Urwumpe]

I understand. I have the same setup. I have to enable a second virtual screen nevertheless to power up the GeForce.

I had configured my Optimus driver to use the GTX 670M as default for Orbiter.

 

[aldarion]

How can I enable this 'virtual' screen? I can only select low power or high performance profile for each app.

Wysłane z mojego SM-G900F przy użyciu Tapatalka

 

[kuddel]

D3D9Client for Orbiter BETA r23

As requested (PM) here's a current build of D3D9Client, linked against r23.

Again: As no changes have been made to the Graphics Client API since rev. 20 (of Orbiter BETA) this is not any better / worse than the previous attached version.
...nevertheless everybody likes being "up to date"

 

[Enjo]

How can I enable this 'virtual' screen? I can only select low power or high performance profile for each app.

Answer attached.

 

[aldarion]

Unfortunately, I only see one screen on may computer...

 

[starcraftman]

Pressure on the surface od Mars

Committed r.23.

This should fix two bugs:

1. Atmospheric parameters were referenced to true altitude instead of altitude above mean radius, :facepalm: as spotted by starcraftman. Please let me know if atmospheric parameters now behave as expected.

Thank you ! The atmosphere on mars now works correctly. In addition to the topic mentioned - the atmospheric haze is not rendered properly below mean radius of Mars - as usuall hellas plantita as example.

PS
Is there a way to make a base with runway on this area of Mars ? I'm able to land with DG at speed ~150 m/s but the terrain is not flat.

 

[Hlynkacg]

Can anyone explain the architecture of the new Atlantis "Ascent MFD" to me, I see that there are three classes, an autopilot class, a dialog class, and a mfd class how exactly do they interact?

This is a feature I would like to use but i'm not really sure how or where to start.

 

[martins]

Can anyone explain the architecture of the new Atlantis "Ascent MFD" to me, I see that there are three classes, an autopilot class, a dialog class, and a mfd class how exactly do they interact?

This is a feature I would like to use but i'm not really sure how or where to start.

Well, the AscentAP class defines the actual logic of the ascent autopilot, i.e. the subsystem that controls the feedback loops for the SSME and SRB gimbal settings to follow the specified ascent trajectory.

The AscentApMfd class defines an MFD mode that acts as a user interface to AscentAP. That is, it allows the pilot to enter the trajectory parameters, and provides some feedback on gimbal positions.

It's important to note that AscentAP exists independently of AscentApMfd. Once you have entered the parameters and launched the autopilot, the MFD can be closed and the autopilot continues working in the background.

The AscentAPDlg class does the same thing as AscentApMfd, but via a dialog rather than an MFD. I'm not sure if the dialog version is really useful, so I might remove it at some point.