# Orbiter 2016 - RC.1

#### SolarLiner

##### It's necessary, TARS.
I would but torrents are illegals in my country, plus my ISP actively prevents torrenting.

Use a download accelerator (FDM 3.x is the one I used for the download and even generally), and have some mirrors ready as well (not for you, but rather server owners to allow for a distributed publication like for the tiles).

##### Scientist
I installed VC++ 2013 and 2015 Redistributable (x64) and I still get the missing error. I already had 2005, 2008 and 20010. A search found MSVCR120.dll in Windows/System32, Firefox, Processing and Java folders. I copied from Windows/System32 to Orbiter 2016 folder and now get "...unable to start correctly (0xc000007b)..." I will now try VC++ 2013 Redistrutable (x86).
VC++ 2013 (x86) worked.

---------- Post added at 08:57 PM ---------- Previous post was at 08:51 PM ----------

Minor point: Orbiter 2016 MSI installs to folder Orbiter2014.
Yup - basically *never* copy those MSxxx.DLLs to your directory to try to fix things. If in doubt, install both x86 and x64 redists, but if you have to pick just one, then always pick the x86 ones (yes even on x64 builds).

#### Fabri91

##### Donator
Donator
I would but torrents are illegals in my country, plus my ISP actively prevents torrenting.

Use a download accelerator (FDM 3.x is the one I used for the download and even generally), and have some mirrors ready as well (not for you, but rather server owners to allow for a distributed publication like for the tiles).
Torrents as a distribution method are illegal? :huh: There is software that uses the torrent protocol to disseminate updates very much officially.

#### SolarLiner

##### It's necessary, TARS.
Torrents as a distribution method are illegal? :huh: There is software that uses the torrent protocol to disseminate updates very much officially.
Yeah, the Windows 10 using P2P method to spread updates made some noise here. Torrenting is seen as tied with piracy, thus laws plain and simply shut the whole thing down (well, as much as "shutting" a type of file transfer can mean). Which means I'm obligated to sometimes be an outlaw to download things such as a 5 Gb sample pack for a beautiful sounding piano.

#### Urwumpe

##### Not funny anymore
Donator
Yeah, the Windows 10 using P2P method to spread updates made some noise here. Torrenting is seen as tied with piracy, thus laws plain and simply shut the whole thing down (well, as much as "shutting" a type of file transfer can mean). Which means I'm obligated to sometimes be an outlaw to download things such as a 5 Gb sample pack for a beautiful sounding piano.

HADOPI is obsolete since 2013, after all and even that did not ban BitTorrent. As long as you are not sharing copyright protected material, it was always perfectly fine.

#### jarmonik

Beta Tester
There is a CTD giving some trouble. I was investigating a cloud layer related anomaly when I noticed it. D3D9Client is required to produce it, haven't noticed it with the inline engine. Vertical sync seems to have major effect in ability to reproduce it. With the sync enabled it becomes very hard to reproduce.

1. Load "DG Mk4 in Orbit" scenario
2. Choose Camera -> Target -> Sun -> Earth -> Apply -> Close the window -> Zoom a bit closer to the Earth
3. Frequently change between the two highest time accelerations while rotating the Earth with mouse.

Here it takes something like 10s-40s to produce the CTD without vertical sync. With the sync enable it's something like 5-10 minutes.
There are no references to any other software in the call stack than the Orbiter.

#### Attachments

• 67 KB Views: 39

#### jedidia

##### shoemaker without legs
Huh... looks like older versions (maybe about 3 or 4 revisions ago or so?) of the hi-res textures are not compatible.

#### martins

##### Orbiter Founder
Orbiter Founder
There is a CTD giving some trouble. I was investigating a cloud layer related anomaly when I noticed it. D3D9Client is required to produce it, haven't noticed it with the inline engine. Vertical sync seems to have major effect in ability to reproduce it. With the sync enabled it becomes very hard to reproduce.

1. Load "DG Mk4 in Orbit" scenario
2. Choose Camera -> Target -> Sun -> Earth -> Apply -> Close the window -> Zoom a bit closer to the Earth
3. Frequently change between the two highest time accelerations while rotating the Earth with mouse.

Here it takes something like 10s-40s to produce the CTD without vertical sync. With the sync enable it's something like 5-10 minutes.
There are no references to any other software in the call stack than the Orbiter.
Trying to debug this. It's slightly tricky because I couldn't manage to run the D3D9 client in an Orbiter debug build. I'm afraid I have been out of the D3D9 development loop - are the sources of those latest builds still publicly available, in case I need to link it against an Orbiter debug build?

