[Freeciv-Dev] [patch #3166] Lua 5.1.5
Update of patch #3166 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3166 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3170] Sanity check ruleset road compat_specials
Update of patch #3170 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3170 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #19488] Gtk3-client packaging still expects binary to be named freeciv-gtk2x
Update of bug #19488 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?19488 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3178] Max_Trade_Routes effect
URL: http://gna.org/patch/?3178 Summary: Max_Trade_Routes effect Project: Freeciv Submitted by: cazfi Submitted on: Sat 03 Mar 2012 12:53:45 AM EET Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: This patch makes maximum number of trade routes city may establish controlled by an effect. I intentionally left out removal of existing trade routes even if effect value decreases below current number of max trade routes. This is to reduce micro-management. User should not be forced to establish same traderoute again if effect value temporarily dips. Hard maximum (one that the effect value is clipped to) of trade routes is increased from 4 to 5. In all supplied rulesets, except civ1, effect that makes max number of trade routes always 4 has been added. In civ1 ruleset effect provides maximum of 4 trade routes. I don't know what civ2 ruleset should have. I just assume that freeciv's traditional number of trade routes, 4, has been inherited from civ2. ___ Reply to this item at: http://gna.org/patch/?3178 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3179] Mixed ACTIVITY_ROAD ACTIVITY_GEN_ROAD build
URL: http://gna.org/patch/?3179 Summary: Mixed ACTIVITY_ROAD ACTIVITY_GEN_ROAD build Project: Freeciv Submitted by: cazfi Submitted on: Sat 03 Mar 2012 01:06:10 AM EET Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: While ACTIVITY_ROAD ACTIVITY_RAILROAD should be removed completely in the future, I want to make transitional phase where they exist together with ACTIVITY_GEN_ROAD as stable as possible - it's probably going to take some time before we are ready to get rid of ACTIVITY_ROAD ACTIVITY_RAILROAD. One rather minor remaining problem in transitional phase would be when both ACTIVITY_ROAD ACTIVITY_GEN_ROAD/Road (or ACTIVITY_RAILROAD and ACTIVITY_GEN_ROAD/Railroad) units work together in the same tile. As activity count would be counted separately for each, road (or railroad) would finish only when either activity alone reaches required count. Attached patch makes ACTIVITY_GEN_ROAD activity count calculation to add also activity count from ACTIVITY_ROAD or ACTIVITY_RAILROAD depending on road type being built. ___ File Attachments: --- Date: Sat 03 Mar 2012 01:06:10 AM EET Name: GenRoadOldRoadBuildCoOperation.diff Size: 1kB By: cazfi http://gna.org/patch/download.php?file_id=15320 ___ Reply to this item at: http://gna.org/patch/?3179 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #19029] Possible trouble saving/loading players' known territory for player indices =40
Follow-up Comment #11, bug #19029 (project freeciv): Updated patch attached -- targeted at S2_3 but applies to all branches. (Need to think further about dropping unnecessary backwards compatibility for S2_4 and trunk before commit.) I've fixed a memory leak and moved to unsigned ints in more places (the existing bit-shifting with signed ints is not nice, although probably did the right thing in practice). I've added some comments acknowledging that the backwards compatibility mode deliberately overshifts (and thus invokes undefined behaviour). I'm sure some tool is going to castigate us for it at some future point, so a comment may save some head-scratching. Also, I've tweaked the semantics of the new kvb entries subtly, as suggested in comment #2: a halfbyte (covering 4 player slots) is only saved/loaded if at least one of those slots is actually in use. Previously, a game with 4 players would save/load map-known data for 8 full maps (32 player slots) -- 8x as much as needed. This should mitigate the increase in save time and save file size from this workaround, and reduce load times a bit (when loading new-format games). (I also said in that comment that the value of lines is too big, wasting memory, but I can't see what I meant now -- it looks fine to me.) Strictly, we could avoid bloating savefiles with the kvb stuff entirely for games of =40 player slots (i.e., most of them), since the existing k format is OK for such games. But the code for that would be nasty and would complicate removing backward compatibility in future, so shrug. A further possible refinement: for games with fog-of-war, it would be possible to use the information in the player maps instead, per comment #5. * Pro: for loading existing S2_3 saves, this would avoid relying on the potentially-platform-dependent undefined behaviour. * Pro: moving to only saving this information in one place in future savefile formats would decrease save time/size. * Con: this would mean that the global known save/load code would only be exercised in non-fogofwar games, which are not the default. So it could easily rot. * Con: player maps are loaded rather later than this known information. Messing around with the load sequence is fraught -- particularly on a stable branch -- due to complex dependencies between loading steps. Conclusion: probably not worth it, so I haven't tried to do this. Tested with S2_3 with a game with players in slots 0 and 125 (attached): loaded this old game into a new server, saved it, and loaded that into both a new server and an old server, checking that both players' known info is loaded OK and eyeballing the savefiles. (On x86_64; that doesn't guarantee that backward compatibility works as expected on Sparc, since we're talking about undefined behaviour here.) (file #15321, file #15322) ___ Additional Item Attachment: File name: KnownSaveBitOrder-4.diff Size:7 KB File name: idx-painted.sav.bz2Size:14 KB ___ Reply to this item at: http://gna.org/bugs/?19029 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
