Software Orbiter hang on exit

[kerlix]

I just upgraded my computer to Windows 7 64-bit. I have a AMD Phenom II quad-core processor with 4 gigs of ram. The graphics card is a nVidia GTX 470.

For some reason as of recently, when I attempt to exit Orbiter, it just hangs on the "Please wait while Orbiter is closing down the simulation session...".

I'm not sure what could be causing this. Luckily, I can quick save before exiting so I don't lose all the work I've been doing. Does anybody have a guess at what the problem could be?

 

[Rtyh-12]

Try changing the exit settings in the Extra tab of the launchpad, debugging options>Orbiter shutdown options. Try setting it to Respawn Orbiter process. This will save your work, exit Orbiter and start it again. No idea what the problem could be though.

 

[orb]

No idea what the problem could be though.

The problem could be because of some pre Orbiter 2010 add-on or a new add-on not compliant with the default shutdown option to deallocate memory and come back to the launchpad, which for example doesn't clean up its reserved resources after simulation end. Changing the debugging shutdown option to "Respawn Orbiter process" is only a workaround for the problem.

 

[-Apollo-]

Same thing happen to me when i installed the orulex add on, after i deleted it, the problem gone, check your add ons, or maybe you installed a addon that is not compitable with Orbiter 2010.

 

[Rtyh-12]

The problem could be because of some pre Orbiter 2010 add-on or a new add-on not compliant with the default shutdown option to deallocate memory and come back to the launchpad, which for example doesn't clean up its reserved resources after simulation end.

Then why does TransX do this? :huh:

Changing the debugging shutdown option to "Respawn Orbiter process" is only a workaround for the problem.

I know. But it works, so... :lol:

 

[orb]

Then why does TransX do this? :huh:

TransX doesn't hang my Orbiter on simulation close. TransX wasn't created by martins, but it was added to Orbiter distribution by him, and he can fix some issues of it, like http://www.orbiter-forum.com/project.php?issueid=407 or http://www.orbiter-forum.com/project.php?issueid=564, but it was mainly created as pre-2010 MFD by someone else. You can always post a bug report as it's a part of Orbiter distribution.

I know. But it works, so... :lol:

Which doesn't mean that add-on creators making new add-ons can ignore it too, thinking that if it works with respawn option they don't need to fix their add-ons to work with the default deallocate memory option.

 

[Rtyh-12]

TransX wasn't created by martins, but it was added to Orbiter distribution by him, and he can fix some issues of it [...] You can always post a bug report as it's a part of Orbiter distribution.

I know, both of them, but I didn't think that it was important enough to write a bug report.

Which doesn't mean that add-on creators making new add-ons can ignore it too, thinking that if it works with respawn option they don't need to fix their add-ons to work with the default deallocate memory option.

I know that too, but for newbies, it's easier to know that it works if you set it to 'Respawn Orbiter process.'

 

[kerlix]

The only add-on I have right now is NASSP 7. Which was getting along with Orbiter perfectly fine. And yes, I posted in their forum for help too. All I can think is that I recently installed IMFD 5.5 and LTMFD. Possibly one of those is the issue. In the mean time, using the other shutdown method seems to be working.

 

[blane]

NECROPOST!!!

Whatever. Yeah, just noticed the same problem. Have quite a few addons. But not loading TransX in the beginning solves the problem.

TransX Booo!
IMFD Yay!

Flame on :lol:

 

[Gendo]

This happens to me on Win7Pro64, but only on certain scenarios, such as Soyuz FG+ISS 3.2 missions. Doesn't matter if TransX is checked in launchpad menu or not.

The workaround looks to be the solution for now. Thanks.