Orbiter 2016

[gattispilot]

Doesn't the window close anyway if you click where the "x" should be?

No.

Whats odd is the Orbiter Windows have it.

So it makes me thing it is the add on person code that something is missing.

ALT+F4 does work. Be careful because you can exit easily the whole program

 

[Ripley]

Why don't you submit this to Martin? This way he can more easily track issues and such. Do it here:
http://www.orbiter-forum.com/project.php?projectid=1

Otherwise, it could be overlooked and get lost in the thread.

Very minor difference:

The Map MFD no longer supports both a base target and an orbit target at the same time. The scenario entry BTARGET is over ridden by OTARGET. The base will show if you enter it manually with the TGT button but it disappears if you enter an orbit target manually. While you only need one target at a time, it was nice to have the base showing on the map.

 

[jarmonik]

I have his on Earth, too. But it is even worse on Mars. (D3D9 client)

I haven't been able to reproduce it. Could someone post a scenario using the stock DG.

 

[turtle91]

Here is a scenario wth a standard DG using external view.
In my case, I have a black-flickering at the distance horizon a couple of seconds after the scenario loads.
It flickers between black and the normal horizon in a very fast pattern (multiple times per second).

BEGIN_DESC
Orbiter saved state at T = 45914
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 52007.2799218982
  Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-NT
END_FOCUS

BEGIN_CAMERA
  TARGET GL-NT
  MODE Extern
  POS 95.670164 167.276672 -20.830420
  TRACKMODE TargetRelative
  FOV 50.00
END_CAMERA

BEGIN_HUD
  TYPE Surface
END_HUD

BEGIN_MFD Left
END_MFD

BEGIN_MFD Right
END_MFD

BEGIN_SHIPS
GL-NT:DeltaGlider
  STATUS Landed Mars
  POS -135.4300000 12.7400000
  HEADING 70.00
  ALT 2.532
  AROT 151.614 -45.324 -82.449
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000
  NAVFREQ 0 0 0 0
  XPDR 0
  HOVERHOLD 0 1 0.0000e+000 0.0000e+000
  GEAR 1.0000 0.0000
  AAP 0:0 0:0 0:0
END
END_SHIPS

BEGIN_DX9ExtMFD
END

And here my D3D9 settings (I am using standard textures btw...no hires):

FrameRate = 60
EnableLimiter = 1
CustomCamMode = 0
PlanetPreloadMode = 0
PlanetTexLoadFreq = 500
Anisotrophy = 8
SceneAntialias = 0
SketchpadFont = 0
PreLoadBaseVisuals = 0
EnableNormalMapping = 1
NearClipPlaneMode = 1
RwyLightAnimate = 1
RwyLightAngle = 120
RwyBrightness = 1.8
NightLightsAngle = 10
BumpMapAmplitude = 1
PlanetGlow = 0.7
EnvMapSize = 512
EnvMapMode = 1
EnvMapFaces = 1
ShadowMapMode = 1
ShadowMapSize = 1024
EnableGlass = 1
EnableMeshDbg = 1
TileMipmaps = 1
TextureMips = 1
TileDebug = 0
StereoSeparation = 65
StereoConvergence = 0.2
DebugLvl = 1
VCNearPlane = 0.1
LightSourcesInUse = 12
DisableDrvMgm = 0
NVPerfHUD = 0
DebugLineFontSize = 18
DisableVisualHelperReadout = 0
LODBias = 2
MeshRes = 1
MicroMode = 1
MicroFilter = 3
BlendMode = 1
MicroBias = 3
PostProcess = 1
ShaderDebug = 0
PresentLocation = 1
PlanetTileLoadFlags = 3
SolCfg = Sol
DebugLineFont = Fixed

 

[jarmonik]

Here is a scenario wth a standard DG using external view.
In my case, I have a black-flickering at the distance horizon a couple of seconds after the scenario loads.
It flickers between black and the normal horizon in a very fast pattern (multiple times per second).

That has been fixed already from the latest SVN. But isn't that entirely a different issue than the one discussed above ? What was the talk about cloud layers, GEO distance and high phase angle ?

 

[turtle91]

Ok, I am still on official Orbiter release + D3D9 client R1.
Just an example what I did, to make this flicker-issue even getting worse, as might be seen in my previous scenario:

