Can AMLAs inherit [effect]s? *FIXED*

The place to post your WML questions and answers.

Moderator: Forum Moderators

Forum rules
  • Please use [code] BBCode tags in your posts for embedding WML snippets.
  • To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
User avatar
Spannerbag
Posts: 505
Joined: December 18th, 2016, 6:14 pm
Location: Yes

Can AMLAs inherit [effect]s? *FIXED*

Post by Spannerbag »

EDIT: see https://forums.wesnoth.org/viewtopic.php?p=679752#p679752 for fix.

Hi,
I'm playtesting various custom AMLAs and while they all work fine I have a question.

The setup
A player AMLAs a unit so they get +1 damage to a ranged attack (AMLA #1).
Later the player gains the opportunity to AMLA to a new ranged attack (AMLA #2).

Now the original ranged attack has a +1 (or +2 if AMLA #1 was chosen twice) whereas the second ranged attack acquired via AMLA #2 does not.

This is all fine and is as I'd've expected.

However me being me I was wondering if there was an elegant way to allow the new attack to "inherit" the [effect](s) applied to an existing attack?

I'm assuming that within [effect] variables are not recognised (not actionWML).
One way I could do this would be to have supplementary [effect](s) with [filter] [has_weapon] to test if damage is greater than the original base damage and if so increase damage accordingly. But this feels messy.

Another way would be to manipulate the damage specified for AMLA #2 but I'm not sure how best to do this (besides the AMLA is implemented as a macro with slightly different values for various units).

I cannot make AMLA #1 dependent on AMLA #2 because the latter may never become available.

So, if anyone has any clever ideas (WML or lua) on how to do this I'd be most grateful!
If not, no big deal, I think I'll just leave things as is (or maybe have separate AMLA #1s for the various attacks...)

I've learned that asking here *before* I spend hours keyboard bashing is usually a wise course of action :)

Cheers!
-- Spannerbag
Last edited by Spannerbag on February 13th, 2023, 3:07 pm, edited 1 time in total.
SP Campaigns: After EI (v1.14) Leafsea Burning (v1.17, v1.16)
I suspect the universe is simpler than we think and stranger than we can know.
Also, I fear that beyond a certain point more intelligence does not necessarily benefit a species...
User avatar
Skayland
Posts: 20
Joined: March 27th, 2020, 2:59 am
Location: Somewhere only we know.
Contact:

Re: Can AMLAs inherit [effect]s?

Post by Skayland »

Hello! I was curious about this and I started checking the AMLA tags on https://wiki.wesnoth.org/UnitTypeWML
And if I understood correctly what you want to do I think the solution that might work is using require_amla and exclude_amla tags.

Basically you will have 2 versions of AMLA #2. one which excludes AMLA #1 and has a lower damage and one that requires AMLA #1 and has higher damage. Would something like that work? I haven't tested it but if you do please tell, seems useful. :)
Practice makes perfect, why don't we practice helping others?
User avatar
Spannerbag
Posts: 505
Joined: December 18th, 2016, 6:14 pm
Location: Yes

Re: Can AMLAs inherit [effect]s?

Post by Spannerbag »

Skayland wrote: February 8th, 2023, 3:53 am Hello! I was curious about this and I started checking the AMLA tags on https://wiki.wesnoth.org/UnitTypeWML
And if I understood correctly what you want to do I think the solution that might work is using require_amla and exclude_amla tags.

Basically you will have 2 versions of AMLA #2. one which excludes AMLA #1 and has a lower damage and one that requires AMLA #1 and has higher damage. Would something like that work? I haven't tested it but if you do please tell, seems useful. :)
Hi, thanks for replying.

Yeah, that's kinda what I was referring to at the end of my post where I said (or maybe have separate AMLA #1s for the various attacks...).
I do use require_amla to have certain [advancement]s appear after others have been taken (these are mainly attack upgrades not easily implemented via standard [effect]s).

That said, I am still mulling over options. I have started splitting up the various AMLAs that potentially affect 1+ others into specific AMLAs.
So I have:
  • AMLA #2 -> require_amla AMLA #2 enables AMLA #1(#2version)
  • AMLA #3 -> require_amla AMLA #3 enables AMLA #1(#3version)
  • ...
...and so on, but there's a lot of 'em and the player has to select each one so I think I will revisit my logic.


Suppose there are 3 ALMAs (#2,3,4) that can all be affected by AMLA#1 (which, for example, adds +1 damage).

The player can select any AMLA in any order. Generally speaking in my code AMLA#1 can be selected up to two times.

Suppose they go with #3,#1,#4,#1,#2.
  1. AMLA #3
    Is straighforward.
  2. AMLA #1
    Will do its thing for AMLA #3 (+1 damage or whatever).
  3. AMLA #4
    Here the logic needs to apply AMLA#4 and then AMLA#1 once.
  4. AMLA #1
    This it time operates on AMLAs #3 and #4.
    Note: AMLA #1 is now no longer available as an [advancement] (max_times=2).
  5. AMLA #2
    Also needs AMLA #1 applying twice.
I.e. AMLAs #2,3,4 need to be able to implement AMLA#1 0,1 or 2 times when the player selects that [advancement] depending on how many times the player has selected AMLA #1.

The problem is that I cannot find a workable implementation of this within my knowledge of WML.

E.g. taking AMLA #2 as an example, I cannot use:
[c][advancement][/c] AMLA#2
[c][advancement][/c] AMLA#1v2 [c]require_amla[/c] AMLA#1 # +1 damage/strikes/whatever
[c][advancement][/c] AMLA#1v2 [c]require_amla[/c] AMLA#1,AMLA#1 # +2 damage/strikes/whatever (applies AMLA#1 a 2nd time)
because they are separate (player selectable) [advancements].

Whilst I could craft custom versions of AMLA #2 using require_amla to test whether AMLA#1 has been selected 0,1 or 2 times bear in mind that each AMLA#2/3/... will need up to 5 (x2) separate AMLA#1 type AMLAs (for +1 damage, +1 strike, marksman etc.) and, as fas as I can see, I will need a single [advancement] for each combination because [effect] cannot detect, AFAIK, what [advancement]s have been selected.
Whilst not impossible it would hugely increase the number of [advancement]s and complexity though [effect] new_advancement and remove_advancement might help a bit.
Methinks this way lies madness :shock:

Key things I need to do in WML (but can't) to get this to work include at least one of:
  • Setting a (preferably unit) variable within [effect].
  • Using [effect] apply_to=attack increase_damage=$some_variable (not tried this yet but don't think it'll work and modifying $some_variable to reflect AMLAs selected isn't straightforward to me).
  • Changing damage submitted to advancement via macro, really just a variant of logic above.
I'll keep experimenting as time permits but suspect I'll end up drastically trimming the top level AMLAs to keep the number of options sane.

Any and all feedback gratefully received!

Cheers!
-- Spannerbag
SP Campaigns: After EI (v1.14) Leafsea Burning (v1.17, v1.16)
I suspect the universe is simpler than we think and stranger than we can know.
Also, I fear that beyond a certain point more intelligence does not necessarily benefit a species...
User avatar
Celtic_Minstrel
Developer
Posts: 2166
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

Re: Can AMLAs inherit [effect]s?

Post by Celtic_Minstrel »

This is certainly a lot of work, but perhaps something that "sorts" the taken advancements whenever an advancement is applied, so that instances of AMLA #1 are always placed at the end…

In Lua it would look something like this (this is pseudo-code in Lua style):

Code: Select all

local advancing_unit = w.u__cfg
local advancements = wml.get_child_array(advancing_unit)
for i = #advancements - 1, 1, -1 do
	advancements.insert(advancements[i])
	advancements.remove(i)
end
w.u.to_map(advancing_unit)
That is far from functional code and probably missing a few pieces though.
Author of The Black Cross of Aleron campaign and Default++ era.
Former maintainer of Steelhive.
User avatar
Helmet
Posts: 641
Joined: December 19th, 2006, 5:28 pm
Location: Florida, USA

Re: Can AMLAs inherit [effect]s?

Post by Helmet »

Celtic_Minstrel wrote: February 8th, 2023, 7:02 pm...this is pseudo-code in Lua style.
I just realized something.

All my campaigns are written in pseudo-code in WML style.

:)
Author of:
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
User avatar
Spannerbag
Posts: 505
Joined: December 18th, 2016, 6:14 pm
Location: Yes

Re: Can AMLAs inherit [effect]s?

Post by Spannerbag »

Helmet wrote: February 8th, 2023, 7:07 pm
Celtic_Minstrel wrote: February 8th, 2023, 7:02 pm...this is pseudo-code in Lua style.
I just realized something.

All my campaigns are written in pseudo-code in WML style.

:)
Wish mine were :)

Thanks for the suggestion Celtic_Minstrel, I'll certainly consider descending into TOPOL (The Open Pit Of Lua) but I'll need enough rope (to hang myself) first! However prior to that, the next logic I am thinking of trying out is this (copied straight from my to do list so apologies):

Code: Select all

Within an advancement, need to check if various others already done.
Includes:
A) damage; +1 or +2 (taken once or twice)
B) strikes as above
C) marksman
D) accuracy
E) parry

