2025-07-20 16:03 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004177Spring engineGeneralpublic2013-12-30 11:33
ReporterGoogle_Frog 
Assigned Tocleanrock 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionreopened 
Product Version95.0.1+git 
Target VersionFixed in Version 
Summary0004177: 95.0.1-78 StarburstLaunchers can consistently fail to hit target
DescriptionThis ticket is basically a well written version of this: http://springrts.com/mantis/view.php?id=4174

The unit armmerl in ZK fails to hit midrange targets in the test engine version above. The 'same' unit in latest BA does not have this problem but the weapon properties are different between these units. The BA version has lower weapon velocity and higher turnrate.

To rule out faulty lua I have made a unit which reproduces the issue in a small example mod. Here are the commits which implement and modify this test weapon.
http://code.google.com/p/zero-k/source/detail?r=12175
http://code.google.com/p/zero-k/source/detail?r=12176

To reproduce the issue start a game with examplemod, spawn starbursttank and fire it at the ground. Alternately you can run the attached replay.

The test case can hit ground accurately at max range and very close range.

The bug appears to be triggered by acceleration. If startVelocity is set to weaponVelocity then the bug does not occur. It is easy to modify startVelocity to confirm this.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
related to 0004174closedKloot StarburstLauncher missile targeting always miss... 
+Relationships

-Notes

~0012282

Google_Frog (reporter)

This workaround hides the issue: http://code.google.com/p/zero-k/source/detail?r=12178

I simply made sure that no StarburstLaunchers accelerate. The limit on weaponvelocity is in place because some weapons had very high weaponvelocity and low acceleration.

This workaround works for now but the bug should still be fixed at some point. StarburstLaunchers which start with no velocity is a nice looking feature and the bug makes this feature unusable.

~0012283

Google_Frog (reporter)

The example can hit significantly off its target, about 100 elmos.

~0012476

Google_Frog (reporter)

Detriment missiles (armorco) in ZK fail to hit targets even when acceleration is removed.

~0012501

abma (administrator)

can someone bisect please?

~0012503

Kloot (developer)

Last edited: 2013-12-27 18:57

View 2 revisions

It is NOT a regression.

Personally I have no plans to fix this anytime soon.

~0012505

msafwan (reporter)

Last edited: 2013-12-27 19:06

View 3 revisions

I found it!!!!

Its caused by this: https://github.com/spring/spring/commit/a86a2aa65bdcb0d49cda1fa50eb8de3c24aeed87

Previous working version is this:
https://github.com/spring/spring/commit/6cea6dcdd927df7fbf2bfce9117b92b7c79541cf

Could it be that there's problem with commiting Direction and Velocity of the projectile? the logic in both version appears identical. (also from crude visual observation the turn radius is way bigger than the original, seem like it fail to turn)

Here is the Spring that I use to test:
http://springrts.com/dl/buildbot/default/develop/94.1.1-1118-g6cea6dc/win32/
http://springrts.com/dl/buildbot/default/develop/94.1.1-1356-g04d2ad2/win32/

~0012509

cleanrock (reporter)

Check if this is fixed in
http://springrts.com/dl/buildbot/default/release/95.0.1-225-g6f0119c/
I hope https://github.com/spring/spring/commit/6f0119c43672503785851235dc2f83dab2fa1c5b fix this problem.

~0012510

msafwan (reporter)

Last edited: 2013-12-28 15:27

View 10 revisions

Unfortunately it doesn't fix it. The projectile still miss and the turn radius is still bigger.

UPDATE 2!:
This version is the one where bug first appear: http://springrts.com/dl/buildbot/default/develop/94.1.1-1196-ga86a2aa/

This version is the last one free of this bug:
http://springrts.com/dl/buildbot/default/develop/94.1.1-1195-gc301a99/

UPDATE 3:
after reading commit difference https://github.com/spring/spring/commit/a86a2aa65bdcb0d49cda1fa50eb8de3c24aeed87 , the new StarburstProjectile.cpp is missing an operation:
line 103 : dir = speed / curSpeed; //convert velocity vector into a direction vector

