#2795 Orphaned unit

[Ron Wheeler]

I have a unit that is no longer visible but I get asked to move it. Its location is not shown when the unit (veteran solder with no arms or horse) shows up in the move dialogue box. If I try to move it I get a server error message box. If I click on the control to skip it, the process moves forward.
I think that the unit was captured in a big battle over a city that I failed to capture but I am not sure. There was at least one soldier that was "captured and lost its veteran status".

[Ron Wheeler]

Log file

[Mike Pope]

I have seen this before, and indeed fixed similar bugs. The log file includes the lines:

net.sf.freecol.common.networking.DOMMessage clientError
    WARNING: net.sf.freecol.common.model.Unit not owned by player:1:unit:8856
    Wed Jan 14 01:02:21 EST 2015
    Thread: 3560

Sure enough the saved game contains a unit:8856, owned by the Dutch. However it does not show up as a unit you can move. I expect what you have seen is a dynamic property of a running game and does not survive save/reload.

I then tried getting a unit captured from a settlement and from a unit in the open. In neither case was I able to reproduce the above failure. Again it appears to be a dynamic property of your game.

unit:8856 is currently in Ville de Quebec. Do you have a saved game from before the attack where the unit was lost? And if so, are you able to replay the attack and reproduce the failure? Until there is a reproducible test case, we are stuck on this one.

[Ron Wheeler]

I have the previous saved file but it is from a few years earlier.
I am not sure that you can replay it forward and have the same thing happen.
I have had this happen before in version 0.10.x so I think that it is something that might be related to a core function and probably some sort of overflow (a lot of units or a lot of cities) condition. I have never had it happen when I was starting out.

Many units were involved in the battle which was an attack on my units by the AI engine defending the city.

Exiting and restarting the game seems to have eliminated the problem so at least the load is smart enough to fix the unit's status into a consistent state.
It is clearly not an obvious bug that affects the main processing. It is some sort of edge case where half the process gets done but the rest of the move from English Army to Dutch Army did not get done. It appears that it did not lose its veteran's status which should have happened.
I am not sure that anyone could replay the turns and get to the same battle with the same outcome on each action in the battle. It is going to take someone who really knows the code looking at the process of a unit being captured to see where there is a hole in the code. Somewhere between changing the ownership to Dutch and removing the veteran status and removing it from the list of English units, something failed.

[Mike Pope]

I am not sure that you can replay it forward and have the same thing happen.

I doubt it. I was hoping for something a bit closer to the point the unit was captured.

I have had this happen before in version 0.10.x

Quite so. Bugs in this area have been fixed. Just apparently not all of them.

...probably some sort of overflow (a lot of units or a lot of cities)

That is a possibility, and would explain why I could not reproduce the problem with a simple single unit test.

It is some sort of edge case where half the process gets done but the rest of the move from English Army to Dutch Army did not get done. It appears that it did not lose its veteran's status which should have happened.

Not so. unit:8856 in the first saved game is (correctly) just a Free Colonist.
That part did work. That part however takes place in the main server thread, whereas the choice of units made available to the player to move is done in the client thread. The bug is due to the client not dropping the captured unit from its current cache of player units when the server sends it an update following the combat. This in turn can be due to either a bug in the client processing of the update, or in the server construction of the update, or an unrelated crash in another thread desynchronizing the comms, or...

...It is going to take someone who really knows the code looking at the process of a unit being captured to see where there is a hole in the code.

Just tried that this morning:-P. No holes are apparent. See why I am really keen on test cases?

[Mike Pope]

Several releases on, no further sightings or better information. Time to close.

[Ron Wheeler]

Closing this seems reasonable if no one else has reported it and it is
too hard to reproduce.

Ron

[Mike Pope]

Thanks for your patience. I am hoping this one is gone.