Can AMLAs inherit [effect]s? *FIXED*
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.
- Spannerbag
- Posts: 534
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Can AMLAs inherit [effect]s? *FIXED*
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
I'm assuming that within
One way I could do this would be to have supplementary
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
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.
Re: Can AMLAs inherit [effect]s?
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.
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?
- Spannerbag
- Posts: 534
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: Can AMLAs inherit [effect]s?
Hi, thanks for replying.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.
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) - ...
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.
- AMLA #3
Is straighforward. - AMLA #1
Will do its thing for AMLA #3 (+1 damage or whatever). - AMLA #4
Here the logic needs to apply AMLA#4 and then AMLA#1 once. - 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
). - AMLA #2
Also needs AMLA #1 applying twice.
[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
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.
Any and all feedback gratefully received!
Cheers!
-- Spannerbag
- Celtic_Minstrel
- Developer
- Posts: 2194
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Can AMLAs inherit [effect]s?
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):
That is far from functional code and probably missing a few pieces though.
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)
Re: Can AMLAs inherit [effect]s?
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.
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
- Spannerbag
- Posts: 534
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: Can AMLAs inherit [effect]s?
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).
[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
Re: Can AMLAs inherit [effect]s?
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?
Re: Can AMLAs inherit [effect]s?
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.
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.
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
- Spannerbag
- Posts: 534
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: Can AMLAs inherit [effect]s?
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?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.
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!
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
Sorry to be dim.
Cheers!
-- Spannerbag
- Spannerbag
- Posts: 534
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: Can AMLAs inherit [effect]s?
Hi Helmet, thanks for the post.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.
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
- Celtic_Minstrel
- Developer
- Posts: 2194
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Can AMLAs inherit [effect]s?
The phrase "variables work in ActionWML" means that if it is nested anywhere within ActionWML, then variables will work. So variables will work inSpannerbag 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?
[modify_unit][effect]
but will not work in [side][unit][modifications][object][effect]
.Well, it's the same thing I suggested…Spannerbag wrote: ↑February 8th, 2023, 11:34 pmThanks for replying and .... errr... would that work?
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 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):
I'm not quite sure what you're trying to ask, but I'll try to guess. Is it something like this?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
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]
- Spannerbag
- Posts: 534
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: Can AMLAs inherit [effect]s?
Whoah! A lot to unpack here, thanks for the very detailed reply, much appreciated.
However in the highly likely event I'm wrong then this macro (which I use a lot inside
Could take its value from a variable, something like:
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.
Just to be clear, if I do this in wml I need to:
Presumably, for this work, I need to do this once only as soon as the unit levels up to maximum level and these custom
[/sanity_check]
If that works, it'll be a huge help!
Again, thanks ever so much for the fulsome reply, it really clarified things!
Cheers!
-- Spannerbag
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 insideCeltic_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]
.
[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
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
(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.
It certainly does!Celtic_Minstrel wrote: ↑February 9th, 2023, 12:31 amWell, it's the same thing I suggested…Spannerbag wrote: ↑February 8th, 2023, 8:26 pmThanks for replying and .... errr... would that work?
...
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.
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?
Presumably, for this work, I need to do this once only as soon as the unit levels up to maximum level and these custom
advancement
s become available?[/sanity_check]
If that works, it'll be a huge help!
Exactly that, yesCeltic_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?
Are you asking whether or not the second effect in that snippet will do anything?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]
Again, thanks ever so much for the fulsome reply, it really clarified things!
Cheers!
-- Spannerbag
- Celtic_Minstrel
- Developer
- Posts: 2194
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Can AMLAs inherit [effect]s?
I would not expect that to work. AnSpannerbag wrote: ↑February 9th, 2023, 1:12 pm Whoah! A lot to unpack here, thanks for the very detailed reply, much appreciated.
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 insideCeltic_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]
.[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 insideadvancement
):
[advancement]
can appear in ActionWML (where variables are substituted), but usually it is placed in UnitTypeWML (where variables are not substituted).Close. There are two arrays that sound similar but are very different:Spannerbag wrote: ↑February 9th, 2023, 1:12 pm It certainly does!
Just to be clear, if I do this in wml I need to:[sanity_check]
- 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?
Presumably, for this work, I need to do this once only as soon as the unit levels up to maximum level and these customadvancement
s become available?
[/sanity_check]
If that works, it'll be a huge help
$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.)
I believe it will but I'm not sure. I guess you'd have to test it.Spannerbag wrote: ↑February 9th, 2023, 1:12 pmExactly that, yesCeltic_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?
Are you asking whether or not the second effect in that snippet will do anything?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]
Again, thanks ever so much for the fulsome reply, it really clarified things!
- Spannerbag
- Posts: 534
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: Can AMLAs inherit [effect]s?
My stuff's the latter. Pity, that could've come in handy.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).
May I summarise my understanding of how this works to check I've got it right?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.)
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]
[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 Fair enough, another one for next week.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.
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
Re: Can AMLAs inherit [effect]s?
[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.