Making a Wait Without Waits...

[Sevion]

EGUI does not crash maps... It's the end-user fucking up that crashes maps... Besides, ATM, parts of EGUI aren't compatible atm.

(BTW, latest EGUI will have locals in GUI.)

 

[polo2005]

EGUI does not crash maps... It's the end-user fucking up that crashes maps... Besides, ATM, parts of EGUI aren't compatible atm.

(BTW, latest EGUI will have locals in GUI.)

It's the end-user... i lol'd ^^

haven't sued EGUI myself even once i dont really know, just heared what others have said...

And whati could understand EGUI is like a more advanced up to date version of WEU?

 

[Bogrim]

Chaos_Knight, what defines whether a trigger is MUI or not is how it handles the variable data. Are you storing data for a single unit or are you accounting for multiple units? Waits are a classic example of what typically breaks a trigger's MUI ability because waits almost always introduce the possibility of an event firing in the time period and altering the trigger's variable data. For example:

An ability does X damage to the target after 10 seconds. Unit A casts the spell and the target is saved as SingleUnitVariable and after 5 seconds, Unit B casts the same spell on a different unit and that target now overwrites the previous target in SingleUnitVariable. After another 5 seconds the second target receives damage from the first spell, making the trigger work differently than intended (a bug).

In that example, a simple use of local variables would avoid the conflict. The point in using local variables/hashtables/indexing systems/timers/jass is to make sure the unit stays the same by saving data for which instance the unit was handled in. Again, the easiest way to learn this is simply to learn the different methods of doing MUI triggers as each method has its limits and advantages.

 

[13lade619]

//Read from the bottom up.

struct data //Struct to store data into.
    integer store
endstruct

function SampleTimerCallback takes nothing returns boolean
    local data d = KT_GetData() //KT's syntax for retrieval.
    
    call BJDebugMsg("After 5 seconds, Retrieved Integer: "+I2S(d.store)) //Display retrieved data..
    
    call d.destroy() //Cleanup.
    return true
endfunction

function Trig_Sample_Conditions takes nothing returns boolean
    return GetSpellAbilityId() == 'ANab'
endfunction

function Trig_Sample_Actions takes nothing returns nothing
    local integer i = GetRandomInt(1,100)
    local data d = data.create() //Create the struct.
    
    set d.store = i //Set the data for the struct.
    call BJDebugMsg("Stored Integer: "+I2S(i))
    
    call KT_Add(function SampleTimerCallback, d, 5) //Set the timer with a duration and set what function as callback.
endfunction

//===========================================================================
function InitTrig_Sample takes nothing returns nothing
    set gg_trg_Sample = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( gg_trg_Sample, EVENT_PLAYER_UNIT_SPELL_EFFECT )
    call TriggerAddCondition( gg_trg_Sample, Condition( function Trig_Sample_Conditions ) )
    call TriggerAddAction( gg_trg_Sample, function Trig_Sample_Actions )
endfunction

There's a sample of a wait without using TriggerSleepAction.
Using Jesus4Lyf's KeyTimer (KT), well there are other Timer Attachment Systems out there but this is for the example.

Basiclly, the principle is:

Have a struct to store data into.
and then pass the struct into the callback function.
so that you can retrieve what data you stored and use it again after the duration.

 

[Curo]

As a GUI user who experienced similar problems, I can tell you this:

First off, if you don't know GUI well yet, stop. STOP. Right now. Instead of learning GUI, learn JASS. I wish I had. GUI is pointless, and different. If you learn GUI well like I did, you won't want to learn JASS. And you will suffer.

Second, as someone said, most of the time waits work fine. The biggest flaw is they don't work if you have an ability cast, then cast again before the duration/effect of the first cast is up. In this case you will want to make a hashtable. By combining hashtables with unit groups, you can save the data for any specific unit. You can store damage amounts, effect duration, unit counts, etc. You usually use them with a periodic timer that updates the data for each individual unit. Read a hashtable tutorial for a better explanation.

Third, to those bickering about stuff here, don't argue with someone in a thread (especially over something stupid like why people don't learn JASS). If you want a solution, try and listen to what people say. If you don't like what they say, just say "thanks but no thanks" and leave it. If you argue in a thread, you are likely to both get neg repped and make enemies. Both of these things will reduce the amount of help you get. And seeing as this is a helper forum, that's not something you want here.

 

[Chaos_Knight]

As a GUI user who experienced similar problems, I can tell you this:

First off, if you don't know GUI well yet, stop. STOP. Right now. Instead of learning GUI, learn JASS. I wish I had. GUI is pointless, and different. If you learn GUI well like I did, you won't want to learn JASS. And you will suffer.

Second, as someone said, most of the time waits work fine. The biggest flaw is they don't work if you have an ability cast, then cast again before the duration/effect of the first cast is up. In this case you will want to make a hashtable. By combining hashtables with unit groups, you can save the data for any specific unit. You can store damage amounts, effect duration, unit counts, etc. You usually use them with a periodic timer that updates the data for each individual unit. Read a hashtable tutorial for a better explanation.

Third, to those bickering about stuff here, don't argue with someone in a thread (especially over something stupid like why people don't learn JASS). If you want a solution, try and listen to what people say. If you don't like what they say, just say "thanks but no thanks" and leave it. If you argue in a thread, you are likely to both get neg repped and make enemies. Both of these things will reduce the amount of help you get. And seeing as this is a helper forum, that's not something you want here.

