Hi, > Gesendet: Freitag, 03. Februar 2017 um 23:17 Uhr > Von: "Michael T. Pope" <[email protected]> > An: [email protected] > Betreff: Re: [Freecol-developers] River styles > > On Wed, 1 Feb 2017 13:44:31 +0100 > [email protected] wrote: > > I might have been not clear enough on which type of half-connections > > I meant. You thought I spoke about a normal river-beginning in the middle > > of a tile. I was talking about the river ending on the boundary of a tile, > > Like the appearance we have when flowing into a great river?
No, I meant just a river tile with a connection into a direction where a tile without a river or with a river but with no connection into the opposite direction is. > > where I doubt if that is looking nice enough and am currently slightly > > in favor of forbidding it. > > I do not have a strong opinion there. Generally though its best to keep > the map editor minimal, as it is rare for anyone to work on it:-). 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. > > > 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 know you dont like bumping that number, but I'd think you doing > > that large refactoring of the client-server-messaging, where you > > mentioned it caused instability, would be enough for a .0 version > > to inform users its not just a patch release with some bugfixes. > > We are only few people and trying to keep compatibility while > > still in 0. major version is nice but can add extra work, so it > > should be permissible to shorten the range of supported versions - > > sometimes. If its already broken anyway then it should at least > > be signaled through the version number. > > Bumping the number/incompatible saves always annoys the users. However, > we have been on 0.11.x at least as long as 0.10.x so my resolve is > weakening. I will experiment a little and see how badly my test games > break without the compatibility code (they are from 0.10.3 IIRC), and/or > whether the migration path by reading in 0.11.x and rewriting keeps them > alive. I found some other pieces of related 0.10.5 compatibility code and one just makes broken rivers invisible in a display method (style==null rivers might be fixed on loading instead?). IIRC there was even more that makes it difficult to allow mixed style rivers, such as styles getting overwritten by recreating them from the connections which are just labeled as a cached bitmap, which also does not help as these are binary, which means its not a lossless transform after adding that feature. Its probably better to wait with that until the compatibility code is gone, as that reduces the complexity of the change. Without the version bump I'll just filter the duplicates from the river style dialog, close the BR and not add mixed rivers. I wonder if caching the connections really does improve performance and if TileImprovement.connected could be removed to simplify the code? There is all kinds of other entanglement like putting together a style string, updating the connections, then converting it back to a string, then into TileImprovementStyle class, all inside a loop repeatedly changing the same tiles from different directions. If you select a whole rectangle of tiles in the map editor to add or remove rivers or change their styles, it loops over the tiles one tile changes its neighbours, the loop continues and they get changes again leading to chaotic unpredictable changes to the river styles. Everything would need to be turned inside out to first add all improvements, then add missing connections to all tiles styles, then revome superfluous/broken connections on all tiles, then update the connection cache, to have predictable results (it would also avoid doing much of the work many times), but that would require changing much code. 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. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/freecol-developers
