#42659: Unhardcode autoupgrade
Open Date: 2021-07-23 02:19
Last Update: 2022-04-13 21:36
URL for this Ticket:
https://osdn.net//projects/freeciv/ticket/42659
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=12505&tid=42659
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2022-04-13 21:36 Updated by: cazfi
Comment:
First of all: Time just before d3f might be the most stressful part of our major version cycle. The last blocker issues that we've been unable to resolve so far (sometimes over many years), i.e., the toughest ones, need to be coded, and decisions like one in this ticket need to be done. I'm rather torn with this one.
Reply To alienvalkyrie
One relevant question would be: Is there a current, acute need from ruleset authors to customize the upgrade code – in a context where the AI still has to care about it? Because that would be a circumstance requiring what this patch does.
Also; is this patch alone enough for such needs? Because if something more, that is no longer going in before d3f, would be required, then there's no point in this patch either/alone in S3_1.
In general, judging just from the level where the discussion goes, not caring about the actual content, it sounds more like an attempt to decide if this should go to master development branch, than of an attempt to decide if this should go to a stable branch.
---------------------------------------------------------------------
Ticket Status:
Reporter: ihnatus
Owner: (None)
Type: Feature Requests
Status: Open
Priority: 5 - Medium
MileStone: S3_1 d3f
Component: General
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
Autoupgrade (Leonardo effect) is a gimmick bonus, like hut findings, but it is now hardcoded. The result is, we can't have any good way for adding flexibility to it (e.g., upgrade only units in domestic borders, or have wonders that upgrade different classes separately). So, the logical solution is: write autoupgrade code into a Lua callback in default.lua, and the effect "Upgrade_Unit" will just be used by AI and autohelp as it is, and the default callback looks at it but some other one might not. To do it, we must develop in separate tickets:
"phase_end" signal (called in srv_main.c when we now deal with this effect, after do_tech_parasite_effect() and before player_restore_units() from which we cut do_upgrade_effects());
API to do the things do_upgrade_effects() does:
void (Unit):transform(Unit_Type to_what, bool dont_lose_veteranship) -- maybe the second parameter may be unhardcoded further?
an API for unit_upgrade_test(punit, TRUE). Suggestion:
string (Unit):transform_blocker(Unit_Type tf_to) -- possible values: nil, "cargo", "transport", "tile"; maybe numeric results and constants table for less garbage
Unit_Type (Unit_Type):upgrade_type(Player owner) --for can_upgrade_unittype(), maybe also a shortcut Unit_Type (Unit):upgrade_type(); nil if can't yet upgrade
maybe as more low-level control of the previous: Unit_Type (Unit_Type).obsoleted_by and bool (Player):can_build_direct(Unit_Type utype).
--
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/42659
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=12505&tid=42659