View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002510 | Spring engine | General | public | 2011-07-01 16:34 | 2013-08-06 01:17 |
| Reporter | Google_Frog | Assigned To | Kloot | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.82.7+git | ||||
| Summary | 0002510: unsynced heigh-map give-aways and bugs | ||||
| Description | I thought I was documenting a bug with some new terrain drawing system until I realised that someone had tried to implement terrain deformation that does not appear unless scouted. This is very awesome but currently it is extremely easy to bypass. If it is going to be left like this it should not make it into the next engine release because it makes things that look like bugs and is basically useless in it's current state. I have compiled a list of things that I could find that allow players to see the real location of terrain. Hopefully this will help the feature be completed: * Heightmap view (F1) * Pathingmap view (F2) * The texture, if the terrain has been deformed down to the water it will be water coloured. Only appears to occur when LOS visualisation is enabled. * The texture again, the shading given to inclines. Occurs all the time unlike the last one. * The location of commands given to units. * The camera follows the real location of the terrain (most obvious in middle mouse scroll mode). * Spring.GetGroundHeight, as in any widget that uses this. * Map markers * Map drawings * The position of the player's own units, ones with no detection capabilities whatsoever. These units also cause the fake terrain map to update. * The position of opponent radar dots. * The Radar Map shows radar shadows caused by unscouted terrain. * Units path using the old terrain which gives away impassible areas. (this is a little less important as a large blockage is needed for this to be noticable, although fixing this would be awesome). * The position of the building blueprint while placing buildings. * The red or brown squares underneath a building blueprint while placing a building. * gl.DrawGroundCircle * Probably gl.DrawGroundQuad (untested) | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | |||||
|
|
some of these were already fixed, some have been, and some are never going to be. |
|
|
They weren't already fixed in the version I tested. To be useful I think all but these things need fixing: * The position of opponent radar dots. * Units path using the old terrain. * The position of the player's own units. The bug "Units with no detection capabilities cause the fake terrain map to update" may have been an error with setting the detection of the unit. The unit has 0 LOS in unitdef but no aLOS is set. aLOS and LOS are both set to 0 just after this creation of the unit, that may have been enough to update the terrain. |
|
|
In spring_0.82.3-2405-g85f68c9, mouse raytrace to the terrain still uses the synced heightmap. It tracs to the synced heightmap and then maps the y coordinate onto the corresponding y coordinate in the unsynced heightmap. Some more examples: * Zoom to cursor uses the synced heightmap * Marker placing and line drawing uses the synced heightmap. For example make a large wall and pitch down then draw, the drawing will occur on the x and z coordinates that would be returned from a screen trace to the synced heightmap. For example drawing straight lines can become bent. * Spring.TraceScreenRay. I have confirmed that "Units with no detection capabilities cause the fake terrain map to update" was a due to the unit having detection capabilities when created. |
|
|
spring_0.82.3-2414-g6b0820e, remaining issues: * Heightmap view (F1) * Pathingmap view (F2) * Texture, if the terrain has been deformed down to the water it will be water coloured. * Texture, the shading given to inclines. * The Radar Map shows radar shadows caused by unscouted terrain. * The position of the building blueprint while placing buildings. * The red or brown squares underneath a building blueprint while placing a building. * The location of build commands given to units. (other commands now work) The 2 texture bugs are strange, sometimes they only occur when LOS visualisation is enabled. |
|
|
Units refuse to fire when they have an attack order that is inside the synced heightmap. They also refuse to fire when they have an attack order that is blocked by the synced heightmap. Idk how you get around that one with a purely unsynced heightmap. Units would need to know which bits of the terrain they can ignore, maybe they could ignore all pieces of terrain out of LOS as it may have changed since it was last looked at. Or at least an ignoreTerrain weapon tag could be added to let game devs fix this if they want to. |
|
|
spring_0.82.3-2436-g58d1e44 bug with building placement. Mousing over terrain which has different synced and unsynced heightmap occasionally causes the building blueprint visualization to disappear. Moving the mouse in this mode can also cause the blueprints to snap to the synced heightmap position. This occurs for building without shift as well but shift is shown in the gif as it is easier to see. http://www.mediafire.com/?obvng2ciss1xtlv Buildings can also only be placed on legal locations for the synced heightmap. Players could easily make a box of large buildings in an unscouted area to check for heightmap changes. |
|
|
"Buildings can also only be placed on legal locations for the synced heightmap. Players could easily make a box of large buildings in an unscouted area to check for heightmap changes." ==> Nothing to be done about that, those checks are in synced code after the build orders have been given (only way would be to delay them until construction starts, which has other consequences). Pathfinding can also never be made to respect the unsynced heightmap (without changing the entire pathfinder to unsynced code, which I won't do), and the other solution (one heightmap per allyteam) is too expensive. |
|
|
"Pathfinding can also never be made to respect the unsynced heightmap..." I know, that is why I made this comment a day or so ago: "To be useful I think all but these things need fixing: * The position of opponent radar dots. * Units path using the old terrain. * The position of the player's own units." Because these 3 things sound far too hard to fix using an unsynced heightmap. For my purposes "Units refuse to fire through the synced heightmap" could also be ignored if an ignoreTerrain weapon tag were implemented. This tag could reasonably applied to most long range non-StarburstLauncher weapons in zero-k. "Nothing to be done about that, those checks are in synced code after the build orders have been given (only way would be to delay them until construction starts, which has other consequences)." Do an unsynced check when the command is given against the unsynced heightmap, if this succeeds the command is given. Then do a check against the synced heightmap when construction is about to begin. This solution could even be implemented modside reasonably easily so it should be possible in the engine: * Give all buildings maximun slope tolerance and depth. * Add a widget that does a check in widget:CommandNotify for legal height variation (a customparam). * Add a gadget that does a check in gadget:AllowUnitCreation for legal height variation. Engine implementation would be more elegant and a widget cannot easily duplicate the placement graphics that indicates if a position can be built on. |
|
|
Remaining as of spring_0.82.3-2586-gec16205: * Pathing view (F2) * Radar view * Buildings can also only be placed on legal locations for the synced heightmap * Units refuse to fire through the synced heightmap |
|
|
Pathing view (F2) ==> on my list Radar view ==> simulation issue (static radar coverage is not recalculated when synced terrain deforms, mobile radar coverage is), but even if that were fixed it would be non-trivial to make the visualization from an unsynced perspective ==> not on my list Buildings can also only be placed on legal locations for the synced heightmap ==> on my list, but not until after 0.83 Units refuse to fire through the synced heightmap ==> synced code, not on my list |
|
|
I lol at the huge list of bugs |
|
|
as usual, implementing a feature _satisfactorily_ means a hell of a lot more work than whoever proposes it can ever imagine. also, given how many bugs your dynamic sun code introduced, you are hardly one to talk. |
|
|
Who proposed this one? I foresaw this much work. |
|
|
No-one in particular, at one point it was on the MTR list. I only took it up because the idea was offered to new developers ( http://springrts.com/phpbb/viewtopic.php?f=60&t=25991 ), which didn't seem appropriate considering the amount of changes needed (which I also foresaw, I just did not submit all of them in one giant commit). |
|
|
most should be fixed, if not please create a new bug report as this seems really minor. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-07-01 16:34 | Google_Frog | New Issue | |
| 2011-07-01 16:34 | Google_Frog | Graphics Card | => unknown |
| 2011-07-01 16:51 | hoijui | Product Version | 0.82.3+git => 0.82.7+git |
| 2011-07-01 16:51 | hoijui | Build | => 0.82.3-2384-g0387e6a |
| 2011-07-01 16:51 | hoijui | Summary | LOS dependant terrain severly broken => unsynced heigh-map give-aways and bugs |
| 2011-07-01 23:05 | Kloot | Note Added: 0006843 | |
| 2011-07-01 23:05 | Kloot | Status | new => assigned |
| 2011-07-01 23:05 | Kloot | Assigned To | => Kloot |
| 2011-07-02 10:35 | Google_Frog | Note Added: 0006847 | |
| 2011-07-02 12:16 | Google_Frog | Note Added: 0006849 | |
| 2011-07-02 15:15 | Google_Frog | Note Added: 0006855 | |
| 2011-07-02 16:07 | Google_Frog | Note Added: 0006860 | |
| 2011-07-03 11:22 | Google_Frog | Note Added: 0006869 | |
| 2011-07-03 12:55 | Kloot | Note Added: 0006872 | |
| 2011-07-03 13:49 | Kloot | Note Edited: 0006872 | |
| 2011-07-03 14:24 | Google_Frog | Note Added: 0006879 | |
| 2011-07-12 07:58 | Google_Frog | Note Added: 0007000 | |
| 2011-07-12 11:42 | Kloot | Note Added: 0007002 | |
| 2011-07-13 12:17 | zerver | Note Added: 0007010 | |
| 2011-07-13 12:33 | Kloot | Note Added: 0007011 | |
| 2011-07-13 14:08 | Google_Frog | Note Added: 0007013 | |
| 2011-07-13 14:52 | Kloot | Note Added: 0007014 | |
| 2011-07-13 14:52 | Kloot | Note Edited: 0007014 | |
| 2011-07-16 18:21 | Kloot | Note Edited: 0007011 | |
| 2013-08-06 01:17 | abma | Note Added: 0011196 | |
| 2013-08-06 01:17 | abma | Status | assigned => resolved |
| 2013-08-06 01:17 | abma | Resolution | open => fixed |
