View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000367 | FSSCP | gameplay | public | 2005-04-16 05:02 | 2005-04-18 08:32 |
| Reporter | Goober5000 | Assigned To | Goober5000 | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | open | ||
| Summary | 0000367: Assert: sub_model_num < pm->n_models | ||||
| Description | I'm beta-testing the WCS prologue, and I've run into an assertion failure that I can't fix. (It's reproduced below.) On the surface, the code seems to be trying to access an out-of-bounds subobject 8 on a model (Jumpbuoy.pof) that only has 8 subobjects (0-7). Unfortunately, investigation reveals that there's a much bigger can of worms here. It seems that the TCS George Custer (model TCS_Venture-Class.pof) somehow got assigned the same modelnum as the jumpbuoy model. And I can't figure out where that happened, or even why, since sometimes the mission plays just fine. If another coder could help me out here, I'd appreciate it. I'm running the WCS Prologue Beta with the 4-14 build. I'm sure the WCS guys will allow internal access to get this straightened out. | ||||
| Additional Information | Assert: sub_model_num < pm->n_models File: C:\Languages\Visual Studio Projects\Visual C++\fs2_open\code\Model\ModelRead.cpp Line: 4214 Call stack: ------------------------------------------------------------------ ship_model_start() shipfx_eye_in_shadow() game_sunspot_process() game_render_hud_3d() game_frame() game_do_frame() game_do_state() gameseq_process_events() WinMainSub() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f() ------------------------------------------------------------------ | ||||
| Tags | No tags attached. | ||||
|
|
I run the game with fs2_open_r-T365.exe (an older build compiled by taylor), since it offers good performance and is stable. So far, I have not experienced any crashes while beta testing the game (and I tested a lot, I assure you) :) |
|
|
Interesting. I always wondered, why Fred-HTL is giving me an error about that model. It says : "Serious problem loading model jumpbouy.pof. 240 normals capped to zero." I have the same on the tcs_sheffield-class.pof, only that there are only 36 normals capped. Though after clicking "O.K" in FRED, in can be used and worked with fine (except that the error-message appears every load and safe). Error occurs only, when using -fredhtl flag. Besides that, I never had any ingame-problems with these two ships, I can also switch to mission 2 using the current campaign file, but I'm also using very few flags, namely those : -glow -jpgtga -fps -ambient_factor 125 Also you mention a problem with the bounding-boxes in modelview (guess that's the same FRED is complaining about), but it can be opened fine in the highpoly version of modelview. Besides that, I play very often with the docking-text build you submitted around september, it always works very stable for me, so does in this case. edited on: 04-16-05 08:48 |
|
|
Taylor figured out the problem. The "change-ship-model" sexp should not be used unless the two models have the same number of subobjects and subsystems. So switching from a Venture-class ship to a Jump Buoy is a big, huge, no-no. It can cause random crashes and mission instability. I'm adding a safety check in change-ship-model to prevent this problem in the future. In the meantime, you'll need to fix the mission. |
|
|
Safety check added. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-04-16 05:02 | Goober5000 | New Issue | |
| 2005-04-16 08:03 | Tolwyn | Note Added: 0002143 | |
| 2005-04-16 12:47 | starman01 | Note Added: 0002144 | |
| 2005-04-16 12:48 | starman01 | Note Edited: 0002144 | |
| 2005-04-17 05:38 | taylor | Status | new => assigned |
| 2005-04-17 05:38 | taylor | Assigned To | => taylor |
| 2005-04-17 17:48 | Goober5000 | Note Added: 0002155 | |
| 2005-04-18 08:32 | Goober5000 | Note Added: 0002158 | |
| 2005-04-18 08:32 | Goober5000 | Assigned To | taylor => Goober5000 |
| 2005-04-18 08:32 | Goober5000 | Status | assigned => resolved |
