Can AMLAs inherit [effect]s? *FIXED*

[Celtic_Minstrel]

May I summarise my understanding of how this works to check I've got it right?

Your code snippet is basically correct, yes.

I'm not clear where in the code above the AMLAs are updated/rebuilt, I'm guessing it's [unstore_unit]?

If I recall correctly, they're not – you need to add the following at the end to force a rebuild:

Code: Select all

[transform_unit]
	id=$unitadv.id
	transform_to=$unitadv.type
[/transform_unit]

Also I'm guessing this is only worth doing if $unitadv.modifications.advancement.length >1 ?

Yes, that's true.

Finally, would [modify_unit] be a better option here (I only ask because the wiki [unstore_unit] entry says:

To update a unit on the map after having edited its WML. This usage is common, but discouraged - if possible, you should use [modify_unit] or [object] instead.

If I'm right it seems this would also work where there are multiple additional attacks and multiple modifiers many of which can be taken multple times which is good because my logic uses all of those

No. It's true that it's better to use [modify_unit] when possible, but [modify_unit] has a more limited set of things it can do. It doesn't support this, so store/unstore is your only option here.

[Spannerbag]

Your code snippet is basically correct, yes.

Phew.

... you need to add the following at the end to force a rebuild:

Code: Select all

[transform_unit]
	id=$unitadv.id
	transform_to=$unitadv.type
[/transform_unit]

Ah, that makes much more sense! Not sure I'd ever have thought of transforming a unit to the same type though...

No. It's true that it's better to use [modify_unit] when possible, but [modify_unit] has a more limited set of things it can do. It doesn't support this, so store/unstore is your only option here.

Alright, no problem.

I think I have the tools and understanding to do what I want (though doubtless there will be a few speed bumps on the way...).
So sometime next week I'll do some hacking and see what happens.

As ever thanks for your time and patience, it's very much appreciated!

Cheers!
-- Spannerbag

[Spannerbag]

[modify_unit] is for normal use cases. However, for what you need to do even [unstore_unit] alone is not powerful enough. In addition to that you need to cause unit rebuild so that attribute values are calculated based on effects instead of using stored values.

Thanks for the advice, I was wondering where/how the logic I had actually updated/rebuilt the AMLAs.
I've been advised to use [transform_unit] to do this.

Transforming unit to its own type ... hmm... don't think I would have thought of that!

Thanks as ever for your input, much appreciated!

Cheers!
-- Spannerbag

[Spannerbag]

Hi all,
I'm in shock - there, told you.

Fired up good old notepad and typed in a pile of new stuff (not just AMLA code but various other tweaks, on-the-fly AMLA mods, changes to some other rather gnarly code, various adjustments and other stuff) and fired it up.

No preprocessor errors
No WML errors
Things all seemed to work as expected

Very early days in thoroughly testing the AMLA code but it worked for one of my custom mage types

Here's the code (used [split] because each AMLA id includes a header and, sometimes, a max_times suffix and I just need the middle chunk).
It still isn't fully optimal (I can now remove some ALMAs that are no longer needed such as attack specific modifiers).
However the logic seems OK and it should be straightforward to adapt as needed.

Code: Select all

# Event to force modifier AMLAs (e.g. +1 damage) to apply to *all* relevant AMLAs, even those chosen later
# Done by reshuffling taken [advancement]s so that modifers are processed last (so can affect all others)
#
# Note on advancement arrays in a unit:
# unit.modifications.advancement -> advancements already taken
# unitadv.advancement -> possible available advancements, not needed here
# 
[event]
  name=post advance
  first_time_only=no
  [filter]
    type={AMLA_TYPES}
  [/filter]
  [store_unit]
    [filter]
      id=$unit.id
    [/filter]
    variable=unitadv
  [/store_unit]
  {CLEAR_VARIABLE caid_sorted}		# Pure paranoia
  [if]
    {VARIABLE_CONDITIONAL unitadv.modifications.advancement.length greater_than 1}
  [then]
    [foreach]
      array=unitadv.modifications.advancement
      [do]
        [set_variables]
          name=caid
          mode=replace
          [split]			# Use $caid[1].a
            list=$this_item.id
            key=a
            separator="_"
          [/split]
        [/set_variables]
        [switch]
          variable=caid[1].a
          [case]			# Append these
            value=md,mdn,ms,msn,ma,mp,rd,rdn,rs,rsn,ra,rp,mmr
            [set_variables]
              name=caid_sorted
              mode=append
              to_variable=this_item
            [/set_variables]
          [/case]
          [else]			# Insert everything else
            [set_variables]
              name=caid_sorted[0]
              mode=insert
              to_variable=this_item
            [/set_variables]
          [/else]
        [/switch]
      [/do]
    [/foreach]
    [set_variables]
      name=unitadv.modifications.advancement
      mode=replace
      to_variable=caid_sorted
    [/set_variables]
    [unstore_unit]
      variable=unitadv
      find_vacant=no		# Clobber (overwrite) existing (pre-sort) version
    [/unstore_unit]
    {CLEAR_VARIABLE caid,caid_sorted}
    [transform_unit]		# Force unit rebuild
      id=$unitadv.id
      transform_to=$unitadv.type
    [/transform_unit]
  [/then]
  [/if]
  {CLEAR_VARIABLE unitadv}
[/event]

Posted here in case it's of interest to anyone else

Thanks ever so much to Celtic_Minstrel for help, advice and patience, and to Ravana for very helpful suggestions, I'd've been stuck without your support!

Cheers!
-- Spannerbag