My dummy just won't fly

[Luorax]

SOLVED

So, I'm working on a spell for the 6th hero contest and I just experienced something that I don't seem to be able to solve. I have this code:

            loop
                set thistype.dummy[baseId+i]=CreateUnit(this.owner,DUMMY_UNIT,x,y,0.)
                set thistype.sfx[baseId+i]=AddSpecialEffectTarget(ORB_MODEL,thistype.dummy[baseId+i],"origin")
                call SetUnitScale(thistype.dummy[baseId+i],SFX_SCALE,SFX_SCALE,SFX_SCALE)
                call SetUnitAnimationByIndex(thistype.dummy[baseId+i],75)
                call UnitAddAbility(thistype.dummy[baseId+i],'Amrf')
                call UnitRemoveAbility(thistype.dummy[baseId+i],'Amrf')
                call SetUnitFlyHeight(thistype.dummy[baseId+i],BASE_HEIGHT,0.) //BASE_HEIGHT is a constant and is equal to 400.
                set x=x+OFFSET*cos 
                set y=y+OFFSET*sin
                set i=i-1
                exitwhen i==0
            endloop

That's supposed to make my dummy units fly. But they just won't. They're spawned directly on the ground, and two seconds later, when they should reach the ground, they just die.

Any ideas what I'm doing wrong? Any help is appreciated.

 

[defskull]

1. Do NOT set your dummy movement speed to 0.
2. Set your dummy movement type to Fly.

 

[Luorax]

Yea, you're right, (1) helped. Thanks, I didn't know about that.

 

[defskull]

Side Notes: Setting dummy's movement speed to >0 (or any unit) will make it unable to cast spells simultaneously even if you set the Art - Animation - Cast Backswing/Point: 0

Also, a dummy movement speed of 0 won't move the dummy unit (by visual) with the use of SetUnitX/Y.
The unit in fact, is being moved but you can't see the "model" of the unit is moving (visual issues).

 

[WaterKnight]

So what did they die from?

 

[defskull]

So what did they die from?

That was the part of the spell.
The real problem was that the dummy won't fly because the unit's movement speed is set to 0.

 

[WaterKnight]

This flying height-setting trick only works if the target unit type of the ability is a flyer. Of course, you do not need it at all if the unit you want to elevate is a flyer itself, which might be the case for most dummy units. Why make them walk?

 

[Troll-Brain]

Wait, are you saying that this trick doesn't work for let's say the footman, as an example, since this unit type is not a flyer ?!
I'm quite sure it does work, at least from what i remember.

And anyway, even if it works only on a flyer unit, i suppose it's still useful to got rid of the max height value (sure it can be increased as necessary in the object editor)

Now, about dummies units there are many cases where you need to set the position by trigger actions, especially if the dummy is used as a visual effect.

 

[Luorax]

It does work with non-flyers; if it didn't, my knockup library, that I'm using in IID, wouldn't work either.

It was the movement speed that caused my problem, and as I said, changing it to 522 solved the problem.

 

[WaterKnight]

No, I said that the morph ability Amrf/Arav has a source and a target type. Last one is set to Medivh's crow form/talon crow form on default. If you set these unit types to ground walking, then the trick would not work.

Also, I cannot confirm that SetUnitFlyHeight would be capped by the Movement - Height (umvh) value in object editor.

 

[Troll-Brain]

No, I said that the morph ability Amrf/Arav has a source and a target type. Last one is set to Medivh's crow form/talon crow form on default. If you set these unit types to ground walking, then the trick would not work.

I've never read you need to edit something for this ability.
The bug exploit should work for all units without any more stuff, or we should know it since a while.

Also, I cannot confirm that SetUnitFlyHeight would be capped by the Movement - Height (umvh) value in object editor.

It is IIRC, without the bug exploit ofc (but need to be tested again ...)

 

[WaterKnight]

I've never read you need to edit something for this ability.

You do not have to. The default values are okay. But if Luorax edited the ability/unit type, that might have been a possible source of error.

Since I have custom slk object data and do not use public functions/systems, I could identify some of the basic stuff how wc3 works.

 

[Luorax]

You do not have to. The default values are okay. But if Luorax edited the ability/unit type, that might have been a possible source of error.

I always use custom object editor data, and avoid editing built-in stuff.

 

[WaterKnight]

I used to nullify every value that I do not use/does not matter. A problem arising from that is that the map file stores all modifications of object editor fields, so the more fields are modified, the laggier is the initialization of this object. Of course, when copying an object, it only stores the original object's id and does not consider everything modified. So it probably does not make much of a difference whether you use standard or own objects.

 

[Luorax]

Yes, that's true, but it makes a whole lot easier to find something or see through the object editor structure, if everything is categorized properly.

 

[WaterKnight]

Positive. It's very meddlesome when people here in these forums ask for help, upload their map and everything is unorganized.

 

[Luorax]

Takes 2 seconds to put a spell/unit/whatever into a different category, saves you hours of searching in total It's totally worth it. It also makes it look better when you look at it, and won't burn your eyes out of your head.