[Freeciv-Dev] [patch #3897] Respect slow_invasions in pathfinding
URL: http://gna.org/patch/?3897 Summary: Respect slow_invasions in pathfinding Project: Freeciv Submitted by: persia Submitted on: Mon 06 May 2013 06:14:50 PM JST Category: ai Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: Improved slow_invasions handling for pathfinding extracted from prior revision of patch #3886 (upon which this depends - not functionally, but syntactially (the indentation and placement of the FC_INFINITY handling changed in that patch)). This implementation is far simpler and contains conditional logic to prevent the prior reported hang (moves_left%move_rate may be 0, which isn't a good value to use for cost, unless provided by map_move_cost()). Also included is another conditional in igter_move_unit() to correctly penalise UTYF_IGTER units when slow_invasions is configured. ___ File Attachments: --- Date: Mon 06 May 2013 06:14:50 PM JST Name: respect-slow_invasions.patch Size: 3kB By: persia http://gna.org/patch/download.php?file_id=17898 ___ Reply to this item at: http://gna.org/patch/?3897 ___ 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 #3856] Add nativity check for find_closest_city()
Follow-up Comment #4, patch #3856 (project freeciv): Backport patches for S2_4, S2_5 attached. From manual inspection they appear to be only offset changes, but I had some rejects trying to apply the originally applied patch to these branches (it still applies to trunk with offsets). Also attached is the (tiny) patch for S2_3 that corrects the value provided for only_ocean. As previously discussed, I don't think it worth applying this: while it may improve the AI, the total implications deserve playtesting, and an elder stable branch is not the place for that (so I shan't be opening a separate ticket for it, nor do I anticipate application). (file #17899, file #17900, file #17901) ___ Additional Item Attachment: File name: native-find-closest-city.S2_4.patch Size:9 KB File name: restrict-target-cities-for-umt-sea.S2_3.patch Size:0 KB File name: native-find-closest-city.S2_5.patch Size:9 KB ___ Reply to this item at: http://gna.org/patch/?3856 ___ 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 #16383] Option to forbid RiverNative units moving diagonally / cross-continent
Follow-up Comment #23, bug #16383 (project freeciv): Grr. I need a better way to test pathfinding: things just seeming to work don't seem to be enough. The attached patch actually clears the roads for the virtual tile in tile_move_cost_ptrs(), thereby testing the correct condition to determine if a road is required. I'm not certain this is sufficient: it may be interesting to consider special handling for the case where two cardinally adjacent tiles are both native because of different roads (or one has a base): for !UCF_TERRAIN_SPEED units (e.g. Triremes), this makes no difference, but for other units, there may be wide variability in the move cost associated with such a move when it should perhaps always cost SINGLE_MOVE or MOVE_COST_IGTER. (file #17902) ___ Additional Item Attachment: File name: CardinalRiverMoveRestrictions-2+persia2.patch Size:8 KB ___ Reply to this item at: http://gna.org/bugs/?16383 ___ 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 #3829] Allow compatible roads
Follow-up Comment #26, patch #3829 (project freeciv): That's the easiest way to implement 12, and what was present already in the patch. Ruleset sanity checking added to ensure that road integration is commutative. For 3, I'll stick with move_cost being determined by the cost of the fastest integrating road on the destination, as it is already implemented that way. This means the following rules apply for move costs (ignoring nativity): a) If there are no roads, move_cost is determined by the destination. b) If there is a road at the destination, the move cost of this road may be used iff there is an integrating road at the source. This replicates current behaviour with comment-only ruleset changes, and allows ruleset authors to choose to allow charging Railroad cost for moves from Road if they desire by causing the roads to integrate (changing the behaviour of condition (b) above). Very ambitious ruleset authors could even define a null road with RMM_NO_BONUS, use lua to place it everywhere on the map, and have it integrate with everything, so that the destination tile always controlled movement entirely. (the RMM_NO_BONUS conditional was moved for this revision of the patch to enable just this (and avoid asserts when a bonus road integrates with a no bonus road: apparently some of (4))). I've been changing tile_move_cost_ptrs() in many places lately: for my convenience, the updated patch applies over patch #3886, patch #3897, and a rebased bug #16383, as I consider all those issues to be more important than this (or at least more bug-like and less feature-like): I'm happy to rearrange the order if that is preferred for application to trunk. Note that bug #16383 does not need changes to unit_move_to_tile_test() for road integration unless there is a decision to impose a static cost for moves between tiles made native by differing roads, in which case integrated roads should not be considered differing roads. (file #17903) ___ Additional Item Attachment: File name: allow-compatible-roads+rssanity.patch Size:18 KB ___ Reply to this item at: http://gna.org/patch/?3829 ___ 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 #3830] Change shore bombardment model to use nativity rather than UMT_*
Follow-up Comment #7, patch #3830 (project freeciv):
Not so far as I can tell: the function was originally put in combat.c in
largely the current form (using !is_ocean_tile() is new, but the old
implementation was essentially the same check) in SVN revision 3369 (at which
point HELI_MOVING and is_heli_unit() were still present in common/unit.c)
applying specifically to sailing units attacking ground units: everyone else
keeps their firepower. If a mistake was made in the conflation of AIR_MOVING
and HELI_MOVING, it doesn't appear to have happened for this specific
conditional (land bombardment).
The logic described in my last comment would penalise sailing units and not
penalise helicopters for units with classical nativity, rather than not
penalising either (as in the implementation as of SVN revision 3369 or the
most recently attached patch).
The argument for changing the logic is that the Battleship cannot enter the
tile in which the Helicopter resides (so should be penalised), but the
Helicopter is under no such restriction (so should not be penalised). The
argument for not changing the logic is that as long as the two units are both
native to *either* the attacking or defending square, they will meet there to
fight, and do so without penalty. I still prefer the first argument, but I've
also still not reached absolute confidence. The original logic may also have
included assumptions about the AttackNonNative status of the defender: perhaps
the idea is that the defender can't respond because there is no expectation of
a means to attack the attacker: in such a case, perhaps the nested conditional
should be about whether the defender can attack the attacker, rather than just
whether it could exist on the attacker's tile.
That said, re-reading comment #4, was that a suggestion that the condition
be:
if (!is_native_tile(unit_type(attacker), unit_tile(defender)
is_native_tile(unit_type(defender), unit_tile(defender)) {
att_fp = 1;
def_fp =1;
}
?
If so, I don't like this at all because of the disadvantages this causes
for air units as compared to the is_ground_unit() test. Testing that the
defender is non-native to attacking tile gives a discriminator that happens to
have the same result for classical nativity and can perhaps be explained in
terms of unit capabilities, although I don't have any objection to a test that
checks to ensure the defender is both non-native to the attacking tile and
native to the defending tile, if that seems like it might have a better
explanation.
___
Reply to this item at:
http://gna.org/patch/?3830
___
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 #3858] Drop support for pre-2.0 savegame loading
Update of patch #3858 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3858 ___ 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 #20538] Numerous assertion failures when loading an old savegame
Follow-up Comment #4, bug #20538 (project freeciv): 2.4 / experimental ruleset is *not* affected as nationality as new feature in 2.4 is handled by 2.3 to 2.4 savegame format compatibility function. So, the problem is only rulesets that have no nationality in 2.4, but enable it in later versions, such as classic ruleset in 2.5 ___ Reply to this item at: http://gna.org/bugs/?20538 ___ 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 #20789] Conquering unit is not allied to current city owner
URL: http://gna.org/bugs/?20789 Summary: Conquering unit is not allied to current city owner Project: Freeciv Submitted by: cazfi Submitted on: Tue 07 May 2013 02:04:45 AM EEST Category: None 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: When trying to test situation described in bug #20705, turned out that unit transporting others cannot conquer a city, but move is blocked with message A transported unit is not allied to all units or city on target tile. ___ Reply to this item at: http://gna.org/bugs/?20789 ___ 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 #20790] Shared vision leaves loaded units as ghosts outside the transport
URL: http://gna.org/bugs/?20790 Summary: Shared vision leaves loaded units as ghosts outside the transport Project: Freeciv Submitted by: cazfi Submitted on: Tue 07 May 2013 02:15:22 AM EEST Category: None 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: Got ghost units in one of the clients trying to produce bug #20705 situation. Ruleset is modified to have land transport. Player A has such an transport and a couple of land units in one tile. Player B sees this directly, player C through shared vision from B. Players A C are allied (don't know if that matters). Player A loads land units to transport - as they are already in the same tile with transport, they don't move. Now player C still sees those units outside transport. Even if the transport moves away, these ghost units remain in C's client. ___ Reply to this item at: http://gna.org/bugs/?20790 ___ 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 #20792] in same_pos() [../../../../common/map.c::887]: assertion 'tile1 != ((void *)0) tile2 != ((void *)0)' failed
URL: http://gna.org/bugs/?20792 Summary: in same_pos() [../../../../common/map.c::887]: assertion 'tile1 != ((void *)0) tile2 != ((void *)0)' failed Project: Freeciv Submitted by: None Submitted on: Tue 07 May 2013 05:14:59 AM UTC Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: nighto...@cox.net Open/Closed: Open Release: 2.3 Discussion Lock: Any Operating System: Microsoft Windows Planned Release: ___ Details: when i get this error freeciv crashes ___ File Attachments: --- Date: Tue 07 May 2013 05:14:59 AM UTC Name: freeciv-server.RPT Size: 1kB By: None http://gna.org/bugs/download.php?file_id=17906 ___ Reply to this item at: http://gna.org/bugs/?20792 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
