View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000900 | FSSCP | turrets | public | 2006-05-01 11:59 | 2006-06-10 20:52 |
| Reporter | karajorma | Assigned To | WMCoolmon | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000900: FS2_Open Asserts in The King's Gambit | ||||
| Description | FS2_Open asserts in King's Gambit seconds after the first Orion is destroyed. (on one occassion the Orion blew up okay but it asserted on the second capship instead). The message I get is this. Assert: model_num > -1 File: D:\C++\Freespace\fs2_open\code\Model\ModelRead.cpp Line: 3299 [This filename points to the location of a file on the computer that built this executable] Call stack: ------------------------------------------------------------------ model_find_world_point() ship_get_global_turret_gun_info() beam_get_global_turret_gun_info() beam_type_a_move() beam_move_all_pre() obj_move_all() game_simulation_frame() game_frame() game_do_frame() game_do_state() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f() ------------------------------------------------------------------ | ||||
| Additional Information | Did a little digging and I found that this line model_subsystem *tp = ssp->system_info; in ship_get_global_turret_gun_info() is setting tp with all kinds of bad data. Not really familiar enough with the turret code to look into it any further though. I'm getting this with latest CVS from Phreak too. | ||||
| Tags | No tags attached. | ||||
|
|
* BUMP * Is this still an issue? So far I haven't been able to recreate it. |
|
|
It's definitely not gone. Sometimes the Pax triggers it instead of the Uhuru but I rarely get any further than one of those two. |
|
|
Update to current CVS and see if it's any better. |
|
|
This bug seems to be occurring for me (in 3.6.9RC1), but at an earlier point: targeting the Uhuru as it jumps in-system, causes a CTD right as the ship is about halfway out of the node. Oddly enough, when i try using the debug build, the bug doesn't appear--it seems to only manifest in the 'regular' build. Is that perhaps a factor in why the bug won't recreate for taylor? |
|
|
The crash when the Uhuru jumps in should be fixed, I got that one too and found the problem pretty quickly. Simply based on the bug though it could have worked in debug/release builds differently because of how that type of thing is handled by Windows. You'll have to grab the next RC build, or WMCoolmon's current CVS test build, to see if it's fixed for you. I'm hoping that the same fix will squash karajorma's bug too. It's related to the same thing, and though it's happening in a different spot, I think it could just be a delayed reaction to the same bug (ie, it got corrupted earlier because the memory was invalid in the first place). |
|
|
Nope. Still getting the problem unfortunately with the latest CVS. |
|
|
WMCoolmon's release build crashes for me at startup. [puzzled] |
|
|
The build in question is more optimized for P4 processors than most other builds, that may be a problem. |
|
|
I think I may have figured it out. It looks as though the problem was that all beam types, except for C, required the turret gun info from a ship in order to function. Once the ship was destroyed, that info wasn't present. But the beam still was. The fix I committed, will delete a beam (except for C) when the object associated with it is set to none. It's probably not foolproof - if a ship dies and another object is created in the old spot in the same frame, the safeguard won't trigger - but it makes it less likely for the problem to occur. EDIT: Doh. I realized that beams actually do save the signature of the firing ship, so the fix should be relatively foolproof now. Mostly I'm worried about if a campaign depends on the beam-firing-after-death bug. edited on: 06-10-06 16:52 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-05-01 11:59 | karajorma | New Issue | |
| 2006-06-01 18:36 | taylor | Note Added: 0005696 | |
| 2006-06-03 19:49 | karajorma | Note Added: 0005743 | |
| 2006-06-06 09:30 | taylor | Note Added: 0005781 | |
| 2006-06-10 06:31 | Crusader | Note Added: 0005804 | |
| 2006-06-10 09:32 | taylor | Note Added: 0005805 | |
| 2006-06-10 10:36 | karajorma | Note Added: 0005807 | |
| 2006-06-10 14:36 | Crusader | Note Added: 0005808 | |
| 2006-06-10 20:07 | WMCoolmon | Note Added: 0005813 | |
| 2006-06-10 20:45 | WMCoolmon | Note Added: 0005815 | |
| 2006-06-10 20:52 | WMCoolmon | Note Edited: 0005815 | |
| 2006-06-10 20:52 | WMCoolmon | Status | assigned => resolved |
| 2006-06-10 20:52 | WMCoolmon | Resolution | open => fixed |
