[GUI] Simple Frictional Knockback System v1.11

[defskull]

Reserved.

[Almia]

I dont get it
Why there are two triggers but only have one action?

[.OmG.]

Screenshot is ugly... Convert to JPG format and not PNG

[Tank-Commander]

Notes

Set FK_KB_FrictionPerInterval = (FK_KnockbackFriction x FK_IntervalPerMove)
Set FK_KB_FrictionPerInterval = (FK_KB_FrictionPerInterval x FK_IntervalPerMove)

Put it into one line, no point doing it twice.

Unit - Order FK_KnockbackUnit to Stop

Why?

FK Key

Events
Conditions
Actions

Custom script: set udg_FK_Key = GetHandleId(udg_FK_KnockbackUnit)

Is this necessary? I mean you already do that here in FK Save:

Custom script: set udg_FK_Key = GetHandleId(udg_FK_KnockbackUnit)

Custom script: local real x

Wether these were locals or not wouldn't make any difference to the system and I get the feeling that for good practice they should be created outside of the group pick, since you're just making lots of locals when you only need one of each (x and y)

(FK_KnockbackUnit is alive) Equal to True

For realism, a dead unit wouldn't stop moving just because it died.

Custom script: call SetUnitX(udg_FK_KnockbackUnit, x + udg_FK_KnockbackSpeedPerInterval * Cos(LoadReal(udg_FK_Hashtable, udg_FK_Key, 3) * bj_DEGTORAD))
Custom script: call SetUnitY(udg_FK_KnockbackUnit, y + udg_FK_KnockbackSpeedPerInterval * Sin(LoadReal(udg_FK_Hashtable, udg_FK_Key, 3) * bj_DEGTORAD))

Load "LoadReal(udg_FK_Hashtable, udg_FK_Key, 3)" into another variable before doing anything with it. you call it twice so it's less efficient to load the same value from a hashtable twice.

All I've got for now

[defskull]

Radamantus I dont get it Why there are two triggers but only have one action? Which ?

.OmG. Screenshot is ugly... Convert to JPG format and not PNG The screenshot is in JNGP.

Tank-Commander Set FK_KB_FrictionPerInterval = (FK_KnockbackFriction x FK_IntervalPerMove) Set FK_KB_FrictionPerInterval = (FK_KB_FrictionPerInterval x FK_IntervalPerMove) Put it into one line, no point doing it twice. You mean like this; Set FK_KB_FrictionPerInterval = ((FK_KnockbackFriction x FK_IntervalPerMove) x FK_IntervalPerMove) Unit - Order FK_KnockbackUnit to Stop Why? Using SetUnitX/Y does not interrupt orders, therefore units will still be able to move while being knockbacked. If I order those units to Stop, they won't be able to be ordered around (Move, Attack, etc) Also, when ordering unit to Stop + SetUnitX/Y, it is by default will stop the units from getting out of the map boundaries (saves check line code) FK Key Events Conditions Actions Custom script: set udg_FK_Key = GetHandleId(udg_FK_KnockbackUnit) Is this necessary? I mean you already do that here in FK Save: It is because applying this system to multiples units at once (Unit Group) has different approach. It's a bit hard to understand, I'll try to change the instructions layout in the next version, making it more easier. Custom script: local real x Wether these were locals or not wouldn't make any difference to the system and I get the feeling that for good practice they should be created outside of the group pick, since you're just making lots of locals when you only need one of each (x and y) If you're dealing with IF/THEN/ELSE block + local variables + unit group, you would know where to put that function. The settings of local variables can only be done inside Unit Group action, if you don't believe me, try it. (FK_KnockbackUnit is alive) Equal to True For realism, a dead unit wouldn't stop moving just because it died. Yeah I was thinking hard whether this check should be implemented or not, but since you're thinking that "units just don't stop do they ?", I'll remove that check. Load "LoadReal(udg_FK_Hashtable, udg_FK_Key, 3)" into another variable before doing anything with it. you call it twice so it's less efficient to load the same value from a hashtable twice. I've learn from Magtheridon, he said that if you only use the variable once per trigger run, it would be........ Ahhh, I see it now, I called it twice, for X and Y, ahhh thanks :)