Anyway, this may not be necessary. I've got a feeling that the problem may simply be a case of an orbiting body smashing against the planet surface due to orbit decay or numerical instabilities, and then catapulted into nan-space due to the high time acceleration. The D3D9 client may not have anything to do with it, other than providing higher frame rates than the inline client.

Could you try running the same scenario, but deleting all vessels except one of the landed ones (e.g. SH-03) using the scenario editor, before trying to repeat the procedure you described above? Does this still crash?

#### Face

Beta Tester
I'm afraid I have been out of the D3D9 development loop - are the sources of those latest builds still publicly available, in case I need to link it against an Orbiter debug build?
This here has its last commit on the trunk from ~36h ago (r738): svn://mirror.orbiter-radio.co.uk/D3D9client

#### martins

##### Orbiter Founder
Orbiter Founder
Huh... looks like older versions (maybe about 3 or 4 revisions ago or so?) of the hi-res textures are not compatible.
Can you elaborate? How does the incompatibility manifest itself?

There haven't really been any revisions of the texture packs. The only difference is that textures can now be packed into compressed archive files (*.tree). But the old format should still be supported. Archive files and individual texture files can coexist (but you need to enable the "read from cache + archive" option to allow orbiter to read from both, with preference for individual files).

#### jedidia

##### shoemaker without legs
Can you elaborate? How does the incompatibility manifest itself?
I basically installed RC1 over my old install with the hi-res textures. Result was an all blue earth, black moon, didn't check for Mars.

Installed RC1 without touching anything, works nice. I'll try to download the hi-res textures again and put them on to see if anything similar happens. On second thought, it might actually have something to do with the arrangement confusing the hell out of my HD cache.

