2023-05-30 20:49 CEST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004144Spring engineGeneralpublic2013-11-11 15:512013-11-14 20:47
Reportersilentwings 
Assigned ToKloot 
PriorityhighSeveritymajorReproducibilityalways
StatusresolvedResolutionreopened 
Product Version95.0 
Target VersionFixed in Version 
Summary0004144: partly submerged units not hittable by non water weapons
Descriptionsee demo, with 95.0 and ba 7.84 on dsx.
Additional Informationi think the problem is that the corvette is aiming at a part of the model that is far below the surface, but its laser cannot pass through the water surface,
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0012060

Kloot (developer)

2013-11-11 15:56

 Without verifying what the actual problem is: you can use Spring.SetUnitMidAndAimPos to move a unit's aimpoint higher up.

~0012075

Kloot (developer)

2013-11-11 19:50

 Watched the replay, problem is indeed that cortl's aimpoint/midpos is under water so you either have to edit the model or apply some Lua magic.

~0012076

silentwings (reporter)

2013-11-11 19:53

 It should be targetable by some weapons (e.g. torpedo from sub) that only travel underwater and some weapons (e.g. laser from ship) that only travel above water; if I set an aimpoint won't i break either one or the other?!

~0012077

Kloot (developer)

2013-11-11 19:56

 Not if you set it to exactly 0, then torpedoes will travel up and impact before exiting water while lasers will travel down and impact before entering it.

~0012090

silentwings (reporter)

2013-11-12 18:29

Last edited: 2013-11-12 18:49

View 6 revisions

 That works fine for units which can't move - for units which can move and walk in and out of shallow water it's more of a problem. I've attached a mildly non-realistic demo to show it.

As far as I can see the only way to do it with SetUnitMidAndAimPos that handles mobile things would be to constantly check all mobile units and update the AimPos in e.g. GameFrame.

edit: ops accidentally used $VERSION, made another demo.

~0012092

Kloot (developer)

2013-11-12 19:24

Last edited: 2013-11-12 19:26

View 2 revisions

 There will always be a case that fails for one weapon type or another (units have only a single aimpoint), so what should the engine do?

~0012093

silentwings (reporter)

2013-11-12 22:47

Last edited: 2013-11-12 22:48

View 3 revisions

 I'm not sure how it was implemened, but in 94.1 a non-water weapon can tell when a part of its target is above the water (even if only a small part, like the krogs head) and can fire at it; similarly a torpedo launcher can tell if a part of its target is underwater and can fire at it. I guess this was a more expensive check.

I agree that it's not possible to deal with all cases and I've not read enough of the engine to write you some proper code but roughly what I was thinking:

if(WaterWeapon){
  if(aimpos.y<=0){
    fire at aimpos
  }else{
    if(basepos.y<=0){
      fire at (basepos.x,0,basepos.z)
    }
  }
}else{
  if(aimpos.y>=0){
    fire at aimpos
  }else{
    if(toppos.y>=0){
      fire at (toppos.x,0,toppos.z)
    }
  }
}

Forgive me if I've written rubbish :p

~0012094

Kloot (developer)

2013-11-13 01:07

Last edited: 2013-11-13 01:09

View 3 revisions

 Actually there were more subtleties involved:

94 used basepos.y + MODEL height to decide if a unit was underwater
95 uses midpos.y + UNIT radius to decide if a unit is underwater

where model height wasn't affected by Spring.SetUnitRadiusAndHeight calls but unit radius obviously is, so in effect units (especially those with 3DO models because of the colvol rescaling gadget in BA) are flagged as underwater by 95 earlier than 94 did.

Separate basepos/toppos targeting wasn't (and has never been) implemented however.

~0012095

silentwings (reporter)

2013-11-13 02:39

Last edited: 2013-11-13 02:47

View 6 revisions

 I think there must be still more to it; e.g. in 95.0.1-35 you can have a krog standing right next to a torpedo launcher with 40% of the model underwater, but the torpledo launcher wont fire if the midpoint of the krog is above the waterline. In 94 the torpedo launcher will fire and hit even if only the krogs toes are in the water.

I tried fiddling around with unit radii but I didn't manage to make a laser fire at any point on the model other than the krogs midpoint, and it seemed that the laser fired at the krog if and only if its midpoint was above the waterline. I also tried disabling the colvol adjuster entirely but the problems still occured.

(by midpoint here, i mean the midpoint of the sphere, shown as a purple dot in /debugcolvol).

~0012096

Kloot (developer)

2013-11-13 02:53

 Yes, the aimpoint (same as midpoint by default) is now used for both the "can we fire at this target?" and the "where to aim when we fire at it?" logic, whereas in 94 the basepoint was used (by torpedo launchers) for the former.

