Source Code Project Mantis - FSSCP
View Issue Details
0002706FSSCPmodelspublic2012-08-28 14:002012-12-09 00:58
Assigned ToValathil 
PlatformOSOS Version
Product Version3.6.13 
Target Version3.6.16Fixed in Version 
Summary0002706: Weapons not colliding
DescriptionWeapons are not colliding with objects correctly in all cases. Noticed this with the new HTL Comm Node I'm working on. The mesh is solid and I can collide with it via my ship. However, weapons are not hitting the outer hull.
Steps To ReproduceI can make the mesh available if need be, though I'm sure this is an issue with other models that don't have shields. Shields still seem to be working.
Additional InformationIt seems like the weapons are passing through the outer hull and colliding with the opposite normal on the inside hull.

In the attached image, I've been shooting at the Node for a good 30 seconds, you can see no hit effects of any kind.
TagsNo tags attached.
related to 0002708closed Swifty Collision problems with weapons 
Attached Filesjpg ImageBin.jpg (919,039) 2012-08-28 14:00
patch bug_fixes.patch (4,908) 2012-09-09 09:40
? weaponcollisions.fs2 (6,967) 2012-12-07 11:33
7z Mantis Sandbox.7z (104,339) 2012-12-07 15:21
patch collideshipship.cpp.patch (538) 2012-12-08 18:09

2012-08-28 14:00   
Forgot to include that this works correctly in 9100, but not in 9103.
2012-09-09 09:41   
Uploaded patch with potential fixes.
2012-09-24 20:49   
(Last edited: 2012-09-24 21:03)
Tested and still having collision issues with weapons. 'Use old collision detection system' resolves the problems. A good example is the retail (No Mods) Shivan Comm Node in Into the Lion's Den.

2012-11-26 22:35   
Having issues as well with anything that is a rotating subsystem. I can fly into the object so it does have collision detection vs ships. Missiles and beams go straight through on my testing in TBP. I did record damage to the subsystem if the weapon fire hit something else on the ship behind the subsystem. If they don't hit anything after passing through the subsystem no damage was taken. I did manage to get a series of hits at one point from a certain angle but was not able to reproduce those hits. Collisions worked fine with the old collision flag enabled.

Also tested with the retail comm node. While shots did hit about half the time they seemed to not hit the correct spot in most cases. For instance hitting the lower arm as it rotated toward you would either go through and hit something else or hit the back side of the arm.

This was in r9368
2012-12-07 11:34   
Uploaded a test mission with retail data.

Includes ships with all kinds of rotating subsystems to showcase the issue. The Charybdis is actually a great example because you can shoot right through the domes, but you can hit the hull just fine.
2012-12-08 18:11   
This was the most aggravating 2 days of debugging ever. Has nothing to do with Swifties code or anything. Just that the new code checks the collision pairs in a different order and there was a bug where after the first ship2ship collision only other ship2ship collisions were registered on subsytems cause a flag was set wrongly because of a copypasta. Attached a patch that fixes
2012-12-08 20:21   
(Last edited: 2012-12-08 20:26)
Problem with just removing that section.
Prior to 6878, it was this:
"pm->submodel[submodel_list[i]].blown_off = 1;"

This indicates to me that it was setting up to only skip if the submodel in question had been blown off. Now it's applying regardless of the submodel state.

Rather than just removing the code there, can we reinstate that as being a "if you're blown off, don't bother, otherwise, update"?

If we can validate that blown off submodels are already being appropriately culled elsewhere, then awesome, I'm all for this fix. But otherwise, I think we need to make sure that it is working as intended originally.

2012-12-09 00:36   
au contraire mon ami look at the beginning of the loop before the removed statement there is clearly the if blown off thing in there. Also the blown off thing is checked in other places as well. I didn't want to go too deep into it but this whole iterate over all stuff and set collision_checked thing seems to be useless anyway and seems to come from a copypasta from debris and asteroid collision code.
2012-12-09 00:58   
Fix committed to trunk@9414.

Issue History
2012-08-28 14:00MjnMixaelNew Issue
2012-08-28 14:00MjnMixaelFile Added: ImageBin.jpg
2012-08-28 14:00MjnMixaelNote Added: 0013949
2012-09-04 20:59SwiftyAssigned To => Swifty
2012-09-04 20:59SwiftyStatusnew => assigned
2012-09-04 21:03Goober5000Relationship addedrelated to 0002708
2012-09-09 09:40SwiftyFile Added: bug_fixes.patch
2012-09-09 09:41SwiftyNote Added: 0013957
2012-09-24 20:49MjnMixaelNote Added: 0013973
2012-09-24 21:03MjnMixaelNote Edited: 0013973bug_revision_view_page.php?bugnote_id=13973#r206
2012-11-05 00:45Goober5000Target Version => 3.6.16
2012-11-26 22:35FUBAR-BDHRNote Added: 0014193
2012-12-07 11:33MjnMixaelFile Added: weaponcollisions.fs2
2012-12-07 11:34MjnMixaelNote Added: 0014348
2012-12-07 15:21MjnMixaelFile Added: Mantis Sandbox.7z
2012-12-08 18:09ValathilFile Added: collideshipship.cpp.patch
2012-12-08 18:09ValathilAssigned ToSwifty => Valathil
2012-12-08 18:11ValathilNote Added: 0014362
2012-12-08 18:11ValathilStatusassigned => code review
2012-12-08 20:21ZacamNote Added: 0014367
2012-12-08 20:25ZacamNote Edited: 0014367bug_revision_view_page.php?bugnote_id=14367#r295
2012-12-08 20:26ZacamNote Edited: 0014367bug_revision_view_page.php?bugnote_id=14367#r296
2012-12-09 00:36ValathilNote Added: 0014376
2012-12-09 00:58ZacamChangeset attached => fs2open trunk r9414
2012-12-09 00:58ZacamNote Added: 0014378
2012-12-09 00:58ZacamStatuscode review => resolved
2012-12-09 00:58ZacamResolutionopen => fixed