URL:
http://gna.org/bugs/?20525
Summary: Unused message for /delegate command
Project: Freeciv
Submitted by: pepeto
Submitted on: lun. 18 févr. 2013 10:42:50 CET
Category: general
Severity: 3 - Normal
URL:
http://gna.org/patch/?3717
Summary: Pluralised i18n markup for %d population text
Project: Freeciv
Submitted by: jtn
Submitted on: Mon Feb 18 09:43:01 2013
Category: docs
Priority: 3 - Low
Update of bug #20525 (project freeciv):
Assigned to:None = jtn
___
Follow-up Comment #1:
I have a WIP patch cleaning up the strings for delegation, and I had also
concluded that this
Update of bug #20514 (project freeciv):
Assigned to:None = pepeto
Release:S2_2, S2_3, S2_4 = S2_3, S2_4
Planned Release: 2.4.0 = 2.3.5, 2.4.0
Update of bug #20514 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Freeciv 2.3.4 is now available for download.
This release fixes a variety of bugs in 2.3.3, notably a client crash
triggered by chat messages. See more details at
http://www.freeciv.org/wiki/NEWS-2.3.4, or NEWS-2.3 in the source
distribution.
Source code is available from
Update of patch #3646 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
URL:
http://gna.org/patch/?3718
Summary: Use activity icon to hint that fortifying in cities
does nothing
Project: Freeciv
Submitted by: jtn
Submitted on: Mon Feb 18 10:00:44 2013
Category: general
Update of bug #20086 (project freeciv):
Status: In Progress = Ready For Test
___
Reply to this item at:
http://gna.org/bugs/?20086
___
Message posté
Follow-up Comment #4, bug #20501 (project freeciv):
I vaguely wonder about making this clearer in the UI [...]
Raised separately as patch #3718.
Then there are Worker-type units, which gui shortcut 'f' makes
to build fortress instead of fortifying. They still have
CanFortify flag, so I
Update of bug #20501 (project freeciv):
Status:None = Ready For Test
Planned Release: = 2.3.5,2.4.0,2.5.0
___
Follow-up Comment #5:
Patch applies to
Update of patch #3717 (project freeciv):
Status: In Progress = Ready For Test
Planned Release: 2.4.0,2.5.0 = 2.3.5,2.4.0,2.5.0
___
Follow-up Comment #1:
Patch applies to
Update of bug #20517 (project freeciv):
Status: Ready For Test = Need Info
___
Follow-up Comment #2:
When applying this patch, we may be confronted for the same problem as bug
#20520 if both
Update of bug #19814 (project freeciv):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Discussion is
Update of patch #3698 (project freeciv):
Status:None = In Progress
Assigned to:None = pepeto
___
Reply to this item at:
Update of bug #19868 (project freeciv):
Assigned to:None = pepeto
___
Follow-up Comment #3:
Could you update this patch against current trunk and avoid usage of C++-style
comments //?
I wrote:
Freeciv 2.3.4 is now available for download.
Here are the translation stats.
ca: 100%: 6302 translated.
fr: 100%: 6302 translated.
gd: 100%: 6302 translated.
es: 100%: 6302 translated.
pl: 100%: 6302 translated.
ja: 99.8%: 6291 translated, 10 fuzzy, 1 untranslated.
fi: 98.4%: 6201
Follow-up Comment #2, task #7327 (project freeciv):
If we should use doxygen documentation, shouldn't we begin to use doxygen
syntax in the new comments? And add new comments about it in the CodingStyle
section?
___
Reply to this item at:
Follow-up Comment #11, bug #19943 (project freeciv):
New version of the patch attached:
* move all the process into packets.c, using post-send and post-recv routines
;
* more comments.
(file #17247)
___
Additional Item Attachment:
File
Update of bug #20517 (project freeciv):
Status: Need Info = Ready For Test
Assigned to:None = pepeto
Planned Release: = 2.3.5, 2.4.0, 2.5.0
Follow-up Comment #4, bug #20517 (project freeciv):
I have no idea why patches for S2_3 and S2_4 have been truncated.
Also, notice that it solves the failed assertions of bug #20520.
(file #17251, file #17252)
___
Additional Item
Follow-up Comment #7, bug #16905 (project freeciv):
For the UI:
How about avoiding yet more focus-stealing popups, or at least making that
behaviour optional? Here's my strawman proposal that would also transfer to
telling Engineers to irrigate here, then go there and build a road.
With
Follow-up Comment #6, bug #20501 (project freeciv):
I haven't played with autoattack, but this sounds like a bug to me. Can you
raise a
new ticket about this with some more detail?
Let me set up a reproducible test case.
___
Reply to
Follow-up Comment #4, bug #19868 (project freeciv):
Could you update this patch against current trunk and avoid usage of
C++-style comments //?
Yes. No C++-style comments. As the editing of text currently is done manually
I want to be sure I don't do it wrong: Should I merge the information
Follow-up Comment #5, bug #19868 (project freeciv):
Should I merge the information into existing comments where
those exist (looks better) or add it separately (more grep
friendly)?
I think you can merge with existing comments.
Is the current text in the comment (Used in the network
Update of patch #3458 (project freeciv):
Planned Release: = 2.6.0
___
Follow-up Comment #1:
If done before current roads saving format gets in to official
release
Then again, it would
Follow-up Comment #1, task #7665 (project freeciv):
The installer packages are ready now. I tried to update the Wiki, but the edit
page only showed Loading editor and nothing more happened.
___
Reply to this item at:
Update of task #7665 (project freeciv):
Status:None = Done
Percent Complete: 0% = 100%
Open/Closed:Open = Closed
Follow-up Comment #1, patch #3713 (project freeciv):
Slight variation suggested by Bernd Jendrissek at bug #16905 comment 7.
___
Reply to this item at:
http://gna.org/patch/?3713
___
Follow-up Comment #8, bug #16905 (project freeciv):
How about avoiding yet more focus-stealing popups, [...]
Did you see patch #3713?
Anyway, I think popups still have a place (for new users or those who don't
want to remember the keys), and would like for them to no longer be
focus-stealing.
Follow-up Comment #2, bug #20522 (project freeciv):
It's calculating general UTYF_SETTLERS want, not that of
specific unit type.
Hm, yes, good point.
Still, this can't be helping with the AI's reluctance to improve food
production, can it?
In somewhat related note it's not necessarily good
Almost exactly a year ago, I wrote a long idea about a UI for coping
with generic roads and bases. I've reproduced it below.
Does anyone fundamentally object to this sort of thing in principle? If
not, I'll raise a ticket and, who knows, maybe one day even look at
implementing it.
Previously I
Follow-up Comment #5, bug #18040 (project freeciv):
I wondered if patch #3620 would help with this. It does fix the two cases
described here.
The behaviour previously described here is still reproducible with S2_4
immediately prior to the fix (r22344). After updating to the svn revision of
the
Follow-up Comment #18, bug #18767 (project freeciv):
Checking Echter Name's savegame (file #15373), in the one city I checked
(11z+Frres), there was a single taxman cost of buildings was 20 and issue
went away with gold_upkeep_style=2. So I think that it shows the same issue.
(S2_4 r22344.)
Follow-up Comment #19, bug #18767 (project freeciv):
...and checking before-and-after patch #3620 on S2_4 (this time with the
savegames in bug #17542), the spurious taxmen which were reproducible before
and went away with gold_upkeep_style=2 now never show up; governor
decisions/output seem the
Follow-up Comment #4, bug #17542 (project freeciv):
As noted in bug #18767: patch #3620 appears to get rid of the unwanted tax
collectors regardless of gold_upkeep_style.
___
Reply to this item at:
http://gna.org/bugs/?17542
Follow-up Comment #10, patch #3620 (project freeciv):
In my testing, this patch does look to fix bug #18040, and also gets rid of
the gold_upkeep_style-dependent tax collectors of bug #18767 / #17542.
___
Reply to this item at:
Follow-up Comment #3, bug #20522 (project freeciv):
It's calculating general UTYF_SETTLERS want, not that of
specific unit type.
Hm, yes, good point.
...although the logic in patch #3693 (food upkeep) is unit-type-specific,
isn't it? It could be worrying about Settlers' food upkeep even if it
Follow-up Comment #2, bug #20484 (project freeciv):
(Committed as r22363
http://svn.gna.org/viewcvs/freeciv?revision=22363view=revision, r22364
http://svn.gna.org/viewcvs/freeciv?revision=22364view=revision, r22365
http://svn.gna.org/viewcvs/freeciv?revision=22365view=revision.)
Follow-up Comment #3, bug #20511 (project freeciv):
I haven't spotted where this function is used? Am I being a doofus?
___
Reply to this item at:
http://gna.org/bugs/?20511
___
Message
Follow-up Comment #4, bug #20511 (project freeciv):
I don't think it is used anywhere at the moment, but patch #3384 will use it.
___
Reply to this item at:
http://gna.org/bugs/?20511
___
Follow-up Comment #4, bug #20522 (project freeciv):
...although the logic in patch #3693 (food upkeep) is unit-type
specific, isn't it? It could be worrying about Settlers' food
upkeep even if it would end up building Workers?
Yes. Though this (and pop cost part too) might work perfectly at
Follow-up Comment #5, patch #2951 (project freeciv):
But as everything is just transitional phase to next, in a
decade we may be able to combine bases and roads back to one
specials concept. ;-)
Updating my plans here once more, even this is going a bit off the original
ticket.
In 2.6 there
On 19 February 2013 00:16, Jacob Nevins
0jacobnk.fc...@chiark.greenend.org.uk wrote:
Almost exactly a year ago, I wrote a long idea about a UI for coping
with generic roads and bases. I've reproduced it below.
Does anyone fundamentally object to this sort of thing in principle? If
not, I'll
Follow-up Comment #1, patch #3699 (project freeciv):
- Updated against svn HEAD.
(file #17254)
___
Additional Item Attachment:
File name: HandleRulesetErrors-2.patch.bz2 Size:7 KB
Update of patch #3384 (project freeciv):
Status: Ready For Test = Done
Assigned to:None = cazfi
Open/Closed:Open = Closed
Update of patch #3703 (project freeciv):
Status: Ready For Test = Done
Assigned to:None = cazfi
Open/Closed:Open = Closed
Follow-up Comment #1, patch #3718 (project freeciv):
How can I then tell which units are active (will get focus) and which are
really fortifying/fortified? When activating large number of units fortified
inside city this becomes really important. I don't want to use S)entry to keep
units in
Follow-up Comment #2, patch #3711 (project freeciv):
About obscuring the action, i wonder if it wouldn't be better if all other
unit movements pause until the popup has been dealt with. But, i understand
that would come with its own problems.
About forgetting that a caravan is ready, i don't
Update of patch #3694 (project freeciv):
Status:None = Done
Assigned to:None = cazfi
Open/Closed:Open = Closed
URL:
http://gna.org/patch/?3719
Summary: Distributing cimpletoon .blend sources
Project: Freeciv
Submitted by: cazfi
Submitted on: Tue 19 Feb 2013 07:09:07 AM EET
Category: None
Priority: 5 - Normal
URL:
http://gna.org/patch/?3720
Summary: Bump estimated 2.4.0 release month to June
Project: Freeciv
Submitted by: cazfi
Submitted on: Tue 19 Feb 2013 07:51:43 AM EET
Category: bootstrap
Priority: 5 -
URL:
http://gna.org/patch/?3721
Summary: Getting rid of move_type dependency on unitselect
dialog
Project: Freeciv
Submitted by: cazfi
Submitted on: Tue 19 Feb 2013 09:27:44 AM EET
Category: client
URL:
http://gna.org/patch/?3722
Summary: Move ai_find_source_building() to ai code
Project: Freeciv
Submitted by: cazfi
Submitted on: Tue 19 Feb 2013 09:50:52 AM EET
Category: ai
Priority: 5 - Normal
54 matches
Mail list logo
