Does 'wait 0 sec' interfere with MUI in triggers?

[Sunchips]

I have a spell in my map that runs a trigger when cast on a unit.

• Quick Strike Counter Refresh
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to (==) Quick Strike
  • Actions
    • Set QuickStrike_CD[(Player number of (Owner of (Triggering unit)))] = 10.00
    • Set QuickStrike_ComboReal[(Player number of (Owner of (Triggering unit)))] = 0.00
    • Set Combat_Spell = True
    • Wait 0.00 seconds
    • Unit - Cause (Triggering unit) to damage (Target unit of ability being cast), dealing (Stats_AD[(Player number of (Owner of (Triggering unit)))] x 1.75) damage of attack type Spells and damage type Normal
    • Set Combat_Spell = False
    • Sound - Play MetalHeavySliceFlesh3 <gen> at 100.00% volume, attached to (Target unit of ability being cast)

Before I added the 'Wait 0 seconds' it worked perfectly on all units except one kind. There is nothing special about this kind of unit but for some reason it only works properly on this kind of units when I have the 'Wait 0 seconds' in the trigger.

The even weirder thing is the problem only occurs if I haven't dealt any damage to this kind of units before I cast the spell. So without the 'Wait 0 seconds' it actually worked if I landed an auto attack before casting the spell. I have absolutely no idea how this can be logical in any way.

However I discovered that it works in any way if I have the 'Wait 0 seconds. So does this interfere with MUI?

 

[IcemanBo]

Nope, that's sadly not MUI anymore. Wait 0 seconds does stop current operaton thread. --> all other triggers can fire before the wait ends --> Target unit of ability being cast may be overwritten.

Triggering unit can be used after waits, because it is like a local variable which is only important for triggering trigger.

You have to store targeted unit into variable and use it later after the wait:

• Custom script: local unit u = GetSpellTargetUnit()
• Wait 0 seconds
• Custom script: set udg_Unit = u
• Unit - Cause (Triggering unit) to damage Unit, dealing (Stats_AD[(Player number of (Owner of (Triggering unit)))] x 1.75) damage of attack type Spells and damage type Normal
• Custom script: set u = null

Unit is a unit variable.

If you create an unit variable 'Unit' with GUI, you have to write prefix udg_ before, if you work with JASS/Custom scripts. Thats why: set udg_Unit = u.

But I don't understand exactly why you need the wait. What "kind" of unit is it that bugs without the wait-action?

 

[Cataract92]

