[Freeciv-Dev] [bug #20577] new parameter gameloss_style in game.ruleset

Update of bug #20577 (project freeciv): Depends on: => patch #3812 ___ Follow-up Comment #21: patch #3812 provides new function to use for giving leader units midgame.

[Freeciv-Dev] [patch #3812] Leader to civil war player

URL: Summary: Leader to civil war player Project: Freeciv Submitted by: cazfi Submitted on: Sat 30 Mar 2013 01:29:24 AM EET Category: general Priority: 5 - Normal

[Freeciv-Dev] [patch #3811] Remove S_RIVER

URL: Summary: Remove S_RIVER Project: Freeciv Submitted by: cazfi Submitted on: Sat 30 Mar 2013 12:32:11 AM EET Category: general Priority: 5 - Normal Status:

[Freeciv-Dev] [patch #3798] Remove obsolete m4-files

Update of patch #3798 (project freeciv): Status: Ready For Test => Done Assigned to:None => cazfi Open/Closed:Open => Closed

[Freeciv-Dev] [bug #20660] isophex river outlets misdefined

Update of bug #20660 (project freeciv): Status: Ready For Test => Fixed Open/Closed:Open => Closed ___ Reply to this item at:

[Freeciv-Dev] [bug #20662] island_river_suitability() expects rivers as specials

Update of bug #20662 (project freeciv): Status: Ready For Test => Fixed Assigned to:None => cazfi Open/Closed:Open => Closed _

[Freeciv-Dev] [bug #20664] fcintl.h:71: error

Update of bug #20664 (project freeciv): Status: Ready For Test => Fixed Assigned to:None => cazfi Open/Closed:Open => Closed _

[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver

Follow-up Comment #6, bug #20680 (project freeciv): One thing that probably helped testcases to pass was that ' ' was ignored only when collecting subtokens - garbage was added to the end of subtoken. But the garbage begun with ' ' which terminated subtoken when it was actually used. I'm changing

[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver

Follow-up Comment #5, bug #20680 (project freeciv): > BTW, "build/cvercmp 2.4.0 greater 2.4.0-beta1" says "No". This > is after my changes, but I suspect I can't have affected that. > That seems like it will be a problem for us? Problem is in documentation. I had hard time deciding which order cv

[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver

Follow-up Comment #4, bug #20680 (project freeciv): Here is what I committed to upstream in case we want to keep files completely identical (there's C++-style comment that would be forbidden by freeciv CodingStyle) (file #17602) ___ Additi

[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver

Follow-up Comment #3, bug #20680 (project freeciv): > I really don't understand how my test cases have been passing, > including ordering of "beta1" and "beta2". Bad luck could do it -- depending on the contents of memory and not triggering a segfault -- but it seems like it would have to be quit

[Freeciv-Dev] [bug #20663] Unloading assert failure when autoattack kills transport

Follow-up Comment #2, bug #20663 (project freeciv): I think it's possible to fix this in respect to supplied rulesets by moving block of code that moves trasnported units to new tile to be before handling of autoattack and huts. After that the only possibility of already moved transporter to die b

[Freeciv-Dev] [bug #20668] Loaded submarines are not stealth

Update of bug #20668 (project freeciv): Status:None => Need Info ___ Follow-up Comment #1: I can't reproduce in 2.4.0-beta1; in my quick testing, Cruise Missiles on board a Submarine were

[Freeciv-Dev] [bug #20045] assertion failed with civ2civ3 over S2_4

Follow-up Comment #16, bug #20045 (project freeciv): > in unit_transport_unload() [unit.c::2072]: assertion 'same_pos(unit_tile(pcargo), unit_tile(ptrans))' failed. I've seen this assertion failing in 2.4.0-beta1 on the client a couple of times when testing with loading/unloading submarines and cr

[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver

Follow-up Comment #2, bug #20680 (project freeciv): Your description and patch seem to make sense, but like you said > Not sure why it hasn't bitten me before now, to be honest. I really don't understand how my test cases have been passing, including ordering of "beta1" and "beta2". ___

[Freeciv-Dev] [patch #3810] freeciv-web configure checks to separate m4-file

URL: Summary: freeciv-web configure checks to separate m4-file Project: Freeciv Submitted by: cazfi Submitted on: Fri 29 Mar 2013 06:58:52 PM EET Category: bootstrap Priority:

[Freeciv-Dev] [bug #20542] in unit_virtual_destroy() [unit.c::1881]: assertion '!unit_transported(punit)' failed

Follow-up Comment #4, bug #20542 (project freeciv): To expand on this: > I think in this case that this assertion is wrong. When > exiting the game, it shouldn't check this. So, post bug #20085, we have a policy that (unit)->client.transported_by always reflects what we last saw from the server;

[Freeciv-Dev] [bug #20542] in unit_virtual_destroy() [unit.c::1881]: assertion '!unit_transported(punit)' failed

Follow-up Comment #3, bug #20542 (project freeciv): ...but I don't see it in 2.4.0-beta1 (I'm guessing the fix for bug #20085 is implicated). ___ Reply to this item at: __

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

Follow-up Comment #2, bug #20682 (project freeciv): Don't see this with 2.4.0-beta1, I think because bug #20085 was fixed since then. ___ Reply to this item at: __

[Freeciv-Dev] [bug #20542] in unit_virtual_destroy() [unit.c::1881]: assertion '!unit_transported(punit)' failed

Follow-up Comment #2, bug #20542 (project freeciv): Still happening with file #17386 on latest S2_4 (r22619), FWIW. ___ Reply to this item at: ___ Message sent v

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

Follow-up Comment #1, bug #20682 (project freeciv): (Unit ID 127 is the missile.) ___ Reply to this item at: ___ Message sent via/by Gna! http://gna.org/ ___

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

URL: Summary: unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile) Project: Freeciv Submitted by: jtn Submitted on: Fri Mar 29 14:56:43 2013

[Freeciv-Dev] [bug #20681] "Select" menu disabled when no units selected, but "Unit selection dialog" could be used

URL: Summary: "Select" menu disabled when no units selected, but "Unit selection dialog" could be used Project: Freeciv Submitted by: jtn Submitted on: Fri Mar 29 12:55:50 2013 Category: client

[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver

Update of bug #20680 (project freeciv): Status: In Progress => Ready For Test ___ Additional Item Attachment: File name: trunk-S2_4-cvercmp-subtokenize-crash.patch Size:1 KB

[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver

Follow-up Comment #1, bug #20680 (project freeciv): (For the avoidance of doubt: I am about to submit a patch.) ___ Reply to this item at: ___ Message sent via/b

[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver

URL: Summary: Client crash on contacting metaserver, dependent on latest version advertised by metaserver Project: Freeciv Submitted by: jtn Submitted on: Fri Mar 29 12:04:04 2013 Category: cli

[Freeciv-Dev] [bug #20003] Security advisory

Update of bug #20003 (project freeciv): Severity: 3 - Normal => 6 - Security ___ Reply to this item at: ___ Message sent

[Freeciv-Dev] [bug #20663] Unloading assert failure when autoattack kills transport

Follow-up Comment #1, bug #20663 (project freeciv): As long as I've been hacking freeciv, I've been unhappy with how transported units are assinged to a tile, and not just to their transport. This bug seems like a argument for doing it so. Having transported units really in the transporter, moveme

[Freeciv-Dev] [bug #20679] [Metaticket] move_unit bugs

Update of bug #20679 (project freeciv): Depends on: => bugs #19989 ___ Reply to this item at: ___ Message sent

[Freeciv-Dev] [bug #20679] [Metaticket] move_unit bugs

Update of bug #20679 (project freeciv): Depends on: => bugs #20663 ___ Reply to this item at: ___ Message sent

[Freeciv-Dev] [bug #20679] [Metaticket] move_unit bugs

Update of bug #20679 (project freeciv): Depends on: => bugs #20678 ___ Reply to this item at: ___ Message sent

[Freeciv-Dev] [bug #20679] [Metaticket] move_unit bugs

URL: Summary: [Metaticket] move_unit bugs Project: Freeciv Submitted by: cazfi Submitted on: Fri 29 Mar 2013 11:46:38 AM EET Category: general Severity: 3 - Normal

[Freeciv-Dev] [bug #20678] Unit pointer used after it might died in unit_move_consequences()

URL: Summary: Unit pointer used after it might died in unit_move_consequences() Project: Freeciv Submitted by: cazfi Submitted on: Fri 29 Mar 2013 11:42:14 AM EET Category: general

[Freeciv-Dev] [patch #3804] Enabling restricted air transport

Follow-up Comment #13, patch #3804 (project freeciv): This is a patch with the bitvector implementation, which has passed all the same tests as the original implementation, as well as tests for units trying to implicitly unload through movement. This would not pass a test for units trying to impl

[Freeciv-Dev] [patch #3804] Enabling restricted air transport

Follow-up Comment #12, patch #3804 (project freeciv): The obvious is what needed stating. Thanks for the pointers: even worse, I had not even defined these bitvectors in packets.def, so that regardless of the fact that I wasn't sending them, they could not be sent. __

[Freeciv-Dev] [patch #3804] Enabling restricted air transport

Follow-up Comment #11, patch #3804 (project freeciv): Risking stating the obvious: start by checking (reading code, adding logging) that disembarks bitvector is not all-FALSE in client side, i.e., that you send them from server to client ( ruleset.c:send_ruleset_units() ) and client fills them in