[Dragon]

I decided to post because I got annoyed by this error and would like to solve this problem once and for all.
The problem is: I was debugging my mod using 3.6.10 RC2 INF build and after giving lot of useful information it sends this message:

Code: [Select]

---------------------------
Assertion Failed!
---------------------------
Assert: sip->primary_bank_weapons[i] >= 0File: Ship.cppLine: 3853Call

stack:------------------------------------------------------------------    parse_ship()    parse_shiptbl()    

parse_modular_table()    ship_init()    game_init()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll

7c817077()------------------------------------------------------------------[ This info is in the clipboard so you can

paste it somewhere now ]Use Ok to break into Debugger, Cancel to exit.
---------------------------
OK   Anuluj  
---------------------------

FRED debugger:

Code: [Select]

---------------------------
Assertion Failed!
---------------------------
Assert: sip->primary_bank_weapons[i] >= 0

File: Ship.cpp

Line: 3853





Call stack:

------------------------------------------------------------------

    fred2_open_3_6_10_RC2_INF_debug.exe 0053aae4()

    fred2_open_3_6_10_RC2_INF_debug.exe 0054075d()

    fred2_open_3_6_10_RC2_INF_debug.exe 00525f13()

    fred2_open_3_6_10_RC2_INF_debug.exe 00540c94()

    fred2_open_3_6_10_RC2_INF_debug.exe 00457abe()

    fred2_open_3_6_10_RC2_INF_debug.exe 0044d831()

    fred2_open_3_6_10_RC2_INF_debug.exe 009c6972()

    fred2_open_3_6_10_RC2_INF_debug.exe 009c62d4()

    fred2_open_3_6_10_RC2_INF_debug.exe 009c3e79()

    fred2_open_3_6_10_RC2_INF_debug.exe 009c4315()

    USER32.dll 7e368734()

    USER32.dll 7e37bdf1()

    USER32.dll 7e378ea0()

    USER32.dll 7e37ce7c()

    ntdll.dll 7c90e473()

------------------------------------------------------------------



[ This info is in the clipboard so you can paste it somewhere now ]





Use Ok to break into Debugger, Cancel to exit.


---------------------------
OK   Anuluj  
---------------------------
I'm attaching two files that have something to do with debugging ,can you tell me where to find debug_filter.cfg  so I can provide even more accurate info?
There is also one thing you should know.
I had an assertion problem in other mod after I have reskinned TAC1 and solved it by removing the maps.
Some info about maps:
Diffuse and shine maps were grayscale ,uncompressed JPGs made with Infran view from 3.6.10 mediavps maps.
Normal map was unchanged and Glow map was changed to blue throught "swap colors" function in Infran view.
This other mod though had different problem ,error popped up on when TAC1 was inserted there ,not at the start.
In regular FRED it just caused CTD.
Command line options for my main mod:

Code: [Select]

C:\Games\Freespace2\fs2_open_3_6_10_RC2_INF_debug.exe -mod Main\Root,Main\core -spec -glow -env -mipmap -missile_lighting -normal -3dshockwave -dualscanlines -targetinfo -rearm_timer -ballistic_gauge -ship_choice_3d -weapon_choice_3d -3dwarp -warp_flash  -mod Main\terra -height -ambient_factor 0 -no_emissive_light -spec_exp 11 -spec_point .6 -spec_static .8 -spec_tube .4 -ogl_spec 80
Main mod is split into smaller directories ,Root and Core have everything that is needed to run freespace and Terra have terran shipset.
I'm attaching .tbms ,but they may spoil the campaign suprise (though they are without descriptions and WIP).
The log file without "1" in name is the one given by the FRED debug.
I have Polish version of Windows XP Proffesional.
System specs:

Code: [Select]

