#2596 Weird fog clearance issues with unit movement

Fixed_0.11.0
closed-fixed
nobody
regression (4)
5
2014-10-18
2013-11-11
Bryce Harrington
No

This affects the current git tree only.

Sometimes when moving a unit, the adjacent fog squares don't clear. These fogged squares persist, and aren't cleared by your other units (but sometimes get cleared by indian units).

The behavior is intermittent. Out of 10 new games started, I note the misbehavior only about 4 times. So I can't give an exact set of steps to reproduce, but I've seen it on two different machines with separate git checkouts, and it doesn't occur with 0.10.7.

I've noticed it tends to occur more often when I exit a ship or settlement, however I've seen it occur sometimes when I haven't exited something. If I save and reload, the hidden square reappears, so that's effective as a work-around.

Possibly related to this, I've noticed Indians will sometimes reveal fog on squares I should actually not have visibility on. This seems to occur on squares near to my settlements.

Discussion

  • Mike Pope
    Mike Pope
    2013-11-11

    I can confirm seeing this, however...

    I can't give an exact set of steps to reproduce

    ...I have never been able to discover a consistent cause either, and until someone does we are unlikely to make progress on this.

    It is however not a regression. We have vague reports of this back as far as 0.10.3.

     
  • Can you explain what the significance is of setting Milestone=Fixed_0.10.0? I wouldn't consider the problem fixed, since there's been no code change, so assume I'm misunderstanding what the milestone's meaning is?

    Also, and I'm sure this adds nothing to the bug report, but I've played freecol 0.10.x releases many times and have not seen this issue, but on the git version I'm seeing it quite often (around 40% of the time, as mentioned). I accept that it's perhaps an existing issue, so 'regression' can be dropped, but would emphasize that it's become a lot more common in the current tree.

     
  • Mike Pope
    Mike Pope
    2013-11-11

    • Group: Fixed_0.10.0 --> Current
     
  • Mike Pope
    Mike Pope
    2013-11-11

    Can you explain what the significance is of setting Milestone=Fixed_0.10.0?

    Its what happens by default if you do not set it to the correct value when creating the bug report. If I knew how to change this default behaviour I would, but at the moment it has to be changed explicitly every time someone makes this mistake.

    ...it's become a lot more common in the current tree.

    Fair enough. So that means you will be more able to pin down a reproducible case, right?:-)

     
  • Can you explain what the significance is of setting Milestone=Fixed_0.10.0?

    Its what happens by default
    Aha, thanks, so that bit was my own fault.

    ...it's become a lot more common in the current tree.

    Fair enough. So that means you will be more able to pin down a reproducible case, right?:-)

    Yes, I've held off reporting this bug in exactly that hope. However, this is as far as I've gotten so far, and I decided that between needing to return to work and family stuff, that I'll probably not get more time to examine it for a while, that I should at least register the issue. It's annoying when it happens, and in that way inhibits me from working on the bits I actually want to work on, even though it can be worked around.

     
  • Mike Pope
    Mike Pope
    2013-11-11

    • status: open --> open-needs-info
     
  • I haven't had much time this past month to look into this very much, but some further observations:

    It does not reproduce 100% of the time. When it does occur, it usually happens next to the initial colony, although I think I've seen it at least once somewhere unrelated to my own colony (but maybe that was next to a foreign colony?)

    In at least some of the cases, the blackness appeared when I moved units (usually ships) out of the colony towards the fog. As I mentioned above, the blacked area can't be moved into; so it's not merely a graphics rendering defect.

    Often around the blacked out area, the fog behaves weird too. I.e., Indians will appear in fogged areas that none of my units should have visibility on.

    Saving the game and reloading it makes the blacked area go away.

     
  • Mike Pope
    Mike Pope
    2013-12-04

    As I mentioned above, the blacked area can't be moved into; so it's not merely a graphics rendering defect.

    Confirmed. This is due to the client (correctly IMHO) refusing to move into unexplored territory. The problem remains: why is the tile unexplored?

    Saving the game and reloading it makes the blacked area go away.

    This shows that it is a client-side issue.

     
  • Lone_Wolf
    Lone_Wolf
    2013-12-11

    I have encountered what could be the same issue
    with trunk rev d28c97a
    In the attached year 1525 savegame you see 2 unexplored tiles in territory i already visited.
    In the year 1526 savegame i made those 2 squares seen again, but 2 other squares that were explored in 1525 are now unexplored.
    save / reload DOES NOT fix this for me.

     
    Last edit: Lone_Wolf 2013-12-11
  • Lone_Wolf
    Lone_Wolf
    2013-12-11

    savegame for year 1526

     
  • Mike Pope
    Mike Pope
    2013-12-27

    One bug that can cause this was fixed in git.997555a. I have no confidence that it fixes all of them, especially not the case reported above by Lone_Wolf.

     
  • Evgeny
    Evgeny
    2013-12-28

    I have encountered fog tiles yesterday with the most recent trunk. Unfortunately did not take a picture. This disappeared after "Save&Exit" and reloading.

     
  • Mike Pope
    Mike Pope
    2013-12-28

    For anyone who wants to help on this, pictures and saved games after the fog tiles are seen are not helpful because this is a transient client-side problem. What we need is a saved game from just before the tiles are seen,
    and precise instructions on what unit was moved so that the fog tiles appeared,
    and that the saved-game+instructions are repeatable.

     
  • wintertime
    wintertime
    2014-02-20

    I just encountered the bug again, it was at beginning of a turn, so I tried to reproduce twice from last save, but did not work.
    Then I thought about what could cause that and guessed that there may have been some earlier corruption in the client. I tried from a turn earlier although there had been some random things inbetween (luckily random numbers are repeatable) and it worked!!!

    Reproduction may be a bit complicated though:
    - Load the manual 1527 save
    - Scout: move and check out the rumour, gain treasure train worth 650
    - Treasure: north-west
    - Wagon: east,south
    - Scout: north-west,space
    - Enter for next turn
    - Choose Peter Minuit
    - Click ok on other window listing we gain deSoto and a colonist learned Woodcutting
    - Ship: east,east,southeast,rightclick-go-Europe
    - Treasure: north
    - Scout: north-west,west
    - I hope you see the 3 shadowed tiles from the bug, too.

    I zip-ed up all save files, some logs and a screenshot, in case it helps to havmore than 1 save.

     
    Attachments
  • Mike Pope
    Mike Pope
    2014-02-20

    Well done, this is reproducible. The problem is also now clear --- those tiles should become visible when deSoto is elected and the scout's line of sight increases. A fix will follow soon.

    However, I am somewhat doubtful that this is the only cause.

     
  • Mike Pope
    Mike Pope
    2014-02-20

    • status: open-needs-info --> pending-fixed
    • Group: Current --> Fixed_trunk
     
  • Mike Pope
    Mike Pope
    2014-02-20

    ...having said that, the other saved game/s attached here also include a recent recruiting of deSoto. I am going to hope I am wrong then, and that git.afdafd5
    really has fixed this particularly elusive bug. Kudos to wintertime for making it possible.

    Setting to Pending until next release.

     
  • Mike Pope
    Mike Pope
    2014-10-18

    • Group: Fixed_trunk --> Fixed_0.11.0
     
  • Mike Pope
    Mike Pope
    2014-10-18

    • Status: pending-fixed --> closed-fixed