enclave's WML Macros questions Thread

[Ravana]

## seems to work, but for some reason still shows experience in blue, like if unit can advance to something..

Blue means lack of amla, not availability of advancement.

Ravana how can I be 100% sure to report it? What if there is something in my era making a bug.. Idk..

By creating minimal test case, and seeing if it happens there.

For animation macros see animation-utils.cfg.


...
Downloaded you addon, grepped for fog clearer, and cause of problem is this.

Code: Select all

#define BUILD_BARRIER
					[unit]
					type=Fog Clearer
					id=New_Barrier
					name= _"Barrier"
					upkeep=loyal
					unrenamable=yes
					level=0
					zoc=no
					side=$side_number
					x,y=$x1,$y1
					random_traits=no
					moves=0
					max_moves=1
					role=structure
					to_variable=new_barrier
					[/unit]
	{VARIABLE_OP new_barrier.race value mechanical}
	{VARIABLE_OP new_barrier.image value terrain/castle/encampment-tile.png}
	{VARIABLE_OP new_barrier.id value Barrier}
	{VARIABLE_OP new_barrier.hitpoints value $barrier_hp}
	{VARIABLE_OP new_barrier.max_hitpoints value $barrier_hp}
	{VARIABLE_OP new_barrier.moves value 0}
	{VARIABLE_OP new_barrier.level value 0}
	{VARIABLE_OP new_barrier.defense.castle value 100}
	{VARIABLE_OP new_barrier.resistance.impact value 50}
	{VARIABLE_OP new_barrier.resistance.blade value 100}
	{VARIABLE_OP new_barrier.resistance.pierce value 50}
	{VARIABLE_OP new_barrier.resistance.arcane value 50}
	{VARIABLE_OP new_barrier.resistance.fire value 140}
	{VARIABLE_OP new_barrier.resistance.cold value 50}
	{VARIABLE_OP new_barrier.max_experience value 999}
				[unstore_unit]
					variable=new_barrier
				[/unstore_unit]
	{MODIFY_TERRAIN $barrier_terrain $x1 $y1}
	{CLEAR_VARIABLE new_barrier}
	{VARIABLE finished yes} 
#enddef

and all similar.

Admittedly it is not very intuitive, but I let you think of this few h before explaining more.

[beetlenaut]

If I understood things right, then unfortunately, your way doesn't help me, beetlenaut ;( I think if you try to turn Falcon into Lich you would feel my pain but it probably works perfect for necro-lich conversion.. because they most probably making same sounds etc..

I don't think you are understanding right. (Or, at least one of us isn't.) I didn't use any [object]s or [effect]s. I could totally turn a falcon into a lich my way because the falcon would be removed from the game, and the lich would be a completely separate new unit. There is no reason the lich would inherit any of the sounds, animations, images, etc. from the falcon because they are not related in any way. But, while I was creating the lich with [unit], I could set some variables using data from the stored falcon (name, location, traits, whatever).

[Ravana]

I believe the problem was turning unit into another without having to define another unit_type like you assumed existed for Lich.

[enclave]

Thanks very much Ravana with help on id bug I would never find it just because I wouldn't think there was anything wrong with id part maybe at least until I would make all my walls falcons and find the same problem lol.. then I would study every cm of my code.. and then few years after the bug would be fixed! but now, it will be fixed NOW!

Yeah beetlenaut, I think we both didn't understand each other, now I think I understand you
I think you are using your code to advance necromancer into Lich before necromancer gains xp or something similar.. in short - any time you like. Basically using your code to turn one unit type into another, but keeping the name, position.. side.. etc

My problem was different, I needed to erase parts of the unit_type... it would not help me if I could turn my falcon into Lich or Great Mage or Yeti.. I needed a unit without sound on defense (like Fog Clearer is but NOT fog cleaerer), without traits, with fly ability.. etc..
I'm quite confident that storing unit, then manipulating variables and then unstoring would not help my problem. because I have already tried it and it didn't work, that's why I thought maybe some kind of [effect] could help..

But thankfully Ravana found bug in my code that was inherited to me with my mod from Dovolente settlers and I never changed that bit.. but turns out there was a bug all this time.
Thank you so much for your time both of you!

[enclave]

Hi again!
Has anyone changed advancements for units not in [unit_type]?

I have ogre..
they dont advance.. they have AMLA instead.. and experience is shown in purple color like unit can not advance..
I want to make it shown in teal color..

When I inspect the ogre unit with debug /inspect
it shows

Code: Select all

[advancement]
# textdomain wesnoth-help
description=...
id="amla_default"
max_times=100
strict_amla=yes
...
[effect]
..
[/effect]
[/advancement]

I have tried to store unit and modify it like this:

Code: Select all

{VARIABLE new_unit_advancement[0].modifications.advance.id ogre_leader_advancement}
{VARIABLE new_unit_advancement[0].modifications.advance.strict_amla no}