What is the combat_spell boolean for? Because what I think thats the problem. I guess your are running loop somewhere or another kind of check. But because wc3 is just single threaded its running run trigger at a time. So the combat_spell boolean get set to true and directly after it to false again. If you put a wait in there (even if it's just 0secs) you stop the trigger for this time, and the other triggers have to to run like the check-trigger for combat-spell. To answer your actual question^^ : I'm pretty sure a wait of 0secs doesn' t interferes the mui.

Edit: IcemanBo was a bit quicker and he's right. I forgot about overwriting the target

 

[pOke]

Are you using a DDS? The Boolean as stated above I would assume is why the damage is being blocked but give us more to work with for a better answer.

 

[Sunchips]

Nvm the problem was with my damage engine system.

What is the combat_spell boolean for? Because what I think thats the problem. I guess your are running loop somewhere or another kind of check. But because wc3 is just single threaded its running run trigger at a time. So the combat_spell boolean get set to true and directly after it to false again. If you put a wait in there (even if it's just 0secs) you stop the trigger for this time, and the other triggers have to to run like the check-trigger for combat-spell...

This is no problem it works fine in all my triggers. If I check that the damage source is a Spell before the trigger damages someone and then check it false it will know when the unit takes damage if the source is a Spell or not (for spell shields etc) as I am using a damage engine.

Nope, that's sadly not MUI anymore. Wait 0 seconds does stop current operaton thread. --> all other triggers can fire before the wait ends --> Target unit of ability being cast may be overwritten.

Triggering unit can be used after waits, because it is like a local variable which is only important for triggering trigger.

You have to store targeted unit into variable and use it later after the wait:

• Custom script: local unit u = GetSpellTargetUnit()
• Wait 0 seconds
• Custom script: set udg_Unit = u
• Unit - Cause (Triggering unit) to damage Unit, dealing (Stats_AD[(Player number of (Owner of (Triggering unit)))] x 1.75) damage of attack type Spells and damage type Normal
• Custom script: set u = null

Unit is a unit variable.

If you create an unit variable 'Unit' with GUI, you have to write prefix udg_ before, if you work with JASS/Custom scripts. Thats why: set udg_Unit = u.

But I don't understand exactly why you need the wait. What "kind" of unit is it that bugs without the wait-action?

My variable list for GUI usually gets full and messy. I have always wanted to be able to use local variables for just certain triggers. Can I use these custom scripts to have local variables for GUI triggers?

 

[IcemanBo]

^Yes you always can declare variables in top of each GUI-trigger.

Examples:

• Actions
  • Custom script: local unit u
  • Custom script: local real x
  • Custom script: local location loc

So your trigger would have 3 new variables which are not defined in your variable table.

1. unit variable "u"
2. real variable "x"
3. location variable "loc" (location is same as Point in GUI)

But to use these new local variables you have to use Custom scripts.

But what is positive, that local variables are always MUI, they cant be overwritten.

Edit:

Never forget to initialisite your local variables. So only write "local real x" is not enough.

You must give it a value, for example:

Custom script: local real x = 5

Or you can declare it first on top of trigger and initialisize it later:

Custom script: local real x
....
Custom script: set x = 5

 

[Xonok]

You can also use locals with a bit less custom text.
To do this you make a variable, I'll assume it is named "Var" and the type is integer. (variable editor)
Then you declare a local, like this: "local integer udg_Var" (trigger editor)
Now you have overwritten Var with a local, but can still use it like it wasn't overwritten.
The overwriting will only work for this one trigger and not leak out to other triggers.

This technique is called shadowing.

 

[Sunchips]

That might get useful, thanks guys!

 

[IcemanBo]

http://www.hiveworkshop.com/forums/2481459-post2.html

 

[Kazeon]

don't ever use waits

 

[Chaosy]

don't ever use waits

not true. You can use them if you know how to.

 

[Kazeon]

I meant dont use in spell making

waits may work okay in a simple task

 

[Dr Super Good]

Wait 0 seconds does not work. It will still wait 0.1 seconds + network delay (not sure, but seems logical given experimental results) if a client is remotely connected to the host.

This is why it is not recommended to use wait since the timing accuracy is too low.

 

[Chaosy]

I meant dont use in spell making

waits may work okay in a simple task

you can actually make decent spells with them but it's not the best way.

 

[Malhorne]

@IcemanBo : you have to shadow those variables otherwise you can't get local variable on GUI action

 

[IcemanBo]

I never use shadowing. Or I do as I said:

But to use these new local variables you have to use Custom scripts.

Or I do something like : set i = udg_Int

And then go on with my Int variable.

 

[Magtheridon96]

Target unit of ability being cast may be overwritten.

Jesus no.
The event data remains the same in one execution.

The problems arise when you're depending on values stored in variables.

 

[Kazeon]

you can actually make decent spells with them but it's not the best way.

are you sure? mods always reject it because it's a BAD way..

 

[Malhorne]

It depends how you use them ^^'

 

[Kanadaj]

You can actually use waits for complex operations, like map setup (ie. like TKoK) or mass loop denendant systems - you really don't want to make the game irresponsible with mass uncontrolled looping, better just use a custom loading screen, and put wait in your logic.

 

[Troll-Brain]

Jesus no.
The event data remains the same in one execution.

The problems arise when you're depending on values stored in variables.

Well, according to my very old test (5 december 2007) "target cast of ability being cast" returns null when the spell cast event has fired.
So let's say it can be orverwritten by null if the chanel part of the spell is low ^^ ( less than the duration of a TriggerSleepAction(0) )

Of course this behavior could have changed, but i wouldn't bet any penny on that.

And i have the list of native Get... not mui (overwritten), but well again it's still from 2007 so ...

 

[Kazeon]

are you guys just saying or you can prove that spell with waits can be approved here? please gimme just a simple one example. you have to prove what you have said

because, I feel confused, I warned people not to use waits and you guys just said something like "hey, use waits is actually okay don't trust this guy"

 

[vypur85]

> I warned people not to use waits...
Not using waits when dealing with GUI is a pain in the ass.
Timers are not GUI-friendly.
There are limitations.

> don't trust this guy...
Nobody said waits are awesome.
They are good for use. But only if you know what you're doing.
So use them at your own risk.
Then again, if things are done right, there isn't any risk after all.

I've read that waits (or polled waits) leak? I'm not too sure about this.
If people are too anal about many things, it just makes life harder.

 

[Troll-Brain]

PolledWait leaks an handle id (timer) because it's not nulled when the timer is destroyed.

 

[Magtheridon96]

You can write a spell that uses waits and have it "approvable" if you follow my guide in the Tutorials section.
Just don't though. The inaccuracy and the timer leak are not worth it. At all.