Still on Mars(so..no clouds above Mars in Orbiter-2016 I guess):
-flying from Olympus (night time) to Valles-Marineris (day-time)
-my altitude is about 6500 meters above ground (radio-alt as seen in the surface HUD)
-during my way to the destination, I encounter a nice sun-dawn, still no issues here
-as I am coming more close to my destination (the sun is nearly "above" me),the flickering starts a little as seen at the far horizont.
-right above my destination, I am still at 6500 meters above the surface, while Surface- MFD reads about 1200 meters altitude (so..sea altitude). So I am still in the positive range (not in a hole).
Here the flickering is much worse, I can see a black flicker, mugh more thick in its "altitude" just in front of my view.
This means, I am not playing around with external views and different view-angles, just the 2D-cockpit-view at FOV 50.

-If I swing the view a bit around, the flickering might stop, but will come back, as soon as my camera is set back to standard/neutra("HOME" key).

The problem is, I cannot provide a screenshot, where the issue can be seen.
All screenshots are fine...not showing-up the problem.

 

[Ripley]

What if you hit Ctrl+PrtScr and select "Save frame sequences"?

 

[turtle91]

What if you hit Ctrl+PrtScr and select "Save frame sequences"?

Cool...nice one....I need todo more RT*M...:thumbup:

Ok, I have one example-picture. But it shows the problem at the very beginning.
Here the flicker is very small(thin).

In the far distance, there is a thin black "flicker".
This flickers at about 20-30 per second and ruins the scene.
If I would continue my flight, the black "flicker" goes wider and wider.

Attached the captured example-frame.

 

[DoyleChris]

I am having problems with the hires pack I installed them into the \textures\earth\archive.
And when i go to run orbiter eithier in the default or with dx9 client all i get is a blue marble no textures.

 

[GLS]

That has been fixed already from the latest SVN. But isn't that entirely a different issue than the one discussed above ? What was the talk about cloud layers, GEO distance and high phase angle ?

I think I've got more info about the tearing now:
>> only shows up in internal view
>> only when the planet is not centered in the window
>> the tearing is restricted to the side of the planet closest to the center of the window (day or night)
>> the "holes" change place several times per second, and they stop when the simulation is paused
>> only happens when using MOGE (nothing to report with D3D9 r25.1)

I'm using the latest orbiter revision (r64).
Image of the tearing on Earth:

 

[martins]

>> only shows up in internal view

So does this look like conventional z-tearing between cloud and surface layer? And if so, is this likely to be related to the recent change of reducing the near plane distance to 1 m in internal view?

 

[GLS]

So does this look like conventional z-tearing between cloud and surface layer? And if so, is this likely to be related to the recent change of reducing the near plane distance to 1 m in internal view?

My limited graphics knowledge says it could be possible... but if it is z-trouble, shouldn't it affect more of the planet, instead of just some zones (that are not always the same) at a time?

BTW: I was in the "normal" (non-2D, non-3D) cockpit when I took the screen I posted.... not sure if it matters. And playing with the MFDs and HUD changed nothing.

 

[Tycho]

Longtime Orbinaut, since the 2006 days. Checking in to say how beautiful Orbiter 2016 is. I'd never used the beta, so I'm blown away by the updates. The terrain is incredible. Loads of fun with this are in my future. Thanks, Martin!

 

[jarmonik]

So does this look like conventional z-tearing between cloud and surface layer? And if so, is this likely to be related to the recent change of reducing the near plane distance to 1 m in internal view?

I made 20min test run from a several different altitudes and couldn't reproduce it with Orbiter's inline engine. "Try stencil buffer" had no effect.

 

[Michkov]

I think I'm having the same issues. Took a test flight over the Alps today and got black sections flickering at the far horizon. Turned off all Planetary effects and it seems like Horizon haze causes it.

 

[gattispilot]

So Maybe there is a something I am missing in the code part. I loaded Attachment Manager into Orbiter2016 and I get the red X in its window.

Also Is there a way to reduce the screen. I have noticed if I have debug info. It shows up below the screen where I can't read it.

 

[jedidia]

EDIT: Ignore most of this post, I screwed up badly! See below.

So, after having had a pretty stable setup with dynamic touchdown points on the release version of 2016, I've updated to the last svn and...