Graphic Card: NVIDIA GeForce 9600 GT
Card's RAM: 512,00 MB
Installed Drivers: nv4_disp.dll
Sound Device: Realtek high Definition Audio
Total Disk Space on C: 292 ,97 GB
Free Disk Space on C: 236,30 GB
Total Disk Space on D: 156 ,25 GB
Free Disk Space on D: 114,03 GB

Freespace 2 is installed in C:/Games/Freespace2

Windows Error reporting in System Information:

Code: [Select]

2009-05-01 11:37 Application Error Aplikacja powodująca błąd fred2_open_3_6_10d-20090303_r5083.exe, wersja 1.0.0.1, moduł powodujący błąd fred2_open_3_6_10d-20090303_r5083.exe, wersja 1.0.0.1, adres błędu 0x005f513d.

2009-05-01 11:43 Application Error Aplikacja powodująca błąd fred2_open_3_6_10_rc2.exe, wersja 1.0.0.1, moduł powodujący błąd fred2_open_3_6_10_rc2.exe, wersja 1.0.0.1, adres błędu 0x0017cfc6.

2009-05-01 11:45 Application Error Aplikacja powodująca błąd fred2_open_3_6_10_rc2.exe, wersja 1.0.0.1, moduł powodujący błąd fred2_open_3_6_10_rc2.exe, wersja 1.0.0.1, adres błędu 0x0017cfc6.

2009-05-01 11:46 Application Error Aplikacja powodująca błąd fred2_open_3_6_10_rc2.exe, wersja 1.0.0.1, moduł powodujący błąd fred2_open_3_6_10_rc2.exe, wersja 1.0.0.1, adres błędu 0x0017cfc6.

2009-05-01 11:47 Application Error Aplikacja powodująca błąd fred2_open_3_6_10_rc2.exe, wersja 1.0.0.1, moduł powodujący błąd fred2_open_3_6_10_rc2.exe, wersja 1.0.0.1, adres błędu 0x000bd921.

2009-05-01 21:14 Application Error Aplikacja powodująca błąd fs2_open_3_6_10_rc1_inf.exe, wersja 1.0.0.1, moduł powodujący błąd fs2_open_3_6_10_rc1_inf.exe, wersja 1.0.0.1, adres błędu 0x000912ca.

2009-05-02 20:14 Application Error Aplikacja powodująca błąd fs2_open_3_6_10_rc1_inf_debug.exe, wersja 1.0.0.1, moduł powodujący błąd fs2_open_3_6_10_rc1_inf_debug.exe, wersja 1.0.0.1, adres błędu 0x003e3f2c.

2009-05-02 20:16 Application Error Aplikacja powodująca błąd fs2_open_3_6_10_rc1_inf_debug.exe, wersja 1.0.0.1, moduł powodujący błąd fs2_open_3_6_10_rc1_inf_debug.exe, wersja 1.0.0.1, adres błędu 0x003e3f2c.

2009-05-02 20:44 Application Error Aplikacja powodująca błąd fred2_open_3_6_10_rc2_inf_debug.exe, wersja 1.0.0.1, moduł powodujący błąd fred2_open_3_6_10_rc2_inf_debug.exe, wersja 1.0.0.1, adres błędu 0x00171637.

2009-05-02 20:45 Application Error Aplikacja powodująca błąd fred2_open_3_6_10_rc2_inf_debug.exe, wersja 1.0.0.1, moduł powodujący błąd fred2_open_3_6_10_rc2_inf_debug.exe, wersja 1.0.0.1, adres błędu 0x00171637.

2009-05-02 21:04 Application Hang Aplikacja zawieszająca helpctr.exe, wersja 5.1.2600.5512, moduł zawieszenia hungapp, wersja 0.0.0.0, adres zawieszenia 0x00000000.


