patchFreeciv - Patches: patch #3323, Allow requirement range...

Show feedback again

patch #3323: Allow requirement range "within city workable radius" for tile-based requirements?

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sat Jun 16 13:02:30 2012  
Category: generalPriority: 3 - Low
Status: DuplicatePrivacy: Public
Assigned to: Marko Lindqvist <cazfi>Open/Closed: Closed
Planned Release: 2.5.0Contains string changes: None

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Thu Mar 20 13:12:51 2014, comment #8:

Closing as duplicate makes sense. The other more complicated ideas seem to also have duplicate tickets, or at least that in patch #4532, and the more general model in patch #4216. There might be something else (like the rejected "Range"), but I suspect there's more value in working towards the other strategic resource patches and filing AI bugs for things it can't handle than trying to mine this ticket for specific stuff.

Emmet Hikory <persia>
Project Member
Tue Apr 9 20:36:59 2013, comment #7:

Looks like the original intent was addressed by patch #3740.

There are some other, more complicated ideas floating around in comments, but it looks like we should close this ticket as a duplicate now?

Jacob Nevins <jtn>
Project Administrator
Mon Apr 8 06:25:14 2013, comment #6:

What part of this original request cannot currently be done in trunk? I believe the drivers have been completed, if perhaps not as part of this ticket.

Example ruleset definition using the working "City" range:

name = _("Gold Mine")
graphic = "base.gold_mine"
graphic_alt = "tx.mine"
activity_gfx = "unit.gold_mine"
act_gfx_alt = "unit.minee"
reqs =
{ "type", "name", "range"
"TerrainClass", "Land", "Local"
"Technology", "Currency", "Player"
"Resource", "Gold", "Local"
"UnitFlag", "Settler", "Local"
gui_type = "Other"
build_time = 10
helptext = ("\
Gold Mines allow you to more efficiently extract Gold resources.\

type = "Output_Bonus"
value = 2
reqs =
{ "type", "name", "range"
"Base", "Gold Mine", "City"
"OutputType", "Trade", "Local"

name = _("Mint")
genus = "Improvement"
reqs =
{ "type", "name", "range"
"Base", "Gold Mine", "City"
graphic = ""
graphic_alt = ""
obsolete_by = "None"
build_cost = 60
upkeep = 2
sabotage = 100
sound = "b_mint"
sound_alt = "b_generic"
helptext = _("\
A mint allows you to generate money from a Gold Mine.\

type = "Output_Bonus"
value = 5
reqs =
{ "type", "name", "range"
"Base", "Gold Mine", "City"
"OutputType", "Gold", "Local"

Note that the AI isn't quite up to handling these yet. Given the above, it would never build a Gold Mine (although cities with gold mines in radius would gain the benefit of them).

Emmet Hikory <persia>
Project Member
Sun Jun 17 10:20:21 2012, comment #5:

After night's sleep I don't see need for explicit "CityTile" "Range" requirement, as tile output effects are only used when tile is within city range (or in case of ai evaluating city placement; it will be within city range once city has been founded)

We already have SuperHighways, Colossus, King Richard...

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat Jun 16 21:56:01 2012, comment #4:

There's also difference in that "CityTile" requirement can only be used with effects targeting tiles, while new range proposed in original submission would be available (only) for effects targeting city. So maybe we should handle "CityTile" extensions in another (additional) ticket altogether, though it would be nice to discuss somewhere which one is more urgent in case we implement just one.
To the mailing list was sent use-case that one should be able to increase output of a tile with certain resource when city has specific building. Let's ignore for a while that tile output bonus was requested, and consider also city output bonuses acceptable (the two have different limitations and possibilities. For example tile output is raw food/shield/trade, one cannot affect gold/science/luxury directly) After that I see the main differences to be whether number of suitable tiles should matter, and should one be able to have multiple requirements for the same tile. If we go by city (and not individual tiles) targeted effect, effect is applied just once no matter how many tiles there would be with required resource (as long as there's at least one). One cannot have multiple requirements for same tile if we go by city targeted effect. If you have requirement that some tile within city radius should have given resource and another requirement that some tile should have river in it, those two tiles either are or are not the same, but either fulfills your requirement list. In the future we may want to add requirement type to check if tile is within our borders, and want to combine that with resource check.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat Jun 16 21:35:42 2012, comment #3:

First off, thanks for looking at this. I've been reading the codebase for two other tickets I am about to open (I am not a programmer so I understand maybe 1/3 of it. Yay comments!), so I can see how expensive this could be.

With regards to fluctuations, how about if range where a number, like city radius? I imagine small numbers would have the same effect as CAdj then Adj. The ruleset maker could then decide what an acceptable distance from the city to the target could be.

I did not know about the sell off. If a building requires a min size city and the city shrinks, is it sold? Sounds like an expensive routine to check each turn. Perhaps allow 'persists' or something similar so authors can choose to have no further checks on the building until it obsoletes?

Henkutsu <henkutsu_tama>
Sat Jun 16 14:46:05 2012, comment #2:

> (ai evaluating buildings for example would result in one call
> for every tile for every building type every turn for every
> city))

Ignore that. I blame lack of sleep. Of course it's not "for every building" but for "every building effect that has such an requirement"

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat Jun 16 14:41:40 2012, comment #1:

When "CityTile" requirement was added, only affects on city center were required so extensions to that were left to future. It currently supports only "Center" tiles, but idea was that also "Worked", and "Range" could be later added (I've never had time to figure out sensible way to do it if there's one - I'm worried about computational costs of something that would get called a lot (ai evaluating buildings for example would result in one call for every tile for every building type every turn for every city))

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat Jun 16 13:02:30 2012, original submission:

It might be nice if tile-based prerequisites (terrain, specials, bases etc) could be required to be somewhere in a range of a city's workable radius, rather than just on or adjacent to the city centre.

However, the implications aren't trivial, so this ticket may end up closed without a fix.

An example given freeciv-dev was a "gold mine" city improvement which could only be built in a city with gold nearby (would also need patch #3322).

Answering the question "is a tile with properties X in workable range of this city" isn't trivially cheap (requires iterating over city map), but is it prohibitively expensive?
I suspect it's manageable unless some AI is going to call it in some inner loop.

Answering the inverse question "which cities can work this tile" is likely to be prohibitively expensive, so we'd better avoid that.
(As it happens, in the current implementation, it would actually be much cheaper to answer the question "which city is working this tile". Perhaps "worked by city" would be a useful alternative range? )

It would seem reasonable to use the range "City" for this. In contexts where a non-NULL city is provided to is_req_active(), the "Tile" range already means the tile the city is on, and I can't think of another sensible meaning for "City" for tile-based requirements.
(Except, perhaps, "city is working this kind of tile".)

A quick survey of situations where the "City" range is meaningful (I may have missed some):

  • Improvement build requirements: straightforward at build time.
    • In some cases (but not others), improvements are sold if the requirement goes away (e.g., harbours need nearby ocean). The current mechanism for that (city_landlocked_sell_coastal_improvements()) already isn't very general and wouldn't be easy to extend to city-radius requirements.
      • However, moving to the alternative strategy suggested in comments, of checking every improvement's requirements once per turn, would work.
      • But, examples of reqs whose disappearance don't cause buildings to be sold include tech and other buildings. We probably don't want to change that. So there's inconsistency here already.
    • It would be pretty annoying to have a gold mine sold due to a temporary city radius fluctuation due to plague or whatever. But that's probably up to ruleset designers.
      • If we used a tile-worked requirement, we certainly wouldn't want to sell as soon as a city stopped working a tile.
  • Specialist requirements: probably sensible.
    • May need to re-assess specialists whenever city radius or nearby terrain changes, expensive...
  • Disaster: straightforward, because disasters don't persist.
Jacob Nevins <jtn>
Project Administrator


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by persia (Posted a comment)
  • -unavailable- added by henkutsu_tama (Posted a comment)
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu Mar 20 17:43:27 2014cazfiCategoryNone=>general
      StatusNeed Info=>Duplicate
      Assigned toNone=>cazfi
    Tue Apr 9 20:36:59 2013jtnPlanned Release=>2.5.0
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup