🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
This resource provides GUIers with the ability to benefit from something like SpellEffectEvent by Bribe
I would like to give full credit to Bribe for this system because it's entirely based on his SpellEffectEvent!
The performance gain is incredible.
What it does is use only one trigger to evaluate one spell trigger rather than a thousand.
I coded it in GUI-Jass, so it doesn't require JNGP.
The GUI-Jass idea is Bribe's as well
GUI creates the variables automatically, and if you use custom scripts for most of the code, it turns out to be just as efficient as Jass ^_^
GUI SpellEvent
Events
Conditions
Actions
Custom script: local integer i = 1
-------- - --------
-------- Call the initialization function. --------
-------- - --------
Custom script: call ExecuteFunc("InitSpellEvent")
-------- - --------
-------- Creating the hashtable. --------
-------- - --------
Hashtable - Create a hashtable
Set SpellEventHash = (Last created hashtable)
-------- - --------
-------- Over here, I'm just looping through all the abilities to be registered and saving the triggers in a hashtable. --------
-------- The only purpose of this is to automatically create the variables. --------
-------- - --------
Set SpellEventTrigger[0] = (This trigger)
Set SpellEventAbility[0] = Orb of Slow
-------- - --------
As you can see, this system is very short and easy to implement because all you have to do is:
1) Open up the trigger editor
2) Copy and paste the trigger to your map (Make sure you go to File >> Preferences and check "Create unknown variables when pasting trigger data")
3) Done!
SpellInit
Events
Map initialization
Conditions
Actions
-------- Set Abilities --------
Set SpellEventAbility[1] = Blizzard
Set SpellEventAbility[2] = MassTeleport
Set SpellEventAbility[3] = Summon Water Elemental
Set SpellEventAbility[4] = Holy Light
Set SpellEventAbility[5] = Resurrection
Set SpellEventAbility[6] = Divine Shield
-------- Set Triggers --------
Set SpellEventTrigger[1] = CastBlizzard <gen>
Set SpellEventTrigger[2] = CastMassTeleport <gen>
Set SpellEventTrigger[3] = CastSummonWaterElemental <gen>
Set SpellEventTrigger[4] = CastHolyLight <gen>
Set SpellEventTrigger[5] = CastResurrection <gen>
Set SpellEventTrigger[6] = CastDivineShield <gen>
-------- Run the Initialization Trigger --------
Trigger - Run SpellEvent GUI <gen> (ignoring conditions)
This will register your spells to the system. When a unit casts SpellEventAbility, SpellEventTrigger will run (while checking conditions in-case you need them.)
You don't need to check what ability is being cast in your spell trigger =)
You may not register more than one trigger for a spell.
If you really want two triggers to run, then the solution would be to execute the second trigger in the first line of the first trigger's actions. Either that, or you could merge the triggers. There are no obvious examples of how two triggers registered to the spell effect event for the same spell is the only way to go.
Make sure you run the SpellEvent GUI trigger only once.
Don't touch any of the custom scripts unless instructed to do so within the comments.
v1.0.0.0
Release
v1.0.0.1
Simplified Implementation by making all variables Auto-create.
Added some comments.
v2.0.0.0
The whole system is now in one trigger only.
Faster and better way of registering spells to the system.
Added more comments.
Fixed possible bug.
v2.1.0.0
You don't need the count variable during registration any more.
If you assign "A unit starts the effects of an ability" to 400 triggers, you're creating 400 * 16 = 6400 spell effect events, and whenever a unit casts a spell, the conditions of all these 400 triggers will be evaluated (400 Trigger Evaluations :O)
With this, there will always be only 1 trigger evaluation/trigger execution per spell cast and only 16 spell effect events!
That's why this increases performance and keeps your FPS pretty high whenever a unit casts a spell!
Spell-spamming should never cause as much lag as it did ever again
You forgot to mention that with this, there can only ever be one trigger responding to a particular spells effect. You cant have two triggers responding to the same spell.
You can of course argue that having two triggers respond to the same spell is bad practice and id agree. But you didnt mention this limitation.
Also, the concept you follow originated in 2009 at thehelper.net and wc3c.net.
All you need to do is remove the "A unit starts the effects of a spell" event from your spell trigger, and register your spell to the system like this:
Set SpellEventAbility = MyAbility
Set SpellEventTrigger = MyTrigger
Trigger - Run GUI SpellEvent (ignoring conditions)
And guess what, you don't even need to add conditions to check what the ability being cast is
edit
Updated.
Now has easier implementation.
The SpellEventAbility and SpellEventTrigger variables weren't auto-created before.
ok ok but if we talk theoritical then useing specific unit events then it is faster for rpgs where only heroes can get that abilities?
another question it's use ability start effect right? so not begins casting an ability,right?
i asked the triggersleep thing coz once i checked last timer RegisterPlayerUnitEvent then there was problem with wait, no? i thought this work same way jass converted to jass from vjass
i asked the triggersleep thing coz once i checked last timer RegisterPlayerUnitEvent then there was problem with wait, no? i thought this work same way jass converted to jass from vjass
The speed gain would be very marginal ;p
I don't want to complicate things and give users the ability to configure which players get registered to the system and which players don't D:
A user who has some knowledge of Jass could do that by himself and a GUI user would only loose an amount of speed so little, even Nestharus wouldn't care =P
another question it's use ability start effect right? so not begins casting an ability,right?
Yeah, it registers triggers to the start ability effect event.
This is because it's the most commonly used event for spells.
You don't need a system to handle the channel and begin cast events because typically, for every 100 or so spells, you might have 5-20 that use those events, so you wouldn't gain a worthwhile amount of performance ;/
You would gain performance, but not as much as you would with this ;P
2.This is absolutely unnecessary - set SpellEventTrigger = (ThisTrigger),set SpellEventAbility = Lesser Clarity Potion
3.The only thing that I personally do not like in this system is,constant repetition of the system trigger [Trigger - Run GUI SpellEvent <gen> (ignoring conditions)
] so I started working on this a bit and the result is excellent. Now only need one call system trigger.
I think you could make this super simple by saving the trigger onto a hashtable with the abilities as the arrays. Then load the trigger at each spell cast and run it ;p
Edit: Looking at the triggers, thats exactly what you did... lol
2.This is absolutely unnecessary - set SpellEventTrigger = (ThisTrigger),set SpellEventAbility = Lesser Clarity Potion
3.The only thing that I personally do not like in this system is,constant repetition of the system trigger [Trigger - Run GUI SpellEvent <gen> (ignoring conditions)
] so I started working on this a bit and the result is excellent. Now only need one call system trigger.
variable arrays dont matter. its the 8192 arrays that kill. I had about ~10 8192 variables in my map once and the game wouldn't run any user-defined triggers whatsoever because of a handle overload due to the array size
If you assign "A unit starts the effects of an ability" to 400 triggers, you're creating 400 * 16 = 6400 spell effect events, and whenever a unit casts a spell, the conditions of all these 400 triggers will be evaluated (400 Trigger Evaluations :O)
With this, there will always be only 1 trigger evaluation/trigger execution per spell cast and only 16 spell effect events!
That's why this increases performance and keeps your FPS pretty high whenever a unit casts a spell!
Spell-spamming should never cause as much lag as it did ever again
Well, now this is much better
The way you do this a little different from my,but the basis is the same.
As for me personally, this should look like any system,simple and useful
variable arrays dont matter. its the 8192 arrays that kill. I had about ~10 8192 variables in my map once and the game wouldn't run any user-defined triggers whatsoever because of a handle overload due to the array size
then u made something really wrong coz i use alot array and dont ahve any problem, i mean i never got error from this also u can consider when u make a array its isnt 8192 size because u watched from ur thread too, when u create unit group array then u must create cgroup manually its mean other index's unused
i really doubt normally the arrays kill any map because u cant see any map without arrays
think about that before hashtable patch still was alot rpg and every map used arrays what was made in we
basically anyway u dont need array with 8192 size, u can use more array or if u use unit and others array and u scared about 8192 then u can null when unit die
arrays still better in alot case because u dont need extra function calls, dont need group (what mean also alot function call and check) also more readable and easier to use
Here's a tip to increase map performance when using arrays in GUI:
- If you always set the array sizes to 1, it won't make a difference at all
Arrays in Warcraft III are defaulted to:
0
""
null
false
0.00
Thus, setting the size to something other than 1 for any array would just add overhead to the map initialization.
The sizes are only useful when you're in need of default values.
Anyway: Updated.
This is the final version.
I had one more idea to make this 100% bug-free even when the user doesn't read the instructions at all,
but then I realized that a user who doesn't read the instructions deserves what he's going to get :>
For once i can use one of the good systems! not jngp ftw!
edit, @mag (on post bellow) i know that but close to every system i want to use is in vjass. for example the witchers cam system, makers custom window, the movement system (allowing setting speed more than normal).
All of Bribe's GUI systems are just like this
GUI DamageEngine, GUI UnitIndexer, GUI UnitEvent, etc..
So I wouldn't say that this is the first resource that brings vJass libs to GUI
But in all seriousness, this is incredible. I have 70+ Hero units in my map and each has at least 1 triggered spell/ability. My previous method of avoiding the check lag was to have the triggers be activated only when the related Hero unit type is picked/enters the game. But this method is tons better.
All Their Functions that use of vJass Cause Errors in My World Edit Example: When a function and then Inactive Active, a message from the World's Edit Speaking Mistakes (More than 200 lines) and Non Allows Enable New Function because of errors.
Someone know Fix This?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.