[effect]
  [filter]
    [has_attack]
      range (melee/ranged) >  Need to use "always present" attack,
      name                 >    NOT one that may be acquired later!

      damage      (for +1/+2 damage;  A)
      number      (for +1/+2 strikes; B)
      special_id  (for marksman;      C)
      accuracy    (for accuracy;      D)
      parry       (for parry;         E)

Need multiple extra [effect]s to do this (these).
Added (appended) to [effect] that adds actual new attack.

***TEST THIS EARLY ON***
???
  May not work as previous [effect] (that creates new attack) may not have yet become
  visible to subsequent [effect] [filter]s in same [advancement] code block?
???

Use REF_ATTACK_ID to specify "base" reference attack as basis for testing of applied modifier AMLAs if any?
Use REF_ATTACK_DAMAGE/STRIKES/SPECIAL for "base" damage/strike(s)/special(s) etc.
Accuracy and parry will be specific values; 0, 10 or 20.
(Not used in conjunction with marksman/magic attacks).
Celtic_Minstrel, do you happen to know if an [advancement] thas multiple [effect]s tags whether subsequent [effect]s can "see" (i.e. [filter]) on the earlier [effect]s immediately or do they all "register" when the [advancement] tag is closed.
If it's the latter then this approach won't work :(

Cheers!
-- Spannerbag
SP Campaigns: After EI (v1.14) Leafsea Burning (v1.17, v1.16)
I suspect the universe is simpler than we think and stranger than we can know.
Also, I fear that beyond a certain point more intelligence does not necessarily benefit a species...
User avatar
Ravana
Forum Moderator
Posts: 2952
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: Can AMLAs inherit [effect]s?

Post by Ravana »

Is what you want, sorting [object]s in unit so that all effects which give new attack are earlier than all effects which modify attack values?
User avatar
Helmet
Posts: 641
Joined: December 19th, 2006, 5:28 pm
Location: Florida, USA

Re: Can AMLAs inherit [effect]s?

Post by Helmet »

I probably wouldn't try to do anything so complicated with AMLAs, but if somebody put a crossbow to my head this is how I might approach the problem.

I would give the unit in question a variable to track the chosen AMLAs. There are only so many possible variations of effects, after all. I would use SELECT to identify the value of the variable, and update the value based on the newly chosen effect. After that's done, the actual effects would be updated.
Author of:
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
User avatar
Spannerbag
Posts: 505
Joined: December 18th, 2016, 6:14 pm
Location: Yes

Re: Can AMLAs inherit [effect]s?

Post by Spannerbag »

Ravana wrote: February 8th, 2023, 9:00 pm Is what you want, sorting [object]s in unit so that all effects which give new attack are earlier than all effects which modify attack values?
Thanks for replying and .... errr... would that work?

Here's an example, I have all these AMLAs working with animations etc.
The problem I have is with ordering, not with the AMLAs themselves (in fact they work exactly as I would have thought but here I want to do something different).

Example
A Cavalier has a 20 x 1 ranged crossbow attack.
Suppose they select an AMLA to give this attack +1 damage.
Then later on when this unit again levels, they select another AMLA that bestows a ranged fire attack (flame bolt).
Normally this new ranged attack inflicts the same damage as the regular crossbow attack; 20.
However as the player chose the +1 damage then the crossbow attack has 21 damage and the flame bolt 20 because when the +1 damage was selected the only ranged attack the +1 damage AMLA could find was the regular crossbow.
So, if I understand correctly (biiig if!) then if I place the flame bolt AMLA before the +1 ranged damage AMLA then the +1 damage would automatically apply to the flame bolt when it is created/added?
That is, the flame bolt would "inherit" the +1 and have damage of 21 rather than the 20 specified in the flame bolt AMLA?

If so then
a) great! :D
and
b) how do I implement that?
Is it simply just a case of ordering [advancement]s in the unittype or something more complicated?

