View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001638 | FSSCP | --------- | public | 2008-03-23 21:34 | 2008-03-31 17:08 |
Reporter | FUBAR-BDHR | Assigned To | taylor | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 3.6.9 | ||||
Fixed in Version | 3.6.10 | ||||
Summary | 0001638: Special explosions not working correctly with shockwaves | ||||
Description | Special explosions in regular FS2 seem to work just fine. In TBP however the damage does not work correctly if shockwave is enabled. Only ships between the inner and outer damage radius seem to take damage. Ship closest to the blast don't take any damage or minimal damage. | ||||
Additional Information | Didn't know what to report this under since it works in FS2 and I haven't tried it in BTRL. Happens in both the latest 3.6.9 build of TBP and Kara's 3.6.10 recent build. First file is from FS2. Second from TBP. | ||||
Tags | No tags attached. | ||||
2008-03-23 21:34
|
|
2008-03-23 21:36
|
|
|
I also notice that with the shockwave turned off the explosion is invisible. Don't know if that is by design or not. |
|
Hmmmm. I get a Warning: Null vec3d in vec3d normalize. Trace out of vecmat.cpp and find offending code. when running both missions. Beyond that I think this is well beyond my expertise as vecmat.cpp give me palpitations. |
2008-03-28 02:21
|
|
|
Yea I get the same thing when I run in debug mode. Attaching log from the is-player build. Wonder if the same thing happens in BTRL or if it's just TBP. I don't have BTRL installed or I'd give it a try. |
|
I knew that error message sounded familiar. http://scp.indiegames.us/mantis/view.php?id=1090 |
|
Not sure if anyone was actually working seriously on this or not, but after about 2 hours of trying to track it down I finally figured it out. The heart of the problem is the "carry no damage" flag on subsystems and a bug that messes up how it's handled. When "carry no damage" is used it will subtract the damage used against that subsystem from what the rest of the ship gets. Unfortunately the check that got added to return the eventual damage level turned out to only check the first subsystem for the "carry no damage" flag and then assumes that none of the other subsystems carry damage either. In cases where a ship has a mix of subsystems that have that flag it will obviously screw up the damage count and can easily apply far too little damage to the ship in the end (particularly in this case with EF1 and the "rotatea" subsystem which doesn't have the flag but accounts for about 50% of the hull). This can be fixed by handling that stuff properly, but I'm a little worried about what might break in the process. Technically it's a pretty bad bug though so we'll have to do something about it one way or the other. |
2008-03-29 14:44
|
damage_fix.diff (2,682 bytes)
Index: code/ship/shiphit.cpp =================================================================== --- code/ship/shiphit.cpp (revision 4558) +++ code/ship/shiphit.cpp (working copy) @@ -1285,11 +1285,14 @@ damage_to_apply = Armor_types[subsys->system_info->armor_type_idx].GetDamage(damage_to_apply, dmg_type_idx); } + // if this subsystem doesn't carry damage then subtract it off of our total return + if (subsys->system_info->flags & MSS_FLAG_CARRY_NO_DAMAGE) { + damage -= MIN(subsys->current_hits, damage_to_apply); + } + subsys->current_hits -= damage_to_apply; ship_p->subsys_info[subsys->system_info->type].current_hits -= damage_to_apply; - - if (subsys->current_hits < 0.0f) { damage_left -= subsys->current_hits; ship_p->subsys_info[subsys->system_info->type].current_hits -= subsys->current_hits; @@ -1313,17 +1316,14 @@ //nprintf(("AI", "j=%i, sys = %s, dam = %6.1f, dam left = %6.1f, subhits = %5.0f\n", j, subsys->system_info->name, damage_to_apply, damage_left, subsys->current_hits)); } + if (damage < 0.0f) { + damage = 0.0f; + } + // Note: I changed this to return damage_left and it completely screwed up balance. // It had taken a few MX-50s to destory an Anubis (with 40% hull), then it took maybe ten. // So, I left it alone. -- MK, 4/15/98 - //WMC - MK, whoever you are, thank you for that comment. - if(count) - { - if(subsys_list[0].ptr->system_info->flags & MSS_FLAG_CARRY_NO_DAMAGE) - { - return damage_left; - } - } + return damage; } @@ -2471,9 +2471,6 @@ shipp = &Ships[ship_obj->instance]; ship_info* sip = &Ship_info[shipp->ship_info_index]; - // maybe adjust damage done by shockwave for BIG|HUGE - maybe_shockwave_damage_adjust(ship_obj, other_obj, &damage); - // Goober5000 - check to see what other_obj is if (other_obj) { @@ -2494,15 +2491,18 @@ other_obj_is_ship = 0; } + // maybe do some damage scaling based on whether it's a weapon or shockwave + if (other_obj_is_shockwave) { + maybe_shockwave_damage_adjust(ship_obj, other_obj, &damage); + } else if (other_obj_is_weapon) { + damage *= weapon_get_damage_scale(&Weapon_info[Weapons[other_obj->instance].weapon_info_index], other_obj, ship_obj); + } + // update lethality of ship doing damage - modified by Goober5000 if (other_obj_is_weapon || other_obj_is_shockwave) { ai_update_lethality(ship_obj, other_obj, damage); } - // if this is a weapon - if (other_obj_is_weapon) - damage *= weapon_get_damage_scale(&Weapon_info[Weapons[other_obj->instance].weapon_info_index], other_obj, ship_obj); - MONITOR_INC( ShipHits, 1 ); // Don't damage player ship in the process of warping out. |
|
And here is the patch that I'm testing with now. It's got an ai_lethality fix in there too however. |
|
Tested the 3.6.9 build with this fix included that Kara made for TBP and it looks like it's working just fine. |
|
Good to hear. I'm going to go ahead and commit, but with a slight change from the attached diff. I was previously reducing the damage total after the armor reduction call, but that doesn't account for the total damage that was applied to that subsystem. So going by WMC's comment right above that I moved the block just above the armor call so that we get the proper amount of damage removed from the total. I'm not sure what sort of affect that would have on your tests, but it should be negligible, at most. Maybe karajorma's next build will have the modification and then you can give it another test just to be 100% sure. |
|
Fixered. |
Date Modified | Username | Field | Change |
---|---|---|---|
2008-03-23 21:34 | FUBAR-BDHR | New Issue | |
2008-03-23 21:34 | FUBAR-BDHR | File Added: blasttest.fs2 | |
2008-03-23 21:36 | FUBAR-BDHR | File Added: blasttest2.fs2 | |
2008-03-23 21:49 | FUBAR-BDHR | Note Added: 0009023 | |
2008-03-28 01:57 | karajorma | Note Added: 0009041 | |
2008-03-28 02:21 | FUBAR-BDHR | File Added: fs2_open.log | |
2008-03-28 02:21 | FUBAR-BDHR | Note Added: 0009042 | |
2008-03-28 02:22 | FUBAR-BDHR | Note Edited: 0009042 | |
2008-03-28 05:40 | FUBAR-BDHR | Note Added: 0009046 | |
2008-03-28 05:41 | FUBAR-BDHR | Note Edited: 0009046 | |
2008-03-29 14:33 | taylor | Note Added: 0009054 | |
2008-03-29 14:44 | taylor | File Added: damage_fix.diff | |
2008-03-29 14:44 | taylor | Note Added: 0009055 | |
2008-03-31 08:58 | taylor | Status | new => assigned |
2008-03-31 08:58 | taylor | Assigned To | => taylor |
2008-03-31 09:24 | FUBAR-BDHR | Note Added: 0009106 | |
2008-03-31 17:05 | taylor | Note Added: 0009112 | |
2008-03-31 17:08 | taylor | Status | assigned => resolved |
2008-03-31 17:08 | taylor | Fixed in Version | => 3.6.10 |
2008-03-31 17:08 | taylor | Resolution | open => fixed |
2008-03-31 17:08 | taylor | Note Added: 0009113 |