[GUI] Simple Frictional Knockback System v1.2

[Moderator]

22:31, 22nd Aug 2012
Magtheridon96:

Comments

• Since you're creating 1 special effect 32x times a second, you may end up causing lag. In order to reduce the amount of lag, you can create special effects half the time, or maybe even a third of the time.
  Look:
  
  Example

  • if randomInteger(0, 2) == 0 then
    • // create special effect
  • endif
• You don't need to have the local reals x and y since you're only referencing them once. If you're referencing locals only once, then you don't need them.
• You can cache the Cos/Sin values into the hashtable so you don't have to avoid retrieving the constant value in the loop during every single iteration. It's more efficient this way because Cos/Sin are heavy function calls despite their short name. (Optional)

 

[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]

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

Which ?

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

The screenshot is in JNGP.

• 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]

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.

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.

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

 

[baassee]

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.

not really

 

[defskull]

I don't know, Magtheridon pretty much emphasize on caching data into variables to prevent repetition of same function calls.

 

[CoLd Bon3]

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

Well, someone may create a spell that shoots a knockbacking arrow and he may want to get an effect on the chest for example.

 

[baassee]

I don't know, Magtheridon pretty much emphasize on caching data into variables to prevent repetition of same function calls.

Mag was my old padawan, he will suffer me.

 

[defskull]

He maybe your padawan but he is Hive's Moderator and I will have to obey his standards lol.

 

[baassee]

He maybe your padawan but he is Hive's Moderator and I will have to obey his standards lol.

Nah if you convert it into JASS you'll see why you don't need the locals ^^

 

[defskull]

So I should remove those 2 locals and just get the reals via GetUnitX/Y directly into the function ?

 

[baassee]

So I should remove those 2 locals and just get the reals via GetUnitX/Y directly into the function ?

yeah as I stated in one of my previous replies

 

[defskull]

Don't order the unit to stop.

Since it uses SetUnitX/Y, if I don't order the unit to stop, what if the Player order Move to that unit ?
You are 'knockbacked' but you can move, weird much ?

Don't create a special effect after every iteration, check if a random number between 1 and something is 1, and then create the effect. This 'something' would be "Effect Frequency Denominator". The less this factor, the more the effects. Something like 3-5 would be ideal as a default value.

Do you mean the SFX should spawn at random ?
Not each interval ?
But the random has a high chance to occur, is that it ?

You don't need to have the local reals x and y since you're only referencing them once.

Noted.

You can cache the Cos/Sin values into the hashtable so you don't have to avoid retrieving the constant value in the loop during every single iteration.

Alright sir.

 

[Magtheridon96]

Since it uses SetUnitX/Y, if I don't order the unit to stop, what if the Player order Move to that unit ?
You are 'knockbacked' but you can move, weird much ?

Sometimes, you want the knockback to be something like a force interfering with a unit (the way it is in Warlock). So I just thought that a user may not want you to be ordering the unit to stop ;o

Do you mean the SFX should spawn at random ?
Not each interval ?
But the random has a high chance to occur, is that it ?

Yeah, so, instead of having it spawn /every/ interval, you would have it spawn on some intervals.

Pseudo code:
FrequencyFactor = 5 // The greater this is, the less the effects will appear.
if GetRandomInt(0, FrequencyFactor) == 0 then
createEffect()
endif

edit

Okay,

When to Cache

When to Cache a Value

GUI

Any time you repeat a call more than once, cache it. It's very simple.
If you're only going to reference the variable once, caching it will only make your code a bit slower.

JASS

If you're repeating a call that returns:

• A Scalar-type that doesn't need to be nulled:
  • Once, don't cache it.
  • Twice or more, cache it.
• A Handle-type that needs to be nulled:
  • Once, don't cache it.
  • Twice, don't cache it.
  • Thrice or more, cache it.

 

[Almia]

Add the check pathability because it will cause crash if a unit exceeds the map bounds

 

[baassee]

Add the check pathability because it will cause crash if a unit exceeds the map bounds

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)

Stated before in this thread.

 

[mckill2009]

I recommend this udg_FK_KnockbackAngle * bj_DEGTORAD in the save setup so that you dont need to do it everytime it in loops:

• Custom script: call SaveReal(udg_FK_Hashtable, udg_FKey, 3, FK_KnockbackAngle*bj_DEGTORAD)

 

[Almia]

So you don't have any plans on updating?

 

[makai]

waiting for this to get approved

 

[Almia]

waiting for this to get approved

We have waited months.

 

[makai]

Defskull is currently busy with his university staff i guess.. Sad..

 

[Almia]

Still. Even he is active, he hadn't updated this.

 

[defskull]

Updated v1.2.

 

[Bribe]

Hey defskull, nice to see you updating this. My observations tell me that this needs work to be acceptable, and this system also needs a niche. I'll elaborate:

1) Pathing is not considered except to keep the unit in the overall map. This is only good for knocking back units over completely flat and walkable terrain.
2) If the goal is to have a completely bare knockback, the special effect doesn't serve a purpose and neither should the prop window be used.
3) If you did enhance this to use pathing on non-flat maps, you basically end up with Knockback 2.5D.

 

[Wrda]

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

Agreed, but for realism, a unit that is already dead wouldn't be knockbacked too, wouldn't make any sense. So the condition should be there to prevent this.

 

[defskull]

The dead-moving units are already fixed in the previous version(s) lol.
Also, this one has decelerating knockback which Bribe's 2.5D doesn't support.

Oh well, I guess my system is more simpler to be used for simple map I suppose.

 

[Maker]

No collision with buildings, trees, cliffs. And you mess up the propulsion window values.