An item that provides a unit additional type of AMLA?

[ahyangyi]

Hello, everyone.

What I was trying is to implement an item which, when taken, givens the unit an additional type of AMLA.
However, I then realized that I have no luck in modifying the [advancement] tag inside [unit] then [unstore_unit] it, as [unstore_unit] will read the right advancement tag from the unit_type of the unit instead.

Does anyone have any idea about how can this feature be implemented, or do you think it's impossible?

Thank you!

[ahyangyi]

Well, I just came up with an idea, where I could dynamically create new unit_types basing on the existing ones, then add the AMLA code into the new unit_type, and change the unit type to the new one. We don't even need to use the upgrade_to_something hack as the new unit_type is otherwise identical to the old one.

Sadly, asking for the ability to dynamically create new unit_types is obviously more demanding than asking for the ability to change the [advancements] tag inside a specific unit.

Could it be solved with some triggers? I can accept some variations on the function. As long as the unit gets the desired effect upon AMLA it's OK.

[Gambit]

Store the unit in a variable and add the advancement.

[Piko555]

I have another idea, but don't know will it work - in the unit standard AMLA, define options which require an impossible to get advancement. While getting this item, use advance_to macro to get this impossible advancement. It doesn't have to do anything, but only unlock the other ones.

[Elvish_Hunter]

What I was trying is to implement an item which, when taken, givens the unit an additional type of AMLA.

Does this applies to all unit types, or only to a specific custom unit? If it's the latter, you can create a unit variation, and then use [object] [effect] apply_to=variation.

[Dugi]

Hey, I have been working on this for a while, and I had found a solution.

First, Gambit's idea would not work, unstoring units undoes changes done to advancements.
Piko555's idea is not good neither, tricks with advance_to will never add an AMLA that is not on the list.

Judging from dynamically create new unit_types, I assume that you want the item to work for multiple units. Therefore, variations could be used only for the case if there was only one item of this kind (only one sort of advancements added not more), and preferably only for a single type of unit. There are three ways to do it without variations.

First one is almost perfect, but does not allow you to use unstore_unit then at all, therefore even move_unit, feeding and other tags created with lua using unstore_unit would break it. It is quite simple, just store the unit (kill=yes !), add the advancement to it via set_variables and then use insert_tag with name=unit and set the variable name to the variable holding the unit. This will set the unit's advancements as you wish, unlike unstore_unit that resets advancements to unit_type (note: you might think about doing this just before the unit advances, to avoid problems with unstore_unit before, but if you do so, the unit will not advance, and remain with like 108/98 experience).

Second one tends to slow the game down if there are more items like this available, and is not quite useful with many playable max level units. To all max level units (units that will take AMLA), add all these advancements, but give them an unmeetable prerequisite. When the unit takes the item, use:

Code: Select all

{SET_VARIABLE variable_where_the_unit_is_stored.variables.advancement[$unit.variables.advancement.length].name name_of_the_prerequisite}

This will manually add that advancement, and fulfil that prerequisite and unlock that advancement path. A problem is that if you add more advancement paths this way, there would be many units with tons of advancements, making save files like 40 megabytes large when unpacked and 4 megabytes large when packed, making the game autosave for 5 seconds and slow almost everything in the game down, including graphics. Also, you'll have to create duplicates of units if you are using default units.

The third one removes all performance problems of the previous method, but is difficult. The idea is to make clones of each unit type, that hold all advancements the unit can take (with all variations to make them suit the unit type more), but let them have an unmeetable prerequisite. Fulfil it like in the previous method, and when the unit is advancing, switch it to the other unit type. The unit with many advancements will be in the game only for a very short time, and only one, and no slowdown will occur.

Note: if you are using the default era, you might want to use my campaign's units to extend the advancement lines (from level 3 to level 4 usually) to use advancefrom to alter max level units without having to manipulate with the default units. I have created them for a similar reason.
Also, you might find there a working way to do the third, most complicated method.

Good luck.

[ahyangyi]

Thank you very much for such a detailed and insightful response. I want this campaign to be played with different eras, including Ageless Era. Therefore, the third option seems out of question. I'll give the second a go then, as such an item will not occur more than a few times.