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.)
//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() == 039;ANab039;
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
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.
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.
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).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).
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.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.
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.Why are Waits inaccurate?
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.