Update of bug #20752 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of patch #3859 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Update of patch #3860 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Update of patch #3861 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #20753 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Is it possible to
URL:
http://gna.org/bugs/?20761
Summary: Illegal treaty lives forever
Project: Freeciv
Submitted by: cazfi
Submitted on: Tue 23 Apr 2013 12:17:42 PM EEST
Category: ai
Severity: 3 - Normal
Follow-up Comment #1, bug #20761 (project freeciv):
it's probably bug that they end in such a situation even if tech
loss is involved
That's probably caused by more general Unaccepted treaty lives forever
-issue. As far as I can see treaty between AI players is never rejected or
cancelled.
Follow-up Comment #2, bug #20761 (project freeciv):
A simple solution would seem to be to iterate over open treaties at the
beginning of players_iterate_alive{} in dai_diplomacy_actions() (near the Try
to make peace... comment), closing any that are unacceptable to the player on
whose behalf the
Follow-up Comment #4, patch #3721 (project freeciv):
Not being thread safe isn't just about whether the client is multithreaded.
The entire computational system (client+server) has at least two threads, and
if I read unit_move() correctly, send_unit_info_to_onlookers() is called a few
times
Update of bug #20744 (project freeciv):
Status: Ready For Test = Fixed
Assigned to:None = cazfi
Open/Closed:Open = Closed
Update of bug #20751 (project freeciv):
Status: Ready For Test = Fixed
Assigned to:None = cazfi
Open/Closed:Open = Closed
Follow-up Comment #5, patch #3721 (project freeciv):
Oh, you were talking about server/client sync. Yes, even though client is
single-threaded, and in that sense does a lot of things atomically, user
action can happen between any two packets from server.
As for transport and cargo being in
Follow-up Comment #14, patch #3826 (project freeciv):
Shipping rulesets have no bases surviving in the cities, but if we are adding
it as a feature for ruleset, it should work. Note that almost any ruleset
where some base can exist in city is subject to superior nation conquered
city from weaker
URL:
http://gna.org/patch/?3877
Summary: Explain Alien ruleset unit Rex name
Project: Freeciv
Submitted by: cazfi
Submitted on: Tue 23 Apr 2013 11:21:14 PM EEST
Category: rulesets
Priority: 5 - Normal
Follow-up Comment #15, patch #3826 (project freeciv):
My apologies. I suppose I'm used to significantly less mature projects, where
a feature freeze tends to happen only immediately prior to release (but
releases correspondingly tend to be buggier without the overlap).
Attached is a patch with
Follow-up Comment #1, bug #20634 (project freeciv):
This has actually happened with all the alternating movement autogames I've
run since in S2_4, one or two every day, while there can go full week without
me seeing any other error from any of the 10 other tests.
As there's code to fix the
Update of patch #3872 (project freeciv):
Status: In Progress = Ready For Test
___
Follow-up Comment #1:
- Converted more base claim iterations to call tile_claim_bases() instead
- Actually set
Follow-up Comment #1, patch #3873 (project freeciv):
- Reclaim existing bases on tile only if owner changes
- Set correct tile.extras_owner
(file #17817)
___
Additional Item Attachment:
File name: ClaimCreatedBase-2.patch Size:1 KB
URL:
http://gna.org/patch/?3878
Summary: Buoys without border claiming
Project: Freeciv
Submitted by: cazfi
Submitted on: Wed 24 Apr 2013 01:24:27 AM EEST
Category: rulesets
Priority: 5 - Normal
Follow-up Comment #2, patch #3630 (project freeciv):
- Set correct extras_owner when creating virtual tile
(file #17819)
___
Additional Item Attachment:
File name: BaseOwner-3.patch Size:11 KB
Follow-up Comment #8, bug #19846 (project freeciv):
gtk+ bug is now RESOLVED FIXED. That leaves us to figure out how to live with
buggy versions.
What distributions are affected? I know all too well that Debian Wheezy (to be
released 4/5 May weekend) is. Probably recent Ubuntu versions are too
Follow-up Comment #1, patch #3863 (project freeciv):
- Reworded to make clear it's gtk+ bug, not freeciv bug
observed with some gtk+ versions.
- Added link to gtk+ bug ticket
(file #17820)
___
Additional Item Attachment:
File name:
Follow-up Comment #9, bug #19846 (project freeciv):
Ubuntu and Debian historically diverge in libgtk update timing and history.
Current revisions in releases:
Debian Wheezy: 3.4.2
Debian Experimental: 3.8.0
Ubuntu Oneiric: 3.2.0
Ubuntu Precise:3.4.2
Ubuntu Quantal: 3.6.0
Ubuntu Raring: 3.6.4
URL:
http://gna.org/patch/?3879
Summary: Remove negated reqs{} field in favor of something
semantically nicer
Project: Freeciv
Submitted by: persia
Submitted on: Wed 24 Apr 2013 09:52:01 AM JST
Category: rulesets
Follow-up Comment #4, patch #3332 (project freeciv):
For completeness, although I am not in favor of nreqs{} support everywhere, I
prepared a patch with similar effect (and entirely different implementation)
as part of discussion in patch #3879. While I don't know I will be proposing
that for
Follow-up Comment #1, patch #3697 (project freeciv):
Attached is a patch that seems to work for me. Note that the increase in
appeal for the improvements is essential here: early revisions of the patch
didn't include that, with the result that when the granary was full, the AI
deprioritised
Follow-up Comment #1, patch #3879 (project freeciv):
or by changing the word used to be something positive.
I agree.
Note that the introduction of nreqs uses an entirely different mechanism than
that suggested in patch #3332
The mechanism was wrong and my original idea was confuse. My purpose was
27 matches
Mail list logo
