[Freeciv-Dev] [bug #16838] New diplo state not immediately shown in ui
Follow-up Comment #4, bug #16838 (project freeciv): I had misunderstood the bug - in a big game, the status is updated late rather than never: up to 10s after accepting the ceasefire agreement. The exact time is random, though. I had a 50% repro rate in the beginning of a 25 player game. Your patch seems to help - after applying it the time to update is typically less than 1s. ___ Reply to this item at: http://gna.org/bugs/?16838 ___ 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 #16837] Some messages shown twice, randomly
Update of bug #16837 (project freeciv): Summary: New tech message shown twice = Some messages shown twice, randomly ___ Follow-up Comment #2: I realized this after testing some more: The bug is random. And, it affects other messages as well. Just got this while play testing: You have made contact with the British, ruled by Margaret Thatcher. You have made contact with the British, ruled by Margaret Thatcher. ___ Reply to this item at: http://gna.org/bugs/?16837 ___ 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 #1967] Longer T0 turn
Update of patch #1967 (project freeciv): Status: Ready For Test = In Progress ___ Follow-up Comment #5: first_timeout default could also be set to -1. This special case would not overwrite the timeout at the first turn. It would be really clearer for me. What do you think? Also, the help text for the setting timeout should be modified to point about the existence of the new setting. ___ Reply to this item at: http://gna.org/patch/?1967 ___ 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 #16837] Some messages shown twice, randomly
Follow-up Comment #3, bug #16837 (project freeciv): Savegame? ___ Reply to this item at: http://gna.org/bugs/?16837 ___ 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 #2045] Celtiberian nation
Follow-up Comment #1, patch #2045 (project freeciv): I have maked own Celtiberian nationset with more leaders. ___ Reply to this item at: http://gna.org/patch/?2045 ___ 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 #1949] add casts to utility/support.c for clean compilation
Update of patch #1949 (project freeciv): Status:None = Ready For Test Assigned to:None = pepeto Planned Release: = 2.2.4 ___ Follow-up Comment #3: Patch attached. (file #10697) ___ Additional Item Attachment: File name: S2_2_char_cast_operations.diff Size:2 KB ___ Reply to this item at: http://gna.org/patch/?1949 ___ 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 #1860] require gcc 3.4 for __attribute__((warn_unused_result))
Update of patch #1860 (project freeciv): Status:None = Ready For Test Planned Release: = 2.2.4, 2.3.0 ___ Follow-up Comment #3: I am going to steal it if Marko doesn't. ___ Reply to this item at: http://gna.org/patch/?1860 ___ 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 #1967] Longer T0 turn
Follow-up Comment #6, patch #1967 (project freeciv): Applied more of pepetos suggestions (file #10698) ___ Additional Item Attachment: File name: first_timeout.diff Size:2 KB ___ Reply to this item at: http://gna.org/patch/?1967 ___ 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 #1967] Longer T0 turn
Update of patch #1967 (project freeciv): Status: In Progress = Ready For Test ___ Reply to this item at: http://gna.org/patch/?1967 ___ 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 #16775] lot of errors of type 'get_defender bug'
Follow-up Comment #9, bug #16775 (project freeciv): Third patch attached: * Removed the assertion at the end of get_defender(), as it is normal to return NULL if no defender has been found. * Removed COULD_OCCUPY macro, replaced by unit_can_take_over(). * Fixed a FIXME in server/unithand.c * Moved the definition of 'enum unit_move_result'. I think this part is wrong. By letting victim stay as NULL, this allows the move to proceed. But this is the case where an explorer is trying to move into an enemy tile which should not be allowed. I think the move needs to be denied with a return call, as happens in a lot of places higher up in that function. This is actually checked after, so it's not wrong. (file #10699) ___ Additional Item Attachment: File name: trunk_get_defender3.diff Size:24 KB ___ Reply to this item at: http://gna.org/bugs/?16775 ___ 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 #16837] Some messages shown twice, randomly
Update of bug #16837 (project freeciv): Category:None = client-gtk-2.0 Status: Need Info = Ready For Test Assigned to:None = pepeto Planned Release: = 2.3.0 ___ Follow-up Comment #4: Ok, I have reproduced it. A gtk_list_store_clear() was missing, my mistake. Fix attached. (file #10700) ___ Additional Item Attachment: File name: trunk_gtk2_meswin_dialog_refresh.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?16837 ___ 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 #2045] Celtiberian nation
Follow-up Comment #2, patch #2045 (project freeciv): Here is a large list of names of ancient Iberian nations (including the names of the chiefs; also Celtiberians): http://www.twcenter.net/forums/showthread.php?t=39741 ___ Reply to this item at: http://gna.org/patch/?2045 ___ 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 #16839] cleanup rulesets experimental/multiplayer
Follow-up Comment #2, bug #16839 (project freeciv): Note this patch has several duplicates of file #10676. Could you tell me the patch or bug id? ___ Reply to this item at: http://gna.org/bugs/?16839 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16844] Base radius_sq fields are encoded as unsigned on network
URL: http://gna.org/bugs/?16844 Summary: Base radius_sq fields are encoded as unsigned on network Project: Freeciv Submitted by: jtn Submitted on: Sunday 10/10/10 at 18:29 Category: general Severity: 2 - Minor Priority: 5 - Normal Status: Ready For Test Assigned to: jtn Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: 2.3.0 ___ Details: In the definition of PACKET_RULESET_BASE, the fields border_sq, vision_main_sq, and vision_invis_sq are defined as UINT8. However, the value -1 is used in these fields to indicate that the effect doesn't apply to this kind of base. Thus, by the time these field values get to the client, they have most likely been mangled to 255. This currently has no effect on the client, but it's about to become important for some documentation patches I'm writing. ___ Reply to this item at: http://gna.org/bugs/?16844 ___ 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 #16844] Base radius_sq fields are encoded as unsigned on network
Additional Item Attachment, bug #16844 (project freeciv): File name: trunk-signed-base-radius-sq.diff Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?16844 ___ 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 #2049] First-class help for bases
Update of patch #2049 (project freeciv): Depends on: = bugs #16844 ___ Reply to this item at: http://gna.org/patch/?2049 ___ 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 #2049] First-class help for bases
Update of patch #2049 (project freeciv): Depends on: = patch #1895 ___ Reply to this item at: http://gna.org/patch/?2049 ___ 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 #2050] First-class help for specialists
URL: http://gna.org/patch/?2050 Summary: First-class help for specialists Project: Freeciv Submitted by: jtn Submitted on: Sunday 10/10/10 at 18:41 Category: docs Priority: 5 - Normal Status: None Privacy: Public Assigned to: jtn Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3.0 ___ Details: The number and type of specialists is defined by the ruleset, but there's no good way for the ruleset to document the effects of custom specialists; and references to the default ruleset's specialists are hard-coded in the help. I propose to add a helptext item to each specialist in cities.ruleset. Also, I intend to add such translatable strings as are necessary to refer to specialists properly throughout the game (noun, plural, etc), allowing me to finish the job started in bug #15710. (Haven't started this patch yet.) ___ Reply to this item at: http://gna.org/patch/?2050 ___ 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 #2050] First-class help for specialists
Update of patch #2050 (project freeciv): Depends on: = patch #1895 ___ Reply to this item at: http://gna.org/patch/?2050 ___ 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 #16847] Clean up list-generating pattern in help
URL: http://gna.org/bugs/?16847 Summary: Clean up list-generating pattern in help Project: Freeciv Submitted by: jtn Submitted on: Sunday 10/10/10 at 20:01 Category: docs Severity: 2 - Minor Priority: 5 - Normal Status: Ready For Test Assigned to: jtn Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: There's a recurring pattern in the help of generating lists of one, two, or more elements separated by or or and. Some of them are a bit grody. While working on patch #2049 I've incidentally harmonised some of them a bit, removing some arbitrary limits in the process. (There's definitely scope for factoring this out further; we could have a couple of functions that take a strvec and format it into and and or separated lists respectively; this could remove a chunk of code from these and other places, such as helptext_government() and techs_with_flag_string(), and centralise the handling of i18n issues. But that's more than I have time for right now.) ___ Reply to this item at: http://gna.org/bugs/?16847 ___ 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 #16847] Clean up list-generating pattern in help
Additional Item Attachment, bug #16847 (project freeciv): File name: trunk-cleanup-list-generation.diff Size:5 KB ___ Reply to this item at: http://gna.org/bugs/?16847 ___ 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 #16849] Cosmetic issue with line breaks in government help
URL: http://gna.org/bugs/?16849 Summary: Cosmetic issue with line breaks in government help Project: Freeciv Submitted by: jtn Submitted on: Sunday 10/10/10 at 20:22 Category: docs Severity: 2 - Minor Priority: 5 - Normal Status: Ready For Test Assigned to: jtn Originator Email: Open/Closed: Open Release: trunk Discussion Lock: Any Operating System: None Planned Release: 2.3.0 ___ Details: The help for governments runs paragraphs together. ___ Reply to this item at: http://gna.org/bugs/?16849 ___ 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 #16849] Cosmetic issue with line breaks in government help
Additional Item Attachment, bug #16849 (project freeciv): File name: trunk-gov-help-paragraphs.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?16849 ___ 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] Tracker statuses (was Re: [bug #16767] fix tech tree after a tech was lost)
Matthias Pfafferodt writes: You are right, this should be noted in the wiki. I would like clear instructions as how to use the assigned field of the bug tracker. Here is a proposal for the wiki entry: ### wiki: http://freeciv.wikia.com/wiki/Commit_rules ### === Normal patches === Patches must be posted to the bug tracker. Grant an adequate period of time before commit to allow comments (minimum 36 hours). If there are comments the patch should be modified accordingly and reposted by one of the interested parties. During this time the status of the patch should be set to ''In Progress''. Wait for comments regarding the modification (minimum 24 hours). Iterate. If there are no more issues to solve set the status of the patch to ''Ready For Test'' and assign it to the one who will commit it. Wait a sufficient time before committing the patch. ### wiki: http://freeciv.wikia.com/wiki/Commit_rules ### This last wait a sufficient time step after the review period is new. Do we need it? How long is this additional delay? (Personally, I think the existing review periods are sufficient to allow testing too.) Also, I think we need indication of when someone's taken a patch and is working on it offline, to avoid both duplication of effort and bugs languishing because everyone thinks someone else is dealing with it. I propose In Progress as the working-on-it-offline state, and Ready For Test as the comments-invited state. That's how I've been using them, anyway. ### start http://freeciv.wikia.com/wiki/Commit_rules proposal ### When you start working on a ticket, ensure that it's assigned to yourself and set the status to ''In Progress'' to avoid duplication of effort. (Corollary: don't take others' ''In Progress'' tickets without asking.) When a patch is ready, it must be posted to the bug tracker and the ticket status set to ''Ready For Test''. Allow an adequate period of time in this state for comments (minimum 36 hours). If there are comments, the patch should be modified accordingly and reposted by one of the interested parties. After reposting, the ticket status should once again be set to ''Ready For Test'' and time allowed for re-review (minimum 24 hours). Iterate. If there are no more issues, the patch may be committed and the ticket closed. ### end http://freeciv.wikia.com/wiki/Commit_rules proposal ### ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16839] cleanup rulesets experimental/multiplayer
Follow-up Comment #3, bug #16839 (project freeciv): Yes, this is bug #16799. ___ Reply to this item at: http://gna.org/bugs/?16839 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Tracker statuses (was Re: [bug #16767] fix tech tree after a tech was lost)
The documentation you propose is exactly what I am trying to do. So, I totally agree about it. Regards, Pepeto Le dimanche 10 octobre 2010 à 20:44 +0100, Jacob Nevins a écrit : Matthias Pfafferodt writes: You are right, this should be noted in the wiki. I would like clear instructions as how to use the assigned field of the bug tracker. Here is a proposal for the wiki entry: ### wiki: http://freeciv.wikia.com/wiki/Commit_rules ### === Normal patches === Patches must be posted to the bug tracker. Grant an adequate period of time before commit to allow comments (minimum 36 hours). If there are comments the patch should be modified accordingly and reposted by one of the interested parties. During this time the status of the patch should be set to ''In Progress''. Wait for comments regarding the modification (minimum 24 hours). Iterate. If there are no more issues to solve set the status of the patch to ''Ready For Test'' and assign it to the one who will commit it. Wait a sufficient time before committing the patch. ### wiki: http://freeciv.wikia.com/wiki/Commit_rules ### This last wait a sufficient time step after the review period is new. Do we need it? How long is this additional delay? (Personally, I think the existing review periods are sufficient to allow testing too.) Also, I think we need indication of when someone's taken a patch and is working on it offline, to avoid both duplication of effort and bugs languishing because everyone thinks someone else is dealing with it. I propose In Progress as the working-on-it-offline state, and Ready For Test as the comments-invited state. That's how I've been using them, anyway. ### start http://freeciv.wikia.com/wiki/Commit_rules proposal ### When you start working on a ticket, ensure that it's assigned to yourself and set the status to ''In Progress'' to avoid duplication of effort. (Corollary: don't take others' ''In Progress'' tickets without asking.) When a patch is ready, it must be posted to the bug tracker and the ticket status set to ''Ready For Test''. Allow an adequate period of time in this state for comments (minimum 36 hours). If there are comments, the patch should be modified accordingly and reposted by one of the interested parties. After reposting, the ticket status should once again be set to ''Ready For Test'' and time allowed for re-review (minimum 24 hours). Iterate. If there are no more issues, the patch may be committed and the ticket closed. ### end http://freeciv.wikia.com/wiki/Commit_rules proposal ### ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16851] use after free by diplomat_bribe()
URL: http://gna.org/bugs/?16851 Summary: use after free by diplomat_bribe() Project: Freeciv Submitted by: kernigh Submitted on: Monday 10/11/2010 at 03:03 Category: None Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: trunk r18200 Discussion Lock: Any Operating System: *BSD Planned Release: ___ Details: The trunk version of diplomat_bribe() continues to use struct unit *pvictim after unit_change_owner() frees it. Longturn players found this problem when LTeX, the Longturn experimental game, crashed after they ported a feature from trunk to their server, which is a variant of Freeciv 2.2.1. http://redmine.pagema.net/issues/237#note-23 Longturn admin Maho made a fix which prevents a failed assertion, but still uses *pvictim after free. Longturn (with the fix) only crashes if I use OpenBSD libc MALLOC_OPTIONS=J to fill the free memory with junk. Gna trunk only crashes if I use MALLOC_OPTIONS=J. I am attaching a slightly different fix (for Gna trunk) which does not crash when I use MALLOC_OPTIONS=J. I am also attaching an example game where a Diplomat can bribe a Galleon. ___ File Attachments: --- Date: Monday 10/11/2010 at 03:03 Name: ptrunk-bribe-unit.diff Size: 1kB By: kernigh proposed fix; example game http://gna.org/bugs/download.php?file_id=10706 --- Date: Monday 10/11/2010 at 03:03 Name: bribe-galleon-trunk.sav.bz2 Size: 11kB By: kernigh proposed fix; example game http://gna.org/bugs/download.php?file_id=10707 ___ Reply to this item at: http://gna.org/bugs/?16851 ___ 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 #2033] Vincentian nation
Update of patch #2033 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?2033 ___ 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 #2051] Yakut nation
URL: http://gna.org/patch/?2051 Summary: Yakut nation Project: Freeciv Submitted by: dmarks Submitted on: Monday 10/11/2010 at 14:20 Category: rulesets Priority: 5 - Normal Status: None Privacy: Public Assigned to: mixcoatl Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: Yakut (Sakha) nation. Flag is adapted from PD image by Zachary Harden. http://commons.wikimedia.org/wiki/File:Flag_of_Sakha.svg ___ File Attachments: --- Date: Monday 10/11/2010 at 14:20 Name: trunk-yakut_nation.diff Size: 4kB By: dmarks http://gna.org/patch/download.php?file_id=10708 --- Date: Monday 10/11/2010 at 14:20 Name: sakha.svg Size: 587B By: dmarks http://gna.org/patch/download.php?file_id=10709 ___ Reply to this item at: http://gna.org/patch/?2051 ___ 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 #2034] Tyrolian nation
Update of patch #2034 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Follow-up Comment #2: I was not completely sure about the license of the previous flag so I used a differnt one, this one was based on http://commons.wikimedia.org/wiki/File:Tirol_Wappen.svg (file #10710) ___ Additional Item Attachment: File name: tyrol.svg Size:219 KB ___ Reply to this item at: http://gna.org/patch/?2034 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