[Almia]

key and hashtable

[defskull]

Ah, you see, one is to acknowledge which unit should the data be saved to and hashtable is for saving angle per unit pick.

This "weird" settings only applies to units picked via Unit Group (FK_TempGroup).

As I mentioned earlier, I will change the layout to be more easier to understand in the next version.

[baassee]

jsut declare the locals at the top of the actions, wont do any harm anyway

[defskull]

Top of the actions where exactly baassee ?
Did you tried it yet ?
I tried, but it compiles error, I have talked with WaterKnight with this issues, locals must be declared inside the Unit Group action.

If you already tried it and succeed, please do share the code.

[baassee]

Ah that's true, cause of engine I guess - cannot allocate the local within an if. ops forgot, enumeration creates a whole new function thus the locals have to be declared within that enum func ^^

anyway, these two parts should be stored into the hashtable as well as they are always the same

Cos(udg_FK_KnockbackAngle * bj_DEGTORAD)
Sin(udg_FK_KnockbackAngle * bj_DEGTORAD)

and you can actually get rid of the locals just put

GetUnitY(udg_FK_KnockbackUnit) + udg_FK_KnockbackSpeedPerInterval * Sin(udg_FK_KnockbackAngle * bj_DEGTORAD)

into

call SetUnitX(udg_FK_KnockbackUnit, x)

[Tank-Commander]

Well, I would like to say on the grounds of using stop, other than stopping them from going out of bounds, I was mostly referring to the doctrine as to why you were disabling their functions, since interrupting orders isn't the most useful of things to do and stun/slow/etc. in the actual WC3 does not prevent orders, and knockback isn't really a "disable" thing. I'd suggest just putting the checking for map bounds in so that their orders aren't cancelled, guess it's preferential, but I'd still have a boolean in the "system" to allow you to enable/disable the stop being run and cancelling orders.

[CoLd Bon3]

Just one suggestion - create a configurable variable that sets where the special effect is spawned. Some people might want it to be on the head, no the origin which makes absolutely no sense but it will be good if you put this... just in case.

The system is great, nice job, defskull! :)

[Matarael]

Tag.

[defskull]

baassee anyway, these two parts should be stored into the hashtable as well as they are always the same Cos(udg_FK_KnockbackAngle * bj_DEGTORAD) Sin(udg_FK_KnockbackAngle * bj_DEGTORAD) You mean to store those whole calculation or just FK_KnockbackAngle ? If you're asking me to only save FK_KnockbackAngle, I already did that in v1.1. But if you're asking me to save those whole calculation, I do not do it yet. Ah yeah, they are constants right. and you can actually get rid of the locals just put GetUnitY(udg_FK_KnockbackUnit) + udg_FK_KnockbackSpeedPerInterval * Sin(udg_FK_KnockbackAngle * bj_DEGTORAD) I thought that repeating the same function without caching it reduces performance ? That's why I used locals, x and y to cache the function, instead of repeating the GetUnitX/Y each time.

Tank-Commander I was thinking this too, to add boolean whether the knockback should or should not "disable" the units. Well I guess you have convinced me. Because some people wants those knockbacked units to still be able to do anything, while at the same time, the knockback occurs to the unit.

CoLd Bon3 Just one suggestion - create a configurable variable that sets where the special effect is spawned. Some people might want it to be on the head, no the origin which makes absolutely no sense but it will be good if you put this... just in case. The system is great, nice job, defskull! :) Hah, I thought this too, but the more I think about it, the more crazy it becomes because hey, knockbacked and friction is related to ground, that's why the SFX will be spawned at the feet of the unit, but I'll add this small configuration anyway, it's a small add btw, thanks for the convincing :)