Lua location syntax

[white_haired_uncle]

The documentation is here for the record.

Hmm. I think we can tell that the wiki is wrong and it should be "target", not "facing" from src/scripting/game_lua_kernel.cpp. And it appears target= needs a location, but I can't find a solid definition of location.

It should accept "facing" which is a direction, eg 'nw'. Thus this seems like it might be a bug. It's fine for it to accept "target" as an alternative though, taking a location. From the sounds of it, only the latter is currently supported?

Here it appear the interpreter parses the arguments to animator:add(), and we see them parsed in the same order they are listed in the wiki, except the first one is not facing, but target. I don't see anything that would accept facing.

https://github.com/wesnoth/wesnoth/blob ... l.cpp#L268

A location is either a two-element array, eg {3, 5}, or anything that contains x and y tags, eg {x = 3, y = 5}. It does not require terrain, and usually does not have that. There's no need to use wesnoth.map.get or wesnoth.map.find to get a hex reference.

That's what I thought, but according to OP passing {x = 3, y = 5} doesn't work, but the interesting method of get/find/etc does. I suspect it may actually work because he sets unit.facing (which is attacker.facing as well I believe). My theory is that it's setting the unit facing=direction that's actually making the animation look right, while target=location is either being ignored or not provided correctly when it doesn't work.

[Celtic_Minstrel]

If you look-up for the code I've posted, you discover, you aren't right (that code is from animate_unit implementation).
(Or it just doesn't work in animator)

That was a general statement on what constitutes a location in Wesnoth.

Here it appear the interpreter parses the arguments to animator:add(), and we see them parsed in the same order they are listed in the wiki, except the first one is not facing, but target. I don't see anything that would accept facing.

https://github.com/wesnoth/wesnoth/blob ... l.cpp#L268

Yes, I saw that. I'm saying that it should accept facing, not that it does.

That's what I thought, but according to OP passing {x = 3, y = 5} doesn't work, but the interesting method of get/find/etc does. I suspect it may actually work because he sets unit.facing (which is attacker.facing as well I believe). My theory is that it's setting the unit facing=direction that's actually making the animation look right, while target=location is either being ignored or not provided correctly when it doesn't work.

He said that get/find doesn't work. The only thing that worked was setting the facing direction manually on the unit before animating. However, that same code also passes the facing direction as the target, which doesn't seem like it could work.

[ZombieKnight]

He said that get/find doesn't work. The only thing that worked was setting the facing direction manually on the unit before animating. However, that same code also passes the facing direction as the target, which doesn't seem like it could work.

True, it doesn't work without manually setting facing, it's weird that core code passes the parameter then.

[white_haired_uncle]

He said that get/find doesn't work. The only thing that worked was setting the facing direction manually on the unit before animating. However, that same code also passes the facing direction as the target, which doesn't seem like it could work.

True, it doesn't work without manually setting facing, it's weird that core code passes the parameter then.

What happens if you set facing to the wrong direction, and then pass target={x=X, y=Y} (with target set to the correct location)?

[ZombieKnight]

What happens if you set facing to the wrong direction, and then pass target={x=X, y=Y} (with target set to the correct location)?

Haven't tryied, but when I comment out the line where I set unit's facing (line facing='ne' for example)
Units facing doesn't change.

[white_haired_uncle]

The documentation is here for the record.

Hmm. I think we can tell that the wiki is wrong and it should be "target", not "facing" from src/scripting/game_lua_kernel.cpp. And it appears target= needs a location, but I can't find a solid definition of location.

It should accept "facing" which is a direction, eg 'nw'. Thus this seems like it might be a bug. It's fine for it to accept "target" as an alternative though, taking a location. From the sounds of it, only the latter is currently supported?

I looked into this a bit, and I got to here before I got in over my head.

https://github.com/wesnoth/wesnoth/blob ... #L377-L434

It looks to me like the location provided by target (and I suspect indirectly provided by facing if it were implemented) is never getting used. It appears the second_location is only used when there is a [filter_second] in the animation.

It looks like in an actual attack, unit.facing is set just before the animation is called (which seems right, since the attacker and defender end up facing each other afterwards):

https://github.com/wesnoth/wesnoth/blob ... #L631-L633

It seems to me like the easy "fix" here would just be to have create_animator set unit.facing, at least for flag=attack, when provided with target/facing at least. However, that's probably a one-off solution for one end case, and I'm not even sure about the side effects of that one case (for example, should facing be set back after the animation? my gut says no, because that's not done for a "real" attack?).

I suppose what I should do is raise this as an issue and add a comment as such to the wiki.

[ZombieKnight]

I see...
Thats weird...
Unfortunately I haven't done any further research and so I can't really help you now.
But issue and wiki edit would be welcomed ^^.

[white_haired_uncle]

https://github.com/wesnoth/wesnoth/issues/9032