#42659: Unhardcode autoupgrade Open Date: 2021-07-23 01:19 Last Update: 2022-04-12 22:06 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-12 22:06 Updated by: alienvalkyrie Comment: Reply To cazfi Reply To alienvalkyrie To be clear, I'm not necessarily opposed to moving autoupgrade to Lua script for now – I just a. think it's important to have a plan for how we're gonna do this more cleanly later, and b. am worried that even if we have a plan, this might turn into one of those "temporary" solutions that will be lying around for eighteen years before someone notices there's a better way now. I don't think anybody is working on such a plan now? Does that alone mean that we're rejecting this from S3_1? (I'm not saying that it's the only thing blocking this. It might just be something that renders further considerations irrelevant.) The hint of a plan I have would be to make User Effects variable and definable (like e.g. user-defined terrain flags), and then maybe allow attaching AI hints to those. There's obviously no way that's still ending up in S3_1, but if we solidify that as a plan, we might be able to justify merging this patch now already (although it would still feel a bit like putting the cart before the horse, half-unhardcoding something before the potential to fully unhardcode it exists). 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. --------------------------------------------------------------------- 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