[Freeciv-Dev] [patch #3804] Enabling restricted air transport
Follow-up Comment #10, patch #3804 (project freeciv): I've encountered a strangeness during the implementation: a difference in behaviour of unit.c:can_unit_unload() when called from the client and the server. I am using BV_ISSET(unit_type(pcargo)-disembarks, uclass_index(unit_class(ptrans))) to determine if pcargo is permitted to be unloaded from ptrans. When called from unittools.c:wipe_unit(), this works perfectly, so when the transporter is disbanded or destroyed, it is possible to determine if the unit is helpless or merely imperiled. Strangely, when called from any of the gtk3 client accessors (city popup menu, application menu, keystroke (for either transporter's UnloadAll, or cargo's Unload)), the same test invariably returns false. I find the same behaviour for the gtk2 client, wasn't able to test with the Qt client (load/unload does not yet appear to be implemented), and haven't built any of the others. Is there any obvious client/server context consideration I need to be making, or is this also mysterious to others, so that I am best served by debugging the client behaviour step-by-step? ___ 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] [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 once packet received ( packhand.c:handle_ruleset_unit() ) ___ 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] [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. ___ 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 #20678] Unit pointer used after it might died in unit_move_consequences()
URL: http://gna.org/bugs/?20678 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 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 ___ Details: Unit pointer is being used after unit_move_consequences() call where it can, at least in theory, die. Death would require some unusual lua scripting. This is reggresion since 2.3. Fix attached ___ File Attachments: --- Date: Fri 29 Mar 2013 11:42:14 AM EET Name: MoveDeath.patch Size: 9kB By: cazfi http://gna.org/bugs/download.php?file_id=17588 --- Date: Fri 29 Mar 2013 11:42:14 AM EET Name: MoveDeath-S2_4.patch Size: 9kB By: cazfi http://gna.org/bugs/download.php?file_id=17589 ___ Reply to this item at: http://gna.org/bugs/?20678 ___ 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 #20679] [Metaticket] move_unit bugs
Update of bug #20679 (project freeciv): Depends on: = bugs #20678 ___ Reply to this item at: http://gna.org/bugs/?20679 ___ 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 #20679] [Metaticket] move_unit bugs
Update of bug #20679 (project freeciv): Depends on: = bugs #20663 ___ Reply to this item at: http://gna.org/bugs/?20679 ___ 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 #20679] [Metaticket] move_unit bugs
Update of bug #20679 (project freeciv): Depends on: = bugs #19989 ___ Reply to this item at: http://gna.org/bugs/?20679 ___ 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 #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, movement of whole package would be atomic, and there would be cases where some parts of the package are in one tile and other parts in another tile. Not that I'd want such a fundamental change to stable branches (or even TRUNK this close to S2_5 branching) for resolving this particular ticket, but something we may want to do in the future. ___ Reply to this item at: http://gna.org/bugs/?20663 ___ 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 #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver
URL: http://gna.org/bugs/?20680 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: client Severity: 5 - Blocker Priority: 5 - Normal Status: In Progress Assigned to: cazfi Originator Email: Open/Closed: Open Release: 2.4.0-beta1 Discussion Lock: Any Operating System: GNU/Linux Planned Release: 2.4.0-beta2, 2.5.0 ___ Details: Noticed my S2_4 client segfaulting shortly after choosing Connect to Network Game. Turns out the version comparison (cvercmp) against what is advertised as latest from the metaserver has a couple of bugs: 0 In cvercmp_next_subtoken(), there's no check for '\0'. In the case of a string ending in a non-digit (such as 2.4.0-beta1+, we'll go off the end of the array and probably segfault (unless we happen to find a digit in random memory); 0 This is masked/compounded by another bug: in cvercmp_ver_subtokenize(), there's a spurious +1 causing subtokens to be missed. So in beta1+, the 1 is skipped and we hit +, triggering the previous bug; and when comparing beta1 and beta2, we'll skip over the digits and start at '\0', which is a non-digit and will also trigger the previous bug. I think we've been getting away with it in 2.4.0-beta1 because the metaserver and local strings compare equal before we do this check. So far I think only people running development code from svn are affected. (Not sure why it hasn't bitten me before now, to be honest.) Unfortunately I think this will cause crashes in existing beta1 installations when we release 2.4.0-beta2 and update the metaserver. I don't think there's anything to be done about that, other than advise people to upgrade. Assigning to cazfi initially as the fix will also want pushing to his cvercmp upstream http://www.cazfi.net/other/cvercmp.html and I guess he'll want to handle pulling the new version into Freeciv; however, I will commit this directly to Freeciv soon if it stalls. ___ Reply to this item at: http://gna.org/bugs/?20680 ___ 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 #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: http://gna.org/bugs/?20680 ___ 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 #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 ___ Reply to this item at: http://gna.org/bugs/?20680 ___ 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 #20681] Select menu disabled when no units selected, but Unit selection dialog could be used
URL: http://gna.org/bugs/?20681 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-gtk-2.0 Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: S2_4 r22619 Discussion Lock: Any Operating System: Any Planned Release: 2.4.0 ___ Details: As subject. It used to make sense to grey out the whole Select menu, but now Unit selection dialog could usefully be chosen. Not sure whether the right answer is to ungrey Select, or move Unit selection dialog to another menu. ___ Reply to this item at: http://gna.org/bugs/?20681 ___ 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)
URL:
http://gna.org/bugs/?20682
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
Category: client
Severity: 3 - Normal
Priority: 5 - Normal
Status: None
Assigned to: None
Originator Email:
Open/Closed: Open
Release: S2_4 r22619
Discussion Lock: Any
Operating System: GNU/Linux
Planned Release: 2.4.0
___
Details:
Found a reproducible assertion failure on S2_4: with a submarine carrying a
missile adjacent to to enemy units on the coast, move the missile to the units
(i.e. attack). Both attacker and defender clients hit this assertion failure.
I assume the problem is that the previously invisible missile unit becomes
visible only to be destroyed, and that the transported status at the client
ends up not what we want.
I suspect this isn't related to bug #20542.
Haven't checked if something similar happens with Marines.
Backtrace from one of the clients (with -F):
#0 0x7f9aa8ac87bb in raise (sig=value optimised out)
at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
No locals.
#1 0x005cd9cc in fc_assert_fail (file=0x65a209 unit.c,
function=0x65acc0 unit_virtual_destroy, line=1718,
assertion=value optimised out, message=0x65bec0 nologmsg:%s)
at log.c:520
level = LOG_FATAL
#2 0x005c74fd in unit_virtual_destroy (punit=0x7bb53a0) at
unit.c:1718
__FUNCTION__ = unit_virtual_destroy
#3 0x0045e240 in client_remove_unit (punit=0x7bb53a0) at
climisc.c:96
pcity = value optimised out
ptile = 0x3c3d0a0
hc = 0
old_unit = {utype = 0x9dc270, tile = 0x3c3d0a0,
facing = DIR8_SOUTHEAST, owner = 0x3aded80, id = 127, homecity = 0,
upkeep = {0, 0, 0, 0, 0, 0}, moves_left = 36, hp = 10, veteran = 1,
fuel = 1, goto_tile = 0x0, activity = ACTIVITY_IDLE,
activity_count = 0, activity_target = S_LAST, activity_base = -1,
changed_from = ACTIVITY_IDLE, changed_from_count = 0,
changed_from_target = S_ROAD, changed_from_base = 0,
ai_controlled = false, moved = false, paradropped = false,
done_moving = false, transporter = 0x7bb98f0,
transporting = 0x3c25eb0, battlegroup = -1, has_orders = false,
orders = {length = 0, index = 0, repeat = false, vigilant = false,
list = 0x0}, {client = {focus_status = FOCUS_AVAIL,
transported_by = 126, occupied = false, colored = false,
color_index = 0, asking_city_name = false}, server = {
debug = false, adv = 0x0, ais = {0x0, 0x0, 0x0}, birth_turn = 0,
ord_map = 0, ord_city = 0, vision = 0x0, action_timestamp = 0,
action_turn = 0}}}
old = 1
__FUNCTION__ = client_remove_unit
#4 0x00487de0 in client_handle_packet (type=value optimised out,
packet=0x0) at packhand_gen.c:150
No locals.
#5 0x004592fe in client_packet_input (packet=value optimised out,
type=64) at client_main.c:654
__FUNCTION__ = client_packet_input
#6 0x0045f7a5 in input_from_server (fd=value optimised out)
at clinet.c:421
result = true
packet = 0x0
type = PACKET_UNIT_SHORT_INFO
nb = value optimised out
__FUNCTION__ = input_from_server
#7 0x0044e7e0 in get_net_input (source=value optimised out,
condition=value optimised out, data=value optimised out)
at gui_main.c:1882
No locals.
#8 0x7f9aa28a19d2 in g_main_context_dispatch () from
/lib/libglib-2.0.so.0
No symbol table info available.
#9 0x7f9aa28a5858 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#10 0x7f9aa28a5d65 in g_main_loop_run () from /lib/libglib-2.0.so.0
No symbol table info available.
#11 0x7f9aa4e48bc7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#12 0x00451ce9 in ui_main (argc=1, argv=0x7fffca56a428)
at gui_main.c:1673
home = value optimised out
sig = value optimised out
__FUNCTION__ = ui_main
#13 0x004597e3 in client_main (argc=value optimised out,
argv=0x7fffca56a428) at client_main.c:590
i = 9
loglevel = LOG_VERBOSE
ui_options = value optimised out
ui_separator = 128
option = value optimised out
user_tileset = false
fatal_assertions = 6
__FUNCTION__ = client_main
#14 0x7f9aa696fc4d in __libc_start_main (main=value optimised out,
argc=value optimised out, ubp_av=value optimised out,
init=value optimised out, fini=value optimised out,
rtld_fini=value optimised
[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: 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] [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: http://gna.org/bugs/?20542 ___ 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)
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: 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] [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: http://gna.org/bugs/?20542 ___ 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 #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; and we already had a policy that a unit is not allowed to be being transported at the time it's destroyed. However, in this case, we're deleting units without being told to be the server. If we want to keep these policies, I think that it is necessary to explicitly clear transported_by after unit_transport_unload() in player_clear() (probably both for cargo and the current unit). Anywhere else where the client autonomously messes with this stuff? I didn't spot anything on a quick look. ___ Reply to this item at: http://gna.org/bugs/?20542 ___ 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 #3810] freeciv-web configure checks to separate m4-file
URL: http://gna.org/patch/?3810 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: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: Move configure checks for freeciv-web from configure.ac to new web-client.m4 ___ File Attachments: --- Date: Fri 29 Mar 2013 06:58:52 PM EET Name: webm4.patch Size: 2kB By: cazfi http://gna.org/patch/download.php?file_id=17592 ___ Reply to this item at: http://gna.org/patch/?3810 ___ 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 #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. ___ Reply to this item at: http://gna.org/bugs/?20680 ___ 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 #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 cruise missiles to try to reproduce bug #20668. I haven't worked out exactly what triggers it yet. I've not seen it with the head of S2_4 but that's not conclusive; however I suspect changes since beta1 (notably bug #20085) are likely to have perturbed this area. ___ Reply to this item at: http://gna.org/bugs/?20045 ___ 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 #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 invisible when the Submarine was. However, we do have some bugs with transports at the moment (some fixed since beta1, some still at large). Can you give more details or a savegame? What ruleset were you using? What entity (city, unit, ...) was providing you with visibility of the area where the missiles showed up? Had you loaded/unloaded the missiles recently? If you have a scenario that can reproduce this behaviour, that would be very helpful. ___ Reply to this item at: http://gna.org/bugs/?20668 ___ 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 #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 before also cargo has moved would be if it moves to conquer enemy city and city loss lua-script would kill it. ___ Reply to this item at: http://gna.org/bugs/?20663 ___ 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 #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 quite bad luck. (Is there a regression test suite somewhere that I missed?) 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? ___ Reply to this item at: http://gna.org/bugs/?20680 ___ 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 #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) ___ Additional Item Attachment: File name: JacobNevins.patch Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?20680 ___ 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 #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 cvercmp -binary should take parameters as neither seemed to work as natural in all contexts. ./cvercmp 2.4.0-beta1 greater 2.4.0 Yes ___ Reply to this item at: http://gna.org/bugs/?20680 ___ 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 #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 parameter order of cvercmp binary to match documentation. No changes to library-level that freeciv uses. ___ Reply to this item at: http://gna.org/bugs/?20680 ___ 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 #20664] fcintl.h:71: error
Update of bug #20664 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20664 ___ 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 #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: http://gna.org/bugs/?20660 ___ 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 #3798] Remove obsolete m4-files
Update of patch #3798 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3798 ___ 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 #3812] Leader to civil war player
URL: http://gna.org/patch/?3812 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 Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: Inspired by part of bug #20577: If startunits has role King unit(s), give such units also to new player created by civil war. Assumption here is that if such a unit is in startunits, every player should have one. ___ File Attachments: --- Date: Sat 30 Mar 2013 01:29:24 AM EET Name: MidgameInitilUnits.patch Size: 2kB By: cazfi http://gna.org/patch/download.php?file_id=17606 ___ Reply to this item at: http://gna.org/patch/?3812 ___ 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 #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. ___ Reply to this item at: http://gna.org/bugs/?20577 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
