[Freeciv-Dev] [bug #22200] Clarify what NoVeteran does in ruleset doc comments
Update of bug #22200 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22200 ___ 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 #22203] Custom single-level veteran systems for effectively veteran-less units in supplied rulesets
Update of bug #22203 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22203 ___ 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 #22164] Remove Veteran_Build effect from Nuclear unit in standard rulesets
Update of bug #22164 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22164 ___ 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 #22199] Don't suppress display of veteran level for NoVeteran units
Update of bug #22199 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22199 ___ 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 #22198] Editor prevents setting veteran levels for NoVeteran units
Update of bug #22198 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22198 ___ 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 #22202] Add custom veteran systems for civ1/civ2 diplomatic units to correct strength
Update of bug #22202 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22202 ___ 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 #22201] Don't suppress veteran effects help for NoVeteran units
Update of bug #22201 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22201 ___ 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 #22171] [metaticket] NoVeteran flag misinterpreted in various places
Update of bug #22171 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?22171 ___ 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 #4768] Pathfinding: node behavior optimization
Update of patch #4768 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4768 ___ 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 #4816] civ2civ3: ZoCs not affected by non military units.
Follow-up Comment #1, patch #4816 (project freeciv): My plan was to enable zones of control in deep oceans because I like naval units to be able to protect adjacent units without moving to the same tile, and because it could encourage the use of naval formations. But I do not like to enable ZOCs in coastal ocean because naval units could be stoped by units placed in land. I like the resultant gameplay with ZOCs in Deep ocean and not in Coast, but I do not find any realistic (or narrative) reason for this difference between deep and coastal ocean, apart of the improved gameplay. If you like the idea of naval units with ZOC, but only when placed in Deep Oceans, then the patch would be ready by simply removing the noZoc flag from Deep ocean terrain. ___ Reply to this item at: http://gna.org/patch/?4816 ___ Mensaje enviado vía/por Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4816] civ2civ3: ZoCs not affected by non military units.
URL: http://gna.org/patch/?4816 Summary: civ2civ3: ZoCs not affected by non military units. Project: Freeciv Submitted by: bardo Submitted on: mar 17 jun 2014 12:26:24 UTC Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: This is my first patch that takes advantage of the new features in v2.6, and it is something I was looking forward for long time. With this patch: - Zones of Control are no longer established by non-military units (Small Land and Merchant classes), so they do not affect the movements of enemy units. - Triremes are affected by zones of control while moving on river. ___ File Attachments: --- Date: mar 17 jun 2014 12:26:24 UTC Name: civ2civ3-hasnozoc.patch Size: 8kB By: bardo http://gna.org/patch/download.php?file_id=21063 ___ Reply to this item at: http://gna.org/patch/?4816 ___ Mensaje enviado vía/por Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4806] civ2civ3: terrain transformations
Follow-up Comment #3, patch #4806 (project freeciv): Updated patch that use mines instead of buoys as requisite to get extra shield in deep ocean when there is an offshore platform in the city. I was going to create a different patch, but it would conflit with this one, and they are related after all. (file #21068) ___ Additional Item Attachment: File name: civ2civ3-terraforming2.patch Size:10 KB ___ Reply to this item at: http://gna.org/patch/?4806 ___ Mensaje enviado vía/por Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4608] civ2civ3 rules: added pre-fortress
Follow-up Comment #14, patch #4608 (project freeciv): Updated patch for TRUNK: - Added Trench and Airfield bases, as pre-requisite for Fortress and Airbase, in order to prevent the construction of full bases in one single turn. - Airbases and Fortresses can be built on river tiles again. It may look like a complicated way to prevent the construction of fast bases, but I see the alternative bases as a new feature that could be useful in some situations. For example, when you want to protect a working engineer placed next to the coast, it might be better to use a simple trench that gives some defensive bonus but does not protect from killstack, so it is not a menace for possible disembark of enemy armies. In the same way, it might be better to build trenchs or aifields in the tiles adjacent to your cities, instead of full fortresses or airbases that could be more dangerous if captured by the enemy. (file #21069) ___ Additional Item Attachment: File name: civ2civ3-prebases.patchSize:8 KB ___ Reply to this item at: http://gna.org/patch/?4608 ___ Mensaje enviado vía/por Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4817] [Metaticket] civ2civ3
URL: http://gna.org/patch/?4817 Summary: [Metaticket] civ2civ3 Project: Freeciv Submitted by: bardo Submitted on: mar 17 jun 2014 16:20:46 UTC Category: rulesets Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: I do not plan to submit more patches for some time. Let me list here all my pending patches related to civ2civ3. If applied all them, the result is the ruleset that I have been testing these latest days. I splitted it so each patch is independent from each other, and there should be no problem if some of them are rejected. I'll revise the readme once finished. Balance issues related to huge maps (v2.5 and v2.6): - bug #22191: civ2civ3: granary reduces the waste of food by distance - bug #22192: civ2civ3: Marco Polo's Embassy obsolete by Democracy Aesthetical fixes (v2.5 and v2.6): - bug #22188: civ2civ3: remove DiplomatDefense flag from Airbase Readjusted rules (v2.6): - patch #4608: civ2civ3: added pre-fortress - patch #4806: civ2civ3: terrain transformations - patch #4811: civ2civ3: increase explorer vision - patch #4812: civ2civ3: increase fuel of air units New features (v2.6, not possible in v2.5) - patch #4816: civ2civ3: ZoCs not affected by non military units. ___ Reply to this item at: http://gna.org/patch/?4817 ___ Mensaje enviado vía/por Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22209] Start Scenario Game lists all savegames, not only scenarios
Update of bug #22209 (project freeciv): Planned Release: 2.4.3, 2.5.0, 2.6.0 = 2.5.0, 2.6.0 ___ Follow-up Comment #2: Dropping S2_4 from the targets as there might be savegames that are not technically scenarios in the sense that they have [scenario] -section but people have always considered them scenarios. Invalidating them in the stable branch after several releases would not be a good idea. For S2_5 such scenario -files should be fixed. ___ Reply to this item at: http://gna.org/bugs/?22209 ___ 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 #22192] civ2civ3: Marco Polo's Embassy overpowered with many players
Update of bug #22192 (project freeciv): Category:None = rulesets Status:None = Ready For Test Assigned to:None = cazfi Planned Release: = 2.5.0, 2.6.0 ___ Reply to this item at: http://gna.org/bugs/?22192 ___ 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 #22191] civ2civ3: granary reduces the waste of food by distance
Update of bug #22191 (project freeciv): Category:None = rulesets Status:None = Ready For Test Assigned to:None = cazfi Planned Release: = 2.5.0, 2.6.0 ___ Reply to this item at: http://gna.org/bugs/?22191 ___ 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 #22188] civ2civ3: remove DiplomatDefense flag from Airbase
Update of bug #22188 (project freeciv): Status:None = Ready For Test Assigned to: bdanee = cazfi ___ Reply to this item at: http://gna.org/bugs/?22188 ___ 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 #4797] dai_find_source_building() to consider all unit related requirement types
Follow-up Comment #2, patch #4797 (project freeciv): I worry about this change: as much as I'd like to see move_type dropped from the dai_find_source_building() check, the various times I tried to do it, I lost confidence in the updated validity of the (build_walls) guarded section of code. Part of this is me not really understanding the history of the code, but I did see differences in autogames, even with the classic ruleset (although perhaps the improvements from better checking of unit_type related criteria are better than the penalties from the lack of move_type restriction). ___ Reply to this item at: http://gna.org/patch/?4797 ___ 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 #4818] classic/experimental/multiplayer: set HasNoZOC on Explorers, etc
URL: http://gna.org/patch/?4818 Summary: classic/experimental/multiplayer: set HasNoZOC on Explorers, etc Project: Freeciv Submitted by: jtn Submitted on: Tue 17 Jun 2014 21:16:57 BST Category: rulesets Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Now that we can prevent units imposing ZOC (bug #21507), I think we should use this widely in the default rulesets. Explorers/Settlers imposing ZOC has long annoyed me. I propose setting HasNoZOC for all non-military land units in all the named rulesets unless someone objects. ___ Reply to this item at: http://gna.org/patch/?4818 ___ 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 #4816] civ2civ3: ZoCs not affected by non military units.
Follow-up Comment #2, patch #4816 (project freeciv): - Zones of Control are no longer established by non-military units (Small Land and Merchant classes), so they do not affect the movements of enemy units. (Raised patch #4818 to do the same to other rulesets.) ___ Reply to this item at: http://gna.org/patch/?4816 ___ 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 #22208] dai_find_source_building() ignores move_type parameter
Follow-up Comment #2, bug #22208 (project freeciv): I concur that this isn't used, and that the example fix would be correct. Given the oddities I encountered trying not to pass move type, I'm unsure if the AI behaviour wouldn't change in unanticipated ways if this bug was fixed, and agree that it's not appropriate for 2.4 or earlier (and patch #4797 or similar is better for 2.6+). My feeling is not to apply it for 2_5, just for continuity of AI behaviour, but if others' experience indicates it safe, I'm not utterly opposed. ___ Reply to this item at: http://gna.org/bugs/?22208 ___ 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 #4818] classic/experimental/multiplayer: set HasNoZOC on Explorers, etc
Follow-up Comment #1, patch #4818 (project freeciv): I find ZoC imposition from Settlers/Workers to be useful, in part because Workers are cheap, yet remain useful over a long time (as opposed to early inexpensive military units, which become an upkeep burden or require costly upgrading). I sometimes prioritise improvements of certain areas of the map just to block exploration by opposition military units during a Cease Fire in the start of a game. That said, hiding mapping of unimproved land early in the game may not actually be as strategically useful in practice as I think it is, so perhaps I'm just being inefficient in my gameplay (in which case, it doesn't make sense for Settler/Worker to impose ZOC). ___ Reply to this item at: http://gna.org/patch/?4818 ___ 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 #4818] classic/experimental/multiplayer: set HasNoZOC on Explorers, etc
Follow-up Comment #2, patch #4818 (project freeciv): I find ZoC imposition from Settlers/Workers to be useful [...] Well, yes, clearly it's useful if you're using it to get in someone else's way :) The case that annoyed me most recently was a friendly (ceasefire) AI nation's Settlers wandering through my lands to get at unclaimed territory, which I then claimed. Having lost their purpose, they then sat on one of my roads doing nothing and getting in the way, and I couldn't do anything without declaring war. Their ZOC made this much more annoying. I think having highly mobile Explorers able to also impose ZOC on ceasefire neighbours is too exploitative, too. ___ Reply to this item at: http://gna.org/patch/?4818 ___ 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 #4818] classic/experimental/multiplayer: set HasNoZOC on Explorers, etc
Follow-up Comment #3, patch #4818 (project freeciv): Though fixing my problem is mater of fixing my ruleset, not supplied ones, I've got regularly to a situation where I've conquered AI city in the early game and then his/her nearby Worker has lost all purpose to move anywhere from the far-too-well-defended spot it's on. Given their relatively good defense compared to early game military units (and playing with high researchcost so it takes a long time to get more powerful units) it would be very expensive (in terms of lost units) to kill them off. So they stand in the middle of my nation, causing all my units to take long zoc-avoiding routes around them. Sometimes I've even needed to build extra roads to make movement round them more efficient. ___ Reply to this item at: http://gna.org/patch/?4818 ___ 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 #4818] classic/experimental/multiplayer: set HasNoZOC on Explorers, etc
Follow-up Comment #4, patch #4818 (project freeciv): Right. I remove my opposition. I've also been stuck with peaceful AI units sitting on useful territory, forcing me to either ally or declare war, which is exceedingly annoying (and unlike a human player, one can't discuss the idea of moving with them, (perhaps including the potential threat of war)). The tactical advantages in the early game aren't sufficient to balance this (and I've just been lucky to mostly avoid it). ___ Reply to this item at: http://gna.org/patch/?4818 ___ 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 #4819] Allow imposition of a pythoagorean movement cost penalty for diagonal moves in rect
URL: http://gna.org/patch/?4819 Summary: Allow imposition of a pythoagorean movement cost penalty for diagonal moves in rect Project: Freeciv Submitted by: persia Submitted on: Wed 18 Jun 2014 06:08:12 AM JST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: persia Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6 ___ Details: I happened on http://forum.freeciv.org/f/viewtopic.php?f=13t=51 recently, and when I saw #16, I wondered why nobody had done that before, so wrote the attached patch. Note that this feature is disabled in all supplied rulesets, and that there is no accompanying balance for other distance measurements, just movement costs (and only for normal movement, as opposed to embark/disembark/attack/etc.). ___ File Attachments: --- Date: Wed 18 Jun 2014 06:08:12 AM JST Name: pythagorean-diagonal.patch Size: 8kB By: persia http://gna.org/patch/download.php?file_id=21071 ___ Reply to this item at: http://gna.org/patch/?4819 ___ 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 #21420] Worklist postponement messages don't consistently support negated requirements
Follow-up Comment #5, bug #21420 (project freeciv): Sorry to have forgotten this for a while. Updated, and issues addressed. (file #21072) ___ Additional Item Attachment: File name: worklist-explanation-improvements+less-spaces.patch Size:52 KB ___ Reply to this item at: http://gna.org/bugs/?21420 ___ 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 #4681] Consolidate AI Ferry tests
Update of patch #4681 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4681 ___ 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 #4797] dai_find_source_building() to consider all unit related requirement types
Follow-up Comment #3, patch #4797 (project freeciv): (although perhaps the improvements from better checking of unit_type related criteria are better than the penalties from the lack of move_type restriction) That's what I figured, not necessarily at the moment, but this enables future development to depend on unit type flag rules (removal of IgWall flag from the engine is one patch that depends on this) Note also that there's no regression here. The old code suffered from bug #22208, which means that move_type was never taken to consideration even when it existed. So we're comparing two potential improvements, that would conflict with each other, here. ___ Reply to this item at: http://gna.org/patch/?4797 ___ 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 #4739] Make civ2civ3 ruleset the default
Follow-up Comment #4, patch #4739 (project freeciv): On civ2civ3: I agree that having a single 'editor' for the ruleset who's thinking as deeply about balance and AI issues as you are is very valuable. Personally (not speaking for anyone else) I'd like you to retain some sort of editorial control for as long as you're up for it. Really, I would civ2civ3 to be under version control with you as the authority accepting patches. I think that would enable more people to suggest and contribute changes without having to worry about forking / conflicts. Whenever I tweak the svn version, I'm afraid I'm going to clash with whatever you're working on privately, so I'd rather be able to propose patches that you can decide on and reconcile with your own development. This way I could also propose patches to versions not shipped with Freeciv, such as the 2.4 modpack version. Not sure if that version control should be in Freeciv svn or elsewhere with Freeciv pulling from it, given the existence of versions other than what we're shipping. I think it could use a version naming system, too, so that if some change is particularly controversial there's a good way to refer to the old version and a ready-made name for a fork, and so the since previous version bit of the README has something clear to refer to. Not sure if we should tie that naming system to Freeciv versions or not; if its future lies with Freeciv it's probably better not to invent a new _v3, _v4 etc version scheme. (Patch #4734 should help.) I'm afraid that it could force to freeze the development of the rules I was thinking that we could use the modpack tool for that. I mean, once v2.5 is released, the ruleset civ2civ3 could be kept as stable as possible (only bugfixes and important unbalances), while we could keep another civ2civ3 version available in modpack tool where we backport the changes included in trunk that needs to be tested (and are compatible with previous v2.5). Oh, yes, I like this idea, if you're up for it. I like seeing civ2civ3 develop, but I have been caught out by the 2.4 version on modpack.freeciv.org changing substantially in the middle of a game. We'd have a civ2civ3_26 (or _2_6 or _v3 or _dev) modpack for each stable branch which may be unsuitable to upgrade mid-game (old savegames may not work, your strategy may be invalidated etc); unlike the shipped civ2civ3, you get to choose when to upgrade a modpack independently of Freeciv. And then the next major version of Freeciv would ship with a 'stable' civ2civ3 including whichever major changes looked like a good idea (freezing before beta1). Also, as you may have noticed... I'm not native english speaker, and every text that I wrote for the ruleset should be revised. I do plan to have a go at this before string freeze. ___ Reply to this item at: http://gna.org/patch/?4739 ___ 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 #4797] dai_find_source_building() to consider all unit related requirement types
Follow-up Comment #4, patch #4797 (project freeciv): Indeed. Given bug #22208, I don't understand the odd behaviours seen with changing this use of move_type. May as well apply this, but watch for unexpected behaviour. ___ Reply to this item at: http://gna.org/patch/?4797 ___ 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 #4459] Requirement range Traderoutes
Update of patch #4459 (project freeciv): Status:None = Need Info Assigned to:None = persia ___ Reply to this item at: http://gna.org/patch/?4459 ___ 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 #4679] Convert nreqs to reqs on ruleset load, and only use reqs internally.
Update of patch #4679 (project freeciv): Status: Need Info = Ready For Test Summary: Remove nreqs support entirely = Convert nreqs to reqs on ruleset load, and only use reqs internally. ___ Follow-up Comment #3: Updated patch, now allows rulesets to use nreqs, and silently converts them to reqs on ruleset load. Those portions of the patch affected by the changes from bug #21992 have been removed. README.effects remains unmodified, that being addressed in patch #4401. The iteration issue in advdata.c mentioned in comment #2 was addressed in bug #21999. I believe this suitable for 2.6, as it no longer requires ruleset authors to make a hard transition, and reduces the maintenance overhead for separate management of reqs and nreqs (and the various corner cases that might otherwise still exist, where only reqs are examined). (file #21073) ___ Additional Item Attachment: File name: migrate-nreqs-to-reqs.patchSize:9 KB ___ Reply to this item at: http://gna.org/patch/?4679 ___ 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 #4739] Make civ2civ3 ruleset the default
Follow-up Comment #5, patch #4739 (project freeciv): While working on a new version of civ2civ3, I liked to keep the previous versions updated as much as possible in order to receive some feedback about the latest changes. While setting this system up, one thing to consider is savegame compatibility. The official civ2civ3 ruleset should always be backward compatible in a way that game saved with previous major freeciv version can be continued with the new one. Within release series (branch) rules are even stricter. There also the older version has to be able to load game saved with the newer one, which means that usually any new objects (techs, units, buildings...) cannot be added to the ruleset as their instances couldn't be loaded to game using older version of the ruleset. The experimental civ2civ3 would not necessarily have similar rules, and certainly one cannot continue experimental civ2civ3 game with newer civ2civ3 even if they have more similar rules than old civ2civ3 and new civ2civ3. That would be made impossible by the different name of the ruleset already. I definitely don't want experimental ruleset to have same name (even if different version number) than official one, as that would cause both technical conflicts and human confusion. (whether one even sees that experimental ruleset as different variant of civ2civ3 at all, or independent ruleset forked from it - like civ2civ3 was originally based on classic ruleset - might be just matter of taste in the end) make it more similar to classic rules We already have separate classic ruleset available for those who want those rules, so I wouldn't give much weight to request to make it more like the rules we're used to unless accompanied with other more serious reasons. it could force to freeze the development of the rules, because I guess people do not like as default a set of rules that are continually changing, as we see with classic rules that have not changed for years. You're right that classic ruleset got stagnated because it got so well established, and any change would have broken it for someone, even when fixing for others. That's actually the main reason I'd like to switch to civ2civ3 as default ruleset - if we can't evolve classic ruleset, let's get completely fresh start. But even if civ2civ3 suffers same fate, that's not an issue compared to having it as not-default ruleset. You can always fork new ruleset from it to develop as not-default one. ___ Reply to this item at: http://gna.org/patch/?4739 ___ 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 #4679] Convert nreqs to reqs on ruleset load, and only use reqs internally.
Follow-up Comment #4, patch #4679 (project freeciv): I assume that freeciv-ruledit now does not save anything as nreqs, but ruleset get converted to present=FALSE model simply by loading it to freeciv-ruledit and saving. ___ Reply to this item at: http://gna.org/patch/?4679 ___ 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 #4679] Convert nreqs to reqs on ruleset load, and only use reqs internally.
Follow-up Comment #5, patch #4679 (project freeciv): I haven't tested that, but loading should convert, and I removed the save function for nreqs, so it should always save to reqs. At the current state of development, my interaction with freeciv-ruledit is mostly limited to making sure it compiles, and changing things that show up in there when I grep the code. Having just tried to launch it now, the interface is sufficiently limited that I'm not sure what it has done (I don't mean to criticise the work under development, I just don't feel comfortable testing it yet). ___ Reply to this item at: http://gna.org/patch/?4679 ___ 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 #4679] Convert nreqs to reqs on ruleset load, and only use reqs internally.
Follow-up Comment #6, patch #4679 (project freeciv): The only test-case I ever use for freeciv-ruledit part when changing ruleset format is 1) Load ruleset to it 2) Save 3) Try to load that ruleset saved by freeciv-ruledit to server (4) In some simple cases also manually inspect saved rulesets (but the formatting as saved by freeciv-ruledit is often not easiest to read). ___ Reply to this item at: http://gna.org/patch/?4679 ___ 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 #4795] Rename automake cariables xxx_CAPITAL to xxx_capital
Follow-up Comment #2, patch #4795 (project freeciv): I'm a bit worried about the amount of variable renames in build system where some code-paths are really rarely taken and could remain untested for a long time, and language being one where typoed variable names do not cause clear error messages but variable would be just wrong one and cause whatever subtle problems. Still, there's no 2.5.0-beta1 date announced yet, so I assume we have time to fix problems arising, so boldly going where no commit has gone before. ___ Reply to this item at: http://gna.org/patch/?4795 ___ 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 #4795] Rename automake cariables xxx_CAPITAL to xxx_capital
Update of patch #4795 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4795 ___ 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 #4679] Convert nreqs to reqs on ruleset load, and only use reqs internally.
Follow-up Comment #7, patch #4679 (project freeciv): Tested with something similar to a reversion of patch #4411 (some interaction with bug #22080 means I may not have gotten this perfectly correct), and from manual inspection of the ruledit-generated effects.ruleset, it appears that this does work (so that if ruledit can be convinced to write pretty files, this becomes a viable way for ruleset authors to convert from nreqs to present==FALSE reqs). ___ Reply to this item at: http://gna.org/patch/?4679 ___ 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 #4813] Ai effects evaluation module
Follow-up Comment #1, patch #4813 (project freeciv): Is the new code in adjust_improvement_wants_by_effects() involving the players_iterate() section intended to be part of this patch? The rest looks like a nice separation of concerns, without meaningful code differences, but this bit stands out as special. ___ Reply to this item at: http://gna.org/patch/?4813 ___ 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 #4679] Convert nreqs to reqs on ruleset load, and only use reqs internally.
Follow-up Comment #8, patch #4679 (project freeciv): Found a few more instances when trying to work on the logical next patch: expanded patch attached. (file #21074) ___ Additional Item Attachment: File name: migrate-nreqs-to-reqs+moreso.patch Size:11 KB ___ Reply to this item at: http://gna.org/patch/?4679 ___ 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 #4813] Ai effects evaluation module
Follow-up Comment #2, patch #4813 (project freeciv): Err, please ignore the prior comment: I understand now. Apologies for the noise. ___ Reply to this item at: http://gna.org/patch/?4813 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
