URL:
  <http://gna.org/bugs/?21947>

                 Summary: is_req_unchanging() vs
worklist_change_build_target()
                 Project: Freeciv
            Submitted by: jtn
            Submitted on: Mon 21 Apr 2014 13:00:26 BST
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
                  Status: Need Info
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
                 Release: 
         Discussion Lock: Any
        Operating System: Any
         Planned Release: 

    _______________________________________________________

Details:

(Found while looking at patch #4400; another in the series of not putting off
raising bugs until I know how to fix them)

worklist_change_build_target() has a bunch of tests resulting in messages like
"[city] can't build [improvement] from the worklist; %s terrain is required. 
Postponing...", triggered if !can_city_build_now() but
can_city_build_improvement_later() due to some unmet requirement.

I noticed that on S2_5, VUT_BASE doesn't have a message, triggering an error
(unlike VUT_SPECIAL etc). However, it turns out that this can't be reached,
because is_req_unchanging() returns TRUE for VUT_BASE.

Whether these messages can be reached is mediated by is_req_unchanging(). For
a bunch of terrain-related requirements, this returns TRUE even though terrain
is mutable, with the following excuse:


    /* Terrains, specials and bases aren't really unchanging; in fact they're
     * practically guaranteed to change.  We return TRUE here for historical
     * reasons and so that the AI doesn't get confused (since the AI
     * doesn't know how to meet special and terrain requirements). */


However, not all terrain-related requirements fall into this category. On
S2_5, VUT_ROAD is !unchanging (whereas on trunk VUT_EXTRA is unchanging, so
roads have changed category); and on trunk, VUT_ROADFLAG is !unchanging. Is
there a reason for this? -- does the AI know how to meet these requirements,
for instance?

Seems like some action should be taken to clear up this inconsistency, but I'm
not sure what. One or more of the following, I think:
* Perhaps the AI has learned to meet some of these requirements since the
comment was written, and so some of these could become "changing"
requirements? (I don't understand the AI well enough to check.)
* If there's a real reason for the inconsistencies in the terrain-related
requirements in is_req_unchanging(), comments should be added explaining this.
(Is there some special case for bridges or something that the exceptions are
there for?)
* Failing that, the inconsistencies should be resolved in
is_req_unchanging().
* Once any of the above have been done, unreachable strings should be pruned
from worklist_change_build_target(), to reduce translator load, and make jobs
like bug #21420 easier.
* Also: it's annoying if human players' actions are unnecessarily
circumscribed by the AI's capabilities -- I'm not allowed to put a building
with a terrain-related requirement on my worklist, even if I've carefully
planned worker activities so that the special/base/whatever will be ready by
the time the item comes off the worklist; I have to wait for the base/whatever
to actually exist before I'm even allowed to talk about the building; this
increases micromanagement. Could we split the version the AI uses out from
is_req_unchanging()? (Or are the other unspecified "historical reasons" still
valid?)




    _______________________________________________________

Reply to this item at:

  <http://gna.org/bugs/?21947>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to