View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000833 | FSSCP | gameplay | public | 2006-02-24 19:18 | 2008-08-11 04:10 |
| Reporter | CP5670 | Assigned To | phreak | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000833: Bombs go off in random directions after missing subsystem | ||||
| Description | If you fire bombs at a subsystem and they somehow go past the subsystem without hitting the ship's hull, they sharply turn away and move off in random directions, usually missing the ship altogether. I never noticed this in retail FS2, so I think they're supposed to keep going in the same direction if they miss the target. This usually only happens when the subsystem doesn't quite intersect the hull or is very close to the edge and could be considered a bug with the ship models, but some of the default ship models are like that. (I'm getting this with some subsystems on the Ganymede and Hades) | ||||
| Tags | No tags attached. | ||||
|
|
Does this happen with subsystems that are centered outside of the model? I remember that there were issues with the Hatshepsut engines because of something like that, whether that's part of the bug or not. If that's the problem I'm not sure what to do about it, because I can see certain applications in which it'd be easy to trick the code into doing the wrong thing if this was "fixed" |
|
|
Yeah, it almost always occurs in those cases. Most of the Ganymede's subsystems are good examples. |
|
|
edit: just tested retail and the same thing happens. If you want to stop this from happening, then i have enabled aspect seekers to have a "view cone" much like heat seekers, this should force the aspect seekers to lose lock once the bombs go past their target. the default view cone is 360 degrees to preverve backwards-compatibility. edited on: 04-26-06 19:50 |
|
|
Great, that sounds like it would do the trick for me. I'll try that out in the next build. It's interesting that it happens in retail too. I guess I somehow never got around to trying to bomb a Ganymede in that. |
|
|
close the bug then? |
|
|
looking at the code more throughly, i think the "no collide invisible" flag is at fault in weapon_home()
// If a weapon has missed its target, detonate it.
// This solves the problem of a weapon circling the center of a subsystem that has been blown away.
// Problem: It does not do impact damage, just proximity damage.
if ((dist_to_target < flFrametime * obj->phys_info.speed * 4.0f + 10.0f) && (old_dot < 0.0f)) {
int kill_missile = TRUE;
if (wp->homing_object) {
if (wp->homing_object->type == OBJ_SHIP) {
ship *shipp = &Ships[wp->homing_object->instance];
if (shipp->flags2 & SF2_DONT_COLLIDE_INVIS) {
kill_missile = FALSE;
}
}
}
if (kill_missile && (wp->lifeleft > 0.01f)) {
wp->lifeleft = 0.01f;
}
}
edited on: 04-28-06 12:09 |
|
|
bump, I finally got around to trying this in a newer build (the karajorma 5/17 one), but the parser doesn't recognize the view cone setting for aspect seekers. Has that been added in? Removing the "dont collide invisible" flag does fix the problem, but it introduces other issues with the Ganymede, which has a large invisible bounding cube around it that you keep bumping into. |
|
|
You may have put it in the wrong place Should be: +Turn Time: +View Cone: .... this keeps it inline with how heat missiles are parsed. |
|
|
You're right, I was putting it in the wrong place. Unfortunately, it doesn't fix this problem though. I tried setting the view cone to 0,0, 1.0 and 10.0, but the bombs' behavior seems to be unaffected; they keep turning away very sharply once they miss the subsystem. |
|
|
um theres something in the missile homing code that i overlooked, im not too comfortable with changing that. |
|
|
* BUMP * Is this still an issue? I assume that it is, but this bug hasn't had an update in almost 2 years, so we need to do something with it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-02-24 19:18 | CP5670 | New Issue | |
| 2006-02-24 21:46 | StratComm | Note Added: 0004927 | |
| 2006-02-24 21:57 | CP5670 | Note Added: 0004928 | |
| 2006-04-26 23:42 | phreak | Note Added: 0005396 | |
| 2006-04-26 23:47 | phreak | Note Edited: 0005396 | |
| 2006-04-26 23:49 | phreak | Note Edited: 0005396 | |
| 2006-04-26 23:50 | phreak | Note Edited: 0005396 | |
| 2006-04-27 03:39 | CP5670 | Note Added: 0005398 | |
| 2006-04-27 13:30 | phreak | Note Added: 0005401 | |
| 2006-04-28 16:09 | phreak | Note Added: 0005418 | |
| 2006-04-28 16:09 | phreak | Note Edited: 0005418 | |
| 2006-05-22 16:44 | CP5670 | Note Added: 0005562 | |
| 2006-05-23 04:03 | phreak | Note Added: 0005580 | |
| 2006-05-23 15:51 | CP5670 | Note Added: 0005586 | |
| 2006-05-23 20:57 | phreak | Note Added: 0005597 | |
| 2008-03-21 23:13 | taylor | Note Added: 0009006 | |
| 2008-07-25 17:29 | phreak | Status | new => assigned |
| 2008-07-25 17:29 | phreak | Assigned To | => phreak |
| 2008-08-11 04:10 | phreak | Status | assigned => resolved |
| 2008-08-11 04:10 | phreak | Resolution | open => fixed |