View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001490 | FSSCP | turrets | public | 2007-09-03 17:29 | 2009-08-02 19:45 |
| Reporter | Tolwyn | Assigned To | Wanderer | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001490: turrets do not fire at target? | ||||
| Description | It is a very weird issue I've encountered with the latest builds: turrets do not fire at hostile targets first. I believe it takes about two minutes before they start tracking down hostile targets. Tried with the most recent build by Goober and Xt823 by taylor. I believe this applies both for friendly and hostile ships. Issue affects all turrets, not just turrets on capital ships. | ||||
| Tags | No tags attached. | ||||
|
|
Can you provide a mission that reproduces this in unmodded FS2? |
|
|
Got a test case for this? I haven't been able to replicate it so far. |
|
|
difficult to say... it happens from time to time. I will try to find a mission, in which it is always the case. |
|
|
If this happens in a WCS mission let me know which one and I'll test with that. |
|
|
24th mission is a good example: cruiser and carrier do not fire at you when you approch them directly at nav 4. After some time, they will, of course, return fire... To fly to nav 4 directly and skip previous 3 navs open the mission in FRED, scroll down to Reset Keys Nav 4 and change is-event-true-delay to true... You will also notice another bug (I am not sure if this is in mantis or not): caps , sometimes, have no engine glows. I believe engine glows work fine in your xt builds though... |
|
|
Another example: m44. In m24 you need to afterburn directly at the cruiser to notice the issue, otherwise the ship will start to return fire. I must say, this makes mission balancing a bit difficult. ;) This may be related to the thruster bug, since only ships that arrive in mid mission are affected. |
|
|
Okay, I tested both m24 and m44 with the latest trunk build, and I did not notice any problems. So either the bug is fixed, or you need to provide very specific instructions so that I can trigger it. However, I *did* notice a ton of model problems. Inverted bounding boxes, null moments of inertia, even mismatched subsystems. You should consider the possibility that a model problem is causing the bug. If a turret on the ship model is not specified in ships.tbl, or vice versa, that would prevent the turret from firing. |
|
|
Keldor's just put turretsbug.fs2 mission into the repository, which allows to reproduce the issue. Somehow the position of the cap ships/presence of a friendly cap ship seems to affect the turrets. |
|
|
Can you make a new copy of this mission so that it uses retail ships, please? It would help us determine whether this is a code problem or a WCSaga problem. |
|
|
sure |
|
|
Never mind about making a retail mission; I tested TurretBugTest. This is an excellent testing mission, as it includes only the ships needed to reproduce the bug, and nothing else. There's no requirement to wait through five minutes of dialog with no time compression, either. :) However the TurretBugTest mission worked for me. As soon as the hostile ship appeared, it immediately started firing at both me and the other capital ship. I used the latest trunk build. Try it and see for yourself: http://fs2source.warpcore.org/exes/latest/20080509-Goober5000.zip |
|
|
Yep, but a few seconds later they will stop firing. Just wait and see. ;) |
|
|
Not going to work on this. |
|
|
Has there been any progress with this one? If there hasn't been any.. Then is there somewhere an example mission made using retail FS ships that could be used for testing? Preferably with instructions on how exactly can it be reproduced. |
|
|
This is still an issue. I just tried the mission with a build compiled from the current SVN state. Yes the ship will start firing at the other ship and the player, but right from the start several laser turrets are silent although the player is in line of sight. Also several turrets stop shooting after a few seconds and some only fire every now and then even though the player never changes position. @Goober: If you can confirm a table problem with our data then that's ok too, but I don't find any problems with it. |
|
|
ok.. i see the effect.. i'll do some testing with this |
|
|
I did some testing and found at least one potential reason for the turrets to seize firing. That is for example in the mission example used the ships are placed side by side and the top turrets of the smaller one have fov of 180. As with the larger targets the game assigns target points for the turret on the target ship (turrets and 'important' subsystems). Now the ship is in field of view but the actual point targeted by the turret is not (so the turret refused to fire). Not sure if the explains all such behavior but it certainly affects the targeting |
|
|
It seems to me like the turret should always fire, whether it can see the targeted system or not, if the orders are simply to destroy a target. Although it also sounds like changing that could seriously affect retail. |
|
|
Could it be worked around with the attack subsystem code? Something like giving it orders to attack subsystem hull will still prioritize the other targets but attack the hull directly if none are in the FOV? There's probably a reason not to use hull so maybe some other option? |
|
|
The thing is: FOV was added to prevent turrets to fire "through the hull", Warships in our missions do not have any goals 'xcept waypoint-once order. AI picks targets on its own. |
|
|
According to the code, if a valid target is picked, but some condition (such as fov) prevents the turret from firing, it will wait about 2 seconds before attempting to fire again (which may still end up with the same 2 sec wait). I don't have the ability to test this out to be sure, but it seems to be the most likely culprit to me. Another possibility is if you make use of the ship-turret-target-order SEXP. I just noticed that there is a bug in the code where if you set asteroids to have a higher order then it will skip evaluating any target types that come after it, even if there aren't any asteroids in the mission. |
|
|
Yeah.. that's the code section that i meant while talking about the fov issue. AFAIK there has not yet been any use of the said target order sexps. However according to responses i got to the thread in WCS board it seems that this might not explain all what is wrong in the turrets so I'll try to do some more testing. |
|
|
-This is a Saga showstopper- |
|
|
Is this fixed in the nightly build 5373 by any chance? |
|
|
We need to test it. But from what I could see in recent unrelated tests, turrets still stop firing for no reason in certain situations. So this might have improved but still requires investigation since it certainly isn't 100% solved yet. |
|
|
Oh and before you ask: Unfortunately I do not have a fool proof way to reproduce this. If I could I might have more information on this already. |
|
|
Hmm.. I have a mission that shows severe turret problems and is reproducible. But it is using Saga ships. Anyone willing to look at it? |
|
|
Upload the test mission... either here or to a thread in wcs internal... if i can find time i'll take a look at it |
|
2009-07-03 19:52
|
|
|
|
Mission uploaded. It starts with a single capship in the middle A press to '1' or '2' keys destroys subsystems for testing, so keep away from those. For the reproducing effect do this: pressing '3' will spawn 4 fighters attacking the ship pressing '4' will spawn 4 other capships sitting still but friendly hence supposed to fire upon the ship. Now I noticed the following things: If I spawn the capships, they fire at eachother, also with torpedoes (if in field of view for the launcher) but the ship in the center doesn't fire back with a torp, only with laser turrets, although one of the ships should be in FOV of the launcher. If I spawn the fighters first, THEN spawn the capships, the capships do not fire at eachother. The friendly four don't fire at all, the center one only fires at the fighters. So there's something fishy here in terms of capship turret behavior which I don't really understand, let alone knowing where to look for a problem in the code. |
|
|
I found the issue. The fighters have orders to disarm the capital ship under test. This results in the ship being protected, hence the other capitalships will stop firing at it. I already posted a thread about this problem in the Forums. I'd really like to see a flag in ai_profiles deactivating this, like: $attack_subsystem_order_results_in_protection: NO This is really really unwanted behavior for Saga and I'm sure several other MODs also. Just because I order ships to attack a subsystem that doesn't mean I no longer want to destroy the ship. I might just want to help the destruction by disabling or disarm the ship. Especially disarming orders are not always meant as "do no destroy the ship"... |
|
|
Holy crap that is an annoying behavior. I mean yeah, sometimes I want to prioritize a subsystem but I still want anything _not_ attacking that subsystem to keep pounding too. I can see where it comes from, but maybe an ai_profiles flag isn't broad enough of a fix. What if there was an extra set of comm functions? Or is that even possible? One set that did protect and one that didn't? It seems like it could be hard for the game to 'know' which one you would want and I'd hate to only be able to have one or the other, now that I know why this is happening. Anyone else have any ideas on how to have the cake and eat it too? |
|
|
As discussed in the forums this only happens for "disarm" and "disable" orders. So only turrets and engines are affected. And it also only happens for non-huge ships. That includes big ones. So if one doesn't want this behavior for ones capital ships one has to use HUGE ship classes for all of them, mostly "capital". "cruiser" or "corvette", "freighter" etc will show this behavior and so far that cannot be prevented. |
|
|
I'm voting for a FLAG in FRED: "disable or disarm results in protection" In my opinion the decision of the AI stops attacking that ship or continues to is a matter of mission design, hence the power to influence this should be in the hands of the FREDer and not hardcoded for certain ship classes. I mean sometimes I want to also protect a huge ship.. right now that is just as impossible as not protecting a big ship. Maybe an additional flag would be necessary which activates the second one, to keep retail behavior of falling back to the hardcoded version. But it should be possible to influence this somehow. |
|
|
If this protection issue is taken out are there any other turret woes remaining? And given the nature of the protection issue it is kinda more likely to end up as both fred and objecttypes.tbl flag than anything else |
|
|
It actually seems like your newest turret behavior flag in ai_profiles.tbl also improved the problem of turrets not firing. I'll check this further.. So far I'd set this issue on "feedback". I'll test this further and if I detect no more issues over the next few weeks I'll inform you that you can close it. but for now I'd say we should still keep our eyes open. THis is after all very hard to reproduce or test |
|
|
Marking this bug as resolved. Should there still appear problems with it either reopen or post a new bug with specific description of the issue. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-09-03 17:29 | Tolwyn | New Issue | |
| 2007-09-03 21:51 | Goober5000 | Note Added: 0008475 | |
| 2008-03-30 20:12 | taylor | Note Added: 0009087 | |
| 2008-03-31 11:11 | Tolwyn | Note Added: 0009108 | |
| 2008-04-05 00:37 | taylor | Note Added: 0009186 | |
| 2008-04-05 00:37 | taylor | Status | new => assigned |
| 2008-04-05 00:37 | taylor | Assigned To | => taylor |
| 2008-04-13 21:14 | Tolwyn | Note Added: 0009222 | |
| 2008-04-26 12:08 | Tolwyn | Note Added: 0009243 | |
| 2008-04-30 08:25 | Goober5000 | Note Added: 0009275 | |
| 2008-05-03 16:25 | Tolwyn | Note Added: 0009284 | |
| 2008-05-03 21:34 | Goober5000 | Note Added: 0009288 | |
| 2008-05-04 20:50 | Tolwyn | Note Added: 0009296 | |
| 2008-05-09 09:35 | Goober5000 | Note Added: 0009313 | |
| 2008-05-09 09:55 | Tolwyn | Note Added: 0009315 | |
| 2008-07-17 16:39 | taylor | Note Added: 0009478 | |
| 2008-07-17 16:39 | taylor | Assigned To | taylor => |
| 2008-07-17 16:39 | taylor | Status | assigned => new |
| 2008-08-23 08:57 | Wanderer | Note Added: 0009599 | |
| 2008-09-15 05:41 | KeldorKatarn | Note Added: 0009679 | |
| 2008-09-16 06:43 | Wanderer | Note Added: 0009685 | |
| 2008-09-17 18:33 | Wanderer | Note Added: 0009687 | |
| 2008-09-17 19:39 | chief1983 | Note Added: 0009688 | |
| 2008-09-17 19:57 | FUBAR-BDHR | Note Added: 0009689 | |
| 2008-09-17 19:57 | Tolwyn | Note Added: 0009690 | |
| 2008-09-17 19:58 | Tolwyn | Note Edited: 0009690 | |
| 2008-10-03 11:29 | Wanderer | Status | new => assigned |
| 2008-10-03 11:29 | Wanderer | Assigned To | => Wanderer |
| 2008-10-13 17:36 | taylor | Note Added: 0009954 | |
| 2008-10-13 17:44 | taylor | Note Edited: 0009954 | |
| 2008-10-14 18:07 | Wanderer | Note Added: 0009976 | |
| 2009-06-26 17:01 | KeldorKatarn | Note Added: 0010999 | |
| 2009-06-26 17:21 | chief1983 | Note Added: 0011003 | |
| 2009-06-29 00:19 | KeldorKatarn | Note Added: 0011011 | |
| 2009-06-29 00:19 | KeldorKatarn | Note Added: 0011012 | |
| 2009-07-01 16:38 | KeldorKatarn | Note Added: 0011031 | |
| 2009-07-03 18:42 | Wanderer | Note Added: 0011038 | |
| 2009-07-03 19:52 | KeldorKatarn | File Added: a_model_test.fs2 | |
| 2009-07-03 19:56 | KeldorKatarn | Note Added: 0011039 | |
| 2009-07-05 17:31 | KeldorKatarn | Note Added: 0011052 | |
| 2009-07-06 04:46 | chief1983 | Note Added: 0011054 | |
| 2009-07-06 23:06 | KeldorKatarn | Note Added: 0011055 | |
| 2009-07-07 16:42 | KeldorKatarn | Note Added: 0011056 | |
| 2009-07-07 16:55 | Wanderer | Note Added: 0011057 | |
| 2009-07-07 17:01 | KeldorKatarn | Note Added: 0011058 | |
| 2009-07-15 05:46 | Wanderer | Status | assigned => feedback |
| 2009-08-02 19:45 | Wanderer | Status | feedback => resolved |
| 2009-08-02 19:45 | Wanderer | Resolution | open => fixed |
| 2009-08-02 19:45 | Wanderer | Note Added: 0011120 |
