[Wanderer]

I have got a rather odd problem... When ever i try to use ballistic weapons that are included to the parent table files (tbl) and afterburnertrails from tbms i get a rather depressing error report with debug builds, with r-builds i got no errors but the $PBank Capacity: field has no effect at all. Main fs2 folder contains no extra table or modular table files (apart from stars.tbl) and also no table files or modular table files were in any of the vp files (only extra vp file is ls_neb.vp) in the main freespace2 directory (/freespace2/, /freespace2/data/, /freespace2/data/xxx). Mediavps (3.6.8 delta) are run as a mod as per current recommendations. Problem appears if i have in the main table file a ballistic primary enabled ship that has afterburnertrails defined in some of the tbms (originally mv_effects.vp/mv_trails-shp.tbm seemed to cause the problems). I only get errors for those ships that have abtrails defined in tbms.

For example these test table files give me the error: Ships.tbl, Weapons.tbl, oro-shp.tbm. They are extracted directly from root_fs2.vp and i have only added a single ballistic primary to the allowed primaries list of the GTF Ulysses and also created a new ballistic primary weapon to the weapons.tbl. Again without the tbm they run fine and without errors but with the tbm i get the following error when running debug builds and wrong ballistic primary capacity but no errors if running r-build:

Code: [Select]

Warning: Pbank capacity not specified for ballistic-primary-enabled ship GTF Ulysses.
Defaulting to capacity of 1 per bank.

File:c:\fs2_open\code\ship\ship.cpp
Line: 3229
[This filename points to the location of a file on the computer that built this executable]

Call stack:
------------------------------------------------------------------
    fs2_open_d-20060127.exe 007f6598()
    fs2_open_d-20060127.exe 00a3529e()
    fs2_open_d-20060127.exe 007f6a19()
    fs2_open_d-20060127.exe 006d3973()
    fs2_open_d-20060127.exe 006e02e9()
    fs2_open_d-20060127.exe 006e0619()
    fs2_open_d-20060127.exe 00b56477()
    kernel32.dll 7c816d4f()
------------------------------------------------------------------
I can toggle this error message from appearing (and crashing the d-build) by renaming or removing the tbm that defines abtrails. After quick test (i begged Axem to try it out) this doenst seem to be a common problem...

Command line: FreeSpace2\fs2_open_d-20060127.exe -spec -glow -jpgtga -mipmap -nomotiondebris -2d_poof -dualscanlines -targetinfo -orbradar -rearm_timer -ballistic_gauge -nobeampierce -ship_choice_3d -3dwarp -warp_flash -snd_preload -fps -window  -ambient_factor 75 -fov 0.6

Other info: WinXP Pro /w sp2, amd 2400+, ATI Radeon 9600Pro, run in OGL mode, 640 x 400

EDIT: and this

fs2_open_d-20060127 caused an Integer Divide by Zero in module atioglxx.dll at 001b:691cdfe6.
Exception handler called in Freespace 2 Main Thread.
Error occurred at 1/30/2006 10:00:20.
d:\Games\FreeSpace2\fs2_open_d-20060127.exe

EDIT2: Errorlog text.. it has only something to do with pop up windows (like debug errors) and running the game in OGL mode... That combination causes the crash but the error report and the effects caused by it remains when running the game in DX8 mode.

[Wanderer]

Small addition still...

i) If i include ballistic primaries and abtrail stuff to the ships.tbl then no errors

ii) If i use -shp.tbm to define the ballistic primaries and the tbm that defines ballistic primaries has lower priority (loaded later) than abtrail tbm then no errors

iii) If i use -shp.tbm to define the ballistic primaries and the tbm that defines ballistic primaries has higher priority (loaded earlier) than the abtrail tbm then error occurs in very similar manner as with tbl + abtrail tbm case.

Any one care to explain what is going on?

EDIT: The same error occurs with any tbm (that trail thing now seems to be just the first that i came across) that modifies a ballistic primary enabled ship entry... Then i came across this: perhaps one of these would have something to do with this problem?

int parse_ship(bool replace)
{
   char buf[SHIP_MULTITEXT_LENGTH + 1];
   ship_info *sip;
   int i, j, num_allowed;
   int allowed_weapons[MAX_WEAPON_TYPES];
   int pbank_capacity_specified=0, pbank_capacity_count, sbank_capacity_count;

// optional ballistic primary imformation (Goober5000)......
   pbank_capacity_specified = 0;
   if(optional_string("$PBank Capacity:"))
   {
      pbank_capacity_specified = 1;

I dont know coding too well but to my eyes it seems that it is designed to delete the pbank capacity info when parsing a new tbm over existing ship entry... If the new tbm has no pbank capacity defined it overrides the earlier setting and redefines the pbank_capacity_specified to 0, resulting to the same thing as if the pbank capacity entry would have been missing. That is my guess... i dont know if it went right

[Goober5000]

I dont know coding too well but to my eyes it seems that it is designed to delete the pbank capacity info when parsing a new tbm over existing ship entry... If the new tbm has no pbank capacity defined it overrides the earlier setting and redefines the pbank_capacity_specified to 0, resulting to the same thing as if the pbank capacity entry would have been missing. That is my guess... i dont know if it went right

I'd say you're spot on with that guess (one of the few times a forumite has been right about a bug ).  It seems to me like WMC's modular tables clears the pbank capacity whenever a ship is re-parsed.

[WMCoolmon]

Good catch. It's actually not a problem with the TBM code; just that Goober used a local variable to check whether the table field existed , which has to be cleared every time the parse_ship function is called since it's recycled for use with every ship.

I've committed a quick fix that checks the actual data rather than using a local variable, tested it with both ballistic-primary using mods, and non-ballistic primary retail and it didn't complain.

[Goober5000]

Good catch. It's actually not a problem with the TBM code; just that Goober used a local variable to check whether the table field existed , which has to be cleared every time the parse_ship function is called since it's recycled for use with every ship.

I wasn't the one who wrote the TBM extension for ships.tbl.  Back when I coded the ballistic primaries, TBMs didn't even exist.

It looks like your hack fix removed my safety net, though.  I think I know what the cause is; the safety net just needs to be moved to after the entire ship parsing is done.