[Freeciv-Dev] [patch #3837] Unify UCF_ATT*NON_NATIVE and relevant type flags
Follow-up Comment #6, patch #3837 (project freeciv): S2_4: Umh, but before 2.5 city tile always had road, no matter the terrain. ___ Reply to this item at: http://gna.org/patch/?3837 ___ 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 #3842] Ensure use of boolean TRUE/FALSE in reqs specifications
Update of patch #3842 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi Planned Release: = 2.5.0 ___ Reply to this item at: http://gna.org/patch/?3842 ___ 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 #3826] Allow bases on city tiles
Follow-up Comment #5, patch #3826 (project freeciv): Then I noticed how roads and bases are handled differently when new city is founded. Existing roads remain, but bases are removed unless city owner would be able to build new such base. I think you should be removing only those bases (and roads, for consistency) that cannot exist in city, regardless if player is able to build them. This might even already happen (for both or roads only) outside this code. ___ Reply to this item at: http://gna.org/patch/?3826 ___ 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 #20744] Recursive wipe_unit() saving drowning units from calling wipe_unit()
URL: http://gna.org/bugs/?20744 Summary: Recursive wipe_unit() saving drowning units from calling wipe_unit() Project: Freeciv Submitted by: cazfi Submitted on: Fri 19 Apr 2013 11:52:39 AM EEST Category: general 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.4.0, 2.5.0, 2.6.0 ___ Details: Haven't tried to setup test case, but when reading wipe_unit() refactoring from patch #3804 (use unit lists to store drowning units instead of just having count of them and then rechecking which units they are) it occurred to me that recursively called wipe_unit() might handle those units calling wipe_unit() has counted to its 'drowning' counter, meaning that the counter value is not correct (in practice: counter instructs to wipe units as drowning ones even after all have been saved) Using the lists the way refactoring part of patch #3804 does avoids such problems. ___ Reply to this item at: http://gna.org/bugs/?20744 ___ 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 #3804] Enabling restricted air transport
Follow-up Comment #24, patch #3804 (project freeciv): In the end I split wipe_unit() refactoring to ticket of its own as it occurred to me that it's bugfix required to S2_4 too: bug #20744 ___ Reply to this item at: http://gna.org/patch/?3804 ___ 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 #20744] Recursive wipe_unit() saving drowning units from calling wipe_unit()
Follow-up Comment #1, bug #20744 (project freeciv): - S2_4 version of the patch (file #17768) ___ Additional Item Attachment: File name: WipeUnitLists-S2_4.patch Size:8 KB ___ Reply to this item at: http://gna.org/bugs/?20744 ___ 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 #20744] Recursive wipe_unit() saving drowning units from calling wipe_unit()
Follow-up Comment #2, bug #20744 (project freeciv): try_to_save_unit() doesn't need to take the helpless argument for S2_4, as this only exists as a base for future extension, but leaving it there should cause no problem and it may be helpful to have the S2_4 and S2_5 functions be identical to reduce rework if an issue is discovered. ___ Reply to this item at: http://gna.org/bugs/?20744 ___ 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 #3726] Booleanize all save functions for savegame v2
Update of patch #3726 (project freeciv): Assigned to: cazfi = None ___ Reply to this item at: http://gna.org/patch/?3726 ___ 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 #3837] Unify UCF_ATT*NON_NATIVE and relevant type flags
Follow-up Comment #7, patch #3837 (project freeciv): Then I'm just confused, and this should work for S2_4. (file #17769) ___ Additional Item Attachment: File name: S2_4-use-can_attack-foo-functions-more.patch Size:2 KB ___ Reply to this item at: http://gna.org/patch/?3837 ___ 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 #3502] New /topic command
Update of patch #3502 (project freeciv): Status:None = Wont Do Assigned to:None = cazfi Open/Closed:Open = Closed ___ Follow-up Comment #4: Current metaserver development version has already dropped topic, and uses metamessage in main page too. Main metaserver at meta.freeciv.org just hasn't been updated yet. ___ Reply to this item at: http://gna.org/patch/?3502 ___ 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 #8, patch #3829 (project freeciv): Now I also know what I failed to see last week - and still do. While road is added to the list, it's not added to the bitvector. As bitvetor is currently used only for transmitting information to client side, I assume everything to work on server side, but client side goto not to consider road integrated to itself. ___ 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] [task #7678] Windows packages for 2.4.0-beta2
URL: http://gna.org/task/?7678 Summary: Windows packages for 2.4.0-beta2 Project: Freeciv Submitted by: cazfi Submitted on: Fri 19 Apr 2013 05:26:37 PM EEST Should Start On: Fri 19 Apr 2013 12:00:00 AM EEST Should be Finished on: Fri 19 Apr 2013 12:00:00 AM EEST Category: None Priority: 5 - Normal Status: None Privacy: Public Percent Complete: 0% Assigned to: None Open/Closed: Open Discussion Lock: Any Effort: 0.00 Planned Release: ___ Details: Opening ticket for beta2 windows package feature discussion to continue from similar beta1 ticket: task 7599 About MagickWand: I have managed to build some versions of it for crosser, but most versions are broken one way or the other. At the moment 6.8.1-10 is the latest version that compiles for crosser, so I would try with that if I were to attempt MagickWand inclusion to official build environment. ___ Reply to this item at: http://gna.org/task/?7678 ___ 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 #20745] City size 1, citizen count 2 with concurrent movement
URL: http://gna.org/bugs/?20745 Summary: City size 1, citizen count 2 with concurrent movement Project: Freeciv Submitted by: cazfi Submitted on: Fri 19 Apr 2013 08:58:03 PM EEST Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: S2_4 r22728 Discussion Lock: Any Operating System: None Planned Release: ___ Details: bug #20634 is very much always reproduced when running autogame with alternating movement, but now I got one case with concurrent movement. It's reproducible, with somework. It happens with S2_4 alien ruleset. Available with freeciv-modpack from URL http://www.cazfi.net/freeciv/modinst/2.4/alien-2.4-3.modpack It originally happened when map generation with one mapseed was failed, and second one was picked. As even the failed attempt changes main random state, that must be emulated. Attached patch RetryMapseed.patch sets correct mapseed for the second map generation attempt after first one (from autogame .serv-file) has failed. ___ File Attachments: --- Date: Fri 19 Apr 2013 08:58:03 PM EEST Name: RetryMapseed.patch Size: 968B By: cazfi http://gna.org/bugs/download.php?file_id=17770 --- Date: Fri 19 Apr 2013 08:58:03 PM EEST Name: aliencitcount.serv Size: 305B By: cazfi http://gna.org/bugs/download.php?file_id=17771 ___ Reply to this item at: http://gna.org/bugs/?20745 ___ 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 #9, patch #3829 (project freeciv): This is why the road is also self-added to the integrators road_type_list in packhand.c:handle_rulesets_ready() (as part of the same iteration used to process hiders): by not forcing self in the bitvector, the implementation is entirely separated from the representation. An updated patch is attached that addresses the ordering and uniqueness of integrators. I didn't like any of the ways I ended up trying to implement the mechanism discussed in my last post, so ended up adding comments and using the unique and sort list operators on the list. (file #17772) ___ Additional Item Attachment: File name: allow-compatible-roads+sort-u.patch Size:15 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 #3826] Allow bases on city tiles
Follow-up Comment #6, patch #3826 (project freeciv): Updated patch adjusts base destruction to not be player-specific (so that players may build cities on city-compatible bases they could not build themselves, and keep the base), as well as removing any city-incompatible roads when founding a city. During the production of this patch, I noticed what looks like a duplicate call to tile_remove_base() in tile.c:tile_change_terrain(): is this a bug, or is there some reason to double-remove the base here because of the nature of fc_funcs that I don't understand? (note that destroy_base() calls tile_remove_base() itself if used.) (file #17773) ___ Additional Item Attachment: File name: allow-bases-in-cities+road-removal.patch Size:36 KB ___ Reply to this item at: http://gna.org/patch/?3826 ___ 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 #3826] Allow bases on city tiles
Follow-up Comment #7, patch #3826 (project freeciv): I don't think there's any actual need for double removal, but otherwise destroy_base() would need to either be passed boolean parameter telling if caller is removing base itself, or it would need to be able to deduct the need itself. Some callers other than tile_change_terrain() need it. Or maybe tile_change_terrain() could remove base only if callback is not set, and to rely on *any* callback ever assigned there to take care of the removal. ___ Reply to this item at: http://gna.org/patch/?3826 ___ 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 #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)
Update of bug #20682 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20682 ___ 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 #3850] Fix gameloss_style comment gettext warnings
Update of patch #3850 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3850 ___ 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 #18517] unable to drag items in Target Worklist to reorder.
Follow-up Comment #16, bug #18517 (project freeciv): I just tested this with freeciv trunk built against crosser-0.10.1, and couldn't reproduce. Maybe gtk+ has been fixed? Version in crosser-0.10.1 is 2.24.14. Latest gtk+2 bundle for windows has 2.24.10. Our earlier testing indicates that bug was present in as late version as 2.24.4, but we don't have any data points after that. I'll try to make crosser build that uses 2.24.10 for testing. ___ Reply to this item at: http://gna.org/bugs/?18517 ___ 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 #7678] Windows packages for 2.4.0-beta2
Follow-up Comment #1, task #7678 (project freeciv): bug #18517 is worth following too - it may make sense to start using latest gtk+ bundle in build environment. ___ Reply to this item at: http://gna.org/task/?7678 ___ 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 #3854] Consider nativity for is_square_threatened()
URL: http://gna.org/patch/?3854 Summary: Consider nativity for is_square_threatened() Project: Freeciv Submitted by: persia Submitted on: Sat 20 Apr 2013 06:32:27 AM JST Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: The current implementation of is_square_threatened() relies on a function called is_ground_threat() with embedded nativity assumptions (using is_ground_unit()). The attached patch removes the is_ground_threat() function (which has no other callers), replacing it with similar logic inside the is_square_threatened conditional. The replacement logic is then extended in three ways: 1) The tile is not considered threatened if the potentially threatening unit is not considered an attack unit (attack strength == 0). There is no value in fearing a unit that cannot cause damage. 2) The tile is not considered threatened if the potentially threatening unit is either not native to the tile unless that unit can attack non-native tiles AND there is adjacent native terrain. There is no value in fearing a unit that cannot attack the tile in question. 3) The tile is not considered threatened by a diplomat unless that diplomat is able to pass the nativity test described in (2) above. There is no value in fearing a diplomat that cannot attack the tile in question. In autogame testing, this change showed behavioural differences: for the classic and experimental rulesets, autosettlers appeared less likely to choose to improve coastal tiles. More generally, it seems autosettlers are more accurately risk-averse and last longer before dying. ___ File Attachments: --- Date: Sat 20 Apr 2013 06:32:27 AM JST Name: square-threatened-consolidation.patch Size: 3kB By: persia http://gna.org/patch/download.php?file_id=17774 ___ Reply to this item at: http://gna.org/patch/?3854 ___ 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 #20587] Autosettlers only consider enemy land units dangerous
Follow-up Comment #1, bug #20587 (project freeciv): Oops. Found this after posting patch #3854 Although closely related, I'm not sure this ticket is entirely closed by that patch though: while it does remove the land restriction, it does not include the deeper analysis that might be useful to determine if a given tile is truly dangerous, nor even look beyond the immediate horizon (2 tiles away). ___ Reply to this item at: http://gna.org/bugs/?20587 ___ 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 #3854] Consider nativity for is_square_threatened()
Update of patch #3854 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi Planned Release: = 2.5.0, 2.6.0 ___ Reply to this item at: http://gna.org/patch/?3854 ___ 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 #3854] Consider nativity for is_square_threatened()
Follow-up Comment #1, patch #3854 (project freeciv): This is clearly an improvement over current code, so this should go in for S2_5. I have some vague plans to make it use pf_map to see what units can threaten autosettler - that would correctly consider units that can move (because they are fast (most sea units), or can use roads etc) more than 2 tiles distance currently checked, could account for our own units blocking the way of attack (it's safe to work behind line of defense), would consider corner case of autosettler working next to enemy city on non-native terrain for attacking unit... That's 2.6 stuff, though. ___ Reply to this item at: http://gna.org/patch/?3854 ___ 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 #4, patch #3830 (project freeciv): That said, I'm not sure I understand the specific meaning of this check in a nativity-based environment if it doesn't mean that units have a hard time attacking/defending when they are not native to the target tile. Took me a while too since I followed logic of your patch. It makes no sense that defender (land unit) must be non-native to attacker tile (sea). But it makes sense that defender (land) unit must be native to its own tile (land). Original logic: It's shore bombardment only if sea unit attacks against land unit on land tile. ___ 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 #3830] Change shore bombardment model to use nativity rather than UMT_*
Follow-up Comment #5, patch #3830 (project freeciv):
I understand why an attacking unit might get reduced firepower when attacking
a non-native tile. I don't understand why this reduction fails to apply
depending on the defending unit: I would expect it to apply in all cases, as
it ought indicate remote bombardment. Is the intent to allow the greater
firepower when the defender is weakened by being non-native?
Separately, I understand why a defending unit might get reduced firepower when
defending against an attack from a non-native tile if the attacking unit is
not native to the defending tile, as this also indicates remote bombardment.
I'm not sure that a unit native to both tiles should be so penalised, as it
can defend directly.
For identity with past behaviour, the most recently posted patch is correct.
Given more thought, I think attacker firepower should be reduced
unconditionally if the defending tile is non-native, as the attacker cannot
engage in typical tactics to overtake the tile, and that defender firepower
should be reduced if the attacker is non-native to the attacked tile AND the
defender is non-native to the attacking tile. Like so:
if (!is_native_tile(unit_type(attacker), unit_tile(defender))) {
*att_fp = 1;
if (!can_exist_at_tile(unit_type(defender), unit_tile(attacker))) {
*def_fp = 1;
}
}
This behaves the same as the original code for air-land, air-sea,
air-air, sea-land, sea-sea, land-air, and land-land. This behaves
differently in the sea-air and land-sea cases. For sea-air (e.g.
Battleship attacking Helicopter), the firepower of the attacker is reduced,
but the firepower of the defender is not. For land-sea (e.g. AttackNonNative
Howitzer vs. Battleship), the firepower of both units is reduced.
Note that the most recently posted patch matches the land-sea behaviour
described immediately above, but does not match the sea-air behaviour,
instead not reducing the firepower of either unit. As much as I currently
think the logic in this post is correct, I've had that feeling about other
logic previously, so would appreciate more discussion before posting another
full patch.
___
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 #3855] INSTALL gtk3-client section
URL: http://gna.org/patch/?3855 Summary: INSTALL gtk3-client section Project: Freeciv Submitted by: cazfi Submitted on: Sat 20 Apr 2013 02:52:35 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.4.0, 2.5.0 ___ Details: Fixes to Gtk 3.0 -client section of INSTALL - Download URLs for some packages were broken (version a.b.c from subdir a.b-1) - Gdk-Pixbuf was documented to be part of Gtk+. It's separate now - Download URLs for some packages were for too old versions - updated all of them to point to currently latest versions - URLs of all gnome packages to point to master site, not to any mirror ___ File Attachments: --- Date: Sat 20 Apr 2013 02:52:35 AM EEST Name: INSTALLgtk3-S2_4.patch Size: 3kB By: cazfi http://gna.org/patch/download.php?file_id=17775 --- Date: Sat 20 Apr 2013 02:52:35 AM EEST Name: INSTALLgtk3.patch Size: 3kB By: cazfi http://gna.org/patch/download.php?file_id=17776 ___ Reply to this item at: http://gna.org/patch/?3855 ___ 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()
URL: http://gna.org/patch/?3856 Summary: Add nativity check for find_closest_city() Project: Freeciv Submitted by: persia Submitted on: Sat 20 Apr 2013 08:55:07 AM JST Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: The find_closest_city() function takes an is_ocean parameter that is used for two different purposes: to identify nativity given certain assumptions, and to find coastal/border cities. The attached patch extends this function to take a unit_class argument used for nativity identification, and replaces the use of is_ocean in three places: 1) When the AI has a defending unit with nothing to do (e.g. city disbanded), that unit currently looks for a new city with an apparently reversed nativity check: UMT_LAND units head for coastal cities, and other units (sea/air) look for the closest city (which may not be reachable for sea units). This patch causes bored defenders to seek a native city. Autogame testing showed some differences with this change, although I was unable to idenfity specific generalisation of behaviour: my assumption is that sea units are more likely to rest in cities (where they are potentially defended by land units), and that land units might choose to fortify in other land cities (potentially closer to land borders). 2) When creating a new unit with the editor, assign a homecity that is native to the class being created, rather than only doing this for UMT_SEA units. 3) When teleporting a UTYF_UNDISBANDABLE unit in try_to_save_unit(), teleport to a city native to the transport, rather than always a coastal city. This only affects rulesets with non-UMT_SEA transports that can carry UTYF_UNDISBANDABLE units, so results were not shown in any of my autogame testing (no differences, but not actually exercised meaningfully). This patch does not attempt to remove the is_ocean argument entirely. This remains useful for dai_manage_diplomat(), where the intent is to send bored diplomats to coastal cities to help defend the edges of the continent in cases where there is no access to other civilisations by land. Once AI diplomats learn how to use transport, this argument may be safely removed. Alternately, this could usefully be adjusted to indicate border/coastal cities rather than is_ocean: the current model behaves suboptimally when cities are adjacent to small lakes (also not addressed by this patch). Note that this patch expects prior application of the wipe_unit() refactoring from patch #3804 (and bug# 20744). ___ File Attachments: --- Date: Sat 20 Apr 2013 08:55:07 AM JST Name: native-find-closest-city.patch Size: 9kB By: persia http://gna.org/patch/download.php?file_id=1 ___ 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 #20747] Units in nested transport considered defensive units
URL: http://gna.org/bugs/?20747 Summary: Units in nested transport considered defensive units Project: Freeciv Submitted by: persia Submitted on: Sat 20 Apr 2013 01:48:01 PM JST Category: general Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.4.99-r22731 Discussion Lock: Any Operating System: GNU/Linux Planned Release: ___ Details: Units in nested transport are considered potential defensive units, although they are unable to unload or attack. Test case is to alter experimental ruleset to give Cruise Missile a defensive rating of 4, then load Cruise Missile in Mech. Inf. in Transport. Attack with something, and the missile is considered the defender. From comments in the code, I suspect that having Missiles be potential defenders of Submarines and Stealth Fighters|Bombers being potential defenders of Carriers may similarly be bugs (these also don't happen because of the coincidental relation between the defense ratings of the transport and the cargo). Discovered when considering allowing AttFromNonNative units to be able to also defend when non-native: thoughts on that idea appreciated, but the attached bugfix patch likely gets priority. ___ File Attachments: --- Date: Sat 20 Apr 2013 01:48:02 PM JST Name: check-unload-to-defend.patch Size: 1kB By: persia http://gna.org/bugs/download.php?file_id=17778 ___ Reply to this item at: http://gna.org/bugs/?20747 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
