Adding moves to a unit after it has attacked

[Celtic_Minstrel]

Parts of the code I don't understand, so this is probably a ridiculous question. Do you think maybe an if/then tag could examine the variable unit.movement_used to see if the unit moved? The difficulty seems to be learning whether or not the unit moved, not modifying the movement.

+ + +

Okay, I added an if/then tag to test the unit.movement_used variable. It did not work. But I make simple mistakes, so maybe I left off a $ or a filter. Incorrect code attached.

There's no such variable — movement_used is an attribute of an attack, not a unit. It means that when you use that attack, your movement points are reduced by the specified amount, instead of being set to 0. A unit could have two attacks that consume different amounts of MP.

[Helmet]

Oh. No wonder it didn't work. Thanks for the info.

I didn't expect that this problem would be so difficult. In my mind (which evidently runs on BASIC), the code is easy and looks something like this, only in WML:

Code: Select all

100 IF MovementUsed > 0 THEN GOTO 300 ELSE GOTO 200
200 REM Bonus Move
210 Moves=1
220 GOTO 300
230 REM note to self, make arrays start at 1
300 BEEP

[Celtic_Minstrel]

There is a variable that determines whether the unit has moved, since the game needs to track this for rest healing. Since that's what it's used for, the variable is called unit.resting in Lua. Chances are it's named the same in a WML stored unit, but I'm not certain of that.

[Pilauli]

I forgot about that! Yeah, that sounds helpful.

The field resting= ("yes" or "no") is stored in my sample save file, so it should be accessible under that name. Specifically, you should be able to write $unit.resting|, but a resting= field doesn't seem to be part of the standard unit filter, so you couldn't write things like

Code: Select all

[filter]
    side=1
    resting=yes
[/filter]

One might need to store whether the frog is resting before it attacks in a variable, and then give it another move after the event is over? That would probably involve an "attack" and an "attack_end" event.

Does attacking invalidate the resting status before or after it fires the attack event? The easiest way I can think of to check that would be to write a short event like this:

Code: Select all

[event]
    name=attack
    first_time_only=no
    [message]
        speaker=unit
        message= _ "Resting = $unit.resting|"
    [/message]
[/event]

I haven't yet tested this myself, so I expect the event to run just fine (without errors), but I obviously can't be sure, and I definitely don't know what the results will be.

[Helmet]

Thanks for telling us about unit.resting, Celtic_Minstrel, and thanks for the debugging code, Pilauli.

I tested your code. The message did not appear after a unit had moved and stopped. The message appeared the moment before a unit attacked (whether it had moved or didn't move). The message said, "resting = no."

I'm not sure how his information can be useful, though.

I made the following code to test what happens when a unit stops on hex 5,5.

Code: Select all

	[event]
    	name=moveto
    	first_time_only=no    			
    		[filter]
    			x,y=5,5
    		[/filter]
    		[message]
       			speaker=unit
        		message= _ "Resting = $unit.resting|"
    		[/message]
	[/event]

After a unit stopped on hex 5,5, the message read, "resting = yes." This surprised me. I expected the unit to get a "resting=no" after moving.

I suspect there exists another cryptic variable unknown to me, one which contains a yes or no depending on whether or not a unit has moved.

[Ravana]

You can add unit variable into each relevant unit which would be updated during moveto and turn refresh event.

[Celtic_Minstrel]

I forgot about that! Yeah, that sounds helpful.

The field resting= ("yes" or "no") is stored in my sample save file, so it should be accessible under that name. Specifically, you should be able to write $unit.resting|, but a resting= field doesn't seem to be part of the standard unit filter, so you couldn't write things like

Code: Select all

[filter]
    side=1
    resting=yes
[/filter]

You can do it:

Code: Select all

[filter]
    side=1
    [filter_wml]
    	resting=yes
    [/filter_wml]
[/filter]

After a unit stopped on hex 5,5, the message read, "resting = yes." This surprised me. I expected the unit to get a "resting=no" after moving.

I suspect there exists another cryptic variable unknown to me, one which contains a yes or no depending on whether or not a unit has moved.

Huh, this sounds like it could maybe be a bug. Perhaps the resting variable is set after the moveto event is fired… which would mean it's correct if you read it from anywhere else but not if you read it from moveto.

Note: resting is also false if the unit has attacked, so maybe it's not even what you need, unfortunately.

[Helmet]

I'm using the not-officially-stable-but-probably-mostly-stable version 1.15.5 of Battle for Wesnoth, so maybe it's a bug. But, like you said, maybe the variable isn't set until after the moveto event is fired.

Or...maybe the BATTLEHOP ability is impossible. Like making a unit literally move off the map, as if the unit was moving to, for example, hex 0,0 (I'm assuming this is impossible; if it's not, let me know).

[Pilauli]

It shouldn't be completely impossible! For one thing, there's Ravana's suggestion to add a custom variable to each frog unit that works sort of like resting should, but is customized for your uses:

You can add unit variable into each relevant unit which would be updated during moveto and turn refresh event.

It would require writing several events and stuff like that, so it would probably be quite fiddly, but you could almost certainly do it that way.

[Helmet]

Oh no. It's starting to sound like I need to concoct mind-boggling code that may or may not work.

Actually...that pretty much describes all my efforts at coding WML.