[solved] unit.__cfg.advances_to
Moderator: Forum Moderators
- hermestrismi
- Posts: 730
- Joined: February 6th, 2016, 11:28 pm
- Location: Tunisia
- Contact:
Re: unit.__cfg.advances_to
so, for now, I can say: problem solved but questions remain to eternity and beyond:D
The Dark Master, The Dark Hordes (Unofficial version), Return of the Legion , Eternal Kingdom, An Elvish Scout,Unrest in Elfland , Hidden War ...
The Dark Master Project, Arabic tra. maintainer
"But he loves you" G. Carlin
The Dark Master Project, Arabic tra. maintainer
"But he loves you" G. Carlin
-
- Posts: 1456
- Joined: August 26th, 2018, 11:46 pm
- Location: A country place, far outside the Wire
Re: unit.__cfg.advances_to
It's an empty table.hermestrismi wrote: ↑July 20th, 2024, 10:03 am the main problem for my point of view is that 'advances_to=null' give an empty space when use 'unit.advance_to' or 'unit.__cfg.advances_to'. in both cases, that space is not a nil value neither a "null" string nor a 'string'. what is it exactly?
Speak softly, and carry Doombringer.
- hermestrismi
- Posts: 730
- Joined: February 6th, 2016, 11:28 pm
- Location: Tunisia
- Contact:
Re: unit.__cfg.advances_to
a logic assumption that I should catch from the beginning. I should know that when I get a table when I used string.format at some point in my tries.white_haired_uncle wrote: ↑July 20th, 2024, 10:11 amIt's an empty table.hermestrismi wrote: ↑July 20th, 2024, 10:03 am the main problem for my point of view is that 'advances_to=null' give an empty space when use 'unit.advance_to' or 'unit.__cfg.advances_to'. in both cases, that space is not a nil value neither a "null" string nor a 'string'. what is it exactly?
is that the same case for empty names, too?
The Dark Master, The Dark Hordes (Unofficial version), Return of the Legion , Eternal Kingdom, An Elvish Scout,Unrest in Elfland , Hidden War ...
The Dark Master Project, Arabic tra. maintainer
"But he loves you" G. Carlin
The Dark Master Project, Arabic tra. maintainer
"But he loves you" G. Carlin
- Spannerbag
- Posts: 759
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: unit.__cfg.advances_to
Probably a bit late now, but if you want a purely WML way to see if a unit has a higher level advancement you can use this code.
I knocked it up pretty quickly and it's ugly but it seems to work and should give you an idea for more elegant WML if you fancy this route.
If you use the
Basically shove all the units you want to test in the filter and if you want to extract all those *with* higher level advancements, it should find them if you wrap a [not] around [filter_wml], otherwise the logic will store all units that are at their highest level.
I've also coded a test via [have_unit] if all you want to do is test whether or not one or more units have higher level advancements.
Edit: added [not] test to code below
Hope this helps!
Cheers!
-- Spannerbag
I knocked it up pretty quickly and it's ugly but it seems to work and should give you an idea for more elegant WML if you fancy this route.
If you use the
[store_unit]
method, you can extract the individual advancement(s) for each unit if you wish.Basically shove all the units you want to test in the filter and if you want to extract all those *with* higher level advancements, it should find them if you wrap a [not] around [filter_wml], otherwise the logic will store all units that are at their highest level.
I've also coded a test via [have_unit] if all you want to do is test whether or not one or more units have higher level advancements.
Edit: added [not] test to code below
Code: Select all
# Advances_to test
[event]
name=side 1 turn 1 refresh
{GENERIC_UNIT 1 (Great Mage) 4 4)} # Unit with no advancments
[store_unit]
[filter]
id=Goody # Spearman and leader
[filter_wml]
glob_on_advances_to=""
[/filter_wml]
[/filter]
variable=adv2test
[/store_unit]
[if]
{VARIABLE_CONDITIONAL adv2test.length greater_than 0}
[then]
{DEBUG_MSG (_"Goody, Spearman, does NOT have advancements, except perhaps AMLAs - WRONG")}
[/then]
[else]
{DEBUG_MSG (_"Goody, Spearman, has higher level advancements - CORRECT")}
[/else]
[/if]
[store_unit]
[filter]
x,y=4,4
[filter_wml]
glob_on_advances_to=""
[/filter_wml]
[/filter]
variable=adv2test
[/store_unit]
[if]
{VARIABLE_CONDITIONAL adv2test.length greater_than 0}
[then]
{DEBUG_MSG (_"Great Mage does NOT have advancements, except perhaps AMLAs - CORRECT")}
[/then]
[else]
{DEBUG_MSG (_"Great Mage has higher level advancements - WRONG")}
[/else]
[/if]
{CLEAR_VARIABLE adv2test}
# Test via have unit
[if]
[have_unit]
id=Goody # Spearman and leader
[filter_wml]
glob_on_advances_to=""
[/filter_wml]
count=0 # Shorter than [not][/not]
[/have_unit]
[then]
{DEBUG_MSG (_"Goody, Spearman, has higher level advancements - CORRECT")}
[/then]
[else]
{DEBUG_MSG (_"Goody, Spearman, does NOT have advancements, except perhaps AMLAs - WRONG")}
[/else]
[/if]
[if]
[have_unit]
x,y=4,4 # Great Mage
[filter_wml]
glob_on_advances_to=""
[/filter_wml]
[/have_unit]
[then]
{DEBUG_MSG (_"Great Mage does NOT have advancements, except perhaps AMLAs - CORRECT")}
[/then]
[else]
{DEBUG_MSG (_"Great Mage has higher level advancements - WRONG")}
[/else]
[/if]
# test store with not
[store_unit]
[filter]
id=Goody # Spearman and leader
[not]
[filter_wml]
glob_on_advances_to=""
[/filter_wml]
[/not]
[/filter]
variable=adv2test
[/store_unit]
[if]
{VARIABLE_CONDITIONAL adv2test.length greater_than 0}
[then]
{DEBUG_MSG (_"[not] test - Goody, Spearman, has higher level advancements - CORRECT")}
[/then]
[else]
{DEBUG_MSG (_"[not] test - Goody, Spearman, does NOT have advancements, except perhaps AMLAs - WRONG")}
[/else]
[/if]
[/event]
Cheers!
-- Spannerbag
- hermestrismi
- Posts: 730
- Joined: February 6th, 2016, 11:28 pm
- Location: Tunisia
- Contact:
Re: unit.__cfg.advances_to
thank you very much. I may need it when I want to check if a unit have an optional amla already instead of a regular advances_to. I will add it to my library of "to check later"Spannerbag wrote: ↑July 20th, 2024, 12:18 pm Probably a bit late now, but if you want a purely WML way to see if a unit has a higher level advancement you can use this code.
I knocked it up pretty quickly and it's ugly but it seems to work and should give you an idea for more elegant WML if you fancy this route.
If you use the[store_unit]
method, you can extract the individual advancement(s) for each unit if you wish.
Basically shove all the units you want to test in the filter and if you want to extract all those *with* higher level advancements, it should find them if you wrap a [not] around [filter_wml], otherwise the logic will store all units that are at their highest level.
I've also coded a test via [have_unit] if all you want to do is test whether or not one or more units have higher level advancements.
Edit: added [not] test to code below
Hope this helps!Code: Select all
# Advances_to test [event] name=side 1 turn 1 refresh {GENERIC_UNIT 1 (Great Mage) 4 4)} # Unit with no advancments [store_unit] [filter] id=Goody # Spearman and leader [filter_wml] glob_on_advances_to="" [/filter_wml] [/filter] variable=adv2test [/store_unit] [if] {VARIABLE_CONDITIONAL adv2test.length greater_than 0} [then] {DEBUG_MSG (_"Goody, Spearman, does NOT have advancements, except perhaps AMLAs - WRONG")} [/then] [else] {DEBUG_MSG (_"Goody, Spearman, has higher level advancements - CORRECT")} [/else] [/if] [store_unit] [filter] x,y=4,4 [filter_wml] glob_on_advances_to="" [/filter_wml] [/filter] variable=adv2test [/store_unit] [if] {VARIABLE_CONDITIONAL adv2test.length greater_than 0} [then] {DEBUG_MSG (_"Great Mage does NOT have advancements, except perhaps AMLAs - CORRECT")} [/then] [else] {DEBUG_MSG (_"Great Mage has higher level advancements - WRONG")} [/else] [/if] {CLEAR_VARIABLE adv2test} # Test via have unit [if] [have_unit] id=Goody # Spearman and leader [filter_wml] glob_on_advances_to="" [/filter_wml] count=0 # Shorter than [not][/not] [/have_unit] [then] {DEBUG_MSG (_"Goody, Spearman, has higher level advancements - CORRECT")} [/then] [else] {DEBUG_MSG (_"Goody, Spearman, does NOT have advancements, except perhaps AMLAs - WRONG")} [/else] [/if] [if] [have_unit] x,y=4,4 # Great Mage [filter_wml] glob_on_advances_to="" [/filter_wml] [/have_unit] [then] {DEBUG_MSG (_"Great Mage does NOT have advancements, except perhaps AMLAs - CORRECT")} [/then] [else] {DEBUG_MSG (_"Great Mage has higher level advancements - WRONG")} [/else] [/if] # test store with not [store_unit] [filter] id=Goody # Spearman and leader [not] [filter_wml] glob_on_advances_to="" [/filter_wml] [/not] [/filter] variable=adv2test [/store_unit] [if] {VARIABLE_CONDITIONAL adv2test.length greater_than 0} [then] {DEBUG_MSG (_"[not] test - Goody, Spearman, has higher level advancements - CORRECT")} [/then] [else] {DEBUG_MSG (_"[not] test - Goody, Spearman, does NOT have advancements, except perhaps AMLAs - WRONG")} [/else] [/if] [/event]
Cheers!
-- Spannerbag
The Dark Master, The Dark Hordes (Unofficial version), Return of the Legion , Eternal Kingdom, An Elvish Scout,Unrest in Elfland , Hidden War ...
The Dark Master Project, Arabic tra. maintainer
"But he loves you" G. Carlin
The Dark Master Project, Arabic tra. maintainer
"But he loves you" G. Carlin
Re: unit.__cfg.advances_to
Looks like you accept any advancements, not just those that point to higher level.Spannerbag wrote: ↑July 20th, 2024, 12:18 pm Probably a bit late now, but if you want a purely WML way to see if a unit has a higher level advancement you can use this code.
- Spannerbag
- Posts: 759
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: unit.__cfg.advances_to
Well, IRavana wrote: ↑July 20th, 2024, 1:24 pmLooks like you accept any advancements, not just those that point to higher level.Spannerbag wrote: ↑July 20th, 2024, 12:18 pm Probably a bit late now, but if you want a purely WML way to see if a unit has a higher level advancement you can use this code.
:inspected
a unit (Elite Ancient Wose, L3) with AMLAs and advances_to=""
, tho' it did have [advancement]
s?These are custom units with
[base_unit]
s - does that make a difference?Here's the edited highlights (1.18.2):
Code: Select all
advances_to=""
...
level=3
...
[advancement]
#textdomain wesnoth-LSB
description=_"+15 resistance to axes (blade).   Max HP bonus +3.   Max XP +15%.   No heal."
id="ca_irw_2w"
image="amla/blade-resist.png"
major_amla=yes
max_times=2
strict_amla=yes
[effect]
apply_to="resistance"
replace=no
[resistance]
blade=-15
[/resistance]
[/effect]
[effect]
apply_to="hitpoints"
heal_full=no
increase_total=3
[/effect]
[effect]
apply_to="max_experience"
increase="15%"
[/effect]
[/advancement]
...
[variables]
[/variables]
[status]
[/status]
Code: Select all
advances_to="lsb_Ancient Wose"
...
level=2
...
[status]
[/status]
advances_to=
.So, as far as I can see, only when the unit can advance to a new
[unit_type]
is advances_to=
set to non-null?Cheers!
-- Spannerbag
Re: unit.__cfg.advances_to
There is nothing that stops people creating advancement graphs that have level 3 unit advance to level 2 unit that advances to level 4 unit. After all, level makes your unit weaker, by giving enemies xp and spending gold. So better unit should have lower level. It is only in case of leadership and reverse leadership and few other level based abilities where balance uses level.
- Spannerbag
- Posts: 759
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: unit.__cfg.advances_to
OK, didn't realise that, but the op was:Ravana wrote: ↑July 20th, 2024, 11:06 pm There is nothing that stops people creating advancement graphs that have level 3 unit advance to level 2 unit that advances to level 4 unit. After all, level makes your unit weaker, by giving enemies xp and spending gold. So better unit should have lower level. It is only in case of leadership and reverse leadership and few other level based abilities where balance uses level.
Am I misunderstanding something?hermestrismi wrote: ↑July 20th, 2024, 6:42 am I am surrounding. can someone provide me with a function to check if a unit can advance to another unit or to null?
I tried many different methods but I am stock.
As far as I can see my code would be able to differentiate between units that advance to another
[unit_type]
and those that do not?Isn't that what was wanted?
OK my logic ignores AMLAs - but AMLAs don't (usually) change
[unit_type]
(I suppose an AMLA could be created to do that, but not sure why anyone would bother; a regular advancement would be more in keeping with the gameplay IMHO).Cheers!
-- Spannerbag
Re: unit.__cfg.advances_to
I dont like the design choice to solve the problem with glob, but result sounds correct. After all, if all responsibility is given to [filter], formula looks easier to read.
For WML implementation would make sense to collect the advancements with https://wiki.wesnoth.org/InternalAction ... bles-split.
For WML implementation would make sense to collect the advancements with https://wiki.wesnoth.org/InternalAction ... bles-split.