View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004066 | Spring engine | General | public | 2013-10-15 22:11 | 2013-11-06 11:58 |
| Reporter | Jools | Assigned To | Kloot | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | suspended | ||
| Product Version | 94.1.1+git | ||||
| Summary | 0004066: Rocket launchers can't target things underwater | ||||
| Description | Rocket launchers can't target things such as underwater mexx or underwater energy storages: when you give them the attack order they try to move closer to the target, although the target is within range. Confirmed for Arm Raven and Arm Merl. Units such as Bulldog can instead attack those targets. Merl and Raven can still attack water by attacking ground, but not when given a specific unitID as target (when you have sonar). | ||||
| Steps To Reproduce | 1. Start a map with water 2. Build a sonar station 3. Give arm_underwater_metalextractor to enemy 4. Give Arm Merl to self 5. Try to attack uw mexx | ||||
| Additional Information | Tested with XTA svn version with spring_{develop}94.1.1-1372-g9910407_minimal-portable, with luaui and luarules disabled. Nothing relevant in infolog. | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | |||||
|
|
Repeat this test using arm_bulldog on a map with deep enough water (Finn's Revenge) and you will find it too cannot target submerged crap. This is what we call intended behavior because neither arm_merl nor arm_bulldog has waterweapon=true set and force-firing targets the surface. |
|
|
Posted new report as 0004068. It's bad though that units start moving towards target. |
|
|
Spring cannot know what action to take if targetting fails since there are many possible reasons it might. |
|
|
In this case though the reason is that weapons with waterweapon=false can't target submrged units. |
|
|
Not as simple as that, submerged units can potentially surface later which makes the problem categorically no different than "target currently out of range, move closer". |
|
|
Ok, that's true. But it a big improvement of current behaviour would be to issue the move closer order only after TestRange is false, that is, the unit already knows if target is in range or not. Don't move closer if target is in range. It's vastly better to have units stuck aiming at impossible targets that having them gather on shore. Game can then decide what to do in Allowcommand. |
|
|
Just a note: games can deal with this issue in Allowcommand, but it requires some parsing of tables, you need to get: 1) base position from Spring.GetUnitPosition 2) height from Spring.GetUnitDefDimensions 3) speed from unitdefinition 4) waterweapon from unitdefinition => weapons => iterate through all weeapons You also need to iterate through all selected units to see if one has a waterweapon. Your call if it's better done in engine or game. But just doing nothing instead of move if attack fails would not be so bad imho. |
|
|
I thought a little about this issue, this is how I think it should work: 1) target is in LOS, you can read the unitdef, which means that if you can red from its properties that it cannot surface, then show a bad attack cursor (widget), and possibly deny attack in allowcommand (gadget) 2) If target is in radar/sonar but out of LOS, then move closer, but once target appears in LOS the attack order should be stopped if it turns out to be a target of unattackable type as shown in 1. Would be nice to notify user. |
|
|
>> Spring cannot know what action to take if targetting fails since there are many possible reasons it might. The problem with this stance is that it's not possible to not take action. Not doing anything is also an action and sometimes worse than doing something that is partly correct. |
|
|
I am *really* not interested in playing idiotic semantic games. *If and when* there is a solution that satisfies me and doesn't require refactoring half of CommandAI or GUIHandler I will put this on the todo list again, *not* before. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-10-15 22:11 | Jools | New Issue | |
| 2013-10-15 22:53 | Kloot | Note Added: 0011794 | |
| 2013-10-15 22:53 | Kloot | Status | new => closed |
| 2013-10-15 22:53 | Kloot | Assigned To | => Kloot |
| 2013-10-15 22:53 | Kloot | Resolution | open => no change required |
| 2013-10-15 23:17 | Jools | Note Added: 0011796 | |
| 2013-10-15 23:17 | Jools | Status | closed => feedback |
| 2013-10-15 23:17 | Jools | Resolution | no change required => reopened |
| 2013-10-15 23:26 | Kloot | Note Added: 0011797 | |
| 2013-10-15 23:26 | Kloot | Status | feedback => closed |
| 2013-10-15 23:26 | Kloot | Resolution | reopened => no change required |
| 2013-10-15 23:42 | Jools | Note Added: 0011798 | |
| 2013-10-15 23:42 | Jools | Status | closed => feedback |
| 2013-10-15 23:42 | Jools | Resolution | no change required => reopened |
| 2013-10-15 23:47 | Kloot | Note Added: 0011799 | |
| 2013-10-15 23:47 | Kloot | Status | feedback => closed |
| 2013-10-15 23:47 | Kloot | Resolution | reopened => no change required |
| 2013-10-16 00:02 | Jools | Note Added: 0011802 | |
| 2013-10-16 00:02 | Jools | Status | closed => feedback |
| 2013-10-16 00:02 | Jools | Resolution | no change required => reopened |
| 2013-10-16 11:56 | Kloot | Relationship added | related to 0004068 |
| 2013-10-16 18:18 | Jools | Note Added: 0011814 | |
| 2013-10-16 18:18 | Jools | Status | feedback => assigned |
| 2013-11-06 10:10 | Jools | Note Added: 0011985 | |
| 2013-11-06 10:13 | Jools | Note Added: 0011986 | |
| 2013-11-06 11:58 | Kloot | Note Added: 0011988 | |
| 2013-11-06 11:58 | Kloot | Status | assigned => closed |
| 2013-11-06 11:58 | Kloot | Resolution | reopened => suspended |