Thanks again for the suggestion, I'll try it when I understand it :doh:

Sorry to be dim.

Cheers!
-- Spannerbag
SP Campaigns: After EI (v1.14) Leafsea Burning (v1.17, v1.16)
I suspect the universe is simpler than we think and stranger than we can know.
Also, I fear that beyond a certain point more intelligence does not necessarily benefit a species...
User avatar
Spannerbag
Posts: 505
Joined: December 18th, 2016, 6:14 pm
Location: Yes

Re: Can AMLAs inherit [effect]s?

Post by Spannerbag »

Helmet wrote: February 8th, 2023, 9:07 pm I probably wouldn't try to do anything so complicated with AMLAs, but if somebody put a crossbow to my head this is how I might approach the problem.

I would give the unit in question a variable to track the chosen AMLAs. There are only so many possible variations of effects, after all. I would use SELECT to identify the value of the variable, and update the value based on the newly chosen effect. After that's done, the actual effects would be updated.
Hi Helmet, thanks for the post.

Yeah, it's the update the value based on the newly chosen effect bit that's unknown. I believe inside an [effect] isn't actionwml so variables won't work?
However I need to test this to be sure. I've been trying other things first but this option is bubbling up to the top.

Thanks for the suggestion!

Been a bit mad this week so not had time to try/do much, hopefully have some more time and sanity next week...