~0012097

silentwings (reporter)

2013-11-13 02:57

Last edited: 2013-11-13 03:05

View 5 revisions

 Ok - well isn't that a bug?! I would expect water weapons to be able to aim somewhere lower if the midpoint failed; similarly land weapons to aim somwhere above if the midpoint failed. As far as I can see that's what happens in 94, even if the effect really has some other logic causing it.

~0012098

Kloot (developer)

2013-11-13 03:11

 The current targetting code isn't actually smart enough to try multiple positions.

I will see about overriding the "can we fire at this target?" aimpoint used by torplaunchers, since those are the only major water-weapons.

~0012100

Kloot (developer)

2013-11-13 13:58

 OK, you can mostly forget what I said above because it turns out a different more specific force is at work in your demos: armanni and coresupp both have beamlasers which now stop at the water surface if the water-weapon flag isn't set.

~0012105

Anarchid (reporter)

2013-11-13 18:03

Last edited: 2013-11-13 18:04

View 2 revisions

 >>overriding ... torplaunchers ... the only major water-weapons.
Can't it just be made a tag, or act on all waterweapons regardless of weapontype?

Only affecting torps is likely to cause unnecessary frustration sooner or later.

~0012106

silentwings (reporter)

2013-11-13 18:19

Last edited: 2013-11-13 18:22

View 4 revisions

 The waterweapon tag allows the weapon to target any underwater unit, which is not what happened before, or what I want to happen. Imo what should happen is what happened in 94:

A non-waterweapon should be able to target units that have some part out of the water but not units that are fully submerged, similarly a waterweapon should be able to target a unit that has some part underwater but not one that is fully on land.

After https://github.com/spring/spring/commit/b2c5ebfc41c409dd1d58b67034e25efc4d569fed I wrote http://imolarpg.dyndns.org/trac/balatest/browser/trunk/luarules/gadgets/hotfix_aimpoint_waterline.lua?rev=1838, which bought back the right behaviour for all but mobile land units, but I don't understand the reason for https://github.com/spring/spring/commit/acf76eeb570b2d0d906228a9d7a17cfe02fc5c25 ? I can't see how to make battles in shallow water work naturally (i.e. like 94) at all with that.

~0012109

Kloot (developer)

2013-11-13 18:39

Last edited: 2013-11-13 18:45

View 3 revisions

 Let me try one last time to explain then...

First:

"The waterweapon tag allows the weapon to target any underwater unit, which is not what happened before"

Yes, it did, but according to the old "underwater" definition.

Second:

"A non-waterweapon should be able to target units that have some part out of the water but not units that are fully submerged, similarly a waterweapon should be able to target a unit that has some part underwater but not one that is fully on land."

None of this has changed.

What has changed is the definition of "underwater" as per http://springrts.com/mantis/view.php?id=4144#c12094 and the fact that beamlasers obey waterweapon restrictions (their beams are terminated at y=0 if that tag is set to false).

Finally, your demos all involve units with waterweapon=false *beamlasers* and targets that are *not* fully underwater, so they still can be *fired at* by said beamlasers but not *hit* because beamlaser projectiles are stopped at the water surface. This is why I reverted my earlier commit.

~0012112

silentwings (reporter)

2013-11-13 21:27

Last edited: 2013-11-13 21:30

View 3 revisions

 Yes, I understand that the defn of underwater has changed.

My point is that the reason why, in my demo, the krog does not get hit once its aimpoint is a bit below the waterline is that the beamlaser fires at the wrong point. In 95 it fires at the aimpos, which is submerged and can't be hit by non-waterweapons; in 94 it fired at a point on the krog (not its aimpos) that was still above water. I have added a screenshot to show that it really did do this.

How should I achieve the same behaviour in 95? I can only of hacky (at least to my eyes) solutions like

1) Check units basepos and toppos very often and use SetUnitMidAndAimPos to keep its aimpoint above water
2) Use setSFXoccupy to make it so as when a unit is the water its aimpoint is near the top of its head (this looks very odd for big units + I would have to change 150+ unit scripts).

Is there a better way?!

~0012120

Kloot (developer)

2013-11-13 22:38

Last edited: 2013-11-13 22:40

View 2 revisions

 e: It seems beamlasers in 94 actually did pick a different aimpoint, that's news to me.

~0012121

silentwings (reporter)

2013-11-13 22:40

Last edited: 2013-11-13 22:41

View 2 revisions

 edit: ok ;) good i'm glad we've understood each other.

thank you for putting up with my poor explanations above - i had to learn alot about how targetting worked before i managed to make myself clear.
+Notes

