[GODzilla]

Okay, first: Yes I know, debug-exe. I'm going to use it if the problem persists. For now, just the basic infos and the hope something is already known:

During the playthrough of the original campaign (The Great War) and Silent Threat - Reborn (currently in the last mission) I had several ctds ("Freespace 2 stopped working"). In 99% of those situations I had just given my wingmen instructions, a new target, to disable a subsystem, or to cover me. Upon the response of my wingmen the game crashed.


My FSO-setup is: A clean install of Freespace 2 (GOG-version), mediavps_3.6.12, fsport, fsport-mediavps and fsport-str. Launcher is 5.5g. As you can tell I use the standard folder names, so nothing special there. As of late I've been using the 3.6.14 rc4 exe.


I already tried several sound-related things, like...

- enabling / diaabling EFX in the launcher
- enabled / disabled pre-mission sound loading
- reinstalled openal (uninstalled it, restarted pc, installed it)
- updated my sound card driver
- disabled all audio-devices besides my sound card (like the ATi HDMI output device)
- reset soundcard settings to standard (disabled sound blaster extension)
- enabled / disabled EAX in the soundcard driver settings


A word about reproduction of the bug:

Not so simple. When I simply start the current mission and give orders like a maniac everything works. I can do this for minutes.

It usually happens in the worst moments. Last time it happened when the Hades was at 3%. You can imagine my reaction...


Anyway...if the problem persists - I'm currently testing the latest nightly-build as I read here that FSPort / STR was build for the nightly builds / the nightly-builds were made for FSPort / STR - I will follow my promise and try to get a debug log.

[Goober5000]

That's an unusual bug; I haven't heard of that one before.  But we'll need a debug log in order to help you out beyond trivial advice.

ST:R is designed to work with both retail EXEs and FSO EXEs.

[GODzilla]

I see. I'm going to play with the debug exe from now on, actually hoping to get the bug again. Hehe, sounds strange, but to be honest I'd rather know what is causing it then to fear it happening over and over again...it almost ruined my gaming experience.

The last mission is already hard as it is, but then it crashed 5 seconds before winning...damn was I mad. ^^


/edit: And here comes the first report, playing the the 3.6.14 rc4 debug, loading the last ST-R mission and I get this:

Code: [Select]

---------------------------
Warning!
---------------------------
Inverted bounding box on submodel 'hp-cockpit' of model 'GenericCP.pof'!  Swapping values to compensate.
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! Warning + 430 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! read_model_file + 4238 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! model_load + 754 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! ship_create + 386 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! parse_create_object_sub + 77 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! parse_create_object + 193 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! parse_wing_create_ships + 1417 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! post_process_ships_wings + 506 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! post_process_mission + 49 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! parse_mission + 1520 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! parse_main + 449 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! mission_load + 215 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! game_start_mission + 184 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! game_enter_state + 462 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! gameseq_set_state + 310 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! game_process_event + 242 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! gameseq_process_events + 152 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! game_main + 782 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! WinMain + 330 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_6_14_RC4_DEBUG.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes

[ This info is in the clipboard so you can paste it somewhere now ]


Use Yes to break into Debugger, No to continue.
and Cancel to Quit

Looks like a problem with the cockpit-mod I am using as a sub-mod. Any idea?


/edit2: Mhm...slight problem here. I get nowhere near stable fps with the debug build. No testing possible. Should I disable all advanced graphical effects? But how would that create a realistic testing environment, when several possible causes for the crashes are disabled?

[FreeSpaceFreak]

That warning is unlikely to have anything to do with the comm crashes, just click No to continue playing. It's a faulty model in the cockpit mod, but FS knows how to handle that.

If the FPS is bad, try playing without the mediavps - if the crash doesn't occur then (which seems unlikely BTW), that'll be another clue.

Note: When reporting an error, apart from quoting it, attach your fs2_open.log as well, in most cases the error message alone is not enough to find the cause of the problem.

[GODzilla]

Thanks. When the crashes re-appear I'll do that. (Though it'll be sooo hard to play without the mediavps! *g*)

As for now I successfully finished the last mission of ST-R using the latest nightly build (based on 3.6.13 if I read that correctly), from october 2011. The performance with that exe was a bit slower than with 3.6.14 rc4, but there was no crashing, despite me NOT holding back giving orders to my wingmen. It's just needed for bringing down the Hades.

Now that I'm through, I'm willing to test, even without the mediavps.

[Macfie]

Try disabling the head ANIs in the hud options.

Could be related to this problem.

http://www.hard-light.net/forums/index.php?topic=79816.0

[GODzilla]

Interesting. Indeed, it could be the head animations. The game crashed under those two circumstances:

- 90% of the crashes happend when I used the com-menu, the moment my wingmen answered (head-anim played)
- 10% of the time, when I got a message from command (head-anim played)

So it was always the head animation that was playing. "Com-related crashes"...wrong title it seems.

I'll try that for sure. Would be a pity for the anims, but that'd be a minor annoyance. I might also test if it's somehow related to the position of that animation. Since I did modify the hud-gauges table for the generic cockpit, in order to get all the gauges right for my 16:10 resolution...who knows.

[GODzilla]

No news from me, why? Because the problem seems to be gone. But not by itself, I changed three things: The 3.6.14 rc4 exe is now set into compatibility mode: Win7 32bit, run as admin and with disabled desktop style.

I think the admin-flag could very well be the solution here, the other two are trivial. Maybe the famous talking-head-ctds can be solved by running the game as admnistrator.


/edit: Narrowed it down to "Compatibility: Windows 7" and "run as administrator". I will post my findings in the other topic about the head-anims-problem, just in case someone finds it use- and helpful. ^^

[CaptJosh]

Um, what directory structure is there for your install? You mentioned using the GOG install of FS2. the GOG installer likes to put FS2 into C:\Program Files (x86)\FreeSpace2\ and that location, aside from having spaces in the folder name, has issues with needing admin permissions in a lot of cases. You should probably reinstall the game to something like C:\Games\FreeSpace2\ if it's currently in the x86 program files path.

[GODzilla]

My installation path is E:\Freespace 2. It's a partition reserved for games on my single harddrive.

To be honest I never had problem with administrator rights. Most games run no matter what. Would you recommend to set a whole partition to run everything with administrator rights? How would I do that?

I'm unsure if this is wise, my gut-feeling just tells me it is not. ^^ But please correct me if I'm wrong.

[CaptJosh]

No. The only other thing I can think of is that you do have a space in the path. Theoretically, this no longer matters. In practice, I don't know.

[GODzilla]

Uhm...I'm not sure if you realized that I actually solved the problem. Starting the exe with administrator rights seems to do the trick. I'll also try to deactivate the Win7 compatibility mode, to narrow it down even more. But for me the problem is no more, as both flags - win7 and administrator - don't have any disadvantages. So it's not a workaround for me, but a working solution. ^^

Anyway, thank you for your input and help. 

[mjn.mixael]

except that FSO should not require either of those flags...

[GODzilla]

Well, I never said or thought that it would be a problem specific to the FSO code. It could be an incompatibility with my hardware and / or software combination. My sound card is rather old, there has not been a driver update for a long time. Or...or...or...

Doesn't matter, problem solved. The compatibilty mode and the admin flag are both no exotic features, they come with windows and are easy to use. For future reference I have to think of those more often, too. I played through a whole campaign and a half without trying them out.