CreateThreadScopeVariable
not ratedCopy and paste all of this code into your custom script area, and you will now be able to create variables of "thread" scope.
Q: What is thread scope?
A: Globals can be used anywhere, locals can only be used within the function they're created in, and similarly threadvars can only be used within the thread in which they were created. By thread I mean specific instance of the trigger running. Think of it as a variable with trigger scope, but if two instances of the same trigger are running at the same time, they each have their own separate trigger scope (the thread scope).
Q: Which functions should I actually care about?
The CreateThreadXXXX functions, which let you declare the variable. Simply pass them a string for what you want to be the variable to be named.
The SetThreadXXXX functions, simply pass the name of the variable as a string the value you want to set it too.
The GetThreadXXXX functions, simply pass the the name of the variable you want as a string to get their value.
The AttachTimer2CurrentThread function, which lets this work with timers. Timers are technically their own threads, but this will let you share values between your current thread and a timer. Be sure to read the comments about FlushTimerAttachments and FlushThreadVars though.
The FlushThreadVars function. Call this at the end of all your triggers that use these thread vars to clean up after yourself. Unfortunately there's no way to automate this.
The FlushTimerAttachments function. Call this when you're done sharing timers between a thread and a timer function.
Q: What would I use this for?
A: This is really useful when messing with callback functions, because they can't take parameters. Now you don't have to use the bj_ globals as a workaround or worry about triggers with lots of oddly placed waits.
Q: How do I use this for types that aren't supported?
A: You should be able to store almost any type by using the H2I function to convert the other types to integers. You will need another return bug exploiting function to convert them back.
Q: How does this work under the hood?
A: Read the comments, but in short in creates a unique game cache for every thread running.
Q: If this works via the game cache, why doesn't it support storing unit variables?
A: Because the cache won't actually store unit variables, it stores real copies of the units, not references to them. Instead use H2I to convert unit vars to integers, store the integer in a thread var, later retrieve it, then make a I2U return bug exploiting function to convert them back.
Q: What is thread scope?
A: Globals can be used anywhere, locals can only be used within the function they're created in, and similarly threadvars can only be used within the thread in which they were created. By thread I mean specific instance of the trigger running. Think of it as a variable with trigger scope, but if two instances of the same trigger are running at the same time, they each have their own separate trigger scope (the thread scope).
Q: Which functions should I actually care about?
The CreateThreadXXXX functions, which let you declare the variable. Simply pass them a string for what you want to be the variable to be named.
The SetThreadXXXX functions, simply pass the name of the variable as a string the value you want to set it too.
The GetThreadXXXX functions, simply pass the the name of the variable you want as a string to get their value.
The AttachTimer2CurrentThread function, which lets this work with timers. Timers are technically their own threads, but this will let you share values between your current thread and a timer. Be sure to read the comments about FlushTimerAttachments and FlushThreadVars though.
The FlushThreadVars function. Call this at the end of all your triggers that use these thread vars to clean up after yourself. Unfortunately there's no way to automate this.
The FlushTimerAttachments function. Call this when you're done sharing timers between a thread and a timer function.
Q: What would I use this for?
A: This is really useful when messing with callback functions, because they can't take parameters. Now you don't have to use the bj_ globals as a workaround or worry about triggers with lots of oddly placed waits.
Q: How do I use this for types that aren't supported?
A: You should be able to store almost any type by using the H2I function to convert the other types to integers. You will need another return bug exploiting function to convert them back.
Q: How does this work under the hood?
A: Read the comments, but in short in creates a unique game cache for every thread running.
Q: If this works via the game cache, why doesn't it support storing unit variables?
A: Because the cache won't actually store unit variables, it stores real copies of the units, not references to them. Instead use H2I to convert unit vars to integers, store the integer in a thread var, later retrieve it, then make a I2U return bug exploiting function to convert them back.