Cheers!
-- Spannerbag
SP Campaigns: After EI (v1.14) Leafsea Burning (v1.17, v1.16)
I suspect the universe is simpler than we think and stranger than we can know.
Also, I fear that beyond a certain point more intelligence does not necessarily benefit a species...
User avatar
Celtic_Minstrel
Developer
Posts: 2166
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

Re: Can AMLAs inherit [effect]s?

Post by Celtic_Minstrel »

Spannerbag wrote: February 8th, 2023, 11:40 pm Yeah, it's the update the value based on the newly chosen effect bit that's unknown. I believe inside an [effect] isn't actionwml so variables won't work?
The phrase "variables work in ActionWML" means that if it is nested anywhere within ActionWML, then variables will work. So variables will work in [modify_unit][effect] but will not work in [side][unit][modifications][object][effect].
Spannerbag wrote: February 8th, 2023, 11:34 pm
Ravana wrote: February 8th, 2023, 9:00 pm Is what you want, sorting [object]s in unit so that all effects which give new attack are earlier than all effects which modify attack values?
Thanks for replying and .... errr... would that work?
Well, it's the same thing I suggested…
Spannerbag wrote: February 8th, 2023, 8:26 pm Thanks for the suggestion Celtic_Minstrel, I'll certainly consider descending into TOPOL (The Open Pit Of Lua) but I'll need enough rope (to hang myself) first! However prior to that, the next logic I am thinking of trying out is this (copied straight from my to do list so apologies):
Note that though my example was in Lua pseudo-code, the same logic can be coded in WML – store unit, sort the advancements, unstore unit. In case that helps.
Spannerbag wrote: February 8th, 2023, 8:26 pm Celtic_Minstrel, do you happen to know if an [advancement] thas multiple [effect]s tags whether subsequent [effect]s can "see" (i.e. [filter]) on the earlier [effect]s immediately or do they all "register" when the [advancement] tag is closed.
If it's the latter then this approach won't work :(
I'm not quite sure what you're trying to ask, but I'll try to guess. Is it something like this?

Code: Select all

[object]
	[effect]
		apply_to=new_attack
		name=my_new_attack
		# ... etc ...
	[/effect]
	[effect]
		[filter]
			[has_attack]
				name=my_new_attack
			[/has_attack]
		[/filter]
		apply_to=attack
		name=my_new_attack
		increase_damage=1
	[/effect]
[/object]
Are you asking whether or not the second effect in that snippet will do anything?
Author of The Black Cross of Aleron campaign and Default++ era.
Former maintainer of Steelhive.
User avatar
Spannerbag
Posts: 505
Joined: December 18th, 2016, 6:14 pm
Location: Yes

Re: Can AMLAs inherit [effect]s?

Post by Spannerbag »

Whoah! A lot to unpack here, thanks for the very detailed reply, much appreciated.
Celtic_Minstrel wrote: February 9th, 2023, 12:31 am The phrase "variables work in ActionWML" means that if it is nested anywhere within ActionWML, then variables will work. So variables will work in [modify_unit][effect] but will not work in [side][unit][modifications][object][effect].
So, I have not tried this yet (been a bit of a crazy week) but, when I get a chance I'll see if variables work inside [advancement][effect]. I suspect not 'cos I don't think inside [advancement] is actionwml but you'd know better than me :)

