Update of patch #2695 (project freeciv):
Status:None = Ready For Test
Assigned to:None = cazfi
Planned Release: = 2.3.0, 2.4.0
Update of patch #2696 (project freeciv):
Status:None = Ready For Test
Assigned to:None = cazfi
Planned Release: = 2.3.0, 2.4.0
Update of patch #2697 (project freeciv):
Category:None = docs
Status:None = Ready For Test
Assigned to:None = cazfi
Planned Release:
Update of patch #2698 (project freeciv):
Status:None = Ready For Test
Assigned to:None = cazfi
Planned Release: = 2.3.0, 2.4.0
URL:
http://gna.org/bugs/?18191
Summary: transfer_city() callers are not prepared for city
destruction
Project: Freeciv
Submitted by: cazfi
Submitted on: Tue 07 Jun 2011 11:59:47 AM EEST
Category: general
Follow-up Comment #3, bug #17816 (project freeciv):
Findings so far:
- City size has not recently changed, so problem is in increasing citizen
count when city does not grow.
- Last time information of city was sent without problems, it had just 4
workers
- City has 4 workers and one elvis. Note
Follow-up Comment #4, bug #17816 (project freeciv):
Turns out to be rather complicated one to track down.
Anyway, there's suspicious code in city_reduce_size() that might be related
(or bug of its own):
map_clear_border(pcity-tile);
city_size_add(pcity, -pop_loss);
Follow-up Comment #9, bug #17962 (project freeciv):
What kind of hardware you have? I just wonder if this could be simply problem
of map generation taking so long that connection between client and server
timeouts? Or server running out of memory for such a massive map?
I wonder if there is people lurking on this mailing list wanting to
start contributing to freeciv, but don't really know what to work on.
We do have some areas where we really would have use for some help. As
you can see, we basically would want someone taking active role with
each client.
Follow-up Comment #10, bug #18005 (project freeciv):
Can you test if the patch I provided in comment #7 fixes the assert problem?
It's the more important one, client using a bit more memory than it would
actually need is less urgent.
___
Update of bug #18005 (project freeciv):
Category:None = client
Status:None = Ready For Test
Planned Release: 2.3.0 = 2.3.0, 2.4.0
Update of bug #17748 (project freeciv):
Status:None = Invalid
Assigned to:None = cazfi
Open/Closed:Open = Closed
Update of bug #18182 (project freeciv):
Status:None = In Progress
___
Follow-up Comment #3:
The Batswana and Botswanans
(file #13129, file #13130, file #13131)
Update of bug #18182 (project freeciv):
Status: In Progress = Ready For Test
___
Follow-up Comment #4:
and the Bashoto and Lesothoans
I'm not really sure how Bantustan symbolism is regarded
Update of patch #2687 (project freeciv):
Status:None = In Progress
___
Follow-up Comment #1:
We've got quite a lot of North American Native nations now; maybe it's a good
idea to make an
Update of bug #17990 (project freeciv):
Status: Confirmed = Ready For Test
___
Reply to this item at:
http://gna.org/bugs/?17990
___
Message sent
Follow-up Comment #11, bug #17990 (project freeciv):
Funny thing is that I remember fixing exactly this several years
ago, but there's no trace of my fix any more. Someone has
optimized out what he considered redundant city update?
Looks like this was removed as part of the fix for bug
Follow-up Comment #12, bug #18005 (project freeciv):
I've confirmed I can still reproduce the asserts per comment #5 with the
latest trunk (r19694), and that the patch makes them go away. Hurrah.
___
Reply to this item at:
Update of bug #17990 (project freeciv):
Status: Ready For Test = In Progress
___
Follow-up Comment #13:
Yes, there certainly is more than one bug in play. At least for anything
units related you
Follow-up Comment #4, bug #18007 (project freeciv):
Possibly related: there are two special tiles that are
unworkable to me and are marked as 'occupied' by somebody else,
and nobody else is there... The tiles in question are (2, 21)
and (2, 24) - both near cities that i've recently
Follow-up Comment #4, bug #17860 (project freeciv):
Certainly bug #17990 at least affects this bug. There might be separate bug,
but it wouldn't appear like it does now without bug #17990.
For one, that backtrace would be different if results from some if
(city_owner(pcity) == client_player())
URL:
http://gna.org/bugs/?18194
Summary: Client has out-of-date info about units transferred
when city lost
Project: Freeciv
Submitted by: jtn
Submitted on: Tue Jun 7 23:07:41 2011
Category: None
Follow-up Comment #14, bug #17990 (project freeciv):
Units problem raised separately as bug #18194.
___
Reply to this item at:
http://gna.org/bugs/?17990
___
Message sent via/by Gna!
Follow-up Comment #5, bug #18007 (project freeciv):
I'm guessing that this is one of those things that doesn't
survive a save/load?
Or client in original game had somehow gotten out of sync about worked tiles.
Now save/load would restore (correct) server view, and it's also told to
client.
Update of patch #2679 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #1, patch #2688 (project freeciv):
In bug #16471 cazfi asks:
I haven't checked [syntron's linebreak patch -- file #11988],
but does it insert linebreak at exactly 80 characters even if
that's in the middle of a word?
It calls astr_break_lines(), which calls
Update of bug #17990 (project freeciv):
Status: In Progress = Ready For Test
___
Follow-up Comment #15:
- Take those having shared vision pact with city giver in to account
(file #13135)
Follow-up Comment #16, bug #17990 (project freeciv):
New patch works just as well for me (my case didn't involve shared vision).
(NB, it doesn't apply cleanly to trunk, but it's trivial to fix up.)
___
Reply to this item at:
On 7 Jun, 2011, at 9:32 AM, Marko Lindqvist wrote:
Qt-client development
Again, someone should take active role in Qt-client development if we
want to see it forward. It was my original intend when I started that
client that development should be later given to someone else, but as
plan B
29 matches
Mail list logo
