View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004675 | Spring engine | General | public | 2015-02-13 19:43 | 2015-02-22 07:03 |
| Reporter | lamer | Assigned To | jK | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 98.0.1+git | ||||
| Summary | 0004675: water.damage used without reverse scale | ||||
| Description | Next code doesn't seem to be correct: https://github.com/spring/spring/blob/36f68e956d0e6ca45b03d9dc27d717084c43503e/rts/Sim/MoveTypes/MoveDefHandler.cpp#L130-L132 Because water.damage is already scaled here: https://github.com/spring/spring/blob/36f68e956d0e6ca45b03d9dc27d717084c43503e/rts/Map/MapInfo.cpp#L226 | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | |||||
|
|
what? |
|
|
Water damage apllied during SlowUpdate: https://github.com/spring/spring/blob/36f68e956d0e6ca45b03d9dc27d717084c43503e/rts/Sim/Units/Unit.cpp#L921 So water.damage is scaled once on init: https://github.com/spring/spring/blob/36f68e956d0e6ca45b03d9dc27d717084c43503e/rts/Map/MapInfo.cpp#L226 And then next code uses already scaled wate.damage to calc waterDamageCost & noHoverWaterMove (for pathing): https://github.com/spring/spring/blob/36f68e956d0e6ca45b03d9dc27d717084c43503e/rts/Sim/MoveTypes/MoveDefHandler.cpp#L130-L132 Is that correct? Seems like MAX_ALLOWED_WATER_DAMAGE_HMM and MAX_ALLOWED_WATER_DAMAGE_GMM have no meaning in that context, and waterDamageCost calculation is also spoiled by scaled water.damage. |
|
|
| Is that correct? Seems like MAX_ALLOWED_WATER_DAMAGE_HMM and MAX_ALLOWED_WATER_DAMAGE_GMM have no meaning in that context, and waterDamageCost calculation is also spoiled by scaled water.damage. who says that? |
|
|
Code says that. And I'm just checking. There are concrete links to code. Anyway, futher analysis: Issue 1) water.damage = wt.GetFloat("damage", 0.0f) * (16.0f / GAME_SPEED); What happens if UNIT_SLOWUPDATE_RATE will be changed (say from 16 to 8 or 32, doesn't matter)? Then water.damage applied will be incorrect and different in each case due to const 16.0f. But thats the easy fixable part: water.damage = wt.GetFloat("damage", 0.0f) * ((float)UNIT_SLOWUPDATE_RATE / GAME_SPEED); Issue 2) CMoveMath::noHoverWaterMove = (mapInfo->water.damage >= MAX_ALLOWED_WATER_DAMAGE_HMM); CMoveMath::waterDamageCost = (mapInfo->water.damage >= MAX_ALLOWED_WATER_DAMAGE_GMM)? 0.0f: (1.0f / (1.0f + mapInfo->water.damage * 0.1f)); water.damage here is WaterDamage * (16.0f / GAME_SPEED), and we have those round numbers that doesn't related to (16.0f / GAME_SPEED), why? static const float MAX_ALLOWED_WATER_DAMAGE_GMM = 1e3f; static const float MAX_ALLOWED_WATER_DAMAGE_HMM = 1e4f; And why should waterDamageCost be based on UNIT_SLOWUPDATE_RATE (or 16.0f) for pathing? I believe it should be related to unspoiled WaterDamage, so the pathing won't change if UNIT_SLOWUPDATE_RATE changes. More trivial question: in what range WaterDamage should be to make use of hover units but not ground units? Check (like in "check and mate"). Issue 3) Did someone hijack jK's account? Please put it back. P.S. I didn't do any fixes/testing, i was hoping that someone knows the engine code. Maybe pathing does reverse scaling? But unfortunatly i get only questions to my question (but thanks, atleast some attention/response). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-02-13 19:43 | lamer | New Issue | |
| 2015-02-13 19:56 | jK | Note Added: 0014043 | |
| 2015-02-13 20:16 | lamer | Note Added: 0014044 | |
| 2015-02-15 03:03 | jK | Note Added: 0014045 | |
| 2015-02-15 12:03 | lamer | Note Added: 0014046 | |
| 2015-02-15 13:17 | lamer | Note Edited: 0014046 | |
| 2015-02-18 01:31 | lamer | Note Edited: 0014046 | |
| 2015-02-22 07:03 | jK | Status | new => resolved |
| 2015-02-22 07:03 | jK | Resolution | open => fixed |
| 2015-02-22 07:03 | jK | Assigned To | => jK |
