#43251: Chained upgrades lead to actionenabler inconsistency
Open Date: 2021-11-20 15:59
Last Update: 2022-02-08 12:00
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-08 12:00 Updated by: ihnatus
Comment:
Reply To cazfi
This might have an effect on resolving #42666 (Lua API for upgrade actions)
The API I've suggested there allows iterative lookup for upgrade target type using utype = utype.obsoleted_by and test for player:can_build_direct(utype), we can also add any check for each step (just unit:can_do_action(...) test is likely missing now but may be introduced elsewhere). So a user-defined action that works as described could be written, just AI/UI won't handle all the cases when it is disabled (unless we can also write action enablers in Lua that is rather dubious in seeable perspective, especially about executing that Lua at client side).
By all logic (cost formula etc.), upgrade action is not chained (X to Y to Z) but immediate X to Z, and probably should be left as such. In the case mentioned, may we just add the requirements for building Z negated to the upgrade enabler for X and Y?
---------------------------------------------------------------------
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