-Issue History
Date Modified Username Field Change
2013-11-11 15:51 silentwings New Issue
2013-11-11 15:51 silentwings File Added: 20131111_144826_DeltaSiegeX_95.sdf
2013-11-11 15:56 Kloot Note Added: 0012060
2013-11-11 19:50 Kloot Note Added: 0012075
2013-11-11 19:53 silentwings Note Added: 0012076
2013-11-11 19:56 Kloot Note Added: 0012077
2013-11-12 16:15 Kloot Status new => closed
2013-11-12 16:15 Kloot Assigned To => Kloot
2013-11-12 16:15 Kloot Resolution open => no change required
2013-11-12 18:29 silentwings Note Added: 0012090
2013-11-12 18:29 silentwings Status closed => feedback
2013-11-12 18:29 silentwings Resolution no change required => reopened
2013-11-12 18:30 silentwings File Added: 20131112_172615_DeltaSiegeX_95.0.1-29-g94b9c62 develop.sdf
2013-11-12 18:30 silentwings Note Edited: 0012090 View Revisions
2013-11-12 18:31 silentwings Note Edited: 0012090 View Revisions
2013-11-12 18:31 silentwings Note Edited: 0012090 View Revisions
2013-11-12 18:34 silentwings File Added: 20131112_173339_DeltaSiegeX_95.0.1-29-g94b9c62 develop.sdf
2013-11-12 18:34 silentwings Note Edited: 0012090 View Revisions
2013-11-12 18:49 silentwings Note Edited: 0012090 View Revisions
2013-11-12 19:24 Kloot Note Added: 0012092
2013-11-12 19:26 Kloot Note Edited: 0012092 View Revisions
2013-11-12 22:47 silentwings Note Added: 0012093
2013-11-12 22:47 silentwings Status feedback => assigned
2013-11-12 22:48 silentwings Note Edited: 0012093 View Revisions
2013-11-12 22:48 silentwings Note Edited: 0012093 View Revisions
2013-11-13 01:07 Kloot Note Added: 0012094
2013-11-13 01:07 Kloot Note Edited: 0012094 View Revisions
2013-11-13 01:09 Kloot Note Edited: 0012094 View Revisions
2013-11-13 02:39 silentwings Note Added: 0012095
2013-11-13 02:39 silentwings Note Edited: 0012095 View Revisions
2013-11-13 02:40 silentwings Note Edited: 0012095 View Revisions
2013-11-13 02:40 silentwings Note Edited: 0012095 View Revisions
2013-11-13 02:41 silentwings Note Edited: 0012095 View Revisions
2013-11-13 02:47 silentwings Note Edited: 0012095 View Revisions
2013-11-13 02:53 Kloot Note Added: 0012096
2013-11-13 02:57 silentwings Note Added: 0012097
2013-11-13 02:58 silentwings Note Edited: 0012097 View Revisions
2013-11-13 03:00 silentwings Note Edited: 0012097 View Revisions
2013-11-13 03:04 silentwings Note Edited: 0012097 View Revisions
2013-11-13 03:05 silentwings Note Edited: 0012097 View Revisions
2013-11-13 03:11 Kloot Note Added: 0012098
2013-11-13 13:58 Kloot Note Added: 0012100
2013-11-13 18:03 Anarchid Note Added: 0012105
2013-11-13 18:04 Anarchid Note Edited: 0012105 View Revisions
2013-11-13 18:19 silentwings Note Added: 0012106
2013-11-13 18:20 silentwings Note Edited: 0012106 View Revisions
2013-11-13 18:20 silentwings Note Edited: 0012106 View Revisions
2013-11-13 18:22 silentwings Note Edited: 0012106 View Revisions
2013-11-13 18:39 Kloot Note Added: 0012109
2013-11-13 18:44 Kloot Note Edited: 0012109 View Revisions
2013-11-13 18:45 Kloot Note Edited: 0012109 View Revisions
2013-11-13 21:27 silentwings Note Added: 0012112
2013-11-13 21:28 silentwings File Added: screen00045.png
2013-11-13 21:29 silentwings Note Edited: 0012112 View Revisions
2013-11-13 21:30 silentwings Note Edited: 0012112 View Revisions
2013-11-13 22:38 Kloot Note Added: 0012120
2013-11-13 22:40 Kloot Note Edited: 0012120 View Revisions
2013-11-13 22:40 silentwings Note Added: 0012121
2013-11-13 22:41 silentwings Note Edited: 0012121 View Revisions
2013-11-14 20:47 Kloot Changeset attached => spring develop 8e14d295
2013-11-14 20:47 Kloot Status assigned => resolved
+Issue History