[JASS] Adding move ability through jass

[vlekje5]

So for a feature i'm trying to implement i needed to temporarily remove the 'move' function and then add it back later. So i tested both of these in the same trigger. both seperately and in a small test trigger.

The first, unitRemoveAbility correctly removes the move button. However, UnitAddAbility does not add the ability to move back.

• Custom script: call UnitRemoveAbility( udg_TempUnit, 'Amov')

• Custom script: call UnitAddAbility( udg_TempUnit, 'Amov')

Heres my test setup

• Movetest copy
  • Events
    • Unit - A unit Begins casting an ability
  • Conditions
    • (Ability being cast) Equal to test (Neutral Hostile)
  • Actions
    • Set VariableSet TempUnit = (Casting unit)
    • Custom script: call UnitRemoveAbility( udg_TempUnit, 'Amov')
    • Trigger - Turn on Movetest <gen>
    • Trigger - Turn off (This trigger)

This one worked

• Movetest
  • Events
    • Unit - A unit Begins casting an ability
  • Conditions
    • (Ability being cast) Equal to rotate (Neutral Hostile)
  • Actions
    • Set VariableSet TempUnit = (Casting unit)
    • Custom script: call UnitAddAbility( udg_TempUnit, 'Amov')
    • Trigger - Turn on Movetest copy <gen>
    • Trigger - Turn off (This trigger)

Adding the move ability back did nothing though!

Am i missing something in the syntax of UnitAddAbility? I found no documentation about it however i assumed that the same type of syntax would work for it as did for the unitRemoveAbility.

 

[MyPad]

Do not remove a unit's move ability! The native UnitAddAbility will not accept certain ability IDs, such as the move ability, attack ability, and so on. The syntax is otherwise fine.

If suppressing the move ability is your goal, it can be achieved through either of the following options:

• Disabling the ability itself via calling BlzUnitDisableAbility(unit, abilId, bool disable, bool hide), since GUI does not allow you to select the move ability. (Available from 1.29+)
• Setting a unit's prop window to 0 via native SetUnitPropWindow(unit, real newPropWindowAngle) (doing so in GUI will actually keep it at 0.1 instead).

 

[vlekje5]

No, The main goal i had was adding move to a unit.

Basically i want my buildings to rotate using triggers similar to how it's done in some other mods, however i would like to keep them a building in the end (so no buildings classified as units).

So my plan was to change the unit classification to 'not a building' through triggers and then turn it around. However i noticed that without the move ability units can't be turned like that. That's why i wanted to: 1. make building a unit. 2. Add movement ability 3. Turn the unit 90°. 4. Remove the move ability 5. Make unit a building again.

Do not remove a unit's move ability! The native UnitAddAbility will not accept certain ability IDs, such as the move ability, attack ability, and so on. The syntax is otherwise fine.

If suppressing the move ability is your goal, it can be achieved through either of the following options:

• Disabling the ability itself via calling BlzUnitDisableAbility(unit, abilId, bool disable, bool hide), since GUI does not allow you to select the move ability. (Available from 1.29+)
• Setting a unit's prop window to 0 via native SetUnitPropWindow(unit, real newPropWindowAngle) (doing so in GUI will actually keep it at 0.1 instead).

 

[MyPad]

In that case, tinkering with the Uproot ability might be useful. The building must be able to move in the first place, but the custom uproot ability it would have must be hidden (and disabled if necessary for unexpected behavior). That way, the uproot ability will lead to the move ability being initially disabled for the structure, only being re-enabled when the structure has "uprooted" itself (via trigger/code)

On how to hide an ability, you can set the x and y icon values for said ability to 0 and -11 respectively, or mask it under a disabled spell book containing the same.

So, with the uproot ability:
1. Issue uproot order to structure
2. Tell it to rotate 90° and wait
3. ???
4. Profit (root back in place)

 

[vlekje5]

In that case, tinkering with the Uproot ability might be useful. The building must be able to move in the first place, but the custom uproot ability it would have must be hidden (and disabled if necessary for unexpected behavior). That way, the uproot ability will lead to the move ability being initially disabled for the structure, only being re-enabled when the structure has "uprooted" itself (via trigger/code)

On how to hide an ability, you can set the x and y icon values for said ability to 0 and -11 respectively, or mask it under a disabled spell book containing the same.

So, with the uproot ability:
1. Issue uproot order to structure
2. Tell it to rotate 90° and wait
3. ???
4. Profit (root back in place)

Ah, so you're talking about giving it uproot in the object editor, then hiding it and activating it using triggers.
Do you root it back down after giving the order though? How does that work? I would assume that it would just snap back into default rotation if you root it back down no?

 

[MyPad]

Yes. Uproot, rotate, and root back again.

 

[Uncle]

Have you tried this function:

• Custom script: call BlzSetUnitFacingEx(udg_Unit, udg_Angle)

It rotates instantly without the need to turn. Not sure if it will work here.