On 29.06.2013 06:00, Michael T. Pope wrote: > 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 >
Sounds like a sensible plan. Regards Michael ------------------------------------------------------------------------------ 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
