The Battle for Wesnoth Forums

I think the enter_hex approach might work, though I'm not sure of the exact point where move points are removed, but you could figure it out. It sounds pretty complicated, but I doubt it would have a major effect on gameplay – yes, it'll be triggering a lot, but as long as you make sure to keep the ...

If you want the unit to be able to move, attack, and move again, maybe it needs to be a skirmisher. But setting movement_used to 0 could also mean that the unit can start next to an enemy, attack them, and move away – even if it's not a skirmisher.

For the actual effect you want, it's probably ...

I said [object] because that's the most obvious way, but in fact both [trait] and [advancement] will also work just as well. In other words – wrap them in [advancement] for your testing (or even just drop the entire advancement tag, which would usually be defined by a macro, into the [modify_unit ...

That's expected. Applying an effect in [modify_unit] is a "temporary" change that will be reverted when the unit is rebuilt. And the unit will be rebuilt when the variation is changed. If you want the effects to persist, you need to wrap them in an [object].

Nearly all of what you want is probably possible without modifying the engine, except for points 1-3… which, I presume, are the most important points. Though as Ravana says you miiight be able to manage that with a bot, that would basically mean anyone can pop in and submit a command – though you ...

I'm not 100% sure if there's an official policy on this, so take my words with a grain of salt.

I think the policy is roughly "no output from an AI may be uploaded". This implies to me that (for example) asking the AI what's wrong with your code may be acceptable, as long as you wrote the actual ...

I think you can only disable revealing the map with an explicit defeat, not with default defeat conditions.

In short: assuming you want the player to be defeated when any leader dies, adding the following to your scenario should work:

[side]
side=1
defeat_condition=never # disable default ...

I'm not sure what you mean by "override/supersede" or what "[avoid] [ai]" is supposed to be (perhaps you meant "[ai] [avoid]"), but… the simple attack AI does not take [avoid] into account at all. It ignores most other aspects too, like aggression.

Looks correct to me, as long as corner_skeleton_quota has a value.

That's strange; it feels like it could actually be a bug.

Just checking, but… in that example, you've opened inspect immediately after starting the scenario? I just want to make sure there's no other code that might be intervening to add blocker=yes.

Seems like the key issue is that the recruiting animation requires a second unit, but the [animate_unit] tag offers no way to provide one that's not on the map? The Lua API underlying [animate_unit] could probably work by passing in a temporary unit, but the WML tag designates the unit by a filter ...

Although advances_to can indeed be placed inside [unit], it's one of those things that could be randomly overwritten when the unit is "rebuilt". I'd recommend instead using [effect]apply_to=remove_advancement and/or [effect]apply_to=new_advancement.

Why?

Can't you get the same effect just by adding that unit to advances_to? Why use an effect?

Yes, every unit has a standing animation, because one is synthesized if you don't explicitly define one. That's not the case for an idling animation.

Actually, I doubt it works for the idling animation either (unless the unit didn't have an idling animation to begin with).

As I mentioned previously, that only adds a new animation. It doesn't remove the old animation. And the way the animation system works is that it collects all the possible ...