Im learning JASS, vJASS actually.

 

[Zwiebelchen]

I just want to correct a state from the third page:

"Waits are fine if you are okay with the inaccuracy."
This is just a lie! Waits cause nasty bugs other than their inaccuracy. Do not use them if you know exactly what you are doing.

 

[Darthfett]

I just want to correct a state from the third page:

"Waits are fine if you are okay with the inaccuracy."
This is just a lie! Waits cause nasty bugs other than their inaccuracy. Do not use them if you know exactly what you are doing.

Really? And what might these bugs be?

Generally, the only problem with Waits is that they are inaccurate. It's not a big deal if you're just waiting on player input or something similar.

 

[Zwiebelchen]

Really? And what might these bugs be?

Generally, the only problem with Waits is that they are inaccurate. It's not a big deal if you're just waiting on player input or something similar.

Waits can interfere with each other, making some waits fire instantly, although they should have a duration. Waits also bug up inside loops and certain conditions. Waits also bug certain functions that rely on waits internally (Like transmissions and such).

 

[Darthfett]

Waits can interfere with each other, making some waits fire instantly, although they should have a duration. Waits also bug up inside loops and certain conditions. Waits also bug certain functions that rely on waits internally (Like transmissions and such).

Never heard of Waits interfering with others or firing instantly. I've heard of them "bugging" inside a loop, but that's not necessarily a problem with waits - Callback function used as loops and conditions are supposed to be instant, so a wait would understandably cause problems.

For you GUI people, basically Waits cause problems in Pick every group in ... type functions because each iteration is actually a function call. Each one is done in the order they are stored in the group. A wait could result in the group being changed, and wouldn't result in all of the instances being run at the same time. I'm not sure how callbacks are written in the underlying wc3 engine, but in inherently prevents this problem, as it simply terminates the function when it comes to a wait.

 

[Zwiebelchen]

Never heard of Waits interfering with others or firing instantly. I've heard of them "bugging" inside a loop, but that's not necessarily a problem with waits - Callback function used as loops and conditions are supposed to be instant, so a wait would understandably cause problems.

I remember that back to the days where I was a bloody noob in coding and didn't use any JASS, I had lots of trouble with waits either fireing instantly or blocking each other in parallel running triggers.
Don't know if that was an issue of that early game patches or not.

I also had the problem that when I fired a transmission, the duration of that transmission changed entirely depending on the number of players in the game.
It was some kind of a trauma for me and taught me to never use TSA ever again.


But that was some years ago. Might be possible that Blizzard remastered the TSA. Would be good, because for cinematics, it really sucks to use timers.

 

[Darthfett]

I remember that back to the days where I was a bloody noob in coding and didn't use any JASS, I had lots of trouble with waits either fireing instantly or blocking each other in parallel running triggers.
Don't know if that was an issue of that early game patches or not.

I also had the problem that when I fired a transmission, the duration of that transmission changed entirely depending on the number of players in the game.
It was some kind of a trauma for me and taught me to never use TSA ever again.


But that was some years ago. Might be possible that Blizzard remastered the TSA.

Doubtful that they would have remastered it, though it's possible. However, TriggerSleepAction is synced across the game, and so having more players could cause a higher fluctuation in the time.

 

[Chaos_Knight]

Why are Waits inaccurate?

If i use them in a spell, they make the unit, or spell wait.
:nuts:

 

[Seprest]

just because


it's been said thousands of times in this thread, apparently they don't take very precise input or sumtin, what did ppl say they have (+-)~.2s time?

 

[Zwiebelchen]

Why are Waits inaccurate?

Waits use your internal CPU time and split your trigger into multiple threads and thus return other values for every player, depending on what the CPU is calculating at the moment.
To handle this, the time values for waits have to be synced, which involves passing data from one player to another one.
Thats why waits are lag dependand.

Timers are different, as they use game time. That's why they need more processing time in general (getting a programs internal time measurement requires more operations than just comparing system time), but are almost 100% accurate.


I'm not sure about this, but it seems logical to me.

 

[Curo]

So where do we sit on periodic time events (every 1 second of game time)? Would you guys class those with timers?

 

[tooltiperror]

Just a thought, you may use timers instead of waits for periodic effects.

 

[Curo]

Just a thought, you may use timers instead of waits for periodic effects.

And the advantage would be...? Aside from being able to turn them off.

 

[PrisonLove]

And the advantage would be...? Aside from being able to turn them off.

The problem with using waits in a loop is that with waits functions like [ljass]GetSpellTargetLoc() GetSpellTargetUnit()[/ljass]... basically anything except for [ljass]GetTriggerUnit()[/ljass] can bug using a wait. If you use a wait those functions named before cannot be referenced, hence the need for variable declarations. You CAN use waits for periodic events and such, but there are many more advantages to using timers. Timers are more accurate, can be paused, destroyed, restarted, anytime you want, and if using JASS, often do not require multiple triggers, only a callback function, in addition to avoiding the bugs I mentioned before, and are better for MUI capability.

 

[Curo]

I must have misinterpreted what ToolTip said. I was asking about using the "Event - every 1 second of game time" function. Is it more comparable to a timer or a wait, in its accuracy, speed, etc.