WML questions: invalid wml

[picass_dilly]

Hi !

Thanks, that worked well.

Previous question:
Are there any consequences to having negative resistance values? So far it seems to me that it behaves as if 1 was the value for negative and 0 values. In other words, is there any reason to intentionally keep the value above 0?

Resistances are percentages, so negative values are meaningless and probably filtered and replaced to avoid errors (I don't checked Wesnoth code: just my two cents).

I'd assume a negative resistance value would mean an absorb effect. Like say a fire unit of some sort with resistance to fire of say -50 would actually be healed by fire attacks for half the damage they normally do. This type of thing definitely has a precedent in other fantasy games, but I've never actually tried it out to see. I guess based on what battlestar says, this isn't how they actually work. 0 is definitely allowable, though, as the fire dragon has it's resistance to fire set to 0 and that's one of the mainline units.
And now after a little bit of testing, it seems that while negative resistances are displayed (-50 resistance translates to 150 resistance in unit description, so they aren't just filtered out), they don't have any absorb effect. Also, units take at least 1 point of damage per hit, regardless of resistance (I believe that's what battlestar means by "it behaves as if 1 were the value for 0 and negative values"). I'd imagine that's just coded into the game because the developers didn't want any attacks to do 0 damage (although, they do allow damage=0 within the [attack] tag and then it does no damage).
Out of curiosity, battlestar, are you interested in negative resistances because you want to create a unit that has an absorb effect? Because if so, I'd imagine that wouldn't be too terribly difficult to code with a dummy ability and attacker_hits and defender_hits [event]'s.

[battlestar]

1. Regarding negative resistance values:

Resistances are percentages, so negative values are meaningless and probably filtered and replaced to avoid errors (I don't checked Wesnoth code: just my two cents).

If this is the case, then it would save a lot of work for Ceres who's working on spells for our project. On the flip side, if there are unforeseen issues or if there are foreseeable changes to how this works, we'll need some extra lines in the codes to ensure resistance values doesn't go negative.

Out of curiosity, battlestar, are you interested in negative resistances because you want to create a unit that has an absorb effect?

I like the way resistance works as I currently see it. It offers maximum flexibility as an absorptive skill would be easy to code for. My original concern arose from multiple sets of WML (spells, upgrade, and items) modifying resistance values of the same unit, where the original stats of the unit needs to be restored after spells wear out and items are taken off.

2. Thanks pyro, I did utilize [object] though I was still curious about whether [modify_unit] could've done the same thing.

3. Crend solved this problem for me. All I needed was the automatic variables to do this:

Spoiler:

Code: Select all

#define SCC_UPG_ASSASSIN
[event]
	name=attacker hits
	first_time_only=no
	[filter]
		side=1
		[filter_wml]
			[status]
				isHero=yes
			[/status]
		[/filter_wml]
	[/filter]
	[filter_second]
	[/filter_second]
	[set_variable]
		name=upg_assassin_chance
		value=$unit.variables.upg_assassination
	[/set_variable]
	[set_variable]
		name=upg_assassin_chance
		multiply=3
	[/set_variable]
	[set_variable]
		name=upg_assassin_rand
		rand=1..100
	[/set_variable]
	[if]
		[variable]
			name=upg_assassin_chance
			greater_than=$upg_assassin_rand
		[/variable]
		[then]
			[harm_unit]
				[filter]
					id=$second_unit.id
				[/filter]
				amount=$weapon.damage 
				alignment=$unit.alignment
				damage_type=$weapon.type
				fire_event=yes
				animate=no
			[/harm_unit]
			[floating_text]
				x,y=$x1,$y1
				text="<span color='#BF0000'>" + _ "Critical Strike" + "</span>"
			[/floating_text]
		[/then]
	[/if]
	{CLEAR_VARIABLE upg_assassin_chance}
	{CLEAR_VARIABLE upg_assassin_rand}
[/event]
#enddef

It's a part of our upgrading system, which deals double damage on chances determined by the upgrade.

[Elvish_Hunter]

1. Regarding negative resistance values:
pyrophorus wrote:
Resistances are percentages, so negative values are meaningless and probably filtered and replaced to avoid errors (I don't checked Wesnoth code: just my two cents).

If this is the case, then it would save a lot of work for Ceres who's working on spells for our project. On the flip side, if there are unforeseen issues or if there are foreseeable changes to how this works, we'll need some extra lines in the codes to ensure resistance values doesn't go negative.

I just tested on a custom unit, by adding the following code:

Code: Select all

[resistance]
    arcane=-50
[/resistance]

In game, this is displayed as a +150% resistance towards arcane attack, that for gameplay purposes is perfectly equivalent to a 100% resistance (immune to said damage type, only 1 HP lost on hit). If you want to have absorb effects, instead of negative resistances you may want to look to the new [heal_on_hit] special, although it is only available on 1.11.

2. Thanks pyro, I did utilize [object] though I was still curious about whether [modify_unit] could've done the same thing.

If I remember correctly, [modify_unit] can handle objects, by calling the wesnoth.add_modification Lua function:

Code: Select all

[modify_unit]
    [filter]
        # blah
    [/filter]
    [modifications]
        [object]
            # blah again
        [/object]
    [/modifications]
[/modify_unit]

However, it's evident that an [object] tag is simpler to use, unless you need to do multiple modifications.
I also fixed the malformed [ quote ] tags in your post.

[8680]

I’ve made you a [modify_unit_attacks] tag; it may or may not be easier to use or provide more functionality than [object].

Usage example:

Code: Select all

[modify_unit_attacks]
    [filter]
        ## StandardUnitFilter
        id="Konrad"
        type="Fighter"
    [/filter]
    [filter_attack]
        ## Attack filter. This tag may be omitted; if it is, all attacks match.
        range=melee
        type=blade
    [/filter_attack]
    ## [attack] keys. Question marks in the values of these will be replaced
    ## with the original value. Keys that expect numeric values may be given
    ## Lua expressions (which should be quoted).
    description="thrown ?"
    range=ranged
    damage="?-1"
    number="math.floor(?/2)"
    ## In this example, Konrad would end up with a 5-1 thrown sword.
[/modify_unit_attacks]

[battlestar]

1. Thanks elvish. I hope there isn't going to be changes to how it works now.

On the other hand, if the defense value is negative, then the unit will be hit as though the value were positive (from wiki). So this means (and following are tested), if defense are 40 and -40, the chances to evade are both 60%. If defense are 160 and -160, the chances to evade are both -60%.

I think it would make more sense for defense and resistance to deal with negative values similarly, in which I think the way that resistance works is more logical and allows more flexibility. What are your thoughts?

2. Thanks Elvish.

@ 8680: That's a very cool lua segment, and it could be very useful to our project. I'll try it out, thanks!

[picass_dilly]

On the other hand, if the defense value is negative, then the unit will be hit as though the value were positive (from wiki). So this means (and following are tested), if defense are 40 and -40, the chances to evade are both 60%. If defense are 160 and -160, the chances to evade are both -60%.

I think it would make more sense for defense and resistance to deal with negative values similarly, in which I think the way that resistance works is more logical and allows more flexibility. What are your thoughts?

As explained in the unitsWML ( http://wiki.wesnoth.org/UnitsWML#.5Bmovetype.5D ), negative defense values don't work quite exactly the same as positive. A negative value means that defense will apply on a mixed terrain (like say forest /hill) even if it's not the higher of the two. One use of this is with the feral trait which sets village defense to -50 so even in a hill village, that unit's defense is still 50 (normally, it would be overridden by the better defense of the hill terrain, giving the unit a 60% chance to evade). It might not be entirely logical, (although I do see a type of logic to it), but it does allow for flexibility.
I think what you need to do is make sure any effects that lower defense (by which I mean the chance to hit, as it's coded, as opposed to chance to evade, as it's displayed) don't drop it below 0. From the sound of things you'll want to create a macro to do this since you'll have a lot of items and spells that alter defense. I'm not sure exactly how you're altering defense, but I'd imagine something that uses [filter_base_value] to make sure it's greater than or equal to 0, and then adjusts it to 0 if it isn't would do the trick if it was placed after the modification.

[battlestar]

I'll have to try [filter_base_value] when I have a chance, thanks.

[battlestar]

Is there an WML that makes a unit attacks an enemy unit for real, not using animationWML?

Thanks.

[iceiceice]

Does [harm_unit] meet your needs?

[battlestar]

Hmm maybe, I'll have to test it out... but does it go through the hit chance calculations?

[battlestar]

I'm rewriting a piece of code, and something is strange here. It's a weapon special that is supposed to petrify a unit for one turn. It works fine when one unit is petrified at a time. But when multiple units are being petrified, things become weird. I am guessing it's because sometimes it go through {FOREACH cemented i} section and sometimes it doesn't. cemented[$i].variables.cemented is always supposed to be 0 at the next turn, both in the cemented array and within the unit, but sometimes it shows up as 1 in both places. Maybe it has to do with appending in store_unit...

Code: Select all

    [petrifies]
        id=cement
        name= _ "cement"
        description= _ "Cement:
This attack covers the target in cement, rendering it unable to act until it breaks free until the next turn."
    [/petrifies]
	[/specials]
	[/attack]
	[event]
		id="WEAPON_SPECIAL_CEMENT-attacker_hits"
		name=attacker_hits
		first_time_only=no
		[filter_attack]
			special="cement"
		[/filter_attack]
		{STORE_UNIT_VAR x,y=$x2,$y2 side cemented_side}
		{MODIFY_UNIT x,y=$x2,$y2 variables.cemented 1}
		{VARIABLE varname "side_$cemented_side|_units_cemented"}
		{VARIABLE $varname yes}
		{CLEAR_VARIABLE varname}
	[/event]
	[event]
		id="WEAPON_SPECIAL_CEMENT-defender_hits"
		name=defender_hits
		first_time_only=no
		[filter_second_attack]
			special="cement"
		[/filter_second_attack]
		{STORE_UNIT_VAR x,y=$x1,$y1 side cemented_side}
		{MODIFY_UNIT x,y=$x1,$y1 variables.cemented 1}
		{VARIABLE varname "side_$cemented_side|_units_cemented"}
		{VARIABLE $varname yes}
		{CLEAR_VARIABLE varname}
    [/event]
	[event]
		name=side turn
        first_time_only=no
		{VARIABLE this_side_cemented "$side_$side_number|_units_cemented"}
		{IF_VAR this_side_cemented equals yes (
            [then]
				[store_unit]
                    [filter]
                        side=$side_number
						[filter_wml]
							[variables]
								cemented=1
							[/variables]
						[/filter_wml]
                    [/filter]
                    variable=cemented
					mode=append
                    kill=no
                [/store_unit]
				{FOREACH cemented i}
					{IF_VAR cemented[$i].variables.cemented equals 0 (
						[then]
							{CLEAR_VARIABLE cemented[$i].variables.cemented}
							{MODIFY_UNIT id=$cemented[$i].id status.petrified no}
							{CLEAR_VARIABLE cemented[$i]}
						[/then]
						[else]
							{VARIABLE cemented[$i].variables.cemented 0}
							[unstore_unit]
								variable=cemented[$i]
								find_vacant=no
							[/unstore_unit]
						[/else]
					)}
                {NEXT i}
			[/then]
        )}
	[/event]

[trewe]

[...]
{IF_VAR cemented[$i].variables.cemented equals 0 (
[then]
{CLEAR_VARIABLE cemented[$i].variables.cemented}
{MODIFY_UNIT id=$cemented[$i].id status.petrified no}
{CLEAR_VARIABLE cemented[$i]}
[/then]
[else]
[...]
[/code]

In the loop you are are clearing one of its containers, causing to skip units.

Add an {VARIABLE_OP i sub 1} after you delete the variable.

[battlestar]

Ow, yeah, that's exactly right

[battlestar]

is there a way to have a event fire when unit moves from a location (and event happens before the unit moves away)?

[Dugi]

There is a new type of event in 1.11 named exit_hex, that fires when a unit leaves a specified hex.