View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0002354 | Spring engine | General | public | 2011-02-18 07:44 | 2018-02-09 17:17 | ||||
Reporter | Google_Frog | ||||||||
Assigned To | Kloot | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Product Version | 0.82.7.1 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0002354: Error with reloadTime in Spring.GetUnitWeaponState | ||||||||
Description | The 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. | ||||||||
Tags | No tags attached. | ||||||||
Checked infolog.txt for Errors | |||||||||
Attached Files |
|
![]() |
|
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. |
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. |
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. |
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. |
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 |
![]() |
|||
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 |