View Issue Details

IDProjectCategoryView StatusLast Update
0003139FSSCPgameplaypublic2015-05-19 22:09
ReporterHC-Emp Assigned ToMageKing17  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.7.2 RC5 
Target Version3.7.4Fixed in Version3.7.3 
Summary0003139: Ship explosions ignore damage type settings
DescriptionThe shockwave caused by an exploding ship appears to ignore the damage type set by either the $Shockwave Damage Type table entry or the ship-set-shockwave-damage-type SEXP, and deals unmodified damage.
Additional InformationThis is a real problem for AI strikecraft that trade shields for heavy armor, as they don't flee from dying ships and even a Fenris' shockwave can ruin their day.
TagsNo tags attached.

Activities

HC-Emp

2015-02-03 17:25

reporter  

shockwave.zip (2,877 bytes)

MageKing17

2015-02-03 19:58

developer   ~0016469

Shockwaves caused by ship death most certainly are using damage types correctly. However, the blast caused by a ship exploding when it doesn't have a shockwave speed (this is an instantaneous AoE damage effect) will not use the shockwave damage type (because it's not a shockwave); it uses the ship's collision damage type instead.

Since ship_do_damage() and do_subobj_hit_stuff() only know that the damage is coming from an object of type OBJ_SHIP, they assume the two ships are colliding and use the collision damage type. If changing the ship's collsion damage type is undesirable (and, really, there are a lot of reasons to want an explosion to have a different damage type than a collision), and giving the ship a shockwave speed is similarly undesirable, then the code will need to be changed to allow the damage functions to tell when a ship is exploding instead of colliding (that, or temporarily change the ship's collision_damage_type_idx... but that would be quite hackish).

HC-Emp

2015-02-04 14:41

reporter   ~0016470

Last edited: 2015-02-04 14:46

MageKing, I'm able to replicate the behavior you mention in the test mission (a meson bomb sat next to a crate) by altering the bomb's shockwave speed and impact damage type - the crate survives. However, when I restore the shockwave speed to its retail value, the crate is pulverized even if it's armor is set to multiply the shockwave damage type by 0. Honestly, I'm hard pressed to think of a time when a non-shockwave ship explosion would be readily apparent in normal gameplay; as I mentioned this is most noticeable when small ships are crowded around attacking a capital ship.

Anecdotally, I can also confirm that if the "shockwaves damage small ship subsystems" flag is flipped on, a Demon's shockwave will maul an unshielded Bakha's subsystems, even if the subsystem armor is set to negate the shockwave's damage type. At first I thought this was my fault for goofing off and mixing FS1 behavior with advanced ones like armor, but bomb shockwaves behave as documented: with the same set-up the Bakha can eat a Helios shockwave at close range and suffer no subsystem damage.

Could somebody else have a pop at replicating this? I'm pretty sure at this point that it's not just me setting things up wrong but I'd like confirmation.

MageKing17

2015-02-04 22:24

developer   ~0016471

Well, restoring the retail value (100) would naturally cause it to generate a shockwave, thereby making it use the shockwave damage type instead of the impact damage type, so making it immune to the impact damage type instead of the shockwave damage type won't help it survive there.

There are a couple of caveats that could cause unintended behavior (I haven't yet had time to try out your test mod, so I don't know if you're even doing any of these, but I just thought I'd throw them out there):

1) "Kamikaze" ships skip normal blast/shockwave definitions (you can use a "special explosion" to override this).
2) "Special explosions" will, of course, override normal blasts/shockwaves.
3) If the ship/subsystem/shield receiving damage doesn't have an armor type set, the damage type is ignored (the only damage scaling will be difficulty scaling).

If none of those apply, hopefully I'll have some time later to verify that the problem is engine-side.

MageKing17

2015-02-05 20:06

developer   ~0016472

Last edited: 2015-02-05 20:19

Turns out that the ship's shockwave damage type wasn't ever actually being copied onto the shockwave that was created. I should have a patch to fix this up shortly.

EDIT: And done. Note that this will also make kamikaze and "special explosion" shockwaves use the ship's shockwave damage type. Given that there was no particular reason to expect them not to, this may not be a big deal... but at the same time, there was no particular reason to expect them to do so, either, and it might break something in a released mod.

MageKing17

2015-02-05 20:16

developer  

3139.patch (530 bytes)   
Index: code/ship/ship.cpp
===================================================================
--- code/ship/ship.cpp	(revision 11238)
+++ code/ship/ship.cpp	(working copy)
@@ -7163,11 +7163,8 @@
 	}
 
 	if ( shockwave_speed > 0 ) {
-		shockwave_create_info sci;
-		shockwave_create_info_init(&sci);
+		shockwave_create_info sci = sip->shockwave;
 
-		strcpy_s(sci.name, sip->shockwave.name);
-		strcpy_s(sci.pof_name, sip->shockwave.pof_name);
 		sci.inner_rad = inner_rad;
 		sci.outer_rad = outer_rad;
 		sci.blast = max_blast;
3139.patch (530 bytes)   

MageKing17

2015-05-15 23:14

developer   ~0016707

Pull request: https://github.com/scp-fs2open/fs2open.github.com/pull/105

MageKing17

2015-05-19 22:09

developer   ~0016709

Merged: https://github.com/scp-fs2open/fs2open.github.com/commit/7bf700f1730f168e8eeebb4ca0e57504382176fb

Issue History

Date Modified Username Field Change
2015-02-03 17:25 HC-Emp New Issue
2015-02-03 17:25 HC-Emp File Added: shockwave.zip
2015-02-03 19:58 MageKing17 Note Added: 0016469
2015-02-03 19:58 MageKing17 Status new => confirmed
2015-02-04 14:41 HC-Emp Note Added: 0016470
2015-02-04 14:46 HC-Emp Note Edited: 0016470
2015-02-04 22:24 MageKing17 Note Added: 0016471
2015-02-05 20:06 MageKing17 Note Added: 0016472
2015-02-05 20:06 MageKing17 Assigned To => MageKing17
2015-02-05 20:06 MageKing17 Status confirmed => assigned
2015-02-05 20:16 MageKing17 File Added: 3139.patch
2015-02-05 20:16 MageKing17 Status assigned => code review
2015-02-05 20:19 MageKing17 Note Edited: 0016472
2015-05-15 23:14 MageKing17 Note Added: 0016707
2015-05-19 22:09 MageKing17 Note Added: 0016709
2015-05-19 22:09 MageKing17 Status code review => resolved
2015-05-19 22:09 MageKing17 Resolution open => fixed
2015-05-19 22:09 MageKing17 Fixed in Version => 3.7.3
2015-05-19 22:09 MageKing17 Target Version => 3.7.4