[Freeciv-Dev] [bug #22252] Giving techonologies in editor does not work
Update of bug #22252 (project freeciv): Category:None = editor Status:None = Ready For Test Assigned to:None = pepeto Planned Release: = 2.6.0 ___ Follow-up Comment #3: Fix attached. (file #21236) ___ Additional Item Attachment: File name: edit_research.patchSize:2 KB ___ Reply to this item at: http://gna.org/bugs/?22252 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22258] Map topology and tileset incompatible is not an error
URL: http://gna.org/bugs/?22258 Summary: Map topology and tileset incompatible is not an error Project: Freeciv Submitted by: pepeto Submitted on: mer. 02 juil. 2014 15:02:59 CEST Category: client Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: pepeto Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: Any Planned Release: 2.6.0 ___ Details: In patch #4474, an tileset error has been added to warn the user that its tileset doesn't fit the topology. I really think this is not an *error*. I agree the user should be warned. But we shouldn't spam the console with error messages (and backtraces in my case). Changed to LOG_NORMAL, which looks a better compromise. ___ File Attachments: --- Date: mer. 02 juil. 2014 15:02:59 CEST Name: tileset_error_topology_incompatible.patch Size: 1 ko By: pepeto http://gna.org/bugs/download.php?file_id=21237 ___ Reply to this item at: http://gna.org/bugs/?22258 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4888] Move research advance name accessors
URL: http://gna.org/patch/?4888 Summary: Move research advance name accessors Project: Freeciv Submitted by: pepeto Submitted on: mer. 02 juil. 2014 15:11:36 CEST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: pepeto Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: * advance_name_by_player() and advance_name_for_player() are replaced by research_advance_rule_name() and research_advance_name_translation(), they take a _research_ pointer as first argument, and they are a part of the research.[ch] module ; * replaced calls to right function, including also advance_rule_name() and advance_name_translation() when there functions are usable ; * advance_name_researching() is suppressed ; * A_UNSET, A_FUTURE, A_UNKNOWN are renumbered over A_LAST (then A_LAST_REAL is not needed anymore) ; * _research_get(NULL)_ now returns _NULL_ without failed assertion. ___ File Attachments: --- Date: mer. 02 juil. 2014 15:11:36 CEST Name: research_advance_name.patch.gz Size: 15 ko By: pepeto http://gna.org/patch/download.php?file_id=21238 ___ Reply to this item at: http://gna.org/patch/?4888 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4726] [metaticket] Player research clean up
Update of patch #4726 (project freeciv): Depends on: = patch #4888 ___ Reply to this item at: http://gna.org/patch/?4726 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4889] Pathfinding refactoring
URL: http://gna.org/patch/?4889 Summary: Pathfinding refactoring Project: Freeciv Submitted by: pepeto Submitted on: mer. 02 juil. 2014 15:24:47 CEST Category: ai Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: pepeto Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: * can_invade() is now hard-coded ; * better handling of cached values when the tile is not known (notably at server side without omniscience) ; * better action handling, including attacks, diplomat actions and trade route establishing ; * cache values previously calculated in pf_is_ok_move_tile() ; * handle correctly the case we would want to ignore start tile (then the former behavior is restored) ; * handle correctly the case the unit is transported initially and would not return to transported (if it has orders) if returning at start tile. It speeds up the algorithm considerably. Amphibious moves are not perfectly handled, but it wasn't the case before (not a regression). ___ File Attachments: --- Date: mer. 02 juil. 2014 15:24:47 CEST Name: pf_refactoring.patch.gz Size: 11 ko By: pepeto http://gna.org/patch/download.php?file_id=21239 ___ Reply to this item at: http://gna.org/patch/?4889 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4736] Culture victory
Update of patch #4736 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4736 ___ 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
Update of patch #4857 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ 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 #22204] Qt 5 headers no longer found on Debian testing
Update of bug #22204 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #13: _I remain curious about 2.4: as of libqt4-dev 4:4.8.6+dfsg-2, it seems that the headers are still in /usr/include/qt4 (although moc is in /usr/lib/$MULTIARCH_TRIPLET/qt4/bin/moc): is this expected to remain the case for the length of 2.4 support,_ I expect it will remain the case. Qt 4 is in bug-fixes-only maintenance mode. I don't think Debian will wish to change it to much. (Note that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683036 is unresolved since its Qt 4 only) 2.4 version attached in case it becomes an issue or you think it should be supported anyway. Closing for now. (file #21241) ___ Additional Item Attachment: File name: 2.4_Qt_multiarch.patch Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?22204 ___ 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 #22260] tech_want never zeroed (not even initialized)
URL: http://gna.org/bugs/?22260 Summary: tech_want never zeroed (not even initialized) Project: Freeciv Submitted by: cazfi Submitted on: Wed 02 Jul 2014 09:45:17 PM EEST Category: ai Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: Maybe I'm blind but I can't find any place where ai player tech_wants are zeroed, or even initially initialized. First I thought that this must be a bug in my recent patches, but I can't find it from S2_5 either. Can this be intentional (lack of initialization definititely is not)? One would assume that those wants are zeroed every turn and not growing infinitely, but in theory it could be meant that old reasons for the tech want are not to be ignored. ___ Reply to this item at: http://gna.org/bugs/?22260 ___ 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 #4888] Move research advance name accessors
Follow-up Comment #1, patch #4888 (project freeciv): Patch update against current trunk. (file #21242) ___ Additional Item Attachment: File name: 0001-research_advance_rule_name.patch.gz Size:15 KB ___ Reply to this item at: http://gna.org/patch/?4888 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4890] Utility for iterating all requirements of an advance
URL: http://gna.org/patch/?4890 Summary: Utility for iterating all requirements of an advance Project: Freeciv Submitted by: pepeto Submitted on: mer. 02 juil. 2014 22:12:04 CEST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: pepeto Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Instead of making recursive functions, I propose a macro pair for iterating all requirements of an advance linearly. ___ File Attachments: --- Date: mer. 02 juil. 2014 22:12:04 CEST Name: 0003-advance_req_iter.patch Size: 5 ko By: pepeto http://gna.org/patch/download.php?file_id=21243 ___ Reply to this item at: http://gna.org/patch/?4890 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4891] techs_precalc_data() cleanup
Update of patch #4891 (project freeciv): Depends on: = patch #4890 ___ Reply to this item at: http://gna.org/patch/?4891 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4891] techs_precalc_data() cleanup
URL: http://gna.org/patch/?4891 Summary: techs_precalc_data() cleanup Project: Freeciv Submitted by: pepeto Submitted on: mer. 02 juil. 2014 22:16:31 CEST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: pepeto Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: * presumed tech costs are cached in advance structures ; * the client just takes the values the server sends to it, it doesn't calculate them. This patch requires a network capability string update. ___ File Attachments: --- Date: mer. 02 juil. 2014 22:16:31 CEST Name: 0004-techs_precalc_data.patch Size: 12 ko By: pepeto http://gna.org/patch/download.php?file_id=21244 ___ Reply to this item at: http://gna.org/patch/?4891 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4892] Move last harmless functions from tech.[ch] to research.[ch]
URL: http://gna.org/patch/?4892 Summary: Move last harmless functions from tech.[ch] to research.[ch] Project: Freeciv Submitted by: pepeto Submitted on: mer. 02 juil. 2014 22:21:06 CEST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: pepeto Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: The candidates are num_unknown_techs_for_goal(), total_bulbs_required_for_goal() and is_tech_a_req_for_goal(). New names are respectively research_goal_unknown_techs(), research_goal_bulbs_required() and research_goal_tech_req(). They takes a _research_ pointer as first argument. Additionally, the patch implements these function with a _NULL_ pointer. ___ File Attachments: --- Date: mer. 02 juil. 2014 22:21:06 CEST Name: 0005-Last-harmless-functions-tech.-ch-research.-ch.patch.gz Size: 8 ko By: pepeto http://gna.org/patch/download.php?file_id=21245 ___ Reply to this item at: http://gna.org/patch/?4892 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4726] [metaticket] Player research clean up
Update of patch #4726 (project freeciv): Depends on: = patch #4891 ___ Reply to this item at: http://gna.org/patch/?4726 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4726] [metaticket] Player research clean up
Update of patch #4726 (project freeciv): Depends on: = patch #4892 ___ Reply to this item at: http://gna.org/patch/?4726 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22258] Map topology and tileset incompatible is not an error
Follow-up Comment #1, bug #22258 (project freeciv): While I agree it is not an error, I do like getting the popup: it reminds me to change tilesets. Previously, I would often find myself doing things in the wrong topology, which may have unexpected results (gameplay is frequently surprising, and I spent some time trying to solve a non-problem in such a situation once while testing pathfinding). That said, the backtrace isn't either interesting or useful: this isn't a problem with the code, just with the user preferences. ___ Reply to this item at: http://gna.org/bugs/?22258 ___ 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 #4893] Make requirement types that check unit state possible
URL: http://gna.org/patch/?4893 Summary: Make requirement types that check unit state possible Project: Freeciv Submitted by: sveinung Submitted on: Wed 02 Jul 2014 08:47:39 PM UTC Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: sveinung Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Forward unit to is_req_active(), the requirement evaluation function. No new requirement type is added. The unit argument can't replace the unit type argument since some users don't have a specific unit in mind. Related to patch #4671. Posted separately since: - it can be used for many requirement types (like tile nativity, veteran level, hi, mp etc) - it adds noise to the requirement type patch - most of the effort when running git rebase is in it ___ File Attachments: --- Date: Wed 02 Jul 2014 08:47:39 PM UTC Name: 0001-Make-requirement-types-that-check-unit-state-possibl.patch Size: 42kB By: sveinung http://gna.org/patch/download.php?file_id=21246 ___ Reply to this item at: http://gna.org/patch/?4893 ___ 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 #22258] Map topology and tileset incompatible is not an error
Follow-up Comment #2, bug #22258 (project freeciv): While I agree it is not an error, I do like getting the popup: it reminds me to change tilesets. Note that my patch still preserves it. ___ Reply to this item at: http://gna.org/bugs/?22258 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4894] UnitState requirement type with the test TransportDependent
URL: http://gna.org/patch/?4894 Summary: UnitState requirement type with the test TransportDependent Project: Freeciv Submitted by: sveinung Submitted on: Wed 02 Jul 2014 08:51:11 PM UTC Category: None Priority: 5 - Normal Status: In Progress Privacy: Public Assigned to: sveinung Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Add the new requirement type UnitState. UnitState is for checking the properties of a unit's state. It is intended to be like CityTile, but for units. The first test, TransportDependent, checks if the unit can't exist outside a transport on the tile where it currently is located. It uses !can_unit_exist_at_tile() internally. I expect it to mostly be used with !present. The reason for the double negative is to make the documentation easier to write. The purpose of this test is to later use it to move the spy action's can't attack from terrain it can't exist on-rule to the ruleset. That will make it easier to move actions that don't have this requirement, like Establish Trade Route, to be controlled by action enablers. Note that the rule I wish to move is different from the rule about regular attacks. Regular attacks check if the tile the unit is located at is native or not. A spy action check if the unit can exist (outside a transport) on the tile it is located at. Alternative approaches: * Change the rule to require nativity to do a Spy action. Change this to test nativity in stead. Consequence: A spy ship in a land city would no longer be able to act from it (unless the restriction is removed). Consistent with normal attack. * Change the rule to ban actions when transported. Change this test to see if a unit is transported. Consequence: a land spy transported over land would have to exit its transport before it could act (unless the restriction is removed). ___ File Attachments: --- Date: Wed 02 Jul 2014 08:51:11 PM UTC Name: 0002-UnitState-requirement-type-with-the-test-TransportDe.patch Size: 13kB By: sveinung http://gna.org/patch/download.php?file_id=21247 ___ Reply to this item at: http://gna.org/patch/?4894 ___ 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 #4894] UnitState requirement type with the test TransportDependent
Update of patch #4894 (project freeciv): Depends on: = patch #4893 ___ Reply to this item at: http://gna.org/patch/?4894 ___ 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 #4894] UnitState requirement type with the test TransportDependent
Follow-up Comment #1, patch #4894 (project freeciv): Add a patch that applies on top of this meant for testing. It will enable sabotage or targeted sabotage in Experimental depending on if the Spy/Diplomat is on a ship or not. (file #21248) ___ Additional Item Attachment: File name: 0003-Ruleset-test.patchSize:1 KB ___ Reply to this item at: http://gna.org/patch/?4894 ___ 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 #4683] Make the Marines and AttFromNonNative flags action neutral
Update of patch #4683 (project freeciv): Status: In Progress = Wont Do Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4683 ___ 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 #22260] tech_want never zeroed (not even initialized)
Update of bug #22260 (project freeciv): Status:None = Ready For Test Planned Release: = 2.5.0, 2.6.0 ___ Follow-up Comment #1: Patches to enter testing. TRUNK has tech_want tied to AI type, in S2_5 all AI types share the same wants (I hope AI player ever modifies only his own wants, or multiple AI types can end modifying the same wants) (file #21249, file #21250) ___ Additional Item Attachment: File name: ClearTechWant.patchSize:1 KB File name: ClearTechWant-S2_5.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?22260 ___ 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 #22252] Giving techonologies in editor does not work
Follow-up Comment #4, bug #22252 (project freeciv): Fix works for me (applied over r25367): not only do I not have the feedback issue (editor UI showing red, needing to reconnect to refresh), but adding techs seems to be no longer restricted by dependencies. Do we care about tech holes or root_reqs for editor-added advances? ___ Reply to this item at: http://gna.org/bugs/?22252 ___ 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 #22252] Giving techonologies in editor does not work
Follow-up Comment #5, bug #22252 (project freeciv): Do we care about tech holes or root_reqs for editor-added advances? No! Editor is supposed to be part of the scenario creation, not limited by the other rules of the scenario (for example editor might just be the way self root-req'd tech is in the game at all) Also, testing high level tech effects on experimental ruleset would be royal pain if you had to give every recursive root-req on the way. ___ Reply to this item at: http://gna.org/bugs/?22252 ___ 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 #22252] Giving techonologies in editor does not work
Follow-up Comment #6, bug #22252 (project freeciv): adding techs seems to be no longer restricted by dependencies. I think it has never been the case in editor. ___ Reply to this item at: http://gna.org/bugs/?22252 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22260] tech_want never zeroed (not even initialized)
Update of bug #22260 (project freeciv): Status: Ready For Test = None Planned Release:2.5.0, 2.6.0 = ___ Follow-up Comment #2: Initialisation is done by trickery: dai_player_alloc() uses fc_calloc() to initialise the structure which contains the tech_wants array. fc_calloc() calls fc_real_calloc(), which then calls memset(ptr, 0, size). As a result, when the player is initialised, the structure discovers all the tech_want[] values to be zero. Making this explicit would probably be more developer friendly. That said, unless I'm missing something with my reading of the code, this means that tech wants grow infinitely, so may need bounds checking. I suspect that infinite growth (if bounded) is the correct strategy, as it means that if the AI has wanted something a little bit for a long time, it might choose that over something it happens to want a lot today (but didn't want before, and might not want later). ___ Reply to this item at: http://gna.org/bugs/?22260 ___ 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 #22260] tech_want never zeroed (not even initialized)
Follow-up Comment #3, bug #22260 (project freeciv): I believe I'm opposed to this patch: I don't think clearing the tech_want array every turn will result in better behaviour for the AI (because it will always pursue the most immediately interesting tech, rather than having the balancing effect mentioned in my last post (after investigation of tech_want usage). That said, I'm prepared to be convinced, and if the intent is to clear each turn, the attached patch does that well. ___ Reply to this item at: http://gna.org/bugs/?22260 ___ 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 #22252] Giving techonologies in editor does not work
Follow-up Comment #7, bug #22252 (project freeciv): Editor is supposed to be part of the scenario creation, not limited by the other rules of the scenario (for example editor might just be the way self root-req'd tech is in the game at all) In that case, my testing indicates this patch solves this issue. Also, testing high level tech effects on experimental ruleset would be royal pain if you had to give every recursive root-req on the way. In the event that we cared about depedencies, one solution to this problem would be to automatically add all the necessary root-reqs when a tech was added. I think [adding techs being restricted by dependencies] has never been the case in editor. I believe it has been like this since r25290, but don't think that needs a separate bug (this patch solves that as well). ___ Reply to this item at: http://gna.org/bugs/?22252 ___ 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 #22260] tech_want never zeroed (not even initialized)
Update of bug #22260 (project freeciv): Status:None = In Progress Planned Release: = 2.5.0, 2.6.0 ___ Follow-up Comment #4: Having it *never* to forget wants has its downsides - it may cause AI to research something that it needed early in the game but is never going to need again (good defense unit against opponents that are already obsolete) or is not important any more (problem already solved). Maybe optimal solution would be to deteriorate want a bit every turn so older wants would count less than current (want = want * 0.9). Another problem is that wants are not saved to savegame, so they start from zero after loading a saved game anyway. ___ Reply to this item at: http://gna.org/bugs/?22260 ___ 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 #4895] Remove threaded ai wrapper function twai_restart_phase()
URL: http://gna.org/patch/?4895 Summary: Remove threaded ai wrapper function twai_restart_phase() Project: Freeciv Submitted by: cazfi Submitted on: Thu 03 Jul 2014 01:56:49 AM EEST Category: ai Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Set twai_first_activities directly as the restart_phase callback. ___ File Attachments: --- Date: Thu 03 Jul 2014 01:56:49 AM EEST Name: DirectRestartPhase.patch Size: 1kB By: cazfi http://gna.org/patch/download.php?file_id=21251 ___ Reply to this item at: http://gna.org/patch/?4895 ___ 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 #22260] tech_want never zeroed (not even initialized)
Follow-up Comment #5, bug #22260 (project freeciv): Per-turn depreciation sounds sensible to me. if the AI continues to want something at a moderate level for a long time, it still ends up being wanted a lot, but if something was wanted a lot for a short time early in the game, and not wanted anymore, it stops caring. And indeed, either the wants should be stored in savegame, or they should be zeroed each turn. Not saving them and not zeroing them means that recovery from a savegame may not result in the same game as continued progression from the point at which the game was saved. Considering this factor, as much as I suspect the AI may benefit from tracking wants over multiple turns, it's probably safer to apply this patch for now, and have a separate trunk-only patch that does want depreciation and carry-over (with savegame handling). ___ Reply to this item at: http://gna.org/bugs/?22260 ___ 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 #22258] Map topology and tileset incompatible is not an error
Follow-up Comment #3, bug #22258 (project freeciv): My apologies: I didn't understand enough, and hadn't tested. Thank you for the clarification. ___ Reply to this item at: http://gna.org/bugs/?22258 ___ 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 #4896] Document AI callback API changes in 2.6
URL: http://gna.org/patch/?4896 Summary: Document AI callback API changes in 2.6 Project: Freeciv Submitted by: cazfi Submitted on: Thu 03 Jul 2014 02:07:53 AM EEST Category: docs Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Add 2.6 AI callback API changes missing from the README.AI_modules listing. ___ File Attachments: --- Date: Thu 03 Jul 2014 02:07:53 AM EEST Name: AICBAPIDoc.patch Size: 650B By: cazfi http://gna.org/patch/download.php?file_id=21252 ___ Reply to this item at: http://gna.org/patch/?4896 ___ 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 #4893] Make requirement types that check unit state possible
Follow-up Comment #1, patch #4893 (project freeciv): This looks like it is only an API change. Would it make sense to add a preface in is_req_active that sets target_unittype in the event that target_unit != NULL target_unittype == NULL? If not, perhaps at least a sanity assertion that unit_type(target_unit) == target_unittype? ___ Reply to this item at: http://gna.org/patch/?4893 ___ 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 #4897] Autosettlers not to assume GlobalWarming and NuclearWinter flags
URL: http://gna.org/patch/?4897 Summary: Autosettlers not to assume GlobalWarming and NuclearWinter flags Project: Freeciv Submitted by: cazfi Submitted on: Thu 03 Jul 2014 02:22:43 AM EEST Category: ai Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Value cleaning of the pollution and fallout as eco disaster prevention only if they really are cause for one. ___ File Attachments: --- Date: Thu 03 Jul 2014 02:22:43 AM EEST Name: AutosettlersWarmFrost.patch Size: 2kB By: cazfi http://gna.org/patch/download.php?file_id=21253 ___ Reply to this item at: http://gna.org/patch/?4897 ___ 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 #4847] Veterancy level Superb to alien ruleset
Update of patch #4847 (project freeciv): Summary: Veterancy level Super to alien ruleset = Veterancy level Superb to alien ruleset ___ Follow-up Comment #2: - Actually call the new level Superb (file #21254) ___ Additional Item Attachment: File name: GladiatorsSuperbLvl-3.patchSize:3 KB ___ Reply to this item at: http://gna.org/patch/?4847 ___ 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 #4894] UnitState requirement type with the test TransportDependent
Follow-up Comment #2, patch #4894 (project freeciv): To confirm, the intent is to use the same nativity logic as is used for attacks, so: If the tile's terrain is native, the tile is native If the tile contains nativity-granting extras, the tile is native. If the tile contains a city then: () If the unit has UCF_BUILD_ANYWHERE, then the city tile is native () If the tile or an adjacent tile is native, then the city tile is native () If the city belongs to a city channel, then the city tile is native And in all cases above, tile nativity == !TransportDependent, so a spyship (without UCF_BUILD_ANYWHERE) on a trailer (cargo: spyship's class), in a landlocked city would be unable to act? On double negatives: I don't think the internal representation having many negatives matters, so long as the expression doesn't typically require thinking in double negatives for ruleset authors. If there is a reason to prefer present requirements to !present requirements, use of NativeLocation would mean much the same. On banning actions when transported, rather than when on non-native: if there is a UnitState requirement, having an IsTransported state may be potentially useful anyway, even if not required to implement this specific abstraction. ___ Reply to this item at: http://gna.org/patch/?4894 ___ 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 #4683] Make the Marines and AttFromNonNative flags action neutral
Follow-up Comment #2, patch #4683 (project freeciv): Why not do this? It seems a logical accompaniment to patch #4894 to allow ruleset authors to express that a specific action can be performed by a transport-dependent unit only if they have one of the Marines or AttFromNonNative flags set . ___ Reply to this item at: http://gna.org/patch/?4683 ___ 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 #3539] Scorelog: new tags and details
Update of patch #3539 (project freeciv): Planned Release: 2.5.0 = 2.5.0-beta1 ___ Follow-up Comment #8: If we're going to apply this, we should probably do so before 2.5.0-beta1, so we don't have multiple 2.5 scorelog formats around. ___ Reply to this item at: http://gna.org/patch/?3539 ___ 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 #4877] Obsolete NoBonus road move mode
Follow-up Comment #1, patch #4877 (project freeciv): - Handle autosettlers This part was lacking from the original patch since there was no autosettlers code to convert - the functionality has never existed. I'll open separate ticket to fix that in S2_5. (file #21255) ___ Additional Item Attachment: File name: RoadNoBonusRm-2.patch Size:14 KB ___ Reply to this item at: http://gna.org/patch/?4877 ___ 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 #2984] Make AI plan research to preserve its wonders and obsolete others'
Follow-up Comment #4, patch #2984 (project freeciv): We seem to have sat on this patch for 2 years. Still want it for 2.5.0? ___ Reply to this item at: http://gna.org/patch/?2984 ___ 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 #22262] Autosettlers ignore NoBonus road move mode
URL: http://gna.org/bugs/?22262 Summary: Autosettlers ignore NoBonus road move mode Project: Freeciv Submitted by: cazfi Submitted on: Thu 03 Jul 2014 02:49:28 AM EEST Category: ai Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: 2.5.0 ___ Details: As noticed in patch #4877, autosettlers ignore NoBonus move mode of the roads, assuming that such a road would provide what ever move_cost indicates (typically infinite movement). Fix for S2_5 attached (TRUNK will get fixed with patch #4877, if accepted) ___ File Attachments: --- Date: Thu 03 Jul 2014 02:49:28 AM EEST Name: AutosettlerNoBonusRoad.patch Size: 3kB By: cazfi http://gna.org/bugs/download.php?file_id=21256 ___ Reply to this item at: http://gna.org/bugs/?22262 ___ 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: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ 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 #4889] Pathfinding refactoring
Follow-up Comment #1, patch #4889 (project freeciv): In pf_get_action(), could parentheses be added to the assignment of non_allied_city_tile? I found it surprising to read (also, when assigning as the first call in a function, I prefer assigning in declaration, but not doing that isn't unclear). ___ Reply to this item at: http://gna.org/patch/?4889 ___ 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 #4879] Mark redundant buildings in sdl-client
Update of patch #4879 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4879 ___ 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 #2984] Make AI plan research to preserve its wonders and obsolete others'
Follow-up Comment #5, patch #2984 (project freeciv): Needs rebasing for trunk: ai-dai changes, tech_want move, TECH_LOG redefinition, and obsolete_by moving to a requirement vector. Needs much less rebasing for S2_5 (just ai-dai: rename ai_modify_for_wonders() to dai_modify_for_wonders(), and re-add the call above the dai_select_tech() call (as hunk #3 fails to find ai_select_tech, so gets rejected)). ___ Reply to this item at: http://gna.org/patch/?2984 ___ 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 #4893] Make requirement types that check unit state possible
Follow-up Comment #2, patch #4893 (project freeciv): _This looks like it is only an API change._ Correct. _Would it make sense to add a preface in is_req_active that sets target_unittype in the event that target_unit != NULL target_unittype == NULL?_ Great idea. Added. (file #21257) ___ Additional Item Attachment: File name: 0001-Make-requirement-types-that-check-unit-state-possibl.patch Size:42 KB ___ Reply to this item at: http://gna.org/patch/?4893 ___ 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 #4886] Network protocol: Send each effect rule in a single packet.
Update of patch #4886 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4886 ___ 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 #4898] Enable ferry stat checking on debug builds
URL: http://gna.org/patch/?4898 Summary: Enable ferry stat checking on debug builds Project: Freeciv Submitted by: cazfi Submitted on: Thu 03 Jul 2014 04:31:56 AM EEST Category: ai Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: With recent fixes to ferry stats they should now generally work, and not spam a lot of error messages when checking is enabled. So, enable ferry stat checking in debug builds. ___ File Attachments: --- Date: Thu 03 Jul 2014 04:31:56 AM EEST Name: DebugLogFerryStats.patch Size: 961B By: cazfi http://gna.org/patch/download.php?file_id=21258 ___ Reply to this item at: http://gna.org/patch/?4898 ___ 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 #4885] Revised logic for AI improvement consideration and improvement redundancy
Update of patch #4885 (project freeciv): Status:Works For Me = In Progress ___ Follow-up Comment #1: Seems that this needs better logic for EFT_DEFEND_BONUS, as otherwise Barracks III becomes redundant due to Airport. Looking at the relevant AI code, it seems the AI already thinks this is the case, so perhaps it makes sense to sort the AI first, and then use the same logic the AI will use for redundancy. I presume similar guidance ought apply for EFT_UNIT_RECOVER, EFT_VETERAN_BUILD, EFT_VETERAN_COMBAT, EFT_HP_REGEN, and EFT_UPKEEP_FACTOR, in that an improvement providing any of these effects should only be considered redundant if it fails to provide a bonus for any unit (considering class, type, and flags). If I've missed something here, please correct me, as otherwise I'll be using this list as the set for which unit checking is required. ___ Reply to this item at: http://gna.org/patch/?4885 ___ 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 #4842] Scenario earth-160x90: Updated starting positions
Follow-up Comment #1, patch #4842 (project freeciv): Reduced to the minimum the settings forced by the scenario, so the player can decide as much as possible. Changeable settings are changeable even if the scenario gives them default different from freeciv's internal default. So this is not giving player more power. + Using the usual defaults avoids unexpected settings from surprising the player mid-game (though server lists settigs changed from their internal default values) - Using defaults removes some of the special flavor of the scenario That's not to say I oppose the changes. Just wanted to make clear what they mean. ___ Reply to this item at: http://gna.org/patch/?4842 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
