[Freeciv-tickets] [freeciv] #43251: Chained upgrades lead to actionenabler inconsistency

Back to archive index
OSDN Ticket System norep****@osdn*****
Sat Feb 5 04:50:28 JST 2022


#43251: Chained upgrades lead to actionenabler inconsistency

  Open Date: 2021-11-20 14:59
Last Update: 2022-02-04 21:50

URL for this Ticket:
    https://osdn.net//projects/freeciv/ticket/43251
RSS feed for this Ticket:
    https://osdn.net/ticket/ticket_rss.php?group_id=12505&tid=43251

---------------------------------------------------------------------

Last Changes/Comment on this Ticket:
2022-02-04 21:50 Updated by: cazfi

Comment:

Reply To cazfi
1) That we add a new action type
This would work for "A -> B -> C" where we would block update to C. As far as I can see it would have some implications on "A -> B -> C -> D" where we would want to block update to D (if we don't want that blocking, one can still use the current action type); update price of A -> C would go up, as it's more expensive to update A -> B & B -> C, and UI-wise user would need to do two update actions.

---------------------------------------------------------------------
Ticket Status:

      Reporter: ec429
         Owner: (None)
          Type: Bugs
        Status: Open
      Priority: 5 - Medium
     MileStone: (None)
     Component: (None)
      Severity: 5 - Medium
    Resolution: None
---------------------------------------------------------------------

Ticket details:

In my ruleset, I have a NoUpgrade flag that controls the Upgrade action, so that some units can be obsoleted (to declutter the build list) without being able to be upgraded (which e.g. in some cases bypasses an impr_req on the new unit).
[actionenabler_upgrade_unit]
action = "Upgrade Unit"
actor_reqs    =
    { "type",    "name",       "range", "present"
      "DiplRel", "Foreign",    "Local", FALSE
      "UnitFlag", "NoUpgrade", "Local", FALSE
    }
However, if I have three units X → Y → Z (where → represents obsolete_by), and Y has the NoUpgrade flag, an X can still be directly upgraded to Z; I don't see any way to work around this.
In my opinion, the Upgrade Unit action should check that the entire chain of obsolete_by would all pass the actionenabler individually (and if not, upgrade to the point where it fails, so that e.g. X can still upgrade to Y after inventing Z), rather than just looking at the endpoints.

-- 
Ticket information of Freeciv project
Freeciv Project is hosted on OSDN

Project URL: https://osdn.net/projects/freeciv/
OSDN: https://osdn.net

URL for this Ticket:
    https://osdn.net/projects/freeciv/ticket/43251
RSS feed for this Ticket:
    https://osdn.net/ticket/ticket_rss.php?group_id=12505&tid=43251



More information about the Freeciv-tickets mailing list
Back to archive index