| 04-22-2006, 06:22 PM | #1 | |
Could someone clarify the meaning of this criteria for me? Quote:
What does it mean by specific or non-specific variables? Am I allowed to use global variables for my JESP spell or not? |
| 04-22-2006, 06:25 PM | #2 |
As i understand it, it esentally means you can require the map to have a gamecache variable (or the like). You cant name it, it must be configureable. (eg:) JASS:constant function whatever_Game_Cache takes nothing returns gamecache return udg_whateer endfunction |
| 04-22-2006, 06:27 PM | #3 |
I don't want to use a gamecache. I want to use global variables that will only be used for the spell. Does the JESP standard allow this? |
| 04-22-2006, 06:31 PM | #4 |
Why do you need them? If you wan the data to be stored over some time and be multi-instanceable, you have to use a system like handle vars or attachable vars. If you need to store the data only in that specific moment, just use a local variable. |
| 04-22-2006, 06:33 PM | #5 | |
Quote:
No. Im Posative that it doasnt allow that. And, you can make a FULLY MUI spell without a gamecache? o_0 I have my own question about the JESP standard: Are trigger variables allowed? (eg: gg_trg_buttsecks) Cause those are just global variables... |
| 04-22-2006, 06:43 PM | #6 | |
Quote:
You can completely make any multi-instanceable spell without a gamecache. Just use parallel arrays. For example, if you want a unit to be cursed for 30 seconds, to make it multi-instanceable just make an array of units, an array of timers, and an integer holding the highest used value in the array. When a unit becomes cursed, loop through the array until you find a free slot, set the unit and the timer at that index (if one doesn't exist yet create it and the event on the trigger), and if it's higher than the maximum value increment it. When a timer runs out, loop through the array to find it; there's your attached unit, so set it to null and if necessary decrement the maximum. Seems like a perfectly valid way to do it. Completely multi-instanceable, no memory leaks, and probably much faster than a gamecache because there are no string comparisons involved. I greatly prefer using parallel arrays in my maps to attach variables to objects. Globals are such an easy thing to transfer between maps; you can just make a GUI trigger with the references, and a single copy paste does them for you. So why are globals disallowed? |
| 04-22-2006, 06:46 PM | #7 | |
Quote:
JASS:constant integer JASS_MAX_ARRAY_SIZE = 8192 THATS why. A hardcoded limit. |
| 04-22-2006, 06:48 PM | #8 |
Right. 8192 units will be simultaneously casting my spell. |
| 04-22-2006, 07:05 PM | #9 | ||
Quote:
Quote:
Also, the 8192 array size limit might seem huge, but it's still a limit that can bug out in some cases. |
| 04-22-2006, 07:26 PM | #10 | ||
Quote:
Unit comparisons are just comparing the handle, which is just an integer; it's identical in every respect to comparing integers or reals. How could this possibly be more inefficient than asking Warcraft to do string comparisons to find variables in a table? You're not being realistic about how many times this array gets looped through. When someone casts the spell, the trigger goes through one index of the array; there is no loop at all. It literally points directly at the unit. When ten people cast it simultaneously, the expiration trigger goes through 10 variables, doing worst-case scenario 10 comparisons to find the attached unit, average 5 comparisons. This should be eons faster than asking Warcraft to do string comparisons to find some handles stored away in a game cache. 5 integer comparisons versus a table lookup using strings? You have to be joking here. Quote:
This is almost a good point. The procedure for multi-instancing a JESP spell is just find-and-replace the codename and reconfiguring it. With globals, you just rename the globals as well and re-paste the global-making trigger. It's one simple extra step; still extremely easy to multi-instance the spell. |
| 04-22-2006, 07:37 PM | #11 | |
Quote:
I see the validity of your points, now see myne: Your code for dealing with parrallel arrays is not recycleable code. (and cant truly be made recycleable like the caster systems gamecache engine is) Harder to impliment, modify and work with = bad. gotta change the whole base code for dealing with the globals to add a new bit of data to the mix. Gamecache? jsut attatch another variable. |
| 04-22-2006, 07:40 PM | #12 |
I have a question. How are you supposed to find the, lets say, cursed target? Let's say you do this: JASS:
loop
exitwhen udg_Target[i] == null
set i = i+1
endloop
set udg_Target[i] = GetSpellTargetUnit()
How will you know, lets say, in an expiration timer function, how to get that specific unit? That unit can be another udg_Target[i] as well if casted twice at the same time. So comparing the global to the specific unit won't do the trick. How do you find the unit that it was initially casted on? I'd be glad to see an example. |
| 04-22-2006, 08:04 PM | #13 | |||
Quote:
Of course it's recyclable, much more so than a gamecache. In my example, you don't need to recreate timers every time; it recycles previously used ones. When the unit at highest used point in the array, it decrements that point until it finds a used unit or the bottom; thus when all spells expire, the max drops back to zero and everything is completely reset. This is much more recycleable because it has the benefit of a permanent dedicated storage location, whereas a gamecache is constantly shuffling around memory. Quote:
You don't have to change any base code at all to add new data to the mix. Just make a new array. Say you want to add a special effect attached to units to my example above. Just make a new special effect array, and whenever you attach a timer, stick the effect in the same index. When a timer expires, the same old code finds you the attached unit, and its special effect lies at the same index as that of the unit; that took one single line of code to attach the effect, and absolutely ZERO additional computational power to find it! Whereas with a gamecache you need to fetch the attached unit and then fetch the attached effect, here when you fetch the unit you get all its attachments for free; no code required and no computation required. It takes one line of code to attach it (and one to remove it), same as a gamecache only much simpler and faster (as in literally infinitely faster) fetching procedure. Quote:
I don't understand your example; the way you explained it, it wouldn't work with a gamecache either. Two units casting a spell twice on a target is something you'd have to deal with separately; it has nothing to do with the implementation of attaching variables. |
| 04-22-2006, 08:07 PM | #14 |
Well, i'm totally confused. To attach stuff on a timer, you use strings to get what you attached. How do you use that on globals? String arrays or what? |
| 04-22-2006, 08:14 PM | #15 |
You don't really 'attach' them. You just make a list of units and a list of timers, and have the 1st unit corresponding to the 1st timer, the 2nd unit corresponding to the 2nd timer, etc. Anyway, I think what I'll do is write everything my way, but instead of using globals I'll just fetch the arrays themselves from a gamecache in my event handlers. I'm still going to grumble about it though until someone gives me a good reason to use a gamecache for attaching things. |
