[General Battuta]

I am currently testing a mission involving many of Steve-O's and StratComm's models in addition to MVP versions of retail ships.

I am experiencing a persistent crash several minutes into the mission. When I run a debug build, I get the following spew:

Code: [Select]

Assert: geometry_map[index].laser == false
File: grbatch.cpp
Line: 624


Call stack:
------------------------------------------------------------------
    particle_render_all()    game_render_frame()    game_frame()    game_do_frame()    game_do_state()    gameseq_process_events()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c817077()
------------------------------------------------------------------

Is this a known error?

I am using 3.6.10 RC2. I will attempt to replicate the crash on earlier 3.6.10 builds, and I'll also try pulling various classes of ships from the mission to see if any particular class is responsible.

The debug log contains a lot of warnings about null moments of inertia, killing beams due to illegal targeting, and 'no more swarm missiles available.' I assume these are all pretty harmless.

[portej05]

Code: [Select]

Assert( geometry_map[index].laser == false );

You doing something unusual with lasers?

disclaimer: I have NO idea what I'm doing.

[General Battuta]

Just got this variant:

Code: [Select]

"*shot_index < b->binfo.shot_count" at Beam.cpp:1487
    beam_type_d_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 7c817077()
Freeing all existing models...
The crash appears to be occurring around the ten minute mark every time. I have no idea why this would be; there are no events set to go off then, and I don't believe any new weapon types are being fired...

[General Battuta]

Hrm. Is this what it looks like when you hit the object limit? I got yet another variant, this time when I pulled one ship from the mission and ran until the 20-minute mark.

Code: [Select]

Assert: ship_obj->type == OBJ_SHIP
File: ShipHit.cpp
Line: 2496


Call stack:
------------------------------------------------------------------
    ship_apply_global_damage()    do_dying_undock_physics()    ship_dying_frame()    ship_process_post()    obj_move_all_post()    obj_move_all()    game_simulation_frame()    game_frame()    game_do_frame()    game_do_state()    gameseq_process_events()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c817077()
------------------------------------------------------------------

I'm going to try cutting down on the number of shots being fired at any one point in the mission by segmenting the action a bit more. I think the engine's freaking out when too much goes on.

[karajorma]

I think you need to fix everything you can and post up anything you come across (except possibly the null MOI errors) in the order they pop up.

[General Battuta]

All right. I'll pull all the swarm missiles from the mission first off. And I'll try systematically converting the more crazy shiptypes to default versions temporarily.

[General Battuta]

Erm, so only got a couple 'killing beam at initial firing due to illegal target' things now, and the swarm issue is totally gone.

Instead I picked up a lot of 'unable to create debris because no slots are left' immediately before the crash. And this time it occurred early in the mission, as I was attempting to rearm, when the support ship got knocked off me by a beam. I've noticed a couple of these problems have been support-ship related.

I also got a lot of 'too many triangles in shieldhit'. Is that something that might cause crashes?

Is it perhaps because the model I'm using keeps producing errors about how it only has 3 dockpaths instead of 4?

EDIT: a new variant of the crash.

Code: [Select]

(0)
Beam couldn't find a good object model/type!! (0)
Beam couldn't find a good object model/type!! (0)
Beam couldn't find a good object model/type!! (0)
Beam couldn't find a good object model/type!! (0)
Beam couldn't find a good object model/type!! (0)
ASSERTION: "Patterns[SONG_AARV_1].handle >= 0" at eventmusic.cpp:1203
    event_music_arrival()    parse_wing_create_ships()    mission_eval_arrivals()    mission_parse_eval_stuff()    game_simulation_frame()    game_frame()    game_do_frame()    game_do_state()    gameseq_process_events()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c817077()
Int3(): From e:\storage\fso\fs2_open\code\globalincs\windebug.cpp at line 1072

Int3 errors.

It seems like the engine is just hitting some kind of wall and crashing. I've tried to cut back on what's happening in the mission, but it doesn't seem too effective...

[karajorma]

Okay, something strange is going on here. That one is obviously a music error causes when it tries to play the arrival tune for that soundtrack.

That could definitely cause a crash to desktop in release builds as it would skip the Assertion (they only do something in release builds) and then try to access the Patterns array with a negative index.

I suggest checking your music.tbl to see if there is anything strange going on with that piece of music.

[General Battuta]

The music error only occurs on debug builds, so I guess it's not a problem.

However, I believe I've localized the problem. It only occurs when large numbers of Steve-O's fighters are present in a mission. Twelve fighters was a safe bet, but too much more and it's risky business.

I'm now going to try to determine whether it is a problem with the fighters themselves or their weapons.

[karajorma]

The music error only occurs on debug builds, so I guess it's not a problem.

No, it's a problem. It may only crash the debug builds but in the release ones it won't play an arrival tune.

You got lucky this time, the coder remembered to check the index was valid. You can never assume that will always be the case. If someone later changes that code they may forget to check, at which point the table will start to crash the game.

Yes that's the coders fault for not checking but it doesn't mean you won't go through a bunch of hassle trying to figure out what caused it.


In short never assume that a debug message is harmless. Even if it seems to no effect now that may not always be the case.

However, I believe I've localized the problem. It only occurs when large numbers of Steve-O's fighters are present in a mission. Twelve fighters was a safe bet, but too much more and it's risky business.

I'm now going to try to determine whether it is a problem with the fighters themselves or their weapons.

Now that is strange. I can't think of any reason why the game would care.

[General Battuta]

Thanks for the music notification. That table will get checked out. It needs arrival music specified, yes?

Steve-O's fighters use an enormous number of textures, correct? And the mission is already loading all the textures required for the MVP models as well as StratComm's fleetpack? Is it possible that some kind of limit is being pushed, and that, when stressed, the mission is just crashing?

I swapped out all of Steve-O's ships for MVP FS2 models, and the crash has stopped.

EDIT: I just realized that both this mission and the test mission where I reproduced the crash include a particular station based on one of Trashman's models (the GTI Aeglos). I'm going to retry the test mission, swapping in an Arcadia for that station, and then see if it still crashes.

[karajorma]

Thanks for the music notification. That table will get checked out. It needs arrival music specified, yes?

I'm assuming that's the cause of the problem. I suppose a file in the wrong format might cause it too.

[General Battuta]

I've found the cause of the crash. It appears to be - of all things - the support ship. The crash generally occurs when rearming under fire.

This may be due to the support ship itself, or due to a problem with the dockpaths on Steve-O's fighters. However, the fighters themselves are not to blame; nor is Trashman's Aeglos.