Anyways, not so important right now. I'm currently hunting for a CTD when approaching the moon from earth, will post more about that when I have a solid repro to post.
One last thing, just in case it went under against all odds (seeing as this is RC1 and it's still there, it's a possibility): Surface bases render through the terrain (most easy to notice at brighton beach, as it's the only base with anything resembling mountains in the vicinity).

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
I basically installed RC1 over my old install with the hi-res textures. Result was an all blue earth, black moon, didn't check for Mars.

Installed RC1 without touching anything, works nice. I'll try to download the hi-res textures again and put them on to see if anything similar happens. On second thought, it might actually have something to do with the arrangement confusing the hell out of my HD cache.
If you're talking about the hi-res textures planetary textures not showing in D3D9Client, then there's a discussion about it here: http://orbiter-forum.com/showthread.php?t=36637&page=20

#### jarmonik

Beta Tester
Could you try running the same scenario, but deleting all vessels except one of the landed ones (e.g. SH-03) using the scenario editor, before trying to repeat the procedure you described above? Does this still crash?
I made more testing with this issue and:

If I delete all orbiting vessels leaving only the landed ones, then no CTD. After that, I deleted all other vessels from a scenario leaving only orbiting GL-01 in scenario and I made testing with it.

It is stable at 10k acceleration in D3D9 but if the acceleration is pushed to 100k then it will start rotating/spinning very fast and the CTD follows that at some point a while later even at lower accelerations. The DG must get to the spinning state for the CTD can occur.

Orbit stabilization has no effect.
Perturbation settings has no Effect.

I also made some testing with the inline engine. When the time acceleration is set to 10k the DG will end-up in a hyperbolic escape trajectory. However, if the Orbit stabilization is disabled then it will work just fine even at 100k. So, something is wrong with the stabilization. I haven't been able to reproduce that with the D3D9.

Last edited:

#### Eduard

##### New member
Hello,

I don't know if I am talking about the same problem. But the CTDs when time-warping transfers between Earth and Moon still happen, when being not to close to the Earth or Moon, but often when being closer to the Moon than to the Earth.

It does not happen always, but much more often with the D3D9Client than with the stock client.

It happens especially after switching between internal and external view, after doing some RCS actions, and then changing between different time-warp speeds.
It often starts with slowly and shaking reaction of the screen, and then finally the CTD occurs.

I have reported this problem earlier a while ago, but it's still there now.
I experience this problem with r.55, but now I tested it with the r.58 (ignoring the problem that I see no textures in the D3D9Client, I could still test it) and I got the CTD again.

Update:
I have also tested with removing all other vessels now (first remove all other vessels with Scenario Editor, and then I restart Orbiter): this definitely makes a difference.
But it's really needed to remove all vessels, also the ISS and other space stations. Then time warping from Earth to the Moon appears to give no problems anymore.
Is it possible that there exists a kind of memory conflict between vessels or something?

Last edited:

#### jedidia

##### shoemaker without legs
I don't know if I am talking about the same problem. But the CTDs when time-warping transfers between Earth and Moon still happen
That sounds very similar to what I'm currently chasing, except I don't get any stuttering. But the rest of the symptoms are identical: Doesn't happen in inline, doesn't happen if I take other vessels out of the scenario. I'm still looking for a waterproof repro, so far no luck. I have one at 100%, but that's with one of my own vessels, so technically there's the possibility that my code bugs out... Though the access violation isn't triggered anywhere near my code, and the ctd doesn't happen if I have the same vessel in a scenario but fly to the moon with a DG instead. I'll try to narrow it down further.

---------- Post added 07-21-16 at 09:02 PM ---------- Previous post was 07-20-16 at 10:43 PM ----------

I have a 100% repro on my ctd with a minimal scenario. Well, at least on my machine. Since the CTD is caused by an access violation, your lineage may vary, but I hope not.

It is important to note however that I was only able to reproduce running in D3D9 client!

So there is a chance that it is a client-side issue. The reason why I'm posting it here is because of a dependency of the crash on the presence (and apparently state) of GL-01 in the scenario (see below for circumstances under which the crash will not happen).

So here's the scenario:

Code:
BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
System Sol
Date MJD 51982.6414158006
Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
Ship ProjectAlpha_ISS
END_FOCUS

BEGIN_CAMERA
TARGET ProjectAlpha_ISS
MODE Extern
POS 34.269927 171.965869 162.003817
TRACKMODE TargetRelative
FOV 34.00
END_CAMERA

BEGIN_SHIPS
ISS:ProjectAlpha_ISS
STATUS Orbiting Earth
RPOS -10873977.777 16.436 -804218.703
RVEL -4502.1663 0.1564 -7158.3635
AROT 156.154 33.561 25.304
AFCMODE 7
IDS 0:588 100 1:586 100 2:584 100 3:582 100 4:580 100
NAVFREQ 0 0
XPDR 466
END
GL-01:DeltaGlider
STATUS Orbiting Earth
RPOS -5543461.122 2938905.831 -2274724.174
RVEL 4503.7488 5004.5322 -3862.4400
AROT -55.968 -29.940 94.891
AFCMODE 7
PRPLEVEL 0:0.553000 1:0.900000
NAVFREQ 0 0 0 0
XPDR 0
HOVERHOLD 0 1 0.0000e+000 0.0000e+000
AAP 0:0 0:0 0:0
END
END_SHIPS

Reproduction:

IMPORTANT: run in windowed mode, not fullscreen (fullscreen window is ok). When the thing crashed in fullscreen with the debugger hooked in the system couldn't get posession of the screen back, shooting down the task didn't have any effect and I had to reboot.

Start scenario. You'll see the ISS, it's on its way to the moon (don't even ask).

Turn time-accel up to 10,000 (press t 4 times).

At MJD 51985.8, turn time acceleration down to 1000 (press r once).

CTD should occur shortly thereafter. If you make it all the way around the moon, it probably won't happen ever.

CTD will NOT happen when:

You fly by the moon with timeaccel at 10'000

You remove GL-01 from the scenario

You switch the state vectors of ISS and GL-01, taking the glider insted of the ISS to the moon, but preserving the gliders state vectors on the ISS.

Things I found had no influence:

Any kind of graphical settings (terrain- and texture resolution, mipmap settings etc) had no impact on the behavior.

#### Ripley

##### Tutorial translator
Donator
Interesting ... Can anybody reproduce this? Is it a Windows10 specific problem?
Not able to reproduce it on my faithful XP.

#### jedidia

##### shoemaker without legs
Has anybody been able to confirm my ctd?

#### DoyleChris

##### Member
Target Select Messed up

I an trying the new RC1 and found a problem. It may be my end but not sure.
The selection window that comes up when you go to select a target is shrunk and cant read the whole list.
See Picture.
I am running the D3D9 client from here http://www.orbiter-forum.com/showthread.php?t=18431
With the RC1.

#### Attachments

• 20.4 KB Views: 49