System MoveSpeedX

[Renendaru]

Found a bug with the 'newest' release. The footman in the testmap will only use the speed boost if the pheonix moves, and the pathing map is messing up earlier on now.

 

[Frozenhelfir]

Newest release is working rather well in my map, and is meant for higher movespeeds like 20,000. It still snags heavily on long-move orders. I think I have a way to solve this , but i don't think its the best way.

 

[Jesus4Lyf]

Found a bug with the 'newest' release. The footman in the testmap will only use the speed boost if the pheonix moves, and the pathing map is messing up earlier on now.

The newest release is always the one on the front page, in the first post.

You're talking about the messed up random release I made for Frozenhelfir's experimentation and such, I assume.

Edit: Anyway, I checked it out, you can't use a period below 0.001. WC3 doesn't seem to recognise it for multiplication. Adjusted above post accordingly too.

On 0.001 I got up to around 3,000-4,000 ms before it bugged in a way that mattered.

Edit: Yeah. No point in the timer version. KT2 supports 0.00125 which is good enough. WC3 doesn't seem to detect below 0.001 correctly for math. I could make KT2 support that period, though.

 

[Troll-Brain]

Ok i was wrong but because you don't change the walk animation speed, the result is ugly imho.
And i know it would be hard to handle that because all unitid have their own values.

Also you should stop the movement when an unit receive an "immediate" order, or when the unit get stunned/paused. (when the unit is not already stuuned/paused the unit receive a widget target order 851973 , widget which did targeted the unit / the unit receive a point order 851973 , Location(0.,0.)

 

[Jesus4Lyf]

The timer callback terminates too quickly for that to be worthwhile in the case that the unit has not moved. Also, in the quest to perfect things like this, you usually end up screwing up certain cases accidentally (what if the unit uses windwalk, berserk, a potion, etc... although I'm not sure if they register as orders or not).

 

[Troll-Brain]

The timer callback terminates too quickly for that to be worthwhile in the case that the unit has not moved.

I don't really understand what you mean.

Also, in the quest to perfect things like this, you usually end up screwing up certain cases accidentally (what if the unit uses windwalk, berserk, a potion, etc... although I'm not sure if they register as orders or not).

You can detect and handle them i'm pretty sure, even if any order is detected the ability events (with an item or not) should be.

 

[Jesus4Lyf]

Sorry, I phrased that poorly. I simply meant that the timer callback consists of a few simple native calls for units which aren't moving. It is insignificant - not really worth detecting that the unit is casting or issued some other sort of immediate event.

And that "windwalk" is an immediate order, right? So that would mean you'd remove the move speed bonus...? If not, then I'd specifically have to exclude windwalk? What then, about custom user stuff? Etc. Silly thing to try to optimise, bound to break something in the process. And for no real gain.

 

[Troll-Brain]

That's why i said it would be too hard, it can be done, but you need to trigger these kind of abilities at least.
Personally the unit movement with the same animation makes me sad, so i won't use it, anyway i don't think i would ever need more than 512 movement speed.

 

[Jesus4Lyf]

It's 522, and it isn't that hard to change the animation speed manually to go with it. But units can look retarded if it goes too high, it just isn't the sort of thing I'd embed with this. Cosmetics should be done by the mapper, for the sake of flexibility.

 

[GetTriggerUnit-]

No, this is defenetly very useful.

 

[Troll-Brain]

But you don't give a way without editing your system, so for me it's not useful, but that's just me ok.
I just give my opinion and my attempts.

Also :

But units can look retarded if it goes too high

It's a no-no since you cant define a limit.

 

[BlackRose]

I set movespeed to 1200, and order a move order about 9000 range (across the other side of map)...... it bugged. It kept moving backwards and forwards.

 

[Jesus4Lyf]

Read documentation - as per doc, try period 0.00125.

Either way, that's a huge ms. Lol.

 

[Rainther]

Isn't it possible to change the animation speed of the caster during the effect?

 

[Larcenist]

Do that manually in whatever code might use this?

 

[Steel]

Here is some analysis ...tell me what you think (Instructional purposes)

You have 1 ability that modifies MS by 10%
You have 1 aura that modifies MS by 10%
You have 1 aura that modifies MS by 15%
You have 1 item that modifies MS by 50

Unit base movespeed is 100 (for simplicity's sake).

Option 1) If you add the ability you're at 110, then add the item you're at 160. Then the aura for another 10% yielding 176 MS.

Option 2) Different order...item first: You'd get 100+50, 150% then 10% of that for 165. Add the aura for another 10% we get 16.5+165 = 181.5

So how does WC3 actually handle these things? What is the order, is it by the introduction to the unit or does it do straight values first, then apply percentages?

In the options above...

Option 1) What if we remove the item? 176 MS - 50, 126 MS is our new value. How do the values now scale for the percentages? If you scale the 10% value by both the ability and the aura, you have 102.06 MS, which is wrong if it's not actively calculated during removal.

Option 2) Ok so you have 181.5, let's remove the item. 181.5-50 = 131.5, resulting in 10% off each time from there you get 106.515.

So now it is my contention that there is more than the generic Movespeed that we are given access to. There is a base movespeed, then something for straight values, then percentages. The percentages are constantly calculated based on items, abilities or auras and are always applied after the straight values. Again calculate these options.

Option 1) Base 100, ability 10%...110 MS, add the item. Base + Item is 150, then we apply the 10%, 165 MS now. Add in the aura now (The 15% one for this demo). Base+Item is 150. Apply the ability (it came first), 165ms apply the 15% now, 189.75 is our final value.

Let us now remove in the proper order and see how this works.

189.75, say the item is removed. So we now have to actively recalculate the percentages. We have Base only now 100, add in 10% ability, 110. Add in the 15% aura we have 126.5 which is correct!

We don't need to run the second option since it will result in the same method of application. I hope this provides some insight for those individuals confused about movespeed...

 

[Dr.Jack]

Approved!
Thanks for contributing.

 

[Jesus4Lyf]

Thanks, Jack.

 

[BRUTAL]

Woah, cool system.

 

[INCINERATE]

it took me 2 mins to get a critical error in the test map , if you let the phenix expire next to the bounds, something about it will keep running and leave the egg, when it runs off into map bounds wait 2 seconds then instant crash crital error