However in the highly likely event I'm wrong then this macro (which I use a lot inside advancement):

Code: Select all

# Increase max xp
#define EFF_MAX_XP PC
[effect]
  apply_to=max_experience
  increase={PC}%
[/effect]#enddef
Could take its value from a variable, something like:

Code: Select all

# Increase max xp
#define EFF_MAX_XP VAR_NAME
[effect]
  apply_to=max_experience
  increase="${VAR_NAME}|%"		# Or maybe "${VAR_NAME}"+"%" ?
[/effect]#enddef
might work?
(I don't actually need to do this but picked this macro as an example because of the extra appended % sign...)
When I get a decent chunk of time I'll give it a try.

Celtic_Minstrel wrote: February 9th, 2023, 12:31 am
Spannerbag wrote: February 8th, 2023, 8:26 pm
Ravana wrote: February 8th, 2023, 9:00 pm Is what you want, sorting [object]s in unit so that all effects which give new attack are earlier than all effects which modify attack values?
Thanks for replying and .... errr... would that work?
Well, it's the same thing I suggested…
...
Note that though my example was in Lua pseudo-code, the same logic can be coded in WML – store unit, sort the advancements, unstore unit. In case that helps.
It certainly does!
Just to be clear, if I do this in wml I need to:
  • Store the unit into some variable, call it $unitadv
  • then sort $unitadv.advancement so "modifier" AMLAs (+1 damage for example) occur later than "new stuff" AMLAs such as add an entirely new attack?
[sanity_check]
Presumably, for this work, I need to do this once only as soon as the unit levels up to maximum level and these custom advancements become available?
[/sanity_check]

If that works, it'll be a huge help!
Celtic_Minstrel wrote: February 9th, 2023, 12:31 am I'm not quite sure what you're trying to ask, but I'll try to guess. Is it something like this?

Code: Select all

[object]
	[effect]
		apply_to=new_attack
		name=my_new_attack
		# ... etc ...
	[/effect]
	[effect]
		[filter]
			[has_attack]
				name=my_new_attack
			[/has_attack]
		[/filter]
		apply_to=attack
		name=my_new_attack
		increase_damage=1
	[/effect]
[/object]
Are you asking whether or not the second effect in that snippet will do anything?
Exactly that, yes :D

Again, thanks ever so much for the fulsome reply, it really clarified things!

Cheers!
-- Spannerbag
SP Campaigns: After EI (v1.14) Leafsea Burning (v1.17, v1.16)
I suspect the universe is simpler than we think and stranger than we can know.
Also, I fear that beyond a certain point more intelligence does not necessarily benefit a species...
User avatar
Celtic_Minstrel
Developer
Posts: 2166
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

Re: Can AMLAs inherit [effect]s?

Post by Celtic_Minstrel »

Spannerbag wrote: February 9th, 2023, 1:12 pm Whoah! A lot to unpack here, thanks for the very detailed reply, much appreciated.
Celtic_Minstrel wrote: February 9th, 2023, 12:31 am The phrase "variables work in ActionWML" means that if it is nested anywhere within ActionWML, then variables will work. So variables will work in [modify_unit][effect] but will not work in [side][unit][modifications][object][effect].
So, I have not tried this yet (been a bit of a crazy week) but, when I get a chance I'll see if variables work inside [advancement][effect]. I suspect not 'cos I don't think inside [advancement] is actionwml but you'd know better than me :)

However in the highly likely event I'm wrong then this macro (which I use a lot inside advancement):
I would not expect that to work. An [advancement] can appear in ActionWML (where variables are substituted), but usually it is placed in UnitTypeWML (where variables are not substituted).
Spannerbag wrote: February 9th, 2023, 1:12 pm It certainly does!
Just to be clear, if I do this in wml I need to:
  • Store the unit into some variable, call it $unitadv
  • then sort $unitadv.advancement so "modifier" AMLAs (+1 damage for example) occur later than "new stuff" AMLAs such as add an entirely new attack?
[sanity_check]
Presumably, for this work, I need to do this once only as soon as the unit levels up to maximum level and these custom advancements become available?
[/sanity_check]

If that works, it'll be a huge help
Close. There are two arrays that sound similar but are very different: $unitadv.advancement and $unitadv.modifications.advancement. It's the second one you want to sort.

(The first array is possible available advancements; the second is advancements already taken.)

Spannerbag wrote: February 9th, 2023, 1:12 pm
Celtic_Minstrel wrote: February 9th, 2023, 12:31 am I'm not quite sure what you're trying to ask, but I'll try to guess. Is it something like this?

Code: Select all

[object]
	[effect]
		apply_to=new_attack
		name=my_new_attack
		# ... etc ...
	[/effect]
	[effect]
		[filter]
			[has_attack]
				name=my_new_attack
			[/has_attack]
		[/filter]
		apply_to=attack
		name=my_new_attack
		increase_damage=1
	[/effect]
[/object]
Are you asking whether or not the second effect in that snippet will do anything?
Exactly that, yes :D

Again, thanks ever so much for the fulsome reply, it really clarified things!
I believe it will but I'm not sure. I guess you'd have to test it.
Author of The Black Cross of Aleron campaign and Default++ era.
Former maintainer of Steelhive.
User avatar
Spannerbag
Posts: 505
Joined: December 18th, 2016, 6:14 pm
Location: Yes

Re: Can AMLAs inherit [effect]s?

Post by Spannerbag »

Celtic_Minstrel wrote: February 9th, 2023, 2:35 pm ... I would not expect that to work. An [advancement] can appear in ActionWML (where variables are substituted), but usually it is placed in UnitTypeWML (where variables are not substituted).
My stuff's the latter. Pity, that could've come in handy.
Celtic_Minstrel wrote: February 9th, 2023, 2:35 pm ... Close. There are two arrays that sound similar but are very different: $unitadv.advancement and $unitadv.modifications.advancement. It's the second one you want to sort.

(The first array is possible available advancements; the second is advancements already taken.)
May I summarise my understanding of how this works to check I've got it right?

I need to have something like:

Code: Select all

[event]
	name=post advance
	first_time_only=no
	[filter]
		type=<list of unittypes with custom AMLAs>
	[/filter]
	[store_unit]				# Would [modify_unit] work better?
		[filter]
			id=$unit.id
		[/filter]
		variable=unitadv
	[/store_unit]

... logic to sort [c]$unitadv.modifications.advancement[/c] ...

	[unstore_unit]				# Not needed if [modify_unit] used
		variable=unitadv
		find_vacant=no			# Clobber (overwrite) existing (pre-sort) version
	[/unstore_unit]
	{CLEAR_VARIABLE unitadv}	# Not needed if [modify_unit] used
[/event]
I'm not clear where in the code above the AMLAs are updated/rebuilt, I'm guessing it's [unstore_unit]?
Also I'm guessing this is only worth doing if $unitadv.modifications.advancement.length >1 ?
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 :)
Celtic_Minstrel wrote: February 9th, 2023, 12:31 am ... Are you asking whether or not the second effect in that snippet will do anything?
... I believe it will but I'm not sure. I guess you'd have to test it.
Fair enough, another one for next week.

Again, thanks for all your help.

I appreciate all your time and really don't want to impose on your patience so if you've had enough of explaining basic/obvious stuff to a thickie I understand :)

Cheers!
-- Spannerbag
SP Campaigns: After EI (v1.14) Leafsea Burning (v1.17, v1.16)
I suspect the universe is simpler than we think and stranger than we can know.
Also, I fear that beyond a certain point more intelligence does not necessarily benefit a species...
User avatar
Ravana
Forum Moderator
Posts: 2952
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: Can AMLAs inherit [effect]s?

Post by Ravana »

[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.
Post Reply