[Freeciv-Dev] [bug #20752] Errors in nation rulesets cause spurious messages about lack of defined barbarians
Update of bug #20752 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20752 ___ 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 #3859] Nations ruleset: move government compatibility checking to nationlist.ruleset
Update of patch #3859 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3859 ___ 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 #3860] Nations ruleset: allow terrain checking against explicit compatibility list
Update of patch #3860 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3860 ___ 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 #3861] Nations ruleset: replace warn_city_style with allowed_city_styles
Update of patch #3861 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3861 ___ 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 #20753] is_available in nation rulesets does nothing
Update of bug #20753 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: Is it possible to have nation that one cannot select in the beginning, but which still can appear through civil war during the game? I don't think so, offhand. I think civil war nation selection ignores conflicts_with (which is usually set by ruleset authors to avoid flag clashes etc), but I don't think conflicts_with restricts nation selection by players anyway. ___ Reply to this item at: http://gna.org/bugs/?20753 ___ 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 #20761] Illegal treaty lives forever
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 Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: I got treaty between two AI players that they are unable to accept due to one of them not having the tech he is supposed to give away (it's probably bug that they end in such a situation even if tech losss is involved). As handle_diplomacy_accept_treaty_req() aborts early, treaty is never removed. Each turn the AIs try to enter ceasefire, but new clauses are just added to the illegal treaty they cannot accept. ___ Reply to this item at: http://gna.org/bugs/?20761 ___ 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 #20761] Illegal treaty lives forever
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. It's either accepted or waits acceptance forever, even if it turns to illegal one over time. Main problem in such active treaties is that they block all future diplomacy between the players (players cannot even enter ceasefire once there has been proposal the other party didn't want to accept sometime in the past) ___ Reply to this item at: http://gna.org/bugs/?20761 ___ 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 #20761] Illegal treaty lives forever
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 function is running prior to determining if new clauses
should be proposed. I'm presuming that when an AI player submits a proposal,
their evaluation loop is suspended whilst the respondant considers it, but I
haven't read enough of the AI diplomacy code to be sure of this: if this
assumption is invalid, so is this suggestion.
For AI-AI diplomacy, this would provide a mechanism to avoid the described
problem. For AI-Human diplomacy, it would avoid Humans having unacceptable
treaty windows sit open for a long time (perhaps as a means of judging current
AI love, by whether a given pact happens to immediately be acceptable).
___
Reply to this item at:
http://gna.org/bugs/?20761
___
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 #3721] Getting rid of move_type dependency on unitselect dialog
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 before the transported units are moved, so that there is a window during which the client sees the transporting unit moved and the transported units not yet moved, because the client thread (the single thread of the client process) isn't waiting for the server to finish with unit_move_handling() to do the next action. In practice, the situation described above would require either extremely variable network latency or a vast disparity in computational power between the client and the server, but this definitely conceivable with a fast gaming PC running the client and a heavily-loaded public internet server running on aging donated hardware in the lowest QoS band of some oddly-connected data centre. Note that in the situation above, although the units are on different tiles, they still believe themselves to be transported, so by querying transport status, the information collected can be expected to also be reliable once the server has finished processing the move (and since the information that the transport is no longer occupied is sent before the information that the unit has moved, the opposite case (thinking a unit is in a transport when it has in fact moved out) will never occur with the current code). ___ Reply to this item at: http://gna.org/patch/?3721 ___ 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 #20744] Recursive wipe_unit() saving drowning units from calling wipe_unit()
Update of bug #20744 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20744 ___ 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 #20751] assertion 'normal_player_count() = game.server.max_players' failed
Update of bug #20751 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20751 ___ 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 #3721] Getting rid of move_type dependency on unitselect dialog
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 different tiles, that can certainly happen - we've just been fixing entire class of bugs when client does (even without user interaction) illegal things while that's the case. ___ Reply to this item at: http://gna.org/patch/?3721 ___ 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 #3826] Allow bases on city tiles
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 enemy -case. We've been trying to get major releases out more frequently, but fact is that there usually is years between them - 2.6 release (hopefully with extras -framework) is far away (we've not released 2.4! yet) ___ Reply to this item at: http://gna.org/patch/?3826 ___ 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 #3877] Explain Alien ruleset unit Rex name
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 Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: Add translator comment about what the unit name Rex refers to (it's not a King role unit, but alien equivalent of T.Rex) Add also to helptext. ___ File Attachments: --- Date: Tue 23 Apr 2013 11:21:14 PM EEST Name: RexComment.patch Size: 698B By: cazfi http://gna.org/patch/download.php?file_id=17814 ___ Reply to this item at: http://gna.org/patch/?3877 ___ 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 #3826] Allow bases on city tiles
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 the trivalue logic. I noticed while producing this that we unconditionally remove obsolete buildings on city takeover: while I think it outside the scope of this patch (improvements don't currently use negated requirements to indicate obsolescence, nor do roads/bases have a cache of potential obsolecense conditions), it probably makes sense to review this code section for 2.6, and give the same treatment for improvements and extras: the new player may not want some obsolete infrastructure which no longer provides a useful bonus (or may even cause a penalty, depending on applicable effects). (file #17815) ___ Additional Item Attachment: File name: allow-bases-in-cities+less-stunning.patch Size:37 KB ___ Reply to this item at: http://gna.org/patch/?3826 ___ 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 #20634] City size x, citizen count y with alternating movement
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 situation once it occurs, this is not serious enough to warrant postponing 2.4.0 release, i.e., it's not a blocker, but it would be nice to get cleaned out if it turns out to be easy. ___ Reply to this item at: http://gna.org/bugs/?20634 ___ 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 #3872] Do not claim bases indirectly with terrain
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 tile.extras_owner when base claimed - Fixed correct player to claim bases when loading savegame (file #17816) ___ Additional Item Attachment: File name: ClaimBases-2.patch Size:8 KB ___ Reply to this item at: http://gna.org/patch/?3872 ___ 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 #3873] Always claim created base
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 ___ Reply to this item at: http://gna.org/patch/?3873 ___ 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 #3878] Buoys without border claiming
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 Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Remove border claiming property from buoys in all rulesets (classic, experimental, and civ2civ3 - multiplayer that currently has buoys disabled handled in patch #3874) ___ File Attachments: --- Date: Wed 24 Apr 2013 01:24:27 AM EEST Name: Buoys.patch Size: 1kB By: cazfi http://gna.org/patch/download.php?file_id=17818 ___ Reply to this item at: http://gna.org/patch/?3878 ___ 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 #3630] Add separate base owner information for tiles
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 ___ Reply to this item at: http://gna.org/patch/?3630 ___ 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 #19846] Closing unit select dialog asserts or crashes
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 (assuming they have inherited from Debian gtk+ version that has been frozen for a long time - once Wheezy is out we hopefully get a new version soon). ___ Reply to this item at: http://gna.org/bugs/?19846 ___ 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 #3863] Document gtk3-client unit selection dialog crash
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: Gtk3CRASHDoc-2.patch Size:0 KB ___ Reply to this item at: http://gna.org/patch/?3863 ___ 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 #19846] Closing unit select dialog asserts or crashes
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 I don't have tooling to get release history for other distributions installed. I don't know what to do about Wheezy (would need to meet a fairly high set of criteria to get applied), but the patch in bugzilla looks small enough, focused enough, and safe enough that it could probably be released as part of Precise updates, if that meets the local need. As with the tooling, I'm less certain how to arrange this for other distributions. ___ Reply to this item at: http://gna.org/bugs/?19846 ___ 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 #3879] Remove negated reqs{} field in favor of something semantically nicer
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
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Planned Release:
___
Details:
The semantics of the negated field in requirements really irritate me. The
conditionals in the code generally require reverse polarity and
double-negative thinking. Ruleset fragments need careful thought because
TRUE means that a given requirement must not be met, and FALSE means that
it must be met.
There are two ways to address this, either by enabling nreqs everywhere (as
suggested in patch #3332), or by changing the word used to be something
positive. I've prepared patches achieving both, the first against trunk, and
the second against trunk + patch #3835 for consideration. I don't believe
either is currently perfect for application to trunk, but thought discussion
might be improved with code to review. Although the attached patches compile,
I have not tested them in gameplay at all.
I personally prefer the use of a positive term, as this better integrates with
my work-in-progress towards disjunctive requirements specification, but have
not successfully figured out a good word to use for this in the last few weeks
of thinking about it: candidates have been present, active, exists,
condition, test, asserted, found, and others that I dismissed before
adding them to my TODO documentation (hence the use of the easily
searchreplaceable term in the patch). Suggestions welcomed gratefully.
Note that the introduction of nreqs uses an entirely different mechanism than
that suggested in patch #3332 (part of why I'm not reusing that ticket):
specifically reversing the polarity of ruleset defined nreqs when storing them
in the reqs vector, rather than introducing nreqs vectors everywhere (with the
need for all the attendant plumbing in requirements.c and code review of
callers). This doesn't address the double-negation in the code, but it does
mask it from ruleset authors to some degree, making rulesets easier to both
write and read.
___
File Attachments:
---
Date: Wed 24 Apr 2013 09:52:01 AM JST Name:
0001-Drop-negated-in-favor-of-nreqs.patch Size: 13kB By: persia
http://gna.org/patch/download.php?file_id=17821
---
Date: Wed 24 Apr 2013 09:52:01 AM JST Name:
0001-Rename-negated-to-something-positive.patch Size: 37kB By: persia
http://gna.org/patch/download.php?file_id=17822
___
Reply to this item at:
http://gna.org/patch/?3879
___
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 #3332] Negated requirements_vector
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 inclusion, I thought that folk following here might find the
implementation interesting.
___
Reply to this item at:
http://gna.org/patch/?3332
___
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 #3697] When city growth is blocked, AI shouldn't give any value to food surplus
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 food, and then happily decided it didn't need that Aqueduct/Sewer System so much after all, with the result that cities ended up capped at size 8. It still sometimes builds other things in preference to the EFT_SIZE_ADJ improvement, but it gets around to it after what seems a reasonable time, making me think the adjustment factor isn't horridly imbalanced. It may be that we don't need to always rearrange workers with a full granary as if it was an emergency, but not doing so seemed to cause long delays in the AI deciding to actually use more production during my testing. (file #17823) ___ Additional Item Attachment: File name: reduce-food-interest-with-full-granary.patch Size:3 KB ___ Reply to this item at: http://gna.org/patch/?3697 ___ 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 #3879] Remove negated reqs{} field in favor of something semantically nicer
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 the patch #1342, where requirement_vector nreqs replaced obsoleted_by. This was the second step. The first step was in patch #1339, where requirement_vector reqs replaced the fields require_advance, need_improvement and need_government. Same for patch #1341 and #1340. ___ Reply to this item at: http://gna.org/patch/?3879 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
