Yet another heads up wrt trunk. I am working on the disappearing settlements bug (the one where a settlement disappears or changes while you can not see it, currently this correctly does not update during the game, but will incorrectly if you save/load, plus similar issues with missionaries and other tile properties etc). I have a "working" solution, but it is brutal and ugly. In the hope of finding something more elegant I have been investigating if it is possible to make deep but self-contained copies of FreeColObjects.
We have a cloneFreeColGameObject routine that uses serialization to do
something close, but it copies only one level deep and makes a new
object within the current Game. I am using the same technique to make
a general copy method for FreeColObject (which needs some fairly
intimate hacks to the FCGO reader routines) to create an almost
identical copy, differing only in that:
- it is not "interned" in the Game it was derived from,
i.e. Game.getFreeColGameObject will still find the original
object, not the copy, even though it has the same id
- any "enclosed" object is also an "uninterned" copy, where by
"enclosed" I mean anything that is lexically within the serialized
form of the object. So for example, if I copy a native
settlement, the result will include a copy of any missionary
present, or unit inside the settlement, but the owning player/s
will be references to the originals.
The plan is then that the PlayerExploredTiles can change from
including a whole bunch of explicit fields for everything that might
be there, to just a Tile, which is a copy of the original Tile, made
every time it is sighted. Serializing an unseen Tile to a client then
becomes simply a write of this cached copy if it exists, which means
we can lose all the explicit PET handling throughout the serialization
code other than Tile.java. There is a bit of complexity in saving the
PET itself, as you have to use a non-interning read routine on
restore, but that already exists to implement FreeColObject.copy().
That would be much cleaner code. What remains is to see if I can make
it work. Despite the serialization clean up there are still a few
special cases (e.g. the hack that adds settlements to players) that
might need some attention. Also unclear is whether all this extra
serialization will slow things down unacceptably. If so we may have
to go down the clone() path:-P.
So, do not be surprised if there is some thrashing about in trunk over
this issue in the near future.
Cheers,
Mike Pope
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
