2025-07-30 08:48 CEST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002354Spring engineGeneralpublic2011-02-18 07:442018-02-09 17:17
ReporterGoogle_Frog 
Assigned ToKloot 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version0.82.7.1 
Target VersionFixed in Version 
Summary0002354: Error with reloadTime in Spring.GetUnitWeaponState
DescriptionThe value set with SetUnitWeaponState is not the same as the value later read with GetUnitWeaponState. The value read is >= than the set value.

This has caused issues in ZK's unit_attributes gadget as mathematically sound algorithm for speeding and slowing reload speed were not working. The cause was the assumption that if reloadTime is set to a value that value will be what is read later. This has been fixed by tracking the last reload time value inside the gadget, ignoring spring's internal reloadTime value.

This replay is with Zk r1758. It shows the behaviour of the gadget when using GetUnitWeaponState but it also tracks the last value set with SetUnitWeaponState. These values are echoed and it can be seen that they do not agree.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0006398

Rafal99 (reporter)

2011-02-18 07:54

 Related to: 0001973
But that one should have been fixed for 0.82.7.1 so something went wrong.

~0006399

Google_Frog (reporter)

2011-02-19 03:01

Last edited: 2011-02-19 04:53

 Was there another fix for 0001973? jk's commit seems to only change the read value of reloadTime to take xp into account. That could be contributing to my bug as I set reloadTime then read a lowered value which could be due to xp. This is still a bug as if SetUnitWeaponState is used to set reloadTime the value given should not be changed by xp and GetUnitWeaponState should return the correct value.

~0006413

Rafal99 (reporter)

2011-02-20 20:20

 jK's commit changes the return value to take xp into account, and changes the return value type so it is not rounded to nearest integer. "(float)" conversion was redundant since int / float = float.
So it is now correct for standard reloadTime's.
The problem seems to be with reloadTime changed with SetUnitWeaponState, since you would expect the returned value from GetUnitWeaponState to be same you set. But the returned value is actually correct, because engine always takes xp into account even for custom reloadTime.
Perhaps SetUnitWeaponState should take xp into account too, so values you get are the same as you set? Or just ingore xp for custom reloadTime, but some may expect custom reloadTime to behave the same as the one from unitDef.
No idea what solution would be best.

~0006416

Google_Frog (reporter)

2011-02-21 01:54

 A boolean flag in SetWeaponState and GetWeaponState that sets if you want to take xp into account.

~0018796

Kloot (developer)

2018-02-09 17:17

 Fix 061f7a425d1f3ed8843fc90f67fdfb00f5f6638d committed to develop branch: fix 0002354
Spring.GetUnitWeaponState(.., "reloadTime") now returns the unweighted time
Spring.GetUnitWeaponState(.., "reloadTimeXP") takes experience into account, repo: spring changeset id: 9557
+Notes

-Issue History
Date Modified Username Field Change
2011-02-18 07:44 Google_Frog New Issue
2011-02-18 07:44 Google_Frog File Added: broken_slow_weapon_reload_Comet Catcher Redux_0.82.7.sdf
2011-02-18 07:54 Rafal99 Note Added: 0006398
2011-02-19 03:01 Google_Frog Note Added: 0006399
2011-02-19 04:53 Google_Frog Note Edited: 0006399
2011-02-20 20:20 Rafal99 Note Added: 0006413
2011-02-21 01:54 Google_Frog Note Added: 0006416
2018-02-09 17:17 Kloot Changeset attached => spring develop 061f7a42
2018-02-09 17:17 Kloot Note Added: 0018796
2018-02-09 17:17 Kloot Assigned To => Kloot
2018-02-09 17:17 Kloot Status new => resolved
2018-02-09 17:17 Kloot Resolution open => fixed
+Issue History