Hard Light Productions Forums
Hosted Projects - FS2 Required => Blue Planet => Topic started by: Trivial Psychic on June 14, 2021, 07:07:25 pm
-
I've been trying to get through bp2-10 and while the mission is always a challenge, one problem I've been having is a persistent crash. I've tried the mission under a debug build and at the crash point it gives me this:
Assert: "objp->type == OBJ_SHIP"
File: hud.cpp
Line: 2767
ntdll.dll! ZwWaitForSingleObject + 10 bytes
KERNELBASE.dll! WaitForSingleObjectEx + 156 bytes
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 13 bytes
ntdll.dll! RtlUserThreadStart + 29 bytes
[ This info is in the clipboard so you can paste it somewhere now ]
Use Debug to break into Debugger, Exit will close the application.
ntdll.dll! ZwWaitForSingleObject + 10 bytes
KERNELBASE.dll! WaitForSingleObjectEx + 156 bytes
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_21_3_0_20210613_74233c029_x64_SSE2-FASTDBG.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 13 bytes
ntdll.dll! RtlUserThreadStart + 29 bytes
Any guesses?
-
That's probably going to need some SCP investigation. Can you describe the situation leading up to that crash? Does it seem tied to any particular thing happening in game?
-
I haven't noticed any particular event associated with it. It is usually preceded by a slight lag. I thought that perhaps it had something to do with continued use of the game combined with particularly intense sequences. I've just completed a slight fix to the Hecate MK2 in my tables (see bp2-06 thread), and I was getting an error message during load for that ship that I chose to ignore. Maybe it will work now. The error message associated with this crash however references hud.cpp, so maybe its due to something else. Time will tell.
Something else I noticed, not associated with the crash. I often fly a Nyx in this mission, and I noticed that if I am the first to call for a rearm, I get a Hygeia, which can't fix my hull. The only way to solve this as far as I can tell, is to create "#UEF" versions of each ship you might be able to fly so they call a UEF support ship. I know that it's hardly a mission-breaking bug, but it is a bit inconvenient. Maybe there's another way to get around that... but its not very serious, so don't give it much concern.
-
Not sure about the crash itself, but I'd just like to note that there has been some issues with FSO during long play sessions. These usually result in lacking performance in longer sessions, but a crash might not be beyond the realms of possibility. I recall that while doing a longplay of Solaris I experienced an abrupt lag and then a crash to desktop without any error message, but I don't want to come with this as definite proof as 1. that wasn't on a debug build thus I have no info on it, 2. there was a lot of things going on in my computer at that time and it might've been an external interaction.
If this problem is persistent, a full debug log would help greatly.
Also, I'm pretty sure that you shouldn't get hull regen when in Tev ships. At least I think it's a Fed thing.
-
Also, I'm pretty sure that you shouldn't get hull regen when in Tev ships. At least I think it's a Fed thing.
I believe that if there is already a UEF support ship in-mission when I call for a rearm, even if I am flying a GTVA fighter I'll still get the hull repaired.
-
I don't think so...I mean if that does happen it's unintended behavior!
-
So I finally got to trying this, and under a debug build I experienced no crashes, so I thought that perhaps my little table adjustments and driver updates had done the trick and switched back to a release build. Unfortunately, I then got the crash again. I will try to keep a log of when and where this happens in the mission to see if there is any pattern, but my problem is that I can't WIN the mission. The debug build slows down my frame-rate enough that I can't dogfight effectively and end up doing poorly enough that I keep losing the mission, and under release builds I crash. I may try and turn a few of the graphical enhancements off and see if it helps under debug.
-
You can always cheat.
-
Just tried the mission under the June 19th nightly, non-debug SSE2 build. The backup UEF cruiser wing had recently arrived and most of the enemy fighters had been destroyed, though a re-spawn of one of the two Herc2 wings had just arrived. The crash occurred just as I got an alarm signal that the Indus' hull integrity had fallen below 50%. The message hadn't even fully displayed on the screen before it just froze... sounds, music, all of it.
-
THAT'S IT! NO MORE MR. NICE PLAYER! No, I'm not talking about the crash. Oddly enough, over my past five attempts to play that mission, I have experienced no crashes. Though I keep getting my ass and the ass of every asset in the mission handed to me, so I'm gonna win this the same way I protect the Iceni and Hinton in FS2... open the mission and give them ship-guardian-threshold events... and I'll make myself invulnerable at the same time. WHY NOT!? I'll personally disable and disarm the Medea and then call my strike package in and blow it to HELL!
That's right... when I cheat, I don't do it in the traditional sense, and I DON'T play fair.
-
That was therapeutic. Oddly enough I experienced no crashes. It may be down to that warning message about the Indus or Yangtze's hull going below 50%. With their hull guardian'ed, that message never plays. I'll undo some of my cheats and see what happens.