[Freeciv-Dev] [patch #4853] Gen-move support for autoexplorers
Update of patch #4853 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4853 ___ 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 #4852] Clean up flag restriction documentation
Update of patch #4852 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4852 ___ 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 #4854] Un-hardcode safe house discovery
Update of patch #4854 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4854 ___ 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 #4855] Allow amphibious unit for kill_something_with()
Update of patch #4855 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4855 ___ 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 #4856] Remove unused AI channel cache
Update of patch #4856 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4856 ___ 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 #4858] Use terrain_class rather than move_type in AI
Update of patch #4858 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4858 ___ 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 #4857] Move tech_want data to default AI
Follow-up Comment #1, patch #4857 (project freeciv): The civil war chunks seem out of place here, but useful anyway: no reason for a new patch, but if they belong somewhere else, maybe adjust? ___ Reply to this item at: http://gna.org/patch/?4857 ___ 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 #4861] Allow Ferryboat as a starting unit
URL: http://gna.org/patch/?4861 Summary: Allow Ferryboat as a starting unit Project: Freeciv Submitted by: persia Submitted on: Sat 28 Jun 2014 06:45:33 PM JST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: persia Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Ferryboats were initially blocked as starting units as a temporary measure to work around the issue of starting units being placed in inappropriate terrain (r8490). When this was resolved (r12456), the temporary limitation was not lifted. The attached patch lifts this restriction, and adds a new test when setting the startunits string to verify that the first unit will be native to a terrain used when selecting starting positions (as otherwise, there may be an infinite loop seeking for a suitable startpos for the player). As a side effect, when considering radically different rulesets, a startunits string suitable for one may be unsuitable for another, which may be exposed to a player as an inability to enter set startunits fac\n rulesetdir land-ferries\n when rulesetdir land-ferries\n set startunits fac\n works. This patch also fixes the startunits help and code comments to reflect the changes from patch #3352 (r21435). ___ File Attachments: --- Date: Sat 28 Jun 2014 06:45:33 PM JST Name: allow-ferryboat-as-a-starting-unit.patch Size: 7kB By: persia http://gna.org/patch/download.php?file_id=21174 ___ Reply to this item at: http://gna.org/patch/?4861 ___ 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 #4862] Use common ferry function for settler ferry check
URL: http://gna.org/patch/?4862 Summary: Use common ferry function for settler ferry check Project: Freeciv Submitted by: persia Submitted on: Sat 28 Jun 2014 06:47:58 PM JST Category: ai Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: persia Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: When identifying a ferry suitable for a settler, use the common ferry validation function, rather than simply checking whether the potential ferry is able to move on at least some oceanic terrain (possibly with extras support). ___ File Attachments: --- Date: Sat 28 Jun 2014 06:47:58 PM JST Name: use-common-ferry-function-for-settler-ferry-check.patch Size: 1kB By: persia http://gna.org/patch/download.php?file_id=21175 ___ Reply to this item at: http://gna.org/patch/?4862 ___ 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 #4863] Validate boats are sea capable by terrain iteration
URL: http://gna.org/patch/?4863 Summary: Validate boats are sea capable by terrain iteration Project: Freeciv Submitted by: persia Submitted on: Sat 28 Jun 2014 06:52:27 PM JST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: persia Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: When processing the ruleset, perform all validation of L_BARBARIAN_BOAT units and L_FERRYBOAT units in ruleset sanity checking. When performing this sanity checking, iterate over terrains to detect the ability to move on oceanic terrain, rather than using move_type. No, this doesn't actually fix the ferry limitation, but it is a useful precursor for later patches in the series. ___ File Attachments: --- Date: Sat 28 Jun 2014 06:52:27 PM JST Name: validate-boats-are-sea-capable-by-terrain-iteration.patch Size: 3kB By: persia http://gna.org/patch/download.php?file_id=21176 ___ Reply to this item at: http://gna.org/patch/?4863 ___ 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 #4864] Distance-based calculation for meeting charges
URL: http://gna.org/patch/?4864 Summary: Distance-based calculation for meeting charges Project: Freeciv Submitted by: persia Submitted on: Sat 28 Jun 2014 07:01:38 PM JST Category: ai Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: persia Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0, 2.6.0 ___ Details: Currently, when assigned to guard a unit, sailing units attempt to meet their charge at the destination, and non-sailing units attempt to meet their charge at the charges current location. For S2_5, where only simple nativity matters, sailing units should verify the charge is actually headed somewhere, as otherwise they decide they are unable to meet the charge (even if they are initially on the same tile), and find another job to do. For trunk, I've replaced the decision tree for whether to go to the charge or meet the charge at the destination with some simple calculations related to relative distances and rough estimates of travel. I'm not convinced this is the best way to decide, but didn't want to invoke pathfinding to recreate the charge's potential route (which was discarded previously), and then use bodyguard pathfinding to determine the fastest rendezvous point from which the bodyguard can still reach the goal tile at the same time as the charge, as I thought this might be computationally expensive. A compromise solution currently eludes me. ___ File Attachments: --- Date: Sat 28 Jun 2014 07:01:38 PM JST Name: sailing-units-continue-guarding-stationary-charges.S2_5.patch Size: 880B By: persia http://gna.org/patch/download.php?file_id=21177 --- Date: Sat 28 Jun 2014 07:01:38 PM JST Name: distance-based-calculation-for-meeting-cahrges.patch Size: 2kB By: persia http://gna.org/patch/download.php?file_id=21178 ___ Reply to this item at: http://gna.org/patch/?4864 ___ 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 #4865] Consolidate move_type usage and move more usage to client
URL: http://gna.org/patch/?4865 Summary: Consolidate move_type usage and move more usage to client Project: Freeciv Submitted by: persia Submitted on: Sat 28 Jun 2014 07:09:53 PM JST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: persia Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Once the AI and Server no longer use move_type, it becomes possible to consolidate much of the logic, or move it to the client. I've implemented this as two patches, the first for consolidation and general cleanup, and the second for the client migration. Note that savegame processing will continue to rely on the definition of the enumeration for as long as we support reading savegame files with old killstack definitions, so if the remainder of the logic preserved in common/unitttype.[ch] by this patch is removed, the enumeration declaration should be made available to savecompat.c ___ File Attachments: --- Date: Sat 28 Jun 2014 07:09:53 PM JST Name: consolidate-move_type-support-to-unittype.patch Size: 8kB By: persia http://gna.org/patch/download.php?file_id=21179 --- Date: Sat 28 Jun 2014 07:09:53 PM JST Name: migrate-all-move_type-use-to-client.patch Size: 24kB By: persia http://gna.org/patch/download.php?file_id=21180 ___ Reply to this item at: http://gna.org/patch/?4865 ___ 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 #4866] Provide alternate semantics to the client to replace move_type
URL: http://gna.org/patch/?4866 Summary: Provide alternate semantics to the client to replace move_type Project: Freeciv Submitted by: persia Submitted on: Sat 28 Jun 2014 07:18:56 PM JST Category: client Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: Attached are a pair of patches that demonstrate adding new features to the ruleset to provide semantic values to be used by the client to replace move_type checks. The unit class group concept is demonstrated by use in editor tool grab ordering, but may also be useful in other unit selection contexts (e.g. patch #3721). I'm not sure how to make the provided group names translatable, but an adjustment to provide this would improve things in the case where the strings were exposed to the UI. While I've only demonstrated use of ruleset-specified unit background colors in the Xaw client, it might also be useful in the Qt client (which currently has it's own logic to calculate RGBA values depending on move_type). I'm also not entirely sure about the data storage model: casting color_std to int for storage seems to work in my testing, but could potentially cause issues with Qt (as enum is less likely to be int in C++). While these semantic concepts seemed to match the client needs from my viewpoint, I'll defer to folk actually working on clients to determine if these are the right concepts, or if there are better ways to solve this class of problems. ___ File Attachments: --- Date: Sat 28 Jun 2014 07:18:56 PM JST Name: introduce-unit-class-groups.patch Size: 34kB By: persia http://gna.org/patch/download.php?file_id=21181 --- Date: Sat 28 Jun 2014 07:18:56 PM JST Name: assign-background-color-in-the-ruleset.patch Size: 24kB By: persia http://gna.org/patch/download.php?file_id=21182 ___ Reply to this item at: http://gna.org/patch/?4866 ___ 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 #3721] Getting rid of move_type dependency on unitselect dialog
Follow-up Comment #6, patch #3721 (project freeciv): One of the patches in patch #4866 provides a new ruleset field (unit class group) that could be used for this purpose, if there is interest in that sort of solution (as hinted at the end of the original submission). ___ Reply to this item at: http://gna.org/patch/?3721 ___ 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 #4866] Provide alternate semantics to the client to replace move_type
Update of patch #4866 (project freeciv): Depends on: = patch #4865 ___ Reply to this item at: http://gna.org/patch/?4866 ___ 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 #4865] Consolidate move_type usage and move more usage to client
Update of patch #4865 (project freeciv): Depends on: = patch #4861 ___ Reply to this item at: http://gna.org/patch/?4865 ___ 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 #4865] Consolidate move_type usage and move more usage to client
Update of patch #4865 (project freeciv): Depends on: = patch #4863 ___ Reply to this item at: http://gna.org/patch/?4865 ___ 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 #4865] Consolidate move_type usage and move more usage to client
Update of patch #4865 (project freeciv): Depends on: = patch #4864 ___ Reply to this item at: http://gna.org/patch/?4865 ___ 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 #4867] Quickselect should not depend on move_type
URL: http://gna.org/patch/?4867 Summary: Quickselect should not depend on move_type Project: Freeciv Submitted by: persia Submitted on: Sat 28 Jun 2014 07:59:59 PM JST Category: client Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: client/control.c::quickselect() sets priorities based on move_type, but should probably do something more comprehensive to support complex nativity and complex terrain models. Using a structure like patch #4866 suggests for the editor grab tool may not be sufficient, as the preferred result of quickselect may vary by terrain. Perhaps something based on tile nativity, like patch #3721? ___ Reply to this item at: http://gna.org/patch/?4867 ___ 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 #4868] Don't use move_type to set colors in Qt client city production painting
URL: http://gna.org/patch/?4868 Summary: Don't use move_type to set colors in Qt client city production painting Project: Freeciv Submitted by: persia Submitted on: Sat 28 Jun 2014 08:04:01 PM JST Category: client-qt Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: This might be able to use the class-identified color recommendation provided by patch #4866, or perhaps use !UCF_TERRAIN_SPEED (with flying units then overridden by the later fuel check). ___ Reply to this item at: http://gna.org/patch/?4868 ___ 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 #4869] Remove move_type from the client
URL: http://gna.org/patch/?4869 Summary: Remove move_type from the client Project: Freeciv Submitted by: persia Submitted on: Sat 28 Jun 2014 08:16:38 PM JST Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: Once the client no longer uses move_type, there is no longer any reason to calculate move_type on the client, or maintain the support functions. The enumeration definition for killstack savegame support can be compartmentalised, to avoid renewed usage of the move_type concept. ___ File Attachments: --- Date: Sat 28 Jun 2014 08:16:38 PM JST Name: remove-move_type-from-client.patch Size: 7kB By: persia http://gna.org/patch/download.php?file_id=21183 ___ Reply to this item at: http://gna.org/patch/?4869 ___ 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 #4869] Remove move_type from the client
Update of patch #4869 (project freeciv): Depends on: = patch #3721 ___ Reply to this item at: http://gna.org/patch/?4869 ___ 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 #4869] Remove move_type from the client
Update of patch #4869 (project freeciv): Depends on: = patch #4866 ___ Reply to this item at: http://gna.org/patch/?4869 ___ 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 #22241] Nation help uses rule name, not translated name
URL: http://gna.org/bugs/?22241 Summary: Nation help uses rule name, not translated name Project: Freeciv Submitted by: jtn Submitted on: Sat 28 Jun 2014 12:41:27 BST Category: client Severity: 3 - Normal Priority: 5 - Normal Status: In Progress Assigned to: jtn Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: Any Planned Release: 2.4.3, 2.5.0, 2.6.0 ___ Details: The fix for bug #22235 exposed the help system's use of rule_name for nations help -- Kievan Rus' are listed as Ruthenian, and the legend doesn't show. Fix attached (I think I must have been asleep when I wrote the patch for bug #18451.) ___ Reply to this item at: http://gna.org/bugs/?22241 ___ 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] [task #7808] Backport nations from trunk to S2_5
Update of task #7808 (project freeciv): Should be Finished on: Mon 30 Jun 2014 00:00:00 BST = Sat 28 Jun 2014 00:00:00 BST Status: Ready For Test = Done Percent Complete: 80% = 100% Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/task/?7808 ___ 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 #22241] Nation help uses rule name, not translated name
Update of bug #22241 (project freeciv): Status: In Progress = Ready For Test ___ Additional Item Attachment: File name: trunk-S2_5-help-nation-translation.patch Size:4 KB File name: S2_4-help-nation-translation.patch Size:4 KB ___ Reply to this item at: http://gna.org/bugs/?22241 ___ 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 #4822] Use requirements_vector for effects
Update of patch #4822 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4822 ___ 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 #4821] Do not consider harmless units in assess_danger()
Update of patch #4821 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4821 ___ 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 #4852] Clean up flag restriction documentation
Follow-up Comment #3, patch #4852 (project freeciv): In S2_5, Airbase became a userflag. (Actually this was in 2009; patch #1205.) ___ Reply to this item at: http://gna.org/patch/?4852 ___ 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 #4852] Clean up flag restriction documentation
Follow-up Comment #4, patch #4852 (project freeciv): Do you think it's worth pushing this to S2_4 as well? ___ Reply to this item at: http://gna.org/patch/?4852 ___ 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 #4830] Multipliers to effects
Follow-up Comment #11, patch #4830 (project freeciv): Patch version, which adds multipliers to help dialog. Setting two variables in ruleset_free(game.c) to zero is needed for cleanup purposes. If we don't do that, then in special cases (for example ruleset was loaded many times) we can't load all multipliers. (file #21186) ___ Additional Item Attachment: File name: multipliers.patch Size:32 KB ___ Reply to this item at: http://gna.org/patch/?4830 ___ 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 #1341] Replace Improvement replaced_by with a requirements vector
Update of patch #1341 (project freeciv): Status:None = Ready For Test Assigned to:None = persia Planned Release: = 2.6.0 Summary: Improvement negated requirements = Replace Improvement replaced_by with a requirements vector ___ Follow-up Comment #2: As it turns out, the obsolete_by vector can also replace replaced_by, with a couple helper functions for parsing (in large part thanks to the work in bug #21419). Note that in the event a ruleset author adds multiple buildings to the obsolete_by vector, only the first of them will be considered a sensible target for automatic worklist upgrades: I'm not sure where this ought be documented (if anywhere). (file #21187) ___ Additional Item Attachment: File name: use-obsolete_by-vector-for-improvement-replaced_by.patch Size:9 KB ___ Reply to this item at: http://gna.org/patch/?1341 ___ 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 #4830] Multipliers to effects
Follow-up Comment #12, patch #4830 (project freeciv): On the global variables: I agree they are needed for cleanup purposes, but I still think they should be scoped to multipliers.c. Consider adding helper functions to game_ruleset_init() and game_ruleset_free() that operate on static variables in multipliers.c: functions in multipliers.c will be able to see these values, but they will not be directly accessible from other code. For example, the achievements code stores a static array locally scoped to achievements.c, which is initialised and cleared with functions called from game.c. Doing it this way means they are automatically processed however the ruleset is loaded, so you don't need to maintain separate initialisations in client_main and srv_main (and are no longer missing one in ruledit, civmanual, or any other ruleset-consuming tools that get added in the future). r25288 bumped the packet ID count, so your packets need renumbering, but that's very minor (and can be fixed on commit, rather than being an endless chase). Similarly, the network capstring in fc_version will need to be updated with the application of this patch (this, again, can be added on commit). I still worry about the non-static stuff in GTK, but don't know enough to be certain. In helpdlg_g.h, you have Policiess, when I think you want Policies. In handle_ruleset_multiplier(), you have Too many multipliers sended by server, when I think you want Too many multipliers sent by the server. In experimental/multipliers.ruleset, you have Does nothink, when I think you want Does nothing. In helpdata.txt, you have ...which defined your civilization rights, when I think you want ...which define your civilization's rights.. Also in helpdata.txt, consider using a _() macro so that the text string is translated. As may be indicated by the increasingly minor and detailed nature of my feedback, I think this is almost ready for inclusion. ___ Reply to this item at: http://gna.org/patch/?4830 ___ 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 #4789] allow_holes settings for tech loss
Update of patch #4789 (project freeciv): Status:None = Ready For Test Assigned to:None = jtn Planned Release: = 2.6.0 ___ Additional Item Attachment: File name: trunk-tech-loss-holes.patchSize:15 KB ___ Reply to this item at: http://gna.org/patch/?4789 ___ 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 #4857] Move tech_want data to default AI
Follow-up Comment #2, patch #4857 (project freeciv): The AI callback API change was already in separate patch. Do you want also the tech_want copying from player to player to be moved from server/plrhand.c to new callback in separate patch before this (and then just adjusted with this patch)? Frankly, I suspect that the whole tech_want copy makes nothing good for the new player, but didn't want to drop it (that would be behavior change) as part of this patch. ___ Reply to this item at: http://gna.org/patch/?4857 ___ 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 #22243] City with more than max trade routes can't change them
URL: http://gna.org/bugs/?22243 Summary: City with more than max trade routes can't change them Project: Freeciv Submitted by: jtn Submitted on: Sat 28 Jun 2014 22:16:11 BST Category: None Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: Any Planned Release: 2.5.0, 2.6.0 ___ Details: After the fix for bug #21141 (as modified by bug #21152), if a city ends up with more trade routes than the current maximum, I think the routes become frozen; it's impossible for the player to influence them by establishing new routes, and if they try they'll get a potentially inaccurate message The city of Linz already has current max better trade routes!, even if the new route would have had better trade than any of the existing ones. (Not tested this.) The reduction in max traderoutes might not be something they can easily reverse (wonder loss, tech loss, ...). Depending on the ruleset, players might be forced to resort to giving away their city and retaking it (causing routes to be cancelled) to regain control of its trade routes. This may limit the practical use of the Max_Trade_Routes effects in rulesets to requirements likely to survive indefinitely. I think a sensible solution would be to allow establishing a new route in this case iff the new one would yield more than the *sum* of the weakest N routes where N = excess+1, and have the new route cancel *all* of those routes, bringing the total within the current max. (This will be slightly fiddly to implement since it involves sorting/ranking the routes.) * (If we're going to add the ability to sort the routes, I wonder about an alternative behaviour for excess traderoutes where the routes that would yield least in a given turn become inactive, yielding nothing. Establishing a new route in this case would have the same behaviour, bringing the number of routes down to the current max, treating the excess routes as having value 0.) Alternatively, the minimal code change would be to disable the N better trade routes message, leaving just the bare infuriating Sorry, your Caravan cannot establish a trade route here! (but that doesn't improve gameplay, of course). ___ Reply to this item at: http://gna.org/bugs/?22243 ___ 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 #22244] Illegal trade route Active setting counterintuitive
URL: http://gna.org/bugs/?22244 Summary: Illegal trade route Active setting counterintuitive Project: Freeciv Submitted by: jtn Submitted on: Sat 28 Jun 2014 22:32:08 BST Category: docs Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: Any Planned Release: 2.5.0, 2.6.0 ___ Details: Unless I've missed something, the Active setting for illegal trade routes mostly does the same thing as Inactive, since in most cases illegality is signalled by setting a bonus of zero. The only place where Active routes still have value is if they started international and within trademindist, and become domestic. I can't think of a sensible alternative behaviour given the way trade routes are currently specified, so by default I think we should document this in ruleset comments. ___ Reply to this item at: http://gna.org/bugs/?22244 ___ 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 #22244] Illegal trade route Active setting counterintuitive
Follow-up Comment #1, bug #22244 (project freeciv): (this being the setting added in patch #3611) ___ Reply to this item at: http://gna.org/bugs/?22244 ___ 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 #22243] City with more than max trade routes can't change them
Follow-up Comment #1, bug #22243 (project freeciv): Also, can_establish_trade_route() checks for ==max, so currently gives the wrong answer in the face of excess routes. It should be updated for whatever the conclusion of this is. (establish_trade_route() also checks ==max, but in that case assertions rather than graceful handling are appropriate.) ___ Reply to this item at: http://gna.org/bugs/?22243 ___ 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 #22236] Flag swapping for Barbarians Pirates ?
Update of bug #22236 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22236 ___ 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 #1341] Replace Improvement replaced_by with a requirements vector
Follow-up Comment #3, patch #1341 (project freeciv): Does this cause behavior changes? What happens in these situations: 1) You learn Gunpowder, but haven't built any Barracks II yet (all existing Barracks should be sold) 2) You conquer city with Barracks II, but don't know Gunpowder yourself, so you (try to) build Barracks ___ Reply to this item at: http://gna.org/patch/?1341 ___ 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 #22188] civ2civ3: remove DiplomatDefense flag from Airbase
Update of bug #22188 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22188 ___ 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 #4857] Move tech_want data to default AI
Follow-up Comment #3, patch #4857 (project freeciv): No, I just didn't understand why cai_created_by_civil_war() and twai_created_by_civil_war() were being defined in a patch that otherwise looks like a data storage migration patch, having not thought it through sufficiently to realise this copy was necessary to preserve the data previously copied in plrhand.c. Thanks for the explanation. ___ Reply to this item at: http://gna.org/patch/?4857 ___ 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 #4857] Move tech_want data to default AI
Follow-up Comment #4, patch #4857 (project freeciv): - Updated against svn (file #21189) ___ Additional Item Attachment: File name: AiTechWant-2.patch.bz2 Size:7 KB ___ Reply to this item at: http://gna.org/patch/?4857 ___ 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 #4870] Clearer error message when no client can be built
URL: http://gna.org/patch/?4870 Summary: Clearer error message when no client can be built Project: Freeciv Submitted by: cazfi Submitted on: Sun 29 Jun 2014 02:58:34 AM EEST Category: bootstrap Priority: 5 - Normal Status: In Progress Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: When configure checks for all clients fail (it can't select anything to build), it says could not guess which client to compile. It's not about problem in guessing, but simply that nothing can be built. Change the error message to say so. ___ Reply to this item at: http://gna.org/patch/?4870 ___ 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 #4870] Clearer error message when no client can be built
Update of patch #4870 (project freeciv): Status: In Progress = Ready For Test Planned Release: = 2.4.3, 2.5.0, 2.6.0 ___ Additional Item Attachment: File name: GuessNot.patch Size:0 KB File name: GuessNot-S2_4.patchSize:0 KB ___ Reply to this item at: http://gna.org/patch/?4870 ___ 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 #1341] Replace Improvement replaced_by with a requirements vector
Follow-up Comment #4, patch #1341 (project freeciv): I'll test these conditions to verify, but from code interpretation: 1) Because, unlike other requirements vectors, obsolete_by is disjunctive, Barracks is interpreted as obsolete by improvement_obsolete(), so handled appropriately. Thinking about this, I suppose another way to consider bug #21419 would have been to change the semantics to sustained_until or similar, and have all the requirements negated, but if we did that, the result would end up the same. 2) All calls to building_upgrades_to() are from constructions that check can_city_build_improvement_foo(), so that one would build Barracks in that city. I suspect this is a bug, and that this behaviour should be prevented. I don't beleive the client offers the choice, or the AI tries to do it because of improvement redundancy, but that's not sufficient guard (one could construct a hacked client that would miss a client-only guard). ___ Reply to this item at: http://gna.org/patch/?1341 ___ 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 #1341] Replace Improvement replaced_by with a requirements vector
Follow-up Comment #5, patch #1341 (project freeciv): 1) is now tested, and indeed works as expected: learning Gunpowder causes one to sell all Barracks, even if one has not built any Barracks II 2) Is also tested: attempts to force worklist inclusion of the obsolete Barracks I in a city containing Barracks II by a player ignorant of Gunpowder are ignored. Further, I've inspected the codepath more closely: while there are guards in the AI and the client, the server enforces the restriction that only non-obsolete things may be built: while can_player_build_improvement_direct() is sometimes called without the caller checking improvement_obsolete(), this is always checked at some point in the call stack within cityturn.c between the can_player_build_improvement_direct() call and actually processing the building. ___ Reply to this item at: http://gna.org/patch/?1341 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
