[Freeciv-Dev] [bug #18767] cma: always 1 tax collector
Follow-up Comment #20, bug #18767 (project freeciv): Just to clarify, the CMA does not look at the value of gold_upkeep_style. I have not looked at, why gold_upkeep_style=2 could resolve the issue (as described in comment #13), as the flawed pruning caused (at least in my game) many unnecessary taxmen, which disappeared with my patch. (Actually using trade as source of gold did not always get considered correctly, which made the CMA use taxmen to reach minimal surplus, even if not necessary.) There remains the rather philosophical question, whether the CMA should consider the minimal surplus of gold for each city with gold_upkeep_style=2, which is already discussed in (comment #12). (In cities, with lots of buildings, setting -20 gold surplus will not suffice to get rid of all taxmen.) However looking at treasury, etc. would make the CMA not only more complicated but a lot more unintuitive, imho. ___ Reply to this item at: http://gna.org/bugs/?18767 ___ Nachricht gesendet von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3718] Use activity icon to hint that fortifying in cities does nothing
Follow-up Comment #2, patch #3718 (project freeciv): Ah, I meant that units which the user has explicitly asked to fortify which are in cities would get the permanent-F state (to indicate that they're not getting a bonus from the user's action), not that all units inside cities without other orders automatically get an 'F' icon (to indicate the automatic defense bonus). (It's good to know that it's not just me that uses fortify to mean go to sleep until I wake you. Perhaps we need such an order for non-CanFortify units?) ___ Reply to this item at: http://gna.org/patch/?3718 ___ 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 #20361] Pathfinding may prefer move+attack to simply attacking adjacent target
Update of bug #20361 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20361 ___ 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 #20520] player_set_nation() assertions failed
Update of bug #20520 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20520 ___ 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 #3704] struct timer cleanup
Update of patch #3704 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3704 ___ 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 #3689] timer_list cleanup
Update of patch #3689 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3689 ___ 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 #3705] Use FC_STATIC_ASSERT() in dataio.c for type size checking
Update of patch #3705 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3705 ___ 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 #20494] Uninitialized PACKET_UNIT_ORDERS
Update of bug #20494 (project freeciv): Assigned to:None = pepeto Planned Release: = 2.3.5, 2.4.0, 2.5.0 ___ Follow-up Comment #4: I vaguely remember thinking this is finally deciding to leave it as it is. Should have added comment at least to remind why exactly so. Probably I were afraid of masking some erronous use before actual send. Well, I checked again, I don't see what's wrong in initializing this structure. I plan to commit the patch. ___ Reply to this item at: http://gna.org/bugs/?20494 ___ 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 #20490] Player owner reconnecting to player while delegate user attached = server assertion failures, crash
Update of bug #20490 (project freeciv): Assigned to:None = pepeto ___ Reply to this item at: http://gna.org/bugs/?20490 ___ 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 #3384] autosettler check current danger
Follow-up Comment #8, patch #3384 (project freeciv): I had a go with this on S2_4, and while workers do now run away from land units unless accompanied by a bodyguard, workers on the coast are still oblivious to a battleship sat next to them. I think this is due to is_square_threatened() calling is_ground_threat(). Given that nothing else uses this function, perhaps it should be changed to not care about the unit move type? ___ Reply to this item at: http://gna.org/patch/?3384 ___ 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 #20508] Nations functional typo fixes
Follow-up Comment #1, bug #20508 (project freeciv): (Committed in r22366 http://svn.gna.org/viewcvs/freeciv?revision=22366view=revision.) ___ Reply to this item at: http://gna.org/bugs/?20508 ___ 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 #2190] Control of registry boolean compability
Follow-up Comment #2, patch #2190 (project freeciv): New version attached (minor change): * Don't allow digital boolean from metaservers (actually there is no boolean read). (file #17259) ___ Additional Item Attachment: File name: secfile_allow_digital_boolean2.diff Size:6 KB ___ Reply to this item at: http://gna.org/patch/?2190 ___ 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 #20361] Pathfinding may prefer move+attack to simply attacking adjacent target
Follow-up Comment #12, bug #20361 (project freeciv): Where this needs more consideration is the experimental ruleset. If the defender is on a tile that the attacker could not enter except via road, then totally negating the road will make the defender unreachable. I don't think this applies to the current experimental ruleset; if attacker is Big Land (e.g. Cannon) and defender is e.g. on a hill, either there's no road on the hill (in which case attack is impossible) or there is one (in which case attack direction doesn't matter; pathfinding will necessarily arrange that the source tile has a road). I don't think it's possible to set things up so that the attacker can only attack the defender from a certain direction. However, we'd certainly like that to become possible (see for instance bug #16383). Will the committed fix need adjusting once cardinal-move-only roads/rivers exist? ___ Reply to this item at: http://gna.org/bugs/?20361 ___ 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 #20361] Pathfinding may prefer move+attack to simply attacking adjacent target
Update of bug #20361 (project freeciv): Operating System: Microsoft Windows = Any ___ Reply to this item at: http://gna.org/bugs/?20361 ___ 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 #20361] Pathfinding may prefer move+attack to simply attacking adjacent target
Follow-up Comment #13, bug #20361 (project freeciv): Will the committed fix need adjusting once cardinal-move-only roads/rivers exist? I don't think so. The last part of the path is considered as a single move only if the move was previously possible. ___ Reply to this item at: http://gna.org/bugs/?20361 ___ 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 #3700] Natural roads
Follow-up Comment #1, patch #3700 (project freeciv): - Updated against svn HEAD (file #17260) ___ Additional Item Attachment: File name: NaturalRoadsNotRestricted-2.patch Size:8 KB ___ Reply to this item at: http://gna.org/patch/?3700 ___ 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 #3714] Remove CardinalOnly road flag
Follow-up Comment #1, patch #3714 (project freeciv): - Do not remove support for drawing cardinal only roads with roadstyles other than River, but just change it so that it's determined from road move_mode - Applies on top of patch #3700 (file #17261) ___ Additional Item Attachment: File name: CardinalOnlyRm-2.patch Size:8 KB ___ Reply to this item at: http://gna.org/patch/?3714 ___ 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 #3710] Use river gfx tags
Update of patch #3710 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3710 ___ 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 #3723] River gfx tag tx.river - river
URL: http://gna.org/patch/?3723 Summary: River gfx tag tx.river - river Project: Freeciv Submitted by: cazfi Submitted on: Tue 19 Feb 2013 12:27:08 PM EET Category: client 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: Replace (hardcoded) river specials tag tx.river with river. We want to use same tags for rivers as road types, and having tx.river for them, to be only later changed, would be stupid. ___ File Attachments: --- Date: Tue 19 Feb 2013 12:27:08 PM EET Name: RiverRoadTag.patch Size: 17kB By: cazfi http://gna.org/patch/download.php?file_id=17262 ___ Reply to this item at: http://gna.org/patch/?3723 ___ 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 #18006] handle_city() CMA: Larvotto has changed multiple times.
Update of bug #18006 (project freeciv): Status:None = Need Info ___ Reply to this item at: http://gna.org/bugs/?18006 ___ 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 #3706] Use TRUE and FALSE instead of 1 and 0 in rulesets
Update of patch #3706 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Follow-up Comment #2: Documentation updated at wikia. ___ Reply to this item at: http://gna.org/patch/?3706 ___ 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 #3706] Use TRUE and FALSE instead of 1 and 0 in rulesets
Follow-up Comment #3, patch #3706 (project freeciv): Documentation updated at wikia. I haven't been following closely. Did this require some code-side change first? That is; does wiki ruleset documentation need to document that this is new behavior in 2.5? Latest freeciv release is 2.3, so documentation in wiki should be usable for 2.3 and 2.4 at least. ___ Reply to this item at: http://gna.org/patch/?3706 ___ 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 #3706] Use TRUE and FALSE instead of 1 and 0 in rulesets
Follow-up Comment #4, patch #3706 (project freeciv): I haven't been following closely. Did this require some code-side change first? That is; does wiki ruleset documentation need to document that this is new behavior in 2.5? Latest freeciv release is 2.3, so documentation in wiki should be usable for 2.3 and 2.4 at least. 'TRUE' and 'FALSE' are compatible with 2.3, so what I edited in the Editing rulesets matches the current version. I added a section about transforming old '0' and '1' only in How to update a ruleset from 2.4 to 2.5. The code-side change will come very quickly, I just removed one part of my patch today, so I didn't commit it yet (patch #2190). ___ Reply to this item at: http://gna.org/patch/?3706 ___ 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 #3707] Use TRUE and FALSE instead of 1 and 0 in tilesets
Update of patch #3707 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Follow-up Comment #2: Documentation updated at wikia. ___ Reply to this item at: http://gna.org/patch/?3707 ___ 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 #20495] punit-activity_count overflow
Update of bug #20495 (project freeciv): Status:None = Need Info ___ Follow-up Comment #1: Noticed that units fortifying have a increasing activity count. I was wrong. The activity of the units with strange activity count were sentry. I found at r5333 http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=5333 that ACTIVITY_SENTRY has been forgotten as activity where activity count is irrelevant. Or may be that count is relevant? I don't think so. The attached patch should fix that count. However, what should be done when loading savegames with such huge activity counts? Also, why do these AI Muskets and Pikemen are sentry? What advantage do they get? I think they should be fortified, shouldn't they? (file #17263) ___ Additional Item Attachment: File name: update_unit_activity_sentry.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?20495 ___ 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 #17216] Need to press 'ok' twice to load a game
Update of bug #17216 (project freeciv): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #3: My original report is the same as bug #17354. Closing this one. ___ Reply to this item at: http://gna.org/bugs/?17216 ___ 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 #17354] Client tries to load game in spawned server before requesting hack access
Follow-up Comment #7, bug #17354 (project freeciv): It happens when you are too fast to push the load button. I guess same thing can happen on scenario. However, the page takes longer to be displayed, I cannot reproduce with it. ___ Reply to this item at: http://gna.org/bugs/?17354 ___ 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 #17354] Client tries to load game in spawned server before requesting hack access
Update of bug #17354 (project freeciv): Status:None = Ready For Test ___ Follow-up Comment #8: The patch I attach fix the problem for me. But it also delays for a while the apparition of the load or scenario page. It actually wait for the server to process the last packet (JOIN_REQ or maybe preferred settings) before actually switching to the page. Note that the load or the scenario page doesn't appear at all if we fails to start the server. This is not the current behaviour, but I guess this is what the users expect. (file #17264) ___ Additional Item Attachment: File name: client_start_server_and_set_page.diff Size:3 KB ___ Reply to this item at: http://gna.org/bugs/?17354 ___ 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 #20533] Missing building gfx for experimental ruleset: Hospital, Genetic Lab
URL: http://gna.org/bugs/?20533 Summary: Missing building gfx for experimental ruleset: Hospital, Genetic Lab Project: Freeciv Submitted by: jtn Submitted on: Tue Feb 19 21:31:50 2013 Category: art Severity: 3 - Normal Priority: 3 - Low Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: The experimental ruleset has a couple of buildings without icons. (Also on trunk it lacks Maglev graphics, but that's already covered by bug #20031.) Not sure how much effort to sink into experimental graphics, given that we're more likely to invent buildings/techs etc on a whim for it. But we've had these for a while and lack of icons does mess up the city / worklist view a bit. ___ Reply to this item at: http://gna.org/bugs/?20533 ___ 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 #20534] Worklist glitch: unit icons bleed past their boundaries
URL: http://gna.org/bugs/?20534 Summary: Worklist glitch: unit icons bleed past their boundaries Project: Freeciv Submitted by: jtn Submitted on: Tue Feb 19 22:47:35 2013 Category: client-gtk-2.0 Severity: 2 - Minor Priority: 3 - Low Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: GNU/Linux Planned Release: ___ Details: This is very cosmetic, but it's been bothering me for years. In the worklist, unit icons which have pixels set at their vertical edges have those pixel columns bled out into bands horizontally. See attached screenshot of Freight, and also bug #15777's file #8785 for a previous example. In Amplio/2 I think unit icons are a little narrower than building/wonder icons, which force column width; I'm guessing that something is extending the unit icon to match the containing cell in a sub-optimal way. Really we just want whitespace padding. Dunno if this is specific to OS (Ubuntu 10.04.4), window environment (GNOME, Compiz), theme (Freeciv for client, Ambiance for desktop), ... It's been with me with the gtk2 client for at least three years, probably longer. ___ File Attachments: --- Date: Tue Feb 19 22:47:35 2013 Name: worklist_glitch_freight.png Size: 10kB By: jtn Glitch in city worklist, trunk r22387 http://gna.org/bugs/download.php?file_id=17267 ___ Reply to this item at: http://gna.org/bugs/?20534 ___ 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 #20534] Worklist glitch: unit icons bleed past their boundaries
Follow-up Comment #1, bug #20534 (project freeciv): (FWIW, my previous notes on the issue in their entirety: client/gui-gtk-2.0/wldlg.c:cell_render_func(). Make of that what you will.) ___ Reply to this item at: http://gna.org/bugs/?20534 ___ 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 #20535] Road icons in editor are a bit ugly
URL: http://gna.org/bugs/?20535 Summary: Road icons in editor are a bit ugly Project: Freeciv Submitted by: jtn Submitted on: Tue Feb 19 22:56:03 2013 Category: editor Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: GNU/Linux Planned Release: 2.5.0 ___ Details: See attachment. * They seem to be off-centre * They suffer from the same bleeding problem as bug #20534, only vertically Obviously not vital, but would be nice to fix. ___ File Attachments: --- Date: Tue Feb 19 22:56:03 2013 Name: editor_roads.png Size: 19kB By: jtn screenshot of road selection in gtk2 editor, trunk r22387 http://gna.org/bugs/download.php?file_id=17268 ___ Reply to this item at: http://gna.org/bugs/?20535 ___ 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 #20536] Missing icon for roads in editor
URL: http://gna.org/bugs/?20536 Summary: Missing icon for roads in editor Project: Freeciv Submitted by: jtn Submitted on: Tue Feb 19 23:00:20 2013 Category: art Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: Any Planned Release: 2.5.0 ___ Details: Currently we're using one that I think must have been originally intended for editable borders, which doesn't look quite right. It can be seen in file #17268. Would be nice to have something better for 2.5.0. Relevant file is data/misc/editor.png. ___ Reply to this item at: http://gna.org/bugs/?20536 ___ 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 #3724] Alien ruleset: colours tied to nations?
URL: http://gna.org/patch/?3724 Summary: Alien ruleset: colours tied to nations? Project: Freeciv Submitted by: jtn Submitted on: Tue Feb 19 23:33:10 2013 Category: rulesets Priority: 1 - Later Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: I like nations to have particular colours associated with them (for borders, etc), especially if they have distinct traits; it adds to their character and the general atmosphere, and you can have different shades for normal players vs barbarians (dark colours), etc. Clearly impractical for our huge default nation set, but the set of nations in the Alien World ruleset is small enough that this would be practical. In file #16384 (woo) I put an example patch. I didn't think about the colours terribly hard (although IIRC they are picked from the carefully-distinguishable set added in bug #19778), so I'm not wedded to them. However, I leave the decision to cazfi since it's his ruleset; feel free to Wont Do. ___ Reply to this item at: http://gna.org/patch/?3724 ___ 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 #20507] Barbarian nations in unknown group in civ2 ruleset
Follow-up Comment #1, bug #20507 (project freeciv): I think it's harmless. Certainly when I just tested civ2, I had no trouble running into pirates. The obvious way to fix it is to fork barbarian/pirate nations, the same way all the other civ2 nations are forked. (Did civ2 even have pirates?) ___ Reply to this item at: http://gna.org/bugs/?20507 ___ 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 #20501] Help could be clearer about CanFortify defence bonus vs cities
Update of bug #20501 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed Planned Release: 2.3.5,2.4.0,2.5.0 = 2.4.0,2.5.0 ___ Reply to this item at: http://gna.org/bugs/?20501 ___ 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 #3717] Pluralised i18n markup for %d population text
Update of patch #3717 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed Planned Release: 2.3.5,2.4.0,2.5.0 = 2.4.0,2.5.0 ___ Reply to this item at: http://gna.org/patch/?3717 ___ 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 #20390] Québec civilisation name lacks capital letter in Spanish translation
Update of bug #20390 (project freeciv): Status:None = Fixed Assigned to:None = jorneg Open/Closed:Open = Closed Planned Release: = 2.3.4,2.4.0 Summary:Civ name = Québec civilisation name lacks capital letter in Spanish translation ___ Follow-up Comment #5: Fixed in r22105 http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=22105 on S2_3, r22104 http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=22104 on S2_4. ___ Reply to this item at: http://gna.org/bugs/?20390 ___ 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 #20236] Failure to load saved game
Update of bug #20236 (project freeciv): Status:None = Need Info ___ Reply to this item at: http://gna.org/bugs/?20236 ___ 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 #19868] Network protocol documentation
Follow-up Comment #6, bug #19868 (project freeciv): Attached is a version of the patch updated to svn trunk revision 22384 and a file containing the data it is based on. Should a multi line comment end in a blank line ( * last linen */)? Should comments I only change a part of be updated to the new style (include a * on new lines) I have tried to follow If you need to comment a declared variable, it should be as such: from the code style unless all variables / constants in a block is used. In fc_types this has resulted in a block like this: #define MAX_NUM_PLAYER_SLOTS 128 /* Used in the network protocol. */ #define MAX_NUM_BARBARIANS 2 #define MAX_NUM_PLAYERS MAX_NUM_PLAYER_SLOTS - MAX_NUM_BARBARIANS #define MAX_NUM_CONNECTIONS (2 * (MAX_NUM_PLAYER_SLOTS)) /* Used in the * protocol. */ #define MAX_NUM_ITEMS 200 /* eg, unit_types * Used in the network protocol */ #define MAX_NUM_TECH_LIST 10 /* Used in the network protocol. */ #define MAX_NUM_UNIT_LIST 10 /* Used in the network protocol. */ #define MAX_NUM_BUILDING_LIST 10 /* Used in the network protocol. */ #define MAX_LEN_VET_SHORT_NAME 8 #define MAX_VET_LEVELS 20 /* see diplomat_success_vs_defender() * Used in the network protocol */ #define MAX_BASE_TYPES 32 /* Used in the network protocol. */ #define MAX_ROAD_TYPES 8 /* Used in the network protocol. */ #define MAX_DISASTER_TYPES 10 #define MAX_NUM_LEADERS MAX_NUM_ITEMS /* Used in the network protocol. */ #define MAX_NUM_NATION_GROUPS 128 /* Used in the network protocol. */ #define MAX_NUM_STARTPOS_NATIONS 1024 /* Used in the network protocol. */ Should it be kept like it is, should I separate the constants used in the protocol to a commented section (like the one below, even if it makes the stronger claim that this will probably break network compatability) or include a comment that most constants in this section is used in the network protocol? (file #17269, file #17270) ___ Additional Item Attachment: File name: labelProtoChangesDraft.patch Size:16 KB File name: packetsDependOnSize:3 KB ___ Reply to this item at: http://gna.org/bugs/?19868 ___ 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 #3724] Alien ruleset: colours tied to nations?
Update of patch #3724 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi ___ Follow-up Comment #1: That's something I have wanted to do, but not in high enough priority to do so far ;-) Thanks for selecting the colours. Note that I'm not very fond of comical alien ruleset nations in general. They're just somehing I could quickly invent to be used instead of default nations (default nations were even worse in alien ruleset) ___ Reply to this item at: http://gna.org/patch/?3724 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