DEBUGGING TOOL!:
If all the WeaponDef tag is accurate then the projectile behaviour must 100% follow this behaviour:
the_REAL_turn_radius = weaponVelocity_tag/(turnRate_tag*2*pi/65536) ......Note: make sure the speed is constant!

The equation is based on this: http://en.wikipedia.org/wiki/Circular_motion#Velocity

The behaviour in latest Spring have a turnRate of 0.6*WeaponDef->turnRate. IMO there is a bug and the turnRate suffered.

~0012513

Google_Frog (reporter)

If this is not a regression then point out the problem with the weapondef in my small example.

~0012515

cleanrock (reporter)

Me and xponen worked on this today, this can be closed, this is what i think was the problem with detri (merl is fine in zk 12.5):
detri lacked flighttime for its missile launcher, this caused a bad TTL being calculated because weaponVelocity was silly high (8000) and overriding it in "post" did not affect TTL.

~0012516

cleanrock (reporter)

zk config issue.

~0012517

Google_Frog (reporter)

That does not explain the case demonstrated by the example weapondef in the ticket. It also fails to explain why armmerl in ZK does not work. The main issue appears to be related to acceleration.

~0012518

cleanrock (reporter)

zk 12.5 armmerl works fine with latest release, latest release is what matters atm.

~0012521

Google_Frog (reporter)

The ZK armmerl works in 12.5 due to my workaround which amounts to removing acceleration from starburstlaunchers. I said as much in the first comment on this ticket.

Workaround commit: http://code.google.com/p/zero-k/source/detail?r=12178

I have a workaround so to me the bug is not major. That said, I like starburstlaunchers which start off slow and accelerate. As far as I can tell this feature has effectively been removed from the engine so there has been a regression. So the bug remains, it may be minor but it still remains.

This unit is available for testing. It exists in a small basically-lua-free game. I see no problem with the weapondef so something in the engine has to change to make it work. http://code.google.com/p/zero-k/source/browse/trunk/mods/examplemod/units/starbursttank.lua?r=12176

~0012522

cleanrock (reporter)

I investigated some more, it is a change in starburst behaviour caused by https://github.com/spring/spring/commit/a86a2aa65b (refactoring is risky).
Your starburst tank needs some tweaking for the new behaviour, increase turnrate and it will work fine.
I am not sure its worth to correct this and go back to 91 behaviour since this is the behaviour in 95.

~0012523

abma (administrator)

@Kloot:

> It is NOT a regression.

does that mean its wanted behaviour?

~0012524

Kloot (developer)

It means there is no reason this should hold up 96.0 any longer.

~0012525

Google_Frog (reporter)

Last edited: 2013-12-29 15:28

View 2 revisions

@cleanrock only using increased turnrates is not a solution.

~0012526

Google_Frog (reporter)

I do not think that this bug should hold back 96.0. As I said, I have a workaround which does not impact significantly on gameplay.

This is still a bug though. I have an improved method of demonstrating it. The examplemod weapon def has been updated for this and is below:
http://code.google.com/p/zero-k/source/browse/trunk/mods/examplemod/units/starbursttank.lua?r=12336

To reproduce:
 * Spawn a starbursttank.
 * Give it an attack ground order 500 elmos away from it.
 * Notice that the weapon impacts further than 500 elmos away. At this point it appears that the weapondef is setup such that it cannot hit anything closer than a certain distance. It's turnrate is too low.
 * So then note down where the weapon actually hits.
 * Now give the starbursttank an attack ground order further away than where the weapon hits.
 * The weapon will hit further away than this order. This disproves the 'minimum range' theory and shows that aiming is actually at fault.

~0012532

Kloot (developer)

Drama queening will not be tolerated.

This report is suspended until after 96.
+Notes

