Hi, > Gesendet: Sonntag, 05. Februar 2017 um 04:14 Uhr > Von: "Michael T. Pope" <mp...@computer.org> > An: win...@genial.ms > Cc: freecol-developers@lists.sourceforge.net > Betreff: Re: [Freecol-developers] River styles > > On Sat, 4 Feb 2017 00:32:30 +0100 > win...@genial.ms wrote: > > I meanwhile think its actually more about preventing malformed data from > > being saved. > > Some parts of the code already try to prevent it, but there are a few > > loopholes which I now know need to be prevented from allowing broken rivers. > > One example is removing a river tile and the neighbours keeping broken > > connections. > > Ugh. Yes, that is probably worth preventing.
I'll see if I can fix that. > BTW I just got to playing about with the map editor and made some rivers. > I did not have any problems, and it is definitely less aggravating to use > than the older design. Glad you got to that. Thank you. > > > > > the compatibility code > > > > It looks like a bug to me to call updateRiverConnections and I guess > > also updateRoadConnections from the compatibility code inside the > > checkIntegrity method, because they make changes to the data when > > they might not be allowed to, as the fix parameter is only checked later > > for some other changes. > > I agree that sounds buggy. IIRC the semantics of updateRiverConnections > changed a few times and probably desynced with its use in the integrity > checker. > > > I wonder if caching the connections really does improve performance > > and if TileImprovement.connected could be removed to simplify the code? > > Put up a patch or pull req and I will add it to the overnight test queue. > Looking at it again, I am hopeful the effect will be hard to measure. > Definitely a good thing to have got away from a hex string representation. I made the changes but it were 2 commits, so I tried to put it on my SF fork and repeatedly got unpack errors from the SF git. Sometimes, I also get these on normal single commits on the FreeCol repository, but there its no problem to repeat it. Updating the fork is near impossible and I've given up on it for the moment, as the probability of the error seems proportional to the size of the pushed data and my fork was outdated by years needing over 400MB to be pushed, which I tried more than once. I wish they had an update button on the website. I ended up putting it on github, although I had to push the whole repository there again: https://github.com/wintertime/FreeCol/tree/noconnected You can use git remote add and git fetch commands to get the branch off of github. I only tried a bit in map editor and let ant test/testall run and fixed the code to work with that, but the changed code is not called from many places in the game anyway. > That may even have come up at the time. Once again, IIRC I think we were > just relieved to have something that worked, improved the save format, and > dealt with the backwards compatibility. Appetite for further thrashing > was limited by a desire to push forward to a release. > > > If more places would use TileImprovementStyle instead of strings > > containing a style it would improve the code. The class could then > > internally handle manipulating the style strings, instead of many > > different places knowing the format of these strings. > > I believe that was the intent. As you note, the work was incomplete. > Interesting, maybe that can be improved. Greetings, wintertime ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
