[NeonShivan]

So I appear to have ran into quite a snag in my mod development. Sometimes a mission, specifically my very first mission, appears to glitch up the game. Causing the UI to fail to load in properly (example: The escape menu interface doesn't even load in. You can still click buttons and use it, but the UI itself fails to load). If you exit the game back to the mainhall, the mainhall will not load. I attempted to run this mission in the debugger which resulted in it crashing mid way through. This is my wild, shot in the dark guess, but I suspect it might be memory restrictions for the game itself.

This is the error the debugger spit out:

Code: [Select]

Assert: 0
File: cfile.cpp
Line: 862

kernel32.dll! WaitForSingleObjectEx + 58 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_2-DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_7_2-DEBUG.exe! WinAssert + 194 bytes
fs2_open_3_7_2-DEBUG.exe! cfget_cfile_block + 163 bytes
fs2_open_3_7_2-DEBUG.exe! cf_open_fill_cfblock + 35 bytes
fs2_open_3_7_2-DEBUG.exe! cfopen_special + 316 bytes
fs2_open_3_7_2-DEBUG.exe! snd_load + 616 bytes
fs2_open_3_7_2-DEBUG.exe! snd_play_3d + 120 bytes
fs2_open_3_7_2-DEBUG.exe! turret_swarm_fire_from_turret + 713 bytes
fs2_open_3_7_2-DEBUG.exe! turret_swarm_maybe_fire_missile + 614 bytes
fs2_open_3_7_2-DEBUG.exe! ship_process_post + 1454 bytes
fs2_open_3_7_2-DEBUG.exe! obj_move_all_post + 565 bytes
fs2_open_3_7_2-DEBUG.exe! obj_move_all + 417 bytes
fs2_open_3_7_2-DEBUG.exe! game_simulation_frame + 1132 bytes
fs2_open_3_7_2-DEBUG.exe! game_frame + 497 bytes
fs2_open_3_7_2-DEBUG.exe! game_do_frame + 239 bytes
fs2_open_3_7_2-DEBUG.exe! game_do_state + 379 bytes
fs2_open_3_7_2-DEBUG.exe! gameseq_process_events + 237 bytes
fs2_open_3_7_2-DEBUG.exe! game_main + 782 bytes
fs2_open_3_7_2-DEBUG.exe! WinMain + 330 bytes
fs2_open_3_7_2-DEBUG.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_7_2-DEBUG.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes

I can post the fs2_open log located in my data folder if necessary. Help is appreciated, thanks!

[The E]

The log is always necessary in cases like this.

For the record, that's the first time I've seen that particular assertion.

[The E]

Okay, here's what you'll need to do in order to help us figure this out. In the data folder, open the file called "debug_filter.cfg" or create it if it does not exist.

If it exists already, please erase its contents and put this in:

Code: [Select]

+General
-Parse
+CFileDebug

Then run the debug build, replicate the crash, and post the log.

[NeonShivan]

Well I kept a saved copy of the log from last night, I'll replicate the crash again using what you've told me at some point later but until then I'll post the older log anyways, see if it may be of any help: http://pastebin.com/uAp9RkGC

[niffiwan]

There's a few warnings in the log; I'd recommend having a look at this one 1st:

Code: [Select]

WARNING: Unrecognized parameter in ai_profiles: €                                                           
                                                                                                                                               
 
 
$smart afterburner managemen

It looks like there's some unrecognised characters in ai_profiles and that can cause all sorts of problems. I forget the exact text encoding that needs to be used for all tables (maybe windows 1252?), but UTF8 and other internationalisation capable formats are definitely not supported.

[NeonShivan]

This is the second log, pastebin was complaining about a limit as to how much I could paste so I uploaded the whole file to mediafire:
http://www.mediafire.com/download/k56vuo4prn2gqb7/fs2_open+-+copy+2.log

niffiwan, what do you suggest I do? I use microsoft's standard notepad to edit tables and they don't save as UTF8, they seem to save as ANSI.

EDIT: Wrong link lol

[Lepanto]

Notepad++ might help. It's also handy for doing things like search-and-replace across ALL files in a directory.

[niffiwan]

niffiwan, what do you suggest I do? I use microsoft's standard notepad to edit tables and they don't save as UTF8, they seem to save as ANSI.

I'd have a look for the Euro symbol somewhere near "$smart afterburner management" and delete it. It may just be a single odd character rather than an issue with the entire file, but it's a bit hard to tell without seeing the file itself (which I'm happy to look at if you want to share it)

[NeonShivan]

Check your PM

[niffiwan]

Oops, I was looking in completely the wrong place.  Your table was missing #END, when I added that the parsing error went away. Could you see if adding that also fixes the assert?

[NeonShivan]

How silly of me, I'll get on it when I can and will tell you the result.

[mjn.mixael]

I would also point you in the direction of this and this.

EDIT: And as Niffiwan mentioned.. your mod has a lot of warnings in the log. If you continue to develop without addressing these issues, then you are almost definitely going to run into issues, either yourself or your players when you release. You need to go through your debug log and fix LOD mismatches, missing textures, subsystem mismatches.. you've got some sort of shader error going on (are you trying to use custom shaders?), MOI missing, inverted bounding box on a ship... "Too many triangles in shield hit." is a new one to me, but most of these are very easy to fix. You just need to take the time to do it. Basically anything that starts with 'Warning:' needs to be addressed.

I highly, highly, HIGHLY recommend you spend a few days cleaning up your modpack. The types of warnings in your log are going to often present themselves as weird physics/collision issues. Then, when these are all fixed, do it again often, but especially after adding new assets to your mod.

This debug log makes sad panda truly depressed.

[NeonShivan]

I will most certainly take my time to fix these errors, how embarrassing. Also, I don't think the Panda's opinion matters here .

[zookeeper]

Well, in reality many warnings are completely harmless, but unless you know that a given warning is in fact harmless, you should fix it.

[mjn.mixael]

Many of the warnings may not be supremely visible, but they are there for a reason. If you don't put good data into the engine, you cannot reasonable always expect a good outcome. FSO tries to deal with these warnings on it's own, and generally, it does OK. But that's the backup solution. You should not be relying on that to deal with terrible mod data.

In summary: Good mod data = primary solution. FSO dealing with the issues silently = backup only solution.

[NeonShivan]

So I discovered this error when testing one of my missions in the debug build. Preferably someone could shed some light as to what this is:

Code: [Select]

Assert: fireball_type < Num_fireball_types
File: fireballs.cpp
Line: 789

ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_2-DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_7_2-DEBUG.exe! WinAssert + 194 bytes
fs2_open_3_7_2-DEBUG.exe! fireball_create + 102 bytes
fs2_open_3_7_2-DEBUG.exe! shipfx_blow_off_subsystem + 304 bytes
fs2_open_3_7_2-DEBUG.exe! do_subobj_destroyed_stuff + 1964 bytes
fs2_open_3_7_2-DEBUG.exe! do_subobj_hit_stuff + 4223 bytes
fs2_open_3_7_2-DEBUG.exe! ship_do_damage + 2487 bytes
fs2_open_3_7_2-DEBUG.exe! ship_apply_local_damage + 868 bytes
fs2_open_3_7_2-DEBUG.exe! ship_weapon_do_hit_stuff + 400 bytes
fs2_open_3_7_2-DEBUG.exe! ship_weapon_check_collision + 2968 bytes
fs2_open_3_7_2-DEBUG.exe! collide_ship_weapon + 381 bytes
fs2_open_3_7_2-DEBUG.exe! obj_collide_pair + 2327 bytes
fs2_open_3_7_2-DEBUG.exe! obj_find_overlap_colliders + 417 bytes
fs2_open_3_7_2-DEBUG.exe! obj_sort_and_collide + 288 bytes
fs2_open_3_7_2-DEBUG.exe! obj_move_all + 1167 bytes
fs2_open_3_7_2-DEBUG.exe! game_simulation_frame + 1132 bytes
fs2_open_3_7_2-DEBUG.exe! game_frame + 497 bytes
fs2_open_3_7_2-DEBUG.exe! game_do_frame + 239 bytes
fs2_open_3_7_2-DEBUG.exe! game_do_state + 379 bytes
fs2_open_3_7_2-DEBUG.exe! gameseq_process_events + 237 bytes
fs2_open_3_7_2-DEBUG.exe! game_main + 782 bytes
fs2_open_3_7_2-DEBUG.exe! WinMain + 330 bytes
fs2_open_3_7_2-DEBUG.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_7_2-DEBUG.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes

debug build: http://www.mediafire.com/download/kwhowlmjhg3ndlq/fs2_open.log (don't got Pastebin Pro)

[mjn.mixael]

Asserts like that can be a bear to track down... but where you start is by making sure you don't have debug log warnings and errors. Of which, you still have many.

Things like...

Code: [Select]

WARNING: "Model 'Gordia.pof', docking port 'dock01' has docking slot positions that lie on the same axis as the docking normal.  This will cause a NULL VEC crash when docked to another ship.  A new docking normal will be generated." at modelread.cpp:1759

Code: [Select]

WARNING: "After ship_copy_subsystem_fixup, ship 'BF Anouke' does not have subsystem 'weapons' linked into the model file, 'vfighter_01.pof'.  (Ship_info model is 'vfighter_01.pof' and subsystem model is 'NULL'.)" at ship.cpp:15710

Code: [Select]

WARNING: Unable to get shader uniform location for "desaturate"!

Code: [Select]

WARNING: "Rotation without rotation axis defined on submodel 'Turret03' of model 'GVCv_Petbe.pof'!" at modelread.cpp:1310

Code: [Select]

WARNING: "Couldn't open texture 'debris_1' referenced by model 'TCD-Midgard.pof'" at modelread.cpp:2335
...all look like they could lead to all kinds of fun crashes, especially when they exist in tandem with each other. And these are just the ones I cherry picked from the log.

Your log has about 100 warnings, some less severe than others, but all need to be fixed before I would really try and help debug an Assert.

[NeonShivan]

I'm going to need help with some of these errors then. Obviously I know what the last one is and has since been fixed but everything else I need help with.

Also, the shader, I am using no custom shaders.

[mjn.mixael]

My advice is to start at the top of your debug log and work down. Start by fixing anything you know how to one by one. Once you've fixed everything you know how to fix (and have tested with a new debug log to make sure they are fixed), go back to the top of the log. Ask here about whichever error you are going to work on next. You have a lot of errors that are similar to each other, so once you learn how to fix one, you'll be able to fix the others. Keep going down the line until you no longer get warnings in your log.

Take your time and do it right. While it may feel like it's a complete halt in mod progress, your mod will be all the better for it. I promise, I promise, I promise.

When this is done, once a week or so... do it again. This will prevent you from suddenly having hundreds of errors to fix. Instead you'll only have to fix a handful each time, give or take. What I do is I load the mod in Debug, then I load each ship and weapon using the F3 Lab. Once I get no errors that way, I load each mission in Debug.

Now as to specific errors.

Code: [Select]

WARNING: "Model 'Gordia.pof', docking port 'dock01' has docking slot positions that lie on the same axis as the docking normal.  This will cause a NULL VEC crash when docked to another ship.  A new docking normal will be generated." at modelread.cpp:1759
This one has to be fixed in the POF. It means that the docking data is not done correctly. A docking port has two associated points, which you'll see in PSC2. One is green and the other yellow. Both should have a small line pointing in the same direction coming out of the point. Distance between the two points isn't terribly important, I generally just make sure it's easy to tell that there are two separate points with lines. This error means that someone game the points and lines the exact same position data in PCS2.

So, open the POF in PCS2, and find the offending docking port data. Move one of the points along a single axis by a few units. Then make sure both points have normals (the lines) facing away from the ship model by setting appropriate Normal data. It may seem confusing, but just play with the numbers and you'll see what happens.

Here is an example of what it should look like.

Code: [Select]

WARNING: "After ship_copy_subsystem_fixup, ship 'BF Anouke' does not have subsystem 'weapons' linked into the model file, 'vfighter_01.pof'.  (Ship_info model is 'vfighter_01.pof' and subsystem model is 'NULL'.)" at ship.cpp:15710
I'm not entirely sure on this one. I would start by checking to make sure that the POF subsystem 'weapons' exists in the ship's table entry. I would also make sure any subsystem model is properly setup in the table and POF. Check the Wiki for more info on these. Start with Ships.tbl Wiki Page and POF Subsystem Properties Wiki Page.

Code: [Select]

WARNING: Unable to get shader uniform location for "desaturate"!
I don't know anything about this one.. Hopefully someone like The_E or AdmiralRalwood can shed some light here.

Code: [Select]

WARNING: "Rotation without rotation axis defined on submodel 'Turret03' of model 'GVCv_Petbe.pof'!" at modelread.cpp:1310
This one is simple enough. Again, you fix it in the POF file. It means that the turret in question has rotation data, but no one told it which axis it can rotate on. Find the subobject in question (not to be confused with the POF turret data, we want the actual model piece here) on the left panel. Select it, then on the right panel you need to tell it which Axis it can rotate on. It's probably currently set to 'None'.

[zookeeper]

So I discovered this error when testing one of my missions in the debug build. Preferably someone could shed some light as to what this is:

Code: [Select]

Assert: fireball_type < Num_fireball_types

Well, that's pretty straightforward: the game is trying to create a fireball, and the number of the fireball type is greater than the number of fireball types there are. You should be able to confirm that by padding fireball.tbl with extra entries.

Maybe your fireball.tbl is missing entries (should have at least 6), or maybe the ship or subsystem defines some custom fireball type which doesn't exist, or something like that.

EDIT: Or, since you don't seem to have a custom fireball.tbl (based on the log), maybe the mission for some reason has set a non-existent special explosion type for the ship.