HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

tempPoint vs. tempPoint[#]

04-12-2006, 10:26 PM#1
pappi.chullo
I thought of a method for the "tempPoint" variable (used to prevent leaks) of using array values for specific triggers; ie: tempPoint[1] is used in Trigger 1, tempPoint[30923952] used in Trigger ...yeah.

This is so that the values don't get tangled when used at the same time; ie: Trigger 2 fires every .50 seconds, and uses tempPoint twice. At the same time, a trigger is fired when a spell was cast, and it also uses tempPoint. There might be a collision with the value of tempPoint if they are fired at the same time, but that seems pretty unlikely.

All of this, however, is theoretical but it does make sense (to me at least). My question is whether it really is necessary to assign individual "ID"'s to a trigger so that it doesn't collide with other values, and whether doing this hogs up a little more memory/processing power than not doing it. (do variables with array values require more power to run than non-array variables?)
04-12-2006, 10:47 PM#2
Immoralis
Quote:
Originally Posted by pappi.chullo
I thought of a method for the "tempPoint" variable (used to prevent leaks) of using array values for specific triggers; ie: tempPoint[1] is used in Trigger 1, tempPoint[30923952] used in Trigger ...yeah.

This is so that the values don't get tangled when used at the same time; ie: Trigger 2 fires every .50 seconds, and uses tempPoint twice. At the same time, a trigger is fired when a spell was cast, and it also uses tempPoint. There might be a collision with the value of tempPoint if they are fired at the same time, but that seems pretty unlikely.

All of this, however, is theoretical but it does make sense (to me at least). My question is whether it really is necessary to assign individual "ID"'s to a trigger so that it doesn't collide with other values, and whether doing this hogs up a little more memory/processing power than not doing it. (do variables with array values require more power to run than non-array variables?)

this is useless if you dont null and destroy, the leaks are still there, you are just not overlapping them
04-12-2006, 10:48 PM#3
Anitarf
Two triggers can not run at the same time. Only one trigger may run at once, and does so until it finishes, reaches a wait action, or it runs another trigger (through the run trigger action or by causing it's event to fire with one of it's actions), at which point the currently running trigger is put on hold and the next one runs.
04-12-2006, 10:58 PM#4
PipeDream
The best solution is to use JASS and local variables. However, you can do local variables in GUI by declaring globals in the variable editor and then overwriting them with a line like:
Trigger:
Actions
Custom script: local location udg_tempPoint
This lets you select the global from the dropdown while a local copy will be used by warcraft.
The problem with this is that you can't do this more than once in each trigger generally, because each localized-global will share the same space.
Running with your trigger ID suggestion, we can work around by using a single integer which will give us a private spot in an array of locations.
In the custom script section, paste:
Collapse JASS:
//===================================================
//    GUI Temp Memory hack - Hooray for code reuse
//  Variables needed:
//  integer array udg_Stack_Nodes
//  integer udg_Stack_Heap
//  integer udg_Stack_Top with initial value -1
//  whatever object such as location array udg_tempPoint
//========================================================

function AllocateTemp takes nothing returns integer
    local integer p = udg_Stack_Heap
    set udg_Stack_Heap = udg_Stack_Heap + 1
    if(p > 8191) then
        call BJDebugMsg("Too many active GUI triggers!  Use game cache for a heap")
    endif
    return p
endfunction

function GetTempSpace takes nothing returns integer
    local integer p
    if(udg_Stack_Top == -1) then //Check if stack is empty
        set p = AllocateTemp() //Grab a new cell for our collection
    else //Do a regular stack pop
        set p = udg_Stack_Top
        set udg_Stack_Top = udg_Stack_Nodes[udg_Stack_Top] 
    endif
    return p
endfunction

//Regular stack push
function ReleaseTempSpace takes integer p returns nothing
    set udg_Stack_Nodes[p] = udg_Stack_Top
    set udg_Stack_Top = p
endfunction

Your trigger needs a couple extra lines:
Trigger:
sometrig
Collapse Events
Player - Player 1 (Red) types a chat message containing p as An exact match
Conditions
Collapse Actions
Custom script: local integer udg_mem = GetTempSpace()
Set tempPoint[mem] = (Target of current camera view)
Wait 5.00 seconds
Cinematic - Ping minimap for (All players) at tempPoint[mem] for 1.00 seconds
Custom script: call RemoveLocation(udg_tempPoint[udg_mem])
Custom script: call ReleaseTempSpace(udg_mem)
Notably, these two:
Trigger:
Custom script: local integer udg_mem = GetTempSpace()
Custom script: call ReleaseTempSpace(udg_mem)
04-13-2006, 04:40 AM#5
pappi.chullo
Quote:
Originally Posted by Anitarf
Two triggers can not run at the same time. Only one trigger may run at once, and does so until it finishes, reaches a wait action, or it runs another trigger (through the run trigger action or by causing it's event to fire with one of it's actions), at which point the currently running trigger is put on hold and the next one runs.

Oh okay, I was never 100% sure how triggers were actually ordered to fire. Thank you for clearing that up.
04-13-2006, 04:45 AM#6
pappi.chullo
Quote:
Originally Posted by PipeDream
The best solution is to use JASS and local variables. However, you can do local variables in GUI by declaring globals in the variable editor and then overwriting them with a line like:

This lets you select the global from the dropdown while a local copy will be used by warcraft.
The problem with this is that you can't do this more than once in each trigger generally, because each localized-global will share the same space.
Running with your trigger ID suggestion, we can work around by using a single integer which will give us a private spot in an array of locations.
In the custom script section, paste:

So you can easily use another variable such as tempPoint2[#] (for example) for triggers that need two temporary points? This method seems much easier than having to assign an ID to each trigger. Thanks a lot.
04-13-2006, 07:58 AM#7
Captain Griffen
Variable arrays take far, far more memory than ordinary variables. There is no need to have a variable array for temp variables, as they are not needed for any length of time (if they are, eg: there is a wait, I'd suggest using a trigger specific variable called something else).
04-13-2006, 08:38 AM#8
MaD[Lion]
well, maybe it's not a leak, but it still takes up memory, so wat is the point? Especially when u wanna run periodic event, u maybe able to keep the handles, but they will eat memory like hell
04-13-2006, 09:24 PM#9
PipeDream
A variable array does take more memory than an ordinary variable. However, this memory is bounded and very small-about 32kB. In comparison, every single handle object consumes at least on the order of a kB (700B? I measured once, but forgot. Will check again.)

In any case, this does more than let the user take care of memory leaks, as it allows a GUI user to use variables for anything, with little hassle, as everything can be done from the drop down menus, with out having to worry about whether things will work through any myriad of multithreading issues-waits are not the only potential trouble source.

MaD[Lion], please elaborate on your concerns with a concrete example.

A far better long term solution to pappi.chullo's problem is writing JASS directly, however, for now he can use this as a band aid.
04-13-2006, 09:28 PM#10
Captain Griffen
Yea, but purely for temp variables, there isn't any risk of them interferring with each other, and when there IS a risk, it is better just to make a new variable, as that takes up less memory.

One variable array = ~46 handle objects? That backs up my point - effectively 46 less handles for one variable array less.
04-13-2006, 09:44 PM#11
PipeDream
Quote:
Yea, but purely for temp variables, there isn't any risk of them interferring with each other, and when there IS a risk,
You can't have there be no risk and a risk simultaneously. There is always a risk, and carefully studying each situation to figure it out = time, work, bug potential.
Anyway, you CAN'T just make a new variable so easily. What if you have a trigger that runs more than once instance of itself simultaneously? How are you going to tell one version to use variable A, and the other to use variable B? Even different triggers-how are you going to keep track of which uses what?
46 handles is nothing, nor is it comparable, as handles take up somewhat special memory-memory that warcraft must keep an eye on for desyncs.

I am glad that you point out room for "by-hand" optimization, and I will reiterate that the best long term solution is to learn JASS and use warcraft's local variable syntax.

Fundamentally though, this is O(1) in memory used and time spent-what more could you ask for?
04-13-2006, 09:48 PM#12
Captain Griffen
Well, if there is a risk, then it is obviously no longer what I consider a temp variable.

But yea, JASS would be better. I can't be bothered though, and I never have trouble with variables overlapping (locals would come in handy for MUI though...). Meh, it's not that big a problem.