yeah, there's some serious issues that crept in here. Vessels tend to be skiddish and shifting around (especially well observable in landed docked stacks), and once they do that, they become inherently unstable. As in, if I hold a window clicked, thereby temporarily freezing the simulation, and then release it again after a second or so, they get thrown about. The worst I've seen was a stack being flung into NaN-space when moving the orbiter window.
And they do in fact have a tendency to flip over that was not there in the release version. And when they flip over, they don't even flip onto their touchdownpoints on the back... they just flip and seem to lie on their first 3 touchdown points face down, i.e. the back of the vessel is sinking into the ground.

Docking and undocking on the ground was pretty hit-and-miss in the release version already, with the tendency of flinging vessels of the ground on docking (and I'm talking slow, controlled docking here, not remote docking from kilometers away with scenario editor - undocking always went fine, though), but now it can easily happen that they get thrown below the ground on undocking.
Docked stacks also seem to have a strange tendency to not stand straight, which they didn't exhibit before. I'm attaching a screenshot to illustrate the point.

Now I'll grant you, some of the things I do are a bit experimental, but what I'm testing right now worked mostly flawlessly on the release version. Now that I upgraded to the latest SVN, I begin to understand the problems GattisPilot is having. It seems that touchdown points are in fact pretty broken in the current commit.

(note concerning the screenshot: No, this positioning is not due to touchdown points being in the wrong places. Both vessels lie perfectly flat on their own, and they lay flat as a stack in the release version)

 

[turtle91]

essels tend to be skiddish and shifting around (especially well observable in landed docked stacks), and once they do that, they become inherently unstable. As in, if I hold a window clicked, thereby temporarily freezing the simulation, and then release it again after a second or so, they get thrown about.

Ok, I am still on official Orbiter2016 release, but in your screenshot...it looks a bit like Brighton Beach.
At least in the official release, there are still problmes with pads below sea-level-altitude.
Just an example:

XR2 at pad1 Brigton Beach...or Olympus..same story:
-release a LOX tank=
first it looks good, the tank apears close to the vessel
but when the sim-engine tries to switch to IDLE/LANDED...the LOX tank pushes into space.
As far as I can see, the XR2's default payload-"vessels" have valid touchdown-point-definitions within their CFGs.

If I do the same again at KSC(release LOX tank), all is fine.
The "vessel" appears near the XR2 and settled-down after about 5 seconds (to LANDED/IDLE), and keeps there.

Maybe this is related, that some vessel-variables are still using mean-rad instead of altmode_ground. ( i.e. http://www.orbiter-forum.com/project.php?issueid=1281)

 

[hypersonic]

HUGE Congratulations Martin!! - Perhaps another Meet-up Beer is in order!!? - Only been 10 years since the last one ;-)
Al

 

[jedidia]

My sincerest appologies! I hereby gladly report that I made a mistake and was posting my above report on touchdown points based on false data.

When I took my code over to the SVN (I had a regular orbiter 2016 install and checked out the development version in a seperate install), the local repository in which I store my config files ended up one commit behind the remote. I'm not sure why, usually I don't have to do a fetch right after a clone, but in the future I think I will just to be on the save side.

As a result, most touchdown points were never actually created, because the hull shapes were not defined yet in some of the config files in that commit. Even worse, the positions of some of the touchdown points were undefined. I noticed my mistake today when I ran the same tests with 2 Delta Gliders and couldn't make out anything particularly unstable about the arrangement. Once I got my config files up to where they were supposed to be, Behavior was consistent again with the release version. Sorry for the panic!

The one thing I did still notice however is the problem posted in the above screenshot. Even when docking 2 DGs together, it can be observed that they are not standing straight (albeit not as pronounced as in the screenshot). It almost appears as if some force is puishing down on the rear of one of the vessels, lifting its nose up.

Oh, and there's the issue with the scenario editor putting vessels on the pad in a manner that I can only describe as "spring-loaded": The front of the three touchdown points seems compressed proportionally to the vessels mass, and as soon as any tiny force acts on the vessel (like for example firing any of its rcs thrusters for a microsecond), the spring is released... The more massive the vessel, the more impressive the result. It is observable with a stock dg: When you put it on a pad with the scenario editor and then punch any RCS button, its nose will make a small hop upwards (the effect is, of course, proportional to the local gravity, so earth isn't the best place for the experiment).

With more massive vessels this can go as far as flipping it on its back, or off planet. I am aware that this feature probably mostly relates to the scenario editor, not to the core, but it would be nice if it could be fixed.

And once again, sorry for my unfounded report above.