-Issue History
Date Modified Username Field Change
2013-11-30 16:46 Google_Frog New Issue
2013-11-30 16:46 Google_Frog File Added: 20131201_023007_Comet Catcher Redux_95.0.1-78-g7fa9f6c develop.sdf
2013-12-01 08:29 Google_Frog Note Added: 0012282
2013-12-01 09:23 Google_Frog Note Added: 0012283
2013-12-24 02:58 Google_Frog Note Added: 0012476
2013-12-27 16:12 abma Relationship added related to 0004174
2013-12-27 18:45 abma Note Added: 0012501
2013-12-27 18:45 abma Status new => feedback
2013-12-27 18:45 abma Target Version => 96.0
2013-12-27 18:53 Kloot Note Added: 0012503
2013-12-27 18:57 Kloot Note Edited: 0012503 View Revisions
2013-12-27 19:02 msafwan Note Added: 0012505
2013-12-27 19:03 msafwan Note Edited: 0012505 View Revisions
2013-12-27 19:06 msafwan Note Edited: 0012505 View Revisions
2013-12-27 19:28 cleanrock Status feedback => new
2013-12-27 21:20 cleanrock Note Added: 0012509
2013-12-27 21:20 cleanrock Status new => feedback
2013-12-28 11:23 msafwan Note Added: 0012510
2013-12-28 11:32 msafwan Note Edited: 0012510 View Revisions
2013-12-28 11:34 msafwan Note Edited: 0012510 View Revisions
2013-12-28 12:16 msafwan Note Edited: 0012510 View Revisions
2013-12-28 12:17 msafwan Note Edited: 0012510 View Revisions
2013-12-28 12:17 msafwan Note Edited: 0012510 View Revisions
2013-12-28 12:19 msafwan Note Edited: 0012510 View Revisions
2013-12-28 12:40 msafwan Note Edited: 0012510 View Revisions
2013-12-28 14:40 Google_Frog Note Added: 0012513
2013-12-28 14:40 Google_Frog Status feedback => new
2013-12-28 15:25 msafwan Note Edited: 0012510 View Revisions
2013-12-28 15:27 msafwan Note Edited: 0012510 View Revisions
2013-12-28 16:23 cleanrock Note Added: 0012515
2013-12-28 16:24 cleanrock Note Added: 0012516
2013-12-28 16:24 cleanrock Status new => resolved
2013-12-28 16:24 cleanrock Resolution open => fixed
2013-12-28 16:24 cleanrock Assigned To => cleanrock
2013-12-28 18:38 Google_Frog Note Added: 0012517
2013-12-28 18:38 Google_Frog Status resolved => feedback
2013-12-28 18:38 Google_Frog Resolution fixed => reopened
2013-12-28 20:03 cleanrock Note Added: 0012518
2013-12-28 21:29 Kloot Target Version 96.0 =>
2013-12-29 06:31 Google_Frog Note Added: 0012521
2013-12-29 06:31 Google_Frog Status feedback => assigned
2013-12-29 10:08 cleanrock Note Added: 0012522
2013-12-29 11:18 cleanrock Assigned To cleanrock =>
2013-12-29 11:19 cleanrock Status assigned => new
2013-12-29 11:42 abma Note Added: 0012523
2013-12-29 12:54 Kloot Note Added: 0012524
2013-12-29 12:54 Google_Frog Note Added: 0012525
2013-12-29 15:28 Google_Frog Note Edited: 0012525 View Revisions
2013-12-29 15:35 Google_Frog Note Added: 0012526
2013-12-29 22:55 Kloot Note Added: 0012532
2013-12-29 22:55 Kloot Status new => closed
2013-12-29 22:55 Kloot Resolution reopened => suspended
2013-12-30 11:28 cleanrock Assigned To => cleanrock
2013-12-30 11:28 cleanrock Status closed => feedback
2013-12-30 11:28 cleanrock Resolution suspended => reopened
2013-12-30 11:28 cleanrock Status feedback => new
2013-12-30 11:28 cleanrock Status new => assigned
2013-12-30 11:33 cleanrock Changeset attached => spring release 3eee815e
2013-12-30 11:33 cleanrock Status assigned => resolved
+Issue History