Add level to unit

[allanate]

Ive been wondering this for a while now and if it is possible it would make my scenario 1000000x more interesting. Is it possible to add a level to a unit that advances.? i see that you have the option to manualy add a level or more to a unit using the debug command but i actually want to make a event that increases the level of a unit.


EX:
mage steps on this tile, mage is now level 2

[Ravana]

Do you mean level up to custom unit, increase unit.level or level unit to existing unit/amla?
1. part of your post shows that only number needs to change, but I think debug command changes unit type as well.

Why not use {ADVANCE_UNIT}? For most likely thing you requested that works.

[allanate]

Do you mean level up to custom unit, increase unit.level or level unit to existing unit/amla?
1. part of your post shows that only number needs to change, but I think debug command changes unit type as well.

Why not use {ADVANCE_UNIT}? For most likely thing you requested that works.

something like this

apply to= unit level
add=1

without it advancing

[Ravana]

Code: Select all

[store_unit]
[filter]
#yours
[/filter]
variable=to_adv
[/store_unit]
{FOREACH to_adv i}
{VARIABLE_OP to_adv[$i].level add 1}
{NEXT i}
[unstore_unit]
find_vacant=no
variable=to_adv
[/unstore_unit]
{CLEAR_VARIABLE to_adv}

Written in forum so untested and without indentation.

[allanate]

Code: Select all

[store_unit]
[filter]
#yours
[/filter]
variable=to_adv
[/store_unit]
{FOREACH to_adv i}
{VARIABLE_OP to_adv[$i].level add 1}
{NEXT i}
[unstore_unit]
find_vacant=no
variable=to_adv
[/unstore_unit]
{CLEAR_VARIABLE to_adv}

Written in forum so untested and without indentation.

Wow it worked thanx a lot.! and also thanks on your timely response.

[trewe]

The store- /unstore mechanism is obsolete, use modify_unit instead.

Code: Select all

  [modify_unit]
    [filter]
      id=$unit.id # whatever
    [/filter]
    level="$($this_unit.level+1)"
  [/modify_unit]

[Ravana]

The store- /unstore mechanism is obsolete, use modify_unit instead.

Code: Select all

  [modify_unit]
    [filter]
      id=$unit.id # whatever
    [/filter]
    level="$($this_unit.level+1)"
  [/modify_unit]

http://wiki.wesnoth.org/InternalActions ... re_unit.5D does not say that this is obsolete.
I avoid [modify_unit] because http://wiki.wesnoth.org/DirectActionsWM ... fy_unit.5D

note: The syntax allowed is somehow vague. Just try things and possibly correct/add/modify this documentation. (a forum thread discusses some related issues).

With variables I can clearly see what happens.

[trewe]

From my experience unstore_unit is not very multiplayer friendly (especially there). Although modify_unit internally just fires store/unstore too, it usually gives fewer problems. And it is faster.

For the syntax, it allows every attribute as [unit], except variation, without problems. type= should be avoided though since it can leave to unwanted results (use transform_unit to change an unit type).

[Anonymissimus]

The store- /unstore mechanism is obsolete, use modify_unit instead.

Why do you think this ? Sorry, it's nonsense.

I avoid [modify_unit] because http://wiki.wesnoth.org/DirectActionsWM ... fy_unit.5D

note: The syntax allowed is somehow vague. Just try things and possibly correct/add/modify this documentation. (a forum thread discusses some related issues).

Due to the way it is implemented I couldn't give a better description. The allowed syntax depends on a huge number of allowed or disallowed syntaxes of the C++ engine.

And it is faster.

I doubt that.
All it is is sort of a wrapper and syntactic sugar or syntax simplifying interface to functionalities which exist anyway. I think it was added in order to create a challenging test case for our lua interface. In case there are automatically stored variables ($unit etc) it's better to use direct variable modification.

[A Guy]

I doubt that.
All it is is sort of a wrapper and syntactic sugar or syntax simplifying interface to functionalities which exist anyway. I think it was added in order to create a challenging test case for our lua interface. In case there are automatically stored variables ($unit etc) it's better to use direct variable modification.

When I tried to use store and unstore_unit swap the position of two units at the start of combat to replace one with the other, the combat ended. modify_unit works for me.

[Iris]

When I tried to use store and unstore_unit swap the position of two units at the start of combat to replace one with the other, the combat ended. modify_unit works for me.

You probably did something wrong. [modify_unit] is implemented using [store_unit], [kill], and [unstore_unit] internally.

[A Guy]

When I tried to use store and unstore_unit swap the position of two units at the start of combat to replace one with the other, the combat ended. modify_unit works for me.

You probably did something wrong. [modify_unit] is implemented using [store_unit], [kill], and [unstore_unit] internally.

I tried storing both units and unstoring them on top of each other. They swapped places, but the combat ended before anyone attacked.

[Ravana]

I tried storing both units and unstoring them on top of each other. They swapped places, but the combat ended before anyone attacked.

Sounds like you didnt have find_vacant=no for [unstore_unit].
That is assuming you left units alive when storing them.Didnt notice you said start of combat before.

However topic seems to have changed from unit levels to [store_unit] vs [modify_unit] , you might want to create new thread for that.

[trewe]

The store- /unstore mechanism is obsolete, use modify_unit instead.

Why do you think this ? Sorry, it's nonsense.

With obsolete I mean the archaic store - set variable - unstore, when all what one wants to do is some ad-hoc changes to an unit. Obviously, unstore does not dissapear completly, Like

In case there are automatically stored variables ($unit etc) it's better to use direct variable modification.

when one of the above functions is not required. One has to deliberately choose which serves the purpose better.

All it is is sort of a wrapper and syntactic sugar or syntax simplifying interface to functionalities which exist anyway. I think it was added in order to create a challenging test case for our lua interface.

Well, the results are not exactly the same. As it is now it mostly only simplifies the syntax (with some side effects).

I tried storing both units and unstoring them on top of each other. They swapped places, but the combat ended before anyone attacked.

That is expected. How exactly does modify_unit help there?

[A Guy]

I tried storing both units and unstoring them on top of each other. They swapped places, but the combat ended before anyone attacked.

That is expected. How exactly does modify_unit help there?

modify_unit let me change both units to a copy of the other without interrupting combat.