[jc4jc]

I have a new model that will load in the in-game Ship Viewer and during game play, entering, already in mission and leaving, just fine. However, when the ship is destroyed the game crashes. I am using the fs2_open_3_6_12r_INF_SSE.exe build. I'm thinking that I have something up with the model but I'm not sure where. PCS2 is loading it fine but I have no clue if that means anything.

[MatthTheGeek]

Right. Why are you modding with a release build ? We didn't invent debug builds just for the shows. Please produce a debug log.

[jc4jc]

Because I forgot I had switched to the Release Version to play Wing Commander Darkest Dawn and posted what was last in the Launcher. I also forgot to post the debug data and had to regenerate it. Here is the critical fail point:

Code: [Select]

Assert: sip->subsystems[j].model_num == sip->model_num
File: ship.cpp
Line: 14443

<no module>! KiFastSystemCallRet
<no module>! WaitForSingleObject + 18 bytes
<no module>! SCP_DumpStack + 354 bytes
<no module>! WinAssert + 208 bytes
<no module>! ship_page_in + 2108 bytes
<no module>! level_page_in + 48 bytes
<no module>! freespace_mission_load_stuff + 206 bytes
<no module>! game_post_level_init + 182 bytes
<no module>! game_start_mission + 387 bytes
<no module>! game_enter_state + 482 bytes
<no module>! gameseq_set_state + 310 bytes
<no module>! game_process_event + 242 bytes
<no module>! gameseq_process_events + 152 bytes
<no module>! game_main + 782 bytes
<no module>! WinMain + 330 bytes
<no module>! __tmainCRTStartup + 358 bytes
<no module>! WinMainCRTStartup + 15 bytes
<no module>! RegisterWaitForInputIdle + 73 bytes

I understand that a subsystem is to blame but but how do I determine which one.

[General Battuta]

I think we'll need the whole log.

[jc4jc]

OK. I will forewarn that much of the items are all works in progress and that much of the warnings and errors are thing I am still trying to get fixed. This is just the one that is kicking me in the rear right now and I can seem to fix.


[attachment deleted by ninja]

[Wobble73]

Does the model have debris?

[The E]

Code: [Select]

ASSERTION: "nv > 0" at modelinterp.cpp:4157
This one is impossible to trace, as the code in modelinterp.cpp, which is responsible for interpreting model data and making it usable for OpenGL usage has changed quite a lot from 3.6.12 (which you are using) to 3.6.14 (which is the current RC build). Please run this again with one of the release candidate builds so we can get an error message from that; chances are it's going to be much more usable.

Code: [Select]

Assert: sip->subsystems[j].model_num == sip->model_num
File: ship.cpp
Line: 14443
As for this error, it's kinda baffling because it's one of those "this should never ever happen" things. The problem here is the following: For each ship, the engine keeps an internal reference for which model is being used. For every subsystem, there is a similar reference (which, while it may sound redundant, is actually a major timesaver in some areas of the code); and since all subsystem models need to be defined in the same model file as the base model, this must be the same model ID. In this case, this assumption has been violated somehow. In order to fix this, it would be preferable if you could post (or PM) the model in question and its associated tbl entry so that a coder can take a closer look at it.

[jc4jc]

Does the model have debris?

No I have not gotten that far with any of the models.

Code: [Select]

ASSERTION: "nv > 0" at modelinterp.cpp:4157
This one is impossible to trace, as the code in modelinterp.cpp, which is responsible for interpreting model data and making it usable for OpenGL usage has changed quite a lot from 3.6.12 (which you are using) to 3.6.14 (which is the current RC build). Please run this again with one of the release candidate builds so we can get an error message from that; chances are it's going to be much more usable.

Code: [Select]

Assert: sip->subsystems[j].model_num == sip->model_num
File: ship.cpp
Line: 14443
As for this error, it's kinda baffling because it's one of those "this should never ever happen" things. The problem here is the following: For each ship, the engine keeps an internal reference for which model is being used. For every subsystem, there is a similar reference (which, while it may sound redundant, is actually a major timesaver in some areas of the code); and since all subsystem models need to be defined in the same model file as the base model, this must be the same model ID. In this case, this assumption has been violated somehow. In order to fix this, it would be preferable if you could post (or PM) the model in question and its associated tbl entry so that a coder can take a closer look at it.

OK

Revised
I understand the logic behind parallel Arrays and pointers. And your right looking at the Model and tbl file entry could be useful. I am in a rough spot with this as I have very retraining permissions with the models from their creators.

[The E]

Which is why I mentioned using a pm to send it to a coder (like me). We can be trusted to not spread these things around.

Also, if you are planning to release this mod at some point in the future, you would have to share the model anyway...