That's all ,tell me if you need translation of something or I have forgotten something in this ocean of information.
(And please don't get mad on me because of those tons of info ,I really got upset because of those assertions)

[attachment deleted by evil Tolwyn]

[karajorma]

I got most of the cause from the first few lines of the assertion.

Code: [Select]

sip->primary_bank_weapons[i] >= 0
That means that a ship class has no primary weapons assigned to it

Code: [Select]

parse_ship()    parse_shiptbl()   parse_modular_table() 
While this tells me it's from one of your modular tables.

[Dragon]

Great thanks Kajorama ,I have one more question to you.
What exactly are assertion errors?
Because I'm sometimes getting them for various reasons.
For example this reskinned TAC one ,I have no idea what could caused it.
Also I got assertion errors while I accidently selected
pilot from OSE TBP build on normal build and when my little brother
played with FSO launcher and selected FRED build instead of FS2Open.
I would like to know what to do when I encouncer this kind of error and why
they make debug bulids refuse to continue (and normal bilds to CTD in most cases).

[karajorma]

In an ideal world the end user would never see a single assertion even if they ran the debug build.

An assertion is an error in the way the game was coded. You'll only ever see them in the debug builds because they make the game run more slowly. An assertion is a programmer's way of saying "If I haven't cocked things up, x must be true. If I have cocked it up, post a message to say I have so I can fix it." The end users should only ever see Warnings and Errors which in many cases are the game's way of saying "Someone has cocked up, check it isn't you first, then come see if it was me".

Problem is that developers like yourself are always coming up with interesting ways to cock up that the coders haven't ever thought of. In your case the problem was that you had this in your table

$Default PBanks ("")

And the coder who wrote that code assumed no one would ever do that. They assumed that they'd either include a weapon in between those quote marks, leave the brackets empty, or simply delete the line. The idea of someone managing to get past the code with something that wasn't one of those things didn't cross the coders mind.

Later on however the coder thought "I'd better check I haven't cocked up and allowed something through I shouldn't have" Which is why you get the assertion. The coder is saying "This must be a valid weapon, stop the game and complain if it isn't"

Problem is that we aren't in an ideal world and we don't have the manpower to fix every single problem that can cause an assertion and make it give a warning. So instead you'll occasionally hit an assertion if you do something stupid. For instance it's unlikely that anyone is going to fix this particular problem. The game doesn't hit it often and it would take time away from doing more useful things for a coder to fix it.

As a developer you have to treat assertions the way you would errors or warnings.

1) Check if you are doing something wrong and fix it.
2) Ask a coder if he has any idea if you're doing something wrong and how to fix it if you are.
3) Leave it up to the coder to fix whatever they did wrong.

The idea behind this change is to make it easier to go through those steps. Rather than making the coder spend ages fixing  a trivial problem so corrupt data doesn't assert instead the assert simply contains a little more information on what caused it.

Anyway, coming back to your actual problem. In the case of the TAC, post the actual assertion you get. In the case of the other two, stop doing stupid things like that.

[Dragon]

Thank you for explaination of the assertions ,they were my biggest problem while debugging my stuff.
I will post the assertion for TAC ,stupid things I did were temporary ,I though: "I will get this debugged ,corrected and later when it will come to balancing and tuning I will assign weapons."
It's a TC ,so I coudn't use retail dummy.

[karajorma]

Default Pbanks is marked as optional in the code so you should have been able to just removed the line.

[Dragon]

OK ,I ran into another assertion ,this time different from all that I seen.

Code: [Select]

---------------------------
Assertion Failed!
---------------------------
Assert: bank->num_slots < MAX_SLOTS

File: ModelRead.cpp

Line: 2736





Call stack:

------------------------------------------------------------------

    model_load()    labviewer_change_model()    labviewer_change_ship_lod()    DoMouseUp()    OnFrame()    OnFrame()    OnFrame()    OnFrame()    lab_do_frame()    game_do_state()    gameseq_process_events()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c817077()

------------------------------------------------------------------



[ This info is in the clipboard so you can paste it somewhere now ]





Use Ok to break into Debugger, Cancel to exit.


---------------------------
OK   Anuluj   
---------------------------
FRED

Code: [Select]

---------------------------
Assertion Failed!
---------------------------
Assert: bank->num_slots < MAX_SLOTS

File: ModelRead.cpp

Line: 2736





Call stack:

------------------------------------------------------------------

    fred2_open_3_6_10_RC2_INF_debug.exe 005a8c1c()

    fred2_open_3_6_10_RC2_INF_debug.exe 0054b211()

    fred2_open_3_6_10_RC2_INF_debug.exe 0045805f()

    fred2_open_3_6_10_RC2_INF_debug.exe 00458e17()

    fred2_open_3_6_10_RC2_INF_debug.exe 00457ee8()

    fred2_open_3_6_10_RC2_INF_debug.exe 0043fd67()

    fred2_open_3_6_10_RC2_INF_debug.exe 009c6df1()

    fred2_open_3_6_10_RC2_INF_debug.exe 009c62d4()

    fred2_open_3_6_10_RC2_INF_debug.exe 009c3e79()

    fred2_open_3_6_10_RC2_INF_debug.exe 009c4315()

    USER32.dll 7e368734()

    USER32.dll 7e368816()

    USER32.dll 7e37a013()

    USER32.dll 7e37a039()

    OPENGL32.dll 5f1b699b()

------------------------------------------------------------------



[ This info is in the clipboard so you can paste it somewhere now ]





Use Ok to break into Debugger, Cancel to exit.


---------------------------
OK   Anuluj   
---------------------------
Can you tell me what mean this one?
This is reskinned Steve'o's thor ,textures are uncompressed JPGs made with InfranView.
Error pops up when inserting it to FRED or displaying in lab.
Log with 1 is  FSO debug ,without 1 FRED debug.

[attachment deleted by ninja]

[Flaming_Sword]

Too many guns in a gun bank (model issue)?

(this is just a guess)

[karajorma]

Sounds like that to me too. You seem to have too many gunpoints. How many does the model have?

[Dragon]

Don't you know the FTF Thor?
Guns:
1. 2 points
2. 4 points
3. 1 point
Missiles:
1. 28 points
2. 4 points
3. 3 points

It seem strange to me ,three gun banks were allowed since retail.
(I managed to fly Seraphim without CTD ,the only problem was I couldn't switch weapons)
I also encoucered another strange error ,FRED CTD when I insert one of my ships and
I'm trying to show models. It seems that TAC1 problem was also it ,I messed
a bit with tables so I think I fixed it the other way
(the first assertion I posted pops up also when all primaries on ship
are nonexistant ,I fixed problems like this when trying to do something with TAC).

[Wanderer]

Maximum number of firing points per weapon bank is 25...

[Dragon]

Thanks Wanderer ,I would like to know why Steve'o's originals
worked all the time ,but it's not so important now.
This mysterious CTD was caused by JPG textures ,can you check this code for errors?
When I converted those textures to PCX one of them was missing ,after
I converted this one to TGA it appeared and work flawlessly.
I will post if I encouncer more assertion errors (IE. soon).

[Dragon]

OK ,now somethig worse than assertion ,debug build just CTD.
I'm including the log, but I'm totally confused and
I don't know what may have happened.
(FRED works fine and I made the mission I tried to run when it crashed).

[attachment deleted by ninja]

[karajorma]

You hit an Int3(). An Int3() is a close relative of the assertion. The coder adds them when you reach a piece of code that you should never ever hit. Basically it's asserting that you can't possible get to this bit of the code.

Code: [Select]

if ( (header.pixel_depth != 16) && (header.pixel_depth != 24) && (header.pixel_depth != 32) ) {
Int3();
return TARGA_ERROR_READING;
}
You appear to have a TGA file that isn't 16, 24 or 32 bit. The game thinks that's impossible so it Int3()s to tell the coder that somehow code is reaching a part of the code that it shouldn't be possible to reach.

I suppose it might be worth improving Int3() in the same way I did with Assertion. It would be a lot easier too actually.

[Dragon]

Thanks ,after your post I downloaded DDS converter ,converted my textures to DDS and it worked.
Now after the mission start I get this assertion :

Code: [Select]

---------------------------
Assertion Failed!
---------------------------
Assert: ti->texture.bitmap_id != -1

File: Trails.cpp

Line: 414





Call stack:

------------------------------------------------------------------

    trail_render_all()    game_render_frame()    game_frame()    game_do_frame()    game_do_state()    gameseq_process_events()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c817077()

------------------------------------------------------------------



[ This info is in the clipboard so you can paste it somewhere now ]





Use Ok to break into Debugger, Cancel to exit.


---------------------------
OK   Anuluj   
---------------------------

I think it has something to do with trails ,but all trails I have seem valid.
And you helped me very much ,I think you should know on what you're supporting me
,so I'm attaching pic of one of the ships you helped me to get to work.
Unfortunately said error popped up when I tried to fly the mission in this (and other)
ships ,so I cannot give you in-game shots.

[attachment deleted by ninja]

[chief1983]

Shouldn't most Int3()'s be preceded by a logged message though?  I mean I know not everyone does them that way, but I thought that was a recommended practice.  Then you have control of what types of debug logging will output the message to the log as well.

[karajorma]

And you helped me very much

Unfortunately that one I probably can't help you with. My knowledge of the graphics code is rather poor and I had to actually search to figure out in which folder Trails.cpp was let alone what the code does.

You are correct in thinking that the error lies in one of your ship's trails though. It's caused by one of the trails not actually having a bitmap image specified or one which doesn't exist or which is an invalid type (something similar to the TGA error above, probably with a different file type for the texture though).

Beyond that I can't really help much.

Shouldn't most Int3()'s be preceded by a logged message though?  I mean I know not everyone does them that way, but I thought that was a recommended practice.  Then you have control of what types of debug logging will output the message to the log as well.

Personally I think overloading the Int3() function to have an Int3(variable args) version which prints a message and then calls Int3() is a much cleaner way of handing it. It makes it much clearer that the message is only supposed to print on an Int3().

Sometimes the only sensible thing an Int3() can do is crash the program and print the location to the log. But sometimes when the error is data rather than code (as above) it makes sense for it to print out a message first that can help the user figure out what is wrong and fix it.

[Dragon]

OK ,I found this is showing only in debug ,maybe it will don't do any damage.
But I have a problem.
Is there a limit of number of pulses on the battlefield?
Because the mission is generally a giant BOE made for testing ,and it happens that
,for example ,only one gun is firing ,even though there are three.
And I have weird collision problems (like player's shots not hitting the
enemy uless you're very close).
These ships use a lot of blob turrets ,those who played X2 or 3 and seen
Photon Pulse Cannons in action know what I mean.
I would like to know if this rain of blobs causes thes behaviour.
Capships are all from Stratcomm's fleet pack ,of course reskinned.
There are two Titans ,Sparta ,two Hyperions ,Chimera and Bellerophon on
friendly side ,hostles have two titans replaced with Raynor.
All ships have fast firing ,slow moving anti cap blobs in all multipart turrets.
(and torpedoes diverted from Cruiser Torpedo from INF in missile packs).
Only player's fast firing cannons have collision problems ,big pulses
seem to work flawlessly (I want them to make them $Swarm: 2 and
micriscopic $Swarm wait: to make them fire from both barrels simultanously ,is
that a good idea?)
All this happens on standard build ,I cannot run this mission in debug because of assertion.

[Flaming_Sword]

Yes, there is a limit (total number of objects). I even made a mission designed to hit that limit.

[karajorma]

OK ,I found this is showing only in debug ,maybe it will don't do any damage.

What I said to Battuta here applies equally well in this situation. You also are dealing with a bad index variable so the danger is the same.

As for your other problem. I suspect you're running of out weapons. The game only allows a maximum of 350 weapons to be flying around at any one time. It's very easy to go over that limit.