2025-08-11 10:58 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004066Spring engineGeneralpublic2013-11-06 11:58
ReporterJools 
Assigned ToKloot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionsuspended 
Product Version94.1.1+git 
Target VersionFixed in Version 
Summary0004066: Rocket launchers can't target things underwater
DescriptionRocket 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 Reproduce1. 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 InformationTested with XTA svn version with spring_{develop}94.1.1-1372-g9910407_minimal-portable, with luaui and luarules disabled. Nothing relevant in infolog.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
related to 0004068closedKloot Weird behaviour when targetting water 
+Relationships

-Notes

~0011794

Kloot (developer)

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.

~0011796

Jools (reporter)

Posted new report as 0004068. It's bad though that units start moving towards target.

~0011797

Kloot (developer)

Spring cannot know what action to take if targetting fails since there are many possible reasons it might.

~0011798

Jools (reporter)

In this case though the reason is that weapons with waterweapon=false can't target submrged units.

~0011799

Kloot (developer)

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".

~0011802

Jools (reporter)

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.

~0011814

Jools (reporter)

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.

~0011985

Jools (reporter)

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.

~0011986

Jools (reporter)

>> 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.

~0011988

Kloot (developer)

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.
+Notes

-Issue History
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
+Issue History