| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0002721 | Spring engine | General | public | 2011-11-08 13:52 | 2011-11-09 13:51 | ||||
| Reporter | Google_Frog | ||||||||
| Assigned To | Kloot | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 83.0 | ||||||||
| Target Version | Fixed in Version | 84.0 | |||||||
| Summary | 0002721: UHM Bertha Issue | ||||||||
| Description | Long range arty does not fire when told to attack a point where the UHM is lower than the real heightmap. | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
Google_Frog (reporter) 2011-11-08 14:22 |
Moving the player-given attack command to the height of the real heightmap does fix this issue but it is a bad fix, it just creates another issue. If the player aims into an unseen hole the Bertha will not fire for a reason not clear to the player. As I said before this can be worked around by a tag to make the weapon ignore terrain when aiming. This could only apply to explicit attack orders given by the player so it would still auto-aim using the real heightmap (if the projectile can pass through terrain it should obviously ignore terrain all the time). |
|
Kloot (developer) 2011-11-08 14:23 |
the exact problem for future reference: 1) a command gets sent out by a client using an unsynced height value --> 2) the command comes back from its server roundtrip and is now synced --> 3) the original unsynced height parameter is interpreted as synced --> 4) the command is rejected by CommandAI::AllowedCommand if UHM and SHM differ too much |
|
Kloot (developer) 2011-11-08 14:34 Last edited: 2011-11-08 14:35 |
"As I said before this can be worked around by a tag to make the weapon ignore terrain when aiming" sigh... THIS HAPPENS HIGHER IN THE CALLSTACK BEFORE ANY WEAPON TAGS ARE EVEN EVALUATED. SO NO, IT CAN _NOT_ BE "WORKED AROUND BY A TAG", OK? |
|
Google_Frog (reporter) 2011-11-08 15:04 |
I wasn't talking about a specific bug because this is not exactly a bug. It's a core issue with how UHM works (and yes I know that an UHM implementation without this issue is infeasible). There isn't a perfect solution so it is a good idea to add as many tweakable parameters as possible to let game devs choose the compromise that suites them. |
|
Kloot (developer) 2011-11-08 21:07 |
For now the solution chosen is to "move the player-given attack command to the height of the real heightmap", because 1) a hole has to be pretty deep before artillery refuses to fire and 2) scouting is common enough at the stages of the game where such artillery comes into play. It also preserves the range-exploit blocks already in place. I will consider adding a modrule to switch between this and the previous solution if really wanted, but I doubt it. |
|
Google_Frog (reporter) 2011-11-09 07:49 |
"2) scouting is common enough at the stages of the game where such artillery comes into play" Well you can't really assume that as it depends on the game. But anyway your fix works fairly well for the current games. My real reason for reopening is since the fix attack commands are drawn at the height of the SHM. Spamming attack commands gives is a very easy way to subvert the UHM. The command has to have the y position that it was given at for at least the purposes of drawing and unsynced lua. |
|
Kloot (developer) 2011-11-09 13:44 Last edited: 2011-11-09 13:50 |
done (wrt. drawing) as for subverting it with Lua by spamming commands, it's easier to just change the source. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-11-08 13:52 | Google_Frog | New Issue | |
| 2011-11-08 13:52 | Google_Frog | File Added: 20111108_234618_UHM_BERTHA_Comet Catcher Redux_83.0.sdf | |
| 2011-11-08 14:22 | Google_Frog | Note Added: 0007547 | |
| 2011-11-08 14:23 | Kloot | Note Added: 0007548 | |
| 2011-11-08 14:34 | Kloot | Note Added: 0007549 | |
| 2011-11-08 14:34 | Kloot | Note Edited: 0007549 | |
| 2011-11-08 14:35 | Kloot | Note Edited: 0007549 | |
| 2011-11-08 15:04 | Google_Frog | Note Added: 0007550 | |
| 2011-11-08 21:07 | Kloot | Note Added: 0007553 | |
| 2011-11-08 21:08 | Kloot | Status | new => resolved |
| 2011-11-08 21:08 | Kloot | Fixed in Version | => 84.0 |
| 2011-11-08 21:08 | Kloot | Resolution | open => fixed |
| 2011-11-08 21:08 | Kloot | Assigned To | => Kloot |
| 2011-11-09 07:49 | Google_Frog | Note Added: 0007555 | |
| 2011-11-09 07:49 | Google_Frog | Status | resolved => feedback |
| 2011-11-09 07:49 | Google_Frog | Resolution | fixed => reopened |
| 2011-11-09 13:44 | Kloot | Note Added: 0007556 | |
| 2011-11-09 13:44 | Kloot | Status | feedback => resolved |
| 2011-11-09 13:44 | Kloot | Resolution | reopened => fixed |
| 2011-11-09 13:46 | Kloot | Status | resolved => feedback |
| 2011-11-09 13:46 | Kloot | Resolution | fixed => reopened |
| 2011-11-09 13:46 | Kloot | Note Edited: 0007556 | |
| 2011-11-09 13:50 | Kloot | Note Edited: 0007556 | |
| 2011-11-09 13:51 | Kloot | Status | feedback => resolved |
| 2011-11-09 13:51 | Kloot | Resolution | reopened => fixed |
| Issue History |