[Freeciv-Dev] [patch #1807] Update AC_INIT and AM_INIT_AUTOMAKE to new form
Follow-up Comment #6, patch #1807 (project freeciv): This seems to be caused by echo not supporting -n. Even if that's not your current problem, it would cause problems for some users. So I'm committing attached fix immediately as compile fix. (file #9737) ___ Additional Item Attachment: File name: EchoNFix.diff Size:0 KB ___ Reply to this item at: http://gna.org/patch/?1807 ___ 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] Should RiverNative units be able to move diagonally / cross-continent, as currently?
URL: http://gna.org/bugs/?16383 Summary: Should RiverNative units be able to move diagonally / cross-continent, as currently? Project: Freeciv Submitted by: jtn Submitted on: Sunday 08/08/10 at 10:08 Category: None Severity: 3 - Normal Priority: 1 - Later Status: Need Info Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: Observations on playing with experimental ruleset on trunk (but presumably affects implementation of RiverNative on S2_2 too): Currently, RiverNative units (Triremes) can always move diagonally between river squares. This is unlike the effects of rivers on land units, which are governed by river_move_mode, which is usually set to require movement strictly along rivers (prohibiting diagonal movement). As well as reducing movement costs, if two river sources are diagonally adjacent, this allows a Trireme to go from one side of a continent to another along rivers. This seems excessively powerful. Question 1: should RiverNative be influenced by river_move_mode (or by a separate but similar enumeration in the ruleset), or should it stay as it is? Secondly, it's possible for cities adjacent to (not on) river squares to produce RiverNative units. This implies that such units can move through such cities. This makes it possible in some circumstances for a city to bridge two rivers to allow cross-continent movement. Even if we fix diagonal movement, there will still be circumstances where this is possible. Question 2: should cities have to be *on* a river square in order to produce/contain RiverNative units? (Combined with 1, I think this would plug the cross-continent hole.) Question 3: if we are changing this, should we change it on S2_2 also? Are there any significant rulesets which use RiverNative yet which would be upset by such a change? I had a look at the original ticket where this was implemented (RT #40396 http://bugs.freeciv.org/Ticket/Display.html?id=40396) and didn't find any rationale in this area. ___ 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] [bug #16326] fix compiler warning for non-debugging builds in packet.c
Update of bug #16326 (project freeciv): Assigned to: syntron = pepeto ___ Reply to this item at: http://gna.org/bugs/?16326 ___ 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 #16325] fix compiler warning for non-debugging builds in city.c
Update of bug #16325 (project freeciv): Assigned to: syntron = pepeto ___ Reply to this item at: http://gna.org/bugs/?16325 ___ 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 #16382] Breakage: First unit move in new turn lags
Follow-up Comment #1, bug #16382 (project freeciv): Unfortunately, increasing the number of players or the size of the map increase the lag, which is already very huge. Mainly, the server is delayed by the AI. The client makes very numerous useless actions (like doing 10 times the same action whereas nothing changed, or doing action for every packet field whereas only 1 field changed (and the client knows it before testing it!)). I made some improvement in the treatment of the client, but there is still lot of things to do. In the server, that's also right, notably the server systematically wait for the DNS of every connection which can block the server for several seconds. ___ Reply to this item at: http://gna.org/bugs/?16382 ___ 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 #16003] trunk client crashes on connect to 2.2.0 server
Update of bug #16003 (project freeciv): Status: In Progress = Ready For Test Planned Release:2.2.2, 2.3.0 = 2.2.2, 2.2.3, 2.3.0 ___ Follow-up Comment #10: I have made a big mistake treating this ticket. The ping sent when the server receives a new connection is very useful to unsure the connection is really a Freeciv client for example. For S2_2: * It needs to revert the patch I applied. For trunk: * Changing the packet number for PACKET_CONN_PING and PACKET_CONN_PONG to the old value. Adjusting others. * Add a message for packets PACKET_PROCESSING_STARTED, PACKET_PROCESSING_FINISHED, PACKET_SERVER_JOIN_REQ, PACKET_SERVER_JOIN_REPLY, PACKET_CONN_PING and PACKET_CONN_PONG to unsure their number won't change anymore. * Unsure in the client that the only packets received when the connection is not fully established are PACKET_CONN_PING, PACKET_PROCESSING_STARTED, PACKET_PROCESSING_FINISHED or PACKET_SERVER_JOIN_REPLY. (file #9738) ___ Additional Item Attachment: File name: trunk_connection_ping_nb.diff Size:9 KB ___ Reply to this item at: http://gna.org/bugs/?16003 ___ 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 #16318] strict aliasing and warnings
Update of bug #16318 (project freeciv): Category:None = general Status:None = Ready For Test Assigned to:None = pepeto Planned Release: = 2.3.0 ___ Follow-up Comment #3: Updated and modified your patch against current trunk. (file #9739) ___ Additional Item Attachment: File name: trunk_fix_compilation_warnings.diff Size:10 KB ___ Reply to this item at: http://gna.org/bugs/?16318 ___ 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 #16308] Great Wall protects wrong units
Update of bug #16308 (project freeciv): Status:None = Confirmed ___ Follow-up Comment #1: I confirm this is buggy. However, I am out of idea about how we could fix that. ___ Reply to this item at: http://gna.org/bugs/?16308 ___ 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 #16288] poedit doesn't like freeciv.pot
Update of bug #16288 (project freeciv): Status:None = Need Info ___ Follow-up Comment #1: Does this only affect the id.po file? ___ Reply to this item at: http://gna.org/bugs/?16288 ___ 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 #16164] Aircraft commit suicide if 'autoattack' is set
Update of bug #16164 (project freeciv): Priority: 5 - Normal = 3 - Low ___ Follow-up Comment #1: 'ai' is a better category for your report. I think it should be possible to change this. However, do you have a samegame to do the tests? That would be very useful. ___ Reply to this item at: http://gna.org/bugs/?16164 ___ 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 #16178] go-to doesn't function properly for triremes (all sea units?)
Update of bug #16178 (project freeciv): Status:None = Need Info ___ Follow-up Comment #4: Are you sure the tiles you cannot enter with your trireme are not deep ocean type when you press the middle button of the mouse on them? Else, can you explain what happen if you attempt to move to that tiles with the keyboard arrows? ___ Reply to this item at: http://gna.org/bugs/?16178 ___ 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 #16263] Scrolled overview map for large maps
Update of bug #16263 (project freeciv): Assigned to:None = pepeto ___ Reply to this item at: http://gna.org/bugs/?16263 ___ 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 #16255] Full-Screen Troubles
Follow-up Comment #1, bug #16255 (project freeciv): Did you test 2.2.2. Does the new interface fix your problem? ___ Reply to this item at: http://gna.org/bugs/?16255 ___ 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 #16384] Ruleset version and Scenario Game
URL: http://gna.org/bugs/?16384 Summary: Ruleset version and Scenario Game Project: Freeciv Submitted by: gorb Submitted on: Sunday 08/08/2010 at 12:18 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.2.2 Discussion Lock: Any Operating System: None Planned Release: ___ Details: Click - Start Scenario Game Select map - Europe-200x100-v2.sav.gz (or other) Select ruleset version - Realism or another (WW2, MiddleAge, Galactic Ruleset, etc.) Result: ''rulesetdir: This setting can't be modified after the game has started.'' Click START, but the ruleset version charges is DEFAULT. ___ Reply to this item at: http://gna.org/bugs/?16384 ___ 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 #16385] Consider changing how base ownership works to avoid problems with buoys
URL: http://gna.org/bugs/?16385 Summary: Consider changing how base ownership works to avoid problems with buoys Project: Freeciv Submitted by: jtn Submitted on: Sunday 08/08/10 at 13:22 Category: None Severity: 1 - Wish Priority: 1 - Later Status: Need Info Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: Something I've been thinking for a while, but been reminded about by a discussion on the forum http://forum.freeciv.org/viewtopic.php?p=25935#25935: Buoys provide vision to a specific nation, so it's necessary to somehow track who they belong to. This is currently implemented by re-using the border/ownership mechanism: the tile with the buoy on becomes part of the nation's territory (likely an isolated tile). This implementation causes various gameplay issues: * Nations at peace with the buoy owner can't move into the buoy square. This allows obstructive nations to block off arbitrary parts of the ocean or straits with lines of buoys (which are cheap to build). * Buoys act as sea bases for the purpose of reducing unhappiness in representative governments; buoys can be built at will anywhere in the world, and sea units and transported land units can use that tile as a base from which to carry out an aggressive campaign without the usual penalties. * Unless playing with foggedborders, all players can deduce the location of a nation's buoys as soon as they are built. I assume these are all unintended consequences. IMO it would be better if there were a separate way to track ownership for bases without creating borders. I don't think this new ownership concept needs to be per-base -- it's OK for all bases on a tile to have to belong to the same nation, and change ownership en masse -- so this probably means a change to the per-tile structure (which probably rules out changing this in S2_2). I also don't think it makes sense for a base to be inside one nation's borders but belong to another, so continuing with a single owner field should suffice; an additional per-tile flag borders stating whether owner claims borders or is merely deriving benefits from any bases will suffice, I think. I haven't thought this through exhaustively, but some implementation thoughts: * The definition of borders will be changed to treat tiles with a zero borders flag as unclaimed territory, regardless of who owner is (currently this is signalled by a null owner); * When borders recede (e.g., city destroyed), the owner field is *not* cleared. ** So a buoy near a city that is destroyed continues to give benefits to that city's erstwhile owner. ** This leaves some dead but client-visible information in tiles without bases (effectively, the last claimant of that tile). If that's undesirable, the borders code could instead carefully clear owners except on tiles with all relevant bases, with the same effect. * Pillaging an owned base on unclaimed territory will not automatically be an act of war against the owner as far as diplomatic states are concerned; it's undefended and in international waters, thus fair game. (But of course, in the case of a buoy, they probably saw you coming, and are free to take exception to that.) ** Slightly unsure about this, but I think something of the sort is necessary for balance. Perhaps it could at least be a diplomatic incident (excuse for war) like certain Diplomat/Spy actions. * The client UI would need to distinguish base and tile ownership in the tile middle-click popup. Comments? Objections? ___ Reply to this item at: http://gna.org/bugs/?16385 ___ 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 #16384] Ruleset version and Scenario Game
Follow-up Comment #1, bug #16384 (project freeciv): As the scenario contains a map that claim ruleset infos (the definitions of the terrain types and ressources), then it's impossible to overload with another ruleset, because it could be non-compatible with the original one. I am afraid your report cannot be satisfied. ___ Reply to this item at: http://gna.org/bugs/?16384 ___ 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 #1804] Move advisor movement code from ai to advisors
Follow-up Comment #2, patch #1804 (project freeciv): Actually this patch does not fully satisfy needs of autoexplorers, but I leave that to another ticket. ___ Reply to this item at: http://gna.org/patch/?1804 ___ 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 #1804] Move advisor movement code from ai to advisors
Update of patch #1804 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?1804 ___ 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 #1821] Change TRUNK datasubdir to be dev
Update of patch #1821 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?1821 ___ 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 #16215] Received VOTE_SUBMIT(149) from observer
Update of bug #16215 (project freeciv): Category:None = client Severity: 3 - Normal = 2 - Minor Priority: 1 - Later = 3 - Low Status:None = Ready For Test Assigned to:None = pepeto Planned Release: = 2.2.3, 2.3.0 ___ Follow-up Comment #1: Fix attached to prevent the client to send that packet if it is not attached to a player or observing. Unfortunately, this error message will still be displayed if the client is out of synchronization. (file #9740) ___ Additional Item Attachment: File name: trunk_S2_2_voteinfo_do_vote.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?16215 ___ 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 #1826] Store advisors related city data separately from ai data
URL: http://gna.org/patch/?1826 Summary: Store advisors related city data separately from ai data Project: Freeciv Submitted by: cazfi Submitted on: Sunday 08/08/2010 at 16:23 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.3.0 ___ Details: This patch splits from ai_data structure new structure adv_data for advisors related data (data that is needed even when player is not ai) ___ File Attachments: --- Date: Sunday 08/08/2010 at 16:23 Name: CityAdv.diff Size: 14kB By: cazfi http://gna.org/patch/download.php?file_id=9741 ___ Reply to this item at: http://gna.org/patch/?1826 ___ 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 #1826] Store advisors related city data separately from ai data
Update of patch #1826 (project freeciv): Depends on: = patch #1825 ___ Reply to this item at: http://gna.org/patch/?1826 ___ 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 #1825] AI City interface improvements
Update of patch #1825 (project freeciv): Status:None = Ready For Test ___ Reply to this item at: http://gna.org/patch/?1825 ___ 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 #16386] Setting 'aifill' produce an error message
URL: http://gna.org/bugs/?16386 Summary: Setting 'aifill' produce an error message Project: Freeciv Submitted by: pepeto Submitted on: dimanche 08.08.2010 à 13:34 Category: general Severity: 2 - Minor Priority: 3 - Low Status: Ready For Test Assigned to: pepeto Originator Email: Open/Closed: Open Release: trunk Discussion Lock: Any Operating System: None Planned Release: 2.3.0 ___ Details: When aifill fails to remove enough players (because there are human or created ones), it results the following message: 1: Could only reduce the number of players to 1 (requested: 0) +verbatim- ___ File Attachments: --- Date: dimanche 08.08.2010 à 13:34 Name: trunk_aifill_error_msg.diff Size: 547 o By: pepeto http://gna.org/bugs/download.php?file_id=9742 ___ Reply to this item at: http://gna.org/bugs/?16386 ___ 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 #16375] Buoy created inside national borders has no vision effect until save/load
Update of bug #16375 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?16375 ___ 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 #1827] README.distributions
URL: http://gna.org/patch/?1827 Summary: README.distributions Project: Freeciv Submitted by: cazfi Submitted on: Sunday 08/08/2010 at 17:23 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.3.0 ___ Details: This patch adds initial version of README.distributions document. Plan is to collect to it stuff that people packaging Freeciv for their distribution should know. ___ File Attachments: --- Date: Sunday 08/08/2010 at 17:23 Name: ReadmeDistributions.diff Size: 2kB By: cazfi http://gna.org/patch/download.php?file_id=9743 ___ Reply to this item at: http://gna.org/patch/?1827 ___ 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 #1807] Update AC_INIT and AM_INIT_AUTOMAKE to new form
Follow-up Comment #8, patch #1807 (project freeciv): Thanks Marko. Configure is working again on my machine as of r17680. ___ Reply to this item at: http://gna.org/patch/?1807 ___ 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 #1440] Anishinaabe nation
Update of patch #1440 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?1440 ___ 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 #1441] Holy Roman Empire
Update of patch #1441 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?1441 ___ 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 #1442] South Vietnamese nation
Update of patch #1442 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?1442 ___ 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 #1828] Improved Mexican ruleset
URL: http://gna.org/patch/?1828 Summary: Improved Mexican ruleset Project: Freeciv Submitted by: mixcoatl Submitted on: Sunday 08/08/2010 at 18:25 Category: rulesets Priority: 4 Status: None Privacy: Public Assigned to: mixcoatl Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: More leaders, more cities, ruler titles and a larger description. ___ File Attachments: --- Date: Sunday 08/08/2010 at 18:25 Name: mexican.ruleset Size: 6kB By: mixcoatl http://gna.org/patch/download.php?file_id=9744 ___ Reply to this item at: http://gna.org/patch/?1828 ___ 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 #1829] Improved Soviet ruleset
URL: http://gna.org/patch/?1829 Summary: Improved Soviet ruleset Project: Freeciv Submitted by: mixcoatl Submitted on: Sunday 08/08/2010 at 18:29 Category: rulesets Priority: 4 Status: None Privacy: Public Assigned to: mixcoatl Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: The current Soviet nation includes only communist era names, which means that not even Moscow is included, which I thought is a bit weird. I added a lot of major cities that were not included yet. I also think the flag should be changed to a somewhat darker red. ___ File Attachments: --- Date: Sunday 08/08/2010 at 18:29 Name: soviet.ruleset Size: 2kB By: mixcoatl http://gna.org/patch/download.php?file_id=9745 ___ Reply to this item at: http://gna.org/patch/?1829 ___ 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 #1442] South Vietnamese nation
Follow-up Comment #2, patch #1442 (project freeciv): A typo in this change prevents trunk from building. Patch attached. Since this is a build failure, I'm committing it immediately. (file #9746) ___ Additional Item Attachment: File name: trunk-rvn-build-failure.diff Size:0 KB ___ Reply to this item at: http://gna.org/patch/?1442 ___ 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 #16387] attacker can abuse 'go to' to stop pillager
URL: http://gna.org/bugs/?16387 Summary: attacker can abuse 'go to' to stop pillager Project: Freeciv Submitted by: kernigh Submitted on: Sunday 08/08/2010 at 20:32 Category: None Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.2.2+ r17648 Discussion Lock: Any Operating System: *BSD Planned Release: ___ Details: My enemy has ordered a unit to pillage a road. My unit would attack and kill the pillager, but my attacker has 0 movement points. Because the pillaging requires one turn, the pillager will destroy the road at the next turn change. Normally, if my attacker waits until the next turn to get movement points, then the pillager will destroy the road before I can attack. The bug is that my attacker can use the 'go to' command to kill the pillager. At the next turn change, the pillager will die but the road will stay! Therefore, an attacking unit with 0 movement points can abuse the goto command to stop a pillaging. I first observed this bug in online 2.1 game (Longturn 20), but I have reproduced this bug with S2_2 r17648. The attached game x-pillage-test.sav.bz2 reproduces this bug. Load the game and take player S. The only way to prevent the pillaging of the road by player P is to abuse 'go to'. ___ File Attachments: --- Date: Sunday 08/08/2010 at 20:32 Name: x-pillage-test.sav.bz2 Size: 11kB By: kernigh take player S, abuse 'go to' to stop pillagers http://gna.org/bugs/download.php?file_id=9747 ___ Reply to this item at: http://gna.org/bugs/?16387 ___ 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 #16164] Aircraft commit suicide if 'autoattack' is set
Follow-up Comment #2, bug #16164 (project freeciv): I've since 'cleaned house' and deleted old stuff. I think i've got some suitable opponents now, so i'll try and generate something. ___ Reply to this item at: http://gna.org/bugs/?16164 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
