Update that is so controversal and serious that it deserves a double post
I've been playing around with the map and been monitoring the memory consumption SC2 takes up and came to a couple of conclusions:
1#
All functions used in the trigger "UpdateCamera" (in doos101's map) do in fact NOT leak at all. Judging from that it can be assumed that most, if not all, variable types and (native) function calls do not leak.
2#
However the map still leaks! How's that possible? Easy. Every time a trigger runs it'll leak. To be more exact it'll leak 4 kilobytes, probably a pointer to the instance of the trigger? But it's kind of large for a simple pointer.. unless it uses high address values to make sure there's no problem with the addresses of other game objects? Sounds somewhat logical, but it's still a guess.
3#
I have rewritten the UpdateCamera trigger to use a while() loop and not a periodic trigger at the start and there was no leak at all after the first trigger run.
Well, 4 kilobyte. A map would have to leak 100,000 times to double the basic memory usage of SC2. That's quite a bit, but quickly reached when using several periodic runs.
=== Conclusion ===
Based on my finds I'd advice against the use of more than one peroidic timer event in your triggers. Instead, try to use while() loops as a workaround. It should remove the amount of memory leaks by a huge margin.
However, I'm not a pro in this kind of things. I've just observed and found a logical conclusion. I am not 100% certain that this is all correct what I said here. It's based on the observation of a single map and only a couple of trigger events.
Been trying those two maps..
The first one doesn't lag at all. Just the unit moves horribily jerky because it's moved way to often in order to get a smooth animation.
The second also didn't lag, but someone fixed the damn jerkiness yay ^.^
So, well, to me it seems the problem either lies within your pc, or within the combination of your pc and the game architecture.
You know, long long ago I've been playing a wc3 map which did NO leak cleaning at all! It was completely coded in GUI and it created an average of 30 leaks per second!
This game was kind of long.. usually it took us up to 3 hours to complete it. After about 1 1/2 hours we started to notice the memory leaks.
So if it's really memory leaks that make you lag after a few minutes, then you should upgrade your 16 megabyte RAM immediately lol.
Honestly I think your lags have another cause in this situation.
But feel free to prove me wrong - I'd like to see a map that makes you lag when not using local variables, but not makes you lag when using them.
For the stun effect I suggest looking at the 250mm Strike Cannons and see how it's done there.
As for the beam:
You'll find the actor "Ghost Snipe Attack", which is linked to the effect "Ghost - Snipe (Damage)".
Everytime the effect happens, this actor will be created. You can see that pretty nicely under the "Events+"-tab.
"Ghost Snipe Attack" possesses a data field called "Beam" which contains the string of the beam id (in this case "GhostSnipeAttackBeam") that'll be used.
You could change that to, for example, ProbeAttackBeam and it'd shoot a cool electro zapp :)
If you dublicate the effect "Ghost - Snipe (Damage)" to use it with a dublicated version of the Snipe-ability then you'll also want to dublicate "Ghost Snipe Attack".
To change the effect that will create this dublicated "Ghost Snipe Attack" you can simply change the "Attack Effect" under "Token" of "Ghost Snipe Attack".
It's pretty confusing I think, but I hope I made myself clear somehow. Good luck :)
Uhm, I'm using this exactly ( setting the turn angle and turning rate to 0) to prevent unwanted movement and it works just fine.
Maybe you need to have both values at 0 instead of just one?
I don't think you really need to worry about things like that. SC2 seems very good in cleaning up it's own mess.
Also, a couple of memory leaks will not make your map unplayable. You'd need.. thousands and thousands of leaks to even see an impact.
Reading and writing local and global variables shouldn't make much difference at all, since both things basically work the same way. Creating the local variable takes a little bit of time, but that's nothing to worry about. Local variables also don't seems to leak at all, or at least it's much less than in WC3.
Bad performance doesn't really have anything to do with memory leaks. Your triggers have a worse performance the more functions calls you have. Basically try to avoid using things like Get Dying Unit / Get Unit Position / Get Last Created XXX / Get Whatever.. several times, but instead store them in a local variable. Usually I use a variable when I have to use the same function call more than 3 times.
But it actually isn't THAT important. Galaxy is a nice bit faster than the lame JASS2 we've been using for years. I don't think any of my triggers have created lag yet (unless I've screwed up horribly).
There's nothing wrong with TriggeringUnit(), UnitGetPosition() and all the others! Nothing!
The only bad thing is that these things calculate the return value over and over again. For example, getting the position of a unit 20 times will make the game search for this unit 20 times. If you store it in a variable it's faster, but there aren't any memory leaks being created by using that.
SC2 has a robust garbage collection. That means local variables and temporary created things will be cleaned up nicely and get removed from memory.
Global variables and Data Table will obviously not be cleaned up, as they can still be referenced. And that is good. You can't create globals dynamically anyway, so the only way to kill your game with it is to totally rage out on creating globals.
There's nothing wrong in creating a global variable called TempPoint and using it like a local variable to temporarily store information, however. Setting this variable to another value will overwrite the old one, thus take up no additional memory.
Congratulations Sir, you have just exceeded the memory limit of SC2!
Basically the 'UGE amount of variables killed your map. Every index of every variable is taking up a little bit of space in your memory.
Let's see:
Crystarium - HP UP = No File <File - Image[14][100][100]>
14 times 100 times 100 makes... 140,000 indexes just for this one.
All in all you have about .. 538,000 indexes.
Now, the next part of the calculations is a little bit of guessing. I don't know exact numbers.
Let's say every variable index takes up 4 byte.. that makes 2152000 bytes, makes 2101 kilobyte, makes 2.05 megabyte.
Now unfortunately the maximum capacity SC2 can allocate are 2 megabyte.
You exceeded the max capacity by 683 indexes I guess.
Well, the camera target is usually in front of the actual camera. The rotation (GUI name, it's Camera Yaw actually, I think) is the angle betweenthe camera and the camera target (in degrees). By substracting 180 and then polar project is I get a point behind the camera, exactly the opposite direction of the Rotation/Yaw.
There should be a trigger to set the Custom Value of a unit (I'm not 100% sure how it's called in SC2).
Ah, there we go:
Unit - Set (Last created unit) custom value 0 to 100.0
You can make the index no. 0 keep the amount of Strength you have and modify it accordingly. I don't recall having seen a function to actually return the number of stacks of a behavior, but I could be mistaken.
So basically an.. ego shooter type?
Well, you should be able to get the current camera target. Just periodically:
Move unit to (camera target) offset by xx towards (Rotation of camera - 180).
If you don't actually need it to be there at all times (but only when casting a spell or something) then I'd suggest only doing that.
Then you create the dialog for multiple players..
Event: Any player clicks any dialog button
Action:
If the clicked button is Objective[1] then
-- Set ObjectiveCount[1]=ObjectiveCount[1]+1
else if the clicked button is Objective[2] then
-- Set ObjectiveCount[2]=ObjectiveCount[2]+1
else ....
After everyone voted you just see which index of ObjectiveCount is largest.
0
I just used the Task Manager. It's the best tool of measurement I have right now.
I can't do anymore tests right now, however.
0
Update that is so controversal and serious that it deserves a double post
I've been playing around with the map and been monitoring the memory consumption SC2 takes up and came to a couple of conclusions:
1#
All functions used in the trigger "UpdateCamera" (in doos101's map) do in fact NOT leak at all. Judging from that it can be assumed that most, if not all, variable types and (native) function calls do not leak.
2#
However the map still leaks! How's that possible? Easy. Every time a trigger runs it'll leak. To be more exact it'll leak 4 kilobytes, probably a pointer to the instance of the trigger? But it's kind of large for a simple pointer.. unless it uses high address values to make sure there's no problem with the addresses of other game objects? Sounds somewhat logical, but it's still a guess.
3#
I have rewritten the UpdateCamera trigger to use a while() loop and not a periodic trigger at the start and there was no leak at all after the first trigger run.
Well, 4 kilobyte. A map would have to leak 100,000 times to double the basic memory usage of SC2. That's quite a bit, but quickly reached when using several periodic runs.
=== Conclusion ===
Based on my finds I'd advice against the use of more than one peroidic timer event in your triggers. Instead, try to use while() loops as a workaround. It should remove the amount of memory leaks by a huge margin.
However, I'm not a pro in this kind of things. I've just observed and found a logical conclusion. I am not 100% certain that this is all correct what I said here. It's based on the observation of a single map and only a couple of trigger events.
0
Been trying those two maps..
The first one doesn't lag at all. Just the unit moves horribily jerky because it's moved way to often in order to get a smooth animation.
The second also didn't lag, but someone fixed the damn jerkiness yay ^.^
So, well, to me it seems the problem either lies within your pc, or within the combination of your pc and the game architecture.
0
You know, long long ago I've been playing a wc3 map which did NO leak cleaning at all! It was completely coded in GUI and it created an average of 30 leaks per second!
This game was kind of long.. usually it took us up to 3 hours to complete it. After about 1 1/2 hours we started to notice the memory leaks.
So if it's really memory leaks that make you lag after a few minutes, then you should upgrade your 16 megabyte RAM immediately lol.
Honestly I think your lags have another cause in this situation.
But feel free to prove me wrong - I'd like to see a map that makes you lag when not using local variables, but not makes you lag when using them.
0
For the stun effect I suggest looking at the 250mm Strike Cannons and see how it's done there.
As for the beam:
You'll find the actor "Ghost Snipe Attack", which is linked to the effect "Ghost - Snipe (Damage)".
Everytime the effect happens, this actor will be created. You can see that pretty nicely under the "Events+"-tab.
"Ghost Snipe Attack" possesses a data field called "Beam" which contains the string of the beam id (in this case "GhostSnipeAttackBeam") that'll be used.
You could change that to, for example, ProbeAttackBeam and it'd shoot a cool electro zapp :)
If you dublicate the effect "Ghost - Snipe (Damage)" to use it with a dublicated version of the Snipe-ability then you'll also want to dublicate "Ghost Snipe Attack".
To change the effect that will create this dublicated "Ghost Snipe Attack" you can simply change the "Attack Effect" under "Token" of "Ghost Snipe Attack".
It's pretty confusing I think, but I hope I made myself clear somehow. Good luck :)
0
I only know that *.wav and *.ogg work.
I don't know about *.mp3 though.
0
Uhm, I'm using this exactly ( setting the turn angle and turning rate to 0) to prevent unwanted movement and it works just fine.
Maybe you need to have both values at 0 instead of just one?
0
I don't think you really need to worry about things like that. SC2 seems very good in cleaning up it's own mess.
Also, a couple of memory leaks will not make your map unplayable. You'd need.. thousands and thousands of leaks to even see an impact.
Reading and writing local and global variables shouldn't make much difference at all, since both things basically work the same way. Creating the local variable takes a little bit of time, but that's nothing to worry about. Local variables also don't seems to leak at all, or at least it's much less than in WC3.
Bad performance doesn't really have anything to do with memory leaks. Your triggers have a worse performance the more functions calls you have. Basically try to avoid using things like Get Dying Unit / Get Unit Position / Get Last Created XXX / Get Whatever.. several times, but instead store them in a local variable. Usually I use a variable when I have to use the same function call more than 3 times.
But it actually isn't THAT important. Galaxy is a nice bit faster than the lame JASS2 we've been using for years. I don't think any of my triggers have created lag yet (unless I've screwed up horribly).
0
There's nothing wrong with TriggeringUnit(), UnitGetPosition() and all the others! Nothing!
The only bad thing is that these things calculate the return value over and over again. For example, getting the position of a unit 20 times will make the game search for this unit 20 times. If you store it in a variable it's faster, but there aren't any memory leaks being created by using that.
SC2 has a robust garbage collection. That means local variables and temporary created things will be cleaned up nicely and get removed from memory.
Global variables and Data Table will obviously not be cleaned up, as they can still be referenced. And that is good. You can't create globals dynamically anyway, so the only way to kill your game with it is to totally rage out on creating globals.
There's nothing wrong in creating a global variable called TempPoint and using it like a local variable to temporarily store information, however. Setting this variable to another value will overwrite the old one, thus take up no additional memory.
0
Congratulations Sir, you have just exceeded the memory limit of SC2!
Basically the 'UGE amount of variables killed your map. Every index of every variable is taking up a little bit of space in your memory.
Let's see:
Crystarium - HP UP = No File <File - Image[14][100][100]>
14 times 100 times 100 makes... 140,000 indexes just for this one.
All in all you have about .. 538,000 indexes.
Now, the next part of the calculations is a little bit of guessing. I don't know exact numbers.
Let's say every variable index takes up 4 byte.. that makes 2152000 bytes, makes 2101 kilobyte, makes 2.05 megabyte.
Now unfortunately the maximum capacity SC2 can allocate are 2 megabyte.
You exceeded the max capacity by 683 indexes I guess.
Edit: Ah yea, there we go:
http://www.sc2mod.com/board/index.php?page=Thread&postID=227#post227
Edit 2: Brain flash: You might try circumventing that problem by using an external way to save stuff, for example banks.
0
0
0
0
0