and it still shows purple xp.. and the debug /inspect
showing same as before, plus in the end of unit array also:

Code: Select all

[advance]
id="ogre_leader_advancement"
strict_amla=no
[/advance]

How to make xp teal color instead of purple? Thank you very much everyone who can answer..!

[enclave]

Another question: what is parent_type for? any good use?

Regarding my previous question:
I tried like this:

Code: Select all

[unit]
...
[modifications]
[object]
...
[/object]
[advance]
			id="ogre_leader_advancement"
			description="Can advance into Ogre Leader"
			strict_amla=no
			always_display=true
			[/advance]
			[advancement]
			id="ogre_leader_advancement"
			description="Can advance into Ogre Leader"
			strict_amla=no
			always_display=true
			[/advancement]
			unit_description="blablabla"
			[/modifications]
...
[/unit]

same result as with {VARIABLE ...} nothing changed.. it only added this code to the end of unit array.. which I can see with debug /inspect
Am I doing something wrong? http://wiki.wesnoth.org/SingleUnitWML
What unit_description does? Doesn't seem to do anything, am I using it wrong?
Thank you!

[enclave]

Here is the answer to my question:

To make amount of xp show in teal and not purple (make it look like unit can advance to something):
Need to add to [unit] "advances_to=Ogre" (put whatever unit type you like instead of "Ogre", you can find all unit types in core folder of wesnoth... in units folder (on my windows7 PC it is here C:\Program Files (x86)\Battle for Wesnoth 1.12.1\data\core)

So when I put "advances_to=Ogre" to my Ogre [unit], his xp is now teal.. and players may think that it can advance.
The other way is to [store_unit] and then {VARIABLE stored_unit[0].advances_to Ogre} and then [unstore_unit]
In my case I don't care that my Ogre will advance to Ogre, because as soon as it happens it will turn into unit I like anyway..
because I will have [event] name=advance (where it will [store_unit] into some variable..)
and then I have [event] name=post advance (where I will [kill] the advanced ogre and then put some other [unit] to exactly same place.. just using stored_unit[0].name and stored_unit[0].experience and some other variables of my choice.. if need be)

the "advances_to" is not described in help (https://wiki.wesnoth.org/SingleUnitWML).. thats why I just luckily found it just by playing around for couple hours with different variables.. "advances_to" belongs to [unit_type] in help.. but it seems it is working for [unit] tag also.

forget about all these [advance] etc.. nothing worked for me. Unless somebody later reply here who has more knowledge than me to explain the proper way how it works..

I actually just found more information on my previous problem above, Dugi mentioned somewhere (here http://forum.wesnoth.org/viewtopic.php? ... 2&start=15) that you can put [advancement] in a [unit] tag and it will work, but if you [unstore_unit] it will disappear and maybe that was my problem, because I used [unstore_unit].. hmm but not in all cases.. I think im 100% sure I tried without [unstore_unit] also.. and it didn't work for me.

[enclave]

Came across another silly problem..

I am doing {VARIABLE stored_unit[0].defense.cave 30}

and now unit's defense in cave and village cave is 70%...

how to leave it 70% for cave, but make it 40% in village cave?

strange thing is that ogres by default are having 40% in cave village (Uu^Vu) and 50% on hill cave (Uh).. but when I change cave defense they both become 70% for the units I changed.. the rest units are still 40/50.. but I can not see WHAT IS MAKING IT HAPPEN when i /inspect the unit array... I just don't see anything.. Units I changed have the usual 50% on hills (Hh), so I can't understand... please somebody help!!!

PS. I have looked into core unit of Ogre and found there is only arcane=80 in [resistance] while Ogres also have pierce and blade resistances.. so they must be coded in movement_type=largefoot somewhere? But I don't know where to find cfg with movement_types.. anyone knows? Thanks!

[James_The_Invisible]

Regarding my previous question:
I tried like this:

Code: Select all

[unit]
...
[modifications]
[object]
...
[/object]
[advance]
			id="ogre_leader_advancement"
			description="Can advance into Ogre Leader"
			strict_amla=no
			always_display=true
			[/advance]
			[advancement]
			id="ogre_leader_advancement"
			description="Can advance into Ogre Leader"
			strict_amla=no
			always_display=true
			[/advancement]
			unit_description="blablabla"
			[/modifications]
...
[/unit]

same result as with {VARIABLE ...} nothing changed.. it only added this code to the end of unit array.. which I can see with debug /inspect
Am I doing something wrong? http://wiki.wesnoth.org/SingleUnitWML

[modifications][advance] adds something to list of taken amlas. That means that all effects are applied to the unit and the amla will not be available to choose when the unit is advancing. [modifications][advancement] does nothing at all prior to Wesnoth 1.13.2, in 1.13.2 it replaces [advance].
But you can use (since 1.13.2) this:

Code: Select all

[object]
     ...
    [effect]
        apply_to=new_advancement
        ...
       [advancement]
           ...
      [/advancement]
    [/effect]
[/object]

I don't know where to find cfg with movement_types

Default movement types are defined in data/core/units.cfg.

[enclave]

Thanks very much James_The_Invisible, good to know that basically it works just not removing purple color from amount of xp?
I will look at movetypes now, thanks!

Anyone knows how to solve the cave thing? really my biggest problem at the moment

In movetypes saying the following: ogre should have 40% defense on cave.. and 60% on village..
EDIT: sorry was looking at wrong movetype.. listed code below shows smallfoot, ogres are bigfoot. So 40% on cave, 40% on village.

Code: Select all

 [movetype]
        name=smallfoot
        [movement_costs]
            shallow_water=3
            reef=2
            swamp_water=3
            flat=1
            sand=2
            forest=2
            hills=2
            mountains=3
            village=1
            castle=1
            cave=2
            frozen=3
            fungus=2
        [/movement_costs]

        [defense]
            shallow_water=80
            reef=70
            swamp_water=80
            flat=60
            sand=70
            forest=50
            hills=50
            mountains=40
            village=40
            castle=40
            cave=60
            frozen=80
            fungus=50
        [/defense]

        [resistance]
            blade=100
            pierce=100
            impact=100
            fire=100
            cold=100
            arcane=80
        [/resistance]
    [/movetype]

1) Anyone knows why I see that by DEFAULT ogres have 40% defense on cave villages (Uu^Vu) and 50% defense on cave hills (Uh)?
And then if i change defense.cave then suddenly Ogres have same defense on both Uu^Vu and Uh... how is it working? is it a bug?

2) I understand it may be unfixable.. and Im most of the time writing to forums only because somebody may know solution and it will take me 15 min to implement it.. or I need to dig for some hours... which I don't have most of time
So maybe anyone knows how to add trait or ability to unit that would make this unit have specific defense on "terrain=Uh" ?
Not just village.. or cave.. but would work on terrain codes.. and be visible to players (not only worked during attack/defense)?
Thanks everyone!

PS. Ravana answered my question #1 in different place: if we talk about mixed terrains the higest defense will apply..
so for example if you set VARIABLE someunitarray[somenumber].defense.cave 30 (70%), defense.village 20 (80%), defense.hills 10 (90%) then you will get 80% on cave village (highest taken from village not cave), 90% on cave hill (highest taken from hills, not cave). But if you set defense.cave 30 (70%), defense.village 60 (40%), defense.hills 50 (50%) then you will get 70% on cave hill and 70% on cave village.. (highest taken from cave). Keep in mind that cave defense doesn't seem to apply to any fungus types.. one of the fungus despite looking like cave is a road flat type.. and the other one also on cave background is a fungus defense type..
Therefore I will have to solve my problem by either adding my ogre some kind of ferral trait (like Falcon or maybe bat has..) or using different village type (and apply image of cave village on top as overlay, not going to do that.. just listing as one of the options. maybe would not even worked bugfree) or different cave hill terrain.. for example fungus, which has separate defense type.. maybe there are more options, but I'm currently not aware of them. Thanks everyone for reading.

Here is my solution for cave villages (you can use it for whatever else I guess), and it works perfectly:

Code: Select all

		
[unit]
type=Ogre
...
[modifications]
    [trait]
        id=ns_ogre_fortify
        availability="musthave"
        male_name= _ "cave fortify"
        female_name= _ "female^cave fortify"
        description= _ "Receives 70% defense on fortified cave hills"
        [effect]
            apply_to=defense
            replace=true

            [defense]
                village=-60
            [/defense]
        [/effect]
    [/trait]
[/modifications]
...

Doesn't even distract.. maybe I could even leave name to blank " ", idk.. to make it completely hidden. problem solved! Thanks Ravana:)

[enclave]

I just found [filter] doesn't filter traits? That's sad.. why?

[Ravana]

It does with [filter_wml].

[enclave]

filter_wml is known as slowest filter.. so i was trying to avoid it.. in such event as move_to.. so just changed my trait to ability, for me problem is solved. but it is still wrong that traits are not filtered the proper way. workaround don't change that. therefore the post was not in "questions", because i have no questions..

unless filter_wml filters traits fast, but variables slow, is that what you are trying to say?

[Ravana]

I guess you could make your trait also add dummy ability.

[enclave]

is dummy ability filtered.. I think i seen it somewhere.. maybe another part of legacy code from Dovolente ? I didn't really need trait in first place.. i only needed it to be able to filter some special unit.. I added ability in some strange way.. (used [store_unit] then I added array [set_variables] of my ability into stored.unit.abilities and then [unstore_unit])
in result my unit has the ability, which can be filtered, but it never shows visually, only with :inspect
well in first place i thought that adding trait with [effect] that changes status of unit to slowed would be slowing unit every turn, but it only affects once.. so had to do a turn refresh event instead..