It is possible to get 32 updates per second using a while loop:
Test 2 Events Game - Map initialization Local Variables Conditions Actions General - While (Conditions) are true, do (Actions) Conditions Actions Variable - Set test = (test + 1) General - Wait 0.0 Game Time seconds
However, it is possible that's updating twice per game loop (in chunks) instead once per half game loop. I'll find out in a moment though.
No, it's updating in chunks. Twice per game loop, instead of once per half game loop.
I know this by spam pausing the game.
Every time I paused, the variable "Test" was always on odd number (in the form 2n + 1). Thus, I'd either have the best luck in coin flipping in all of human history (more than 800 heads in a row, 0 tails), or it's only updating in chunks OR OR OR the game only pauses after one complete loop (event - key press).
Anyone know of a way to test this?
Confirmation that it does not work. Although it might check the conditions every 1/32 of a second, it does not perform that actions until the expiration of the game loop. Here is the test that confirmed it:
Test 2 Events Game - Map initialization Local Variables clear = False <Boolean> Conditions Actions General - While (Conditions) are true, do (Actions) Conditions Actions Variable - Set test = (test + 1) General - If (Conditions) then do (Actions) else do (Actions) If clear == True Then Variable - Set clear = False UI - Clear All Messages for (All players) Else Variable - Set clear = True UI - Display (Text(test)) for (All players) to Subtitle area General - Wait 0.0 Game Time seconds
When you have "UI - Clear All Messages" it's supposed to display even numbers ONLY. However, it always displays 2n and 2n + 1 when I pause the game.
HOWEVER. If you move that action to the Else, instead of the Then, then it only shows you odd numbers, 2n + 1 followed by 2n + 3.
:(
@EdwardSolomon: Go Heres a test I just made for you
it moves a unit across the map.
The test shows that the periodic event will run even if the prior running of it has not yet completed.
It preforms each action as they occur in the code.
While loops that run hard with out waits will tend to lock up the game and you may not visually see what occurs during each cycle.
What the user sees is not really handled by the script engine.
Testing by pausing is kinda fail, imo
Btw if your using game time... the game speed will effect that
I would suggest you avoid trying to code in a manner that relies on tracking so many cycles per second.
There are quite a few factors that will cause it to run different on different peoples computers and on bnet as well.
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
Quote from SouLCarveRR: Go@EdwardSolomon: Go Heres a test I just made for you
it moves a unit across the map.
The test shows that the periodic event will run even if the prior running of it has not yet completed.
It preforms each action as they occur in the code.
While loops that run hard with out waits will tend to lock up the game and you may not visually see what occurs during each cycle.
What the user sees is not really handled by the script engine.
Testing by pausing is kinda fail, imo
Btw if your using game time... the game speed will effect that
I would suggest you avoid trying to code in a manner that relies on tracking so many cycles per second.
There are quite a few factors that will cause it to run different on different peoples computers and on bnet as well.
I wasn't testing by pausing. Look at my fourth post, you can replicate it easily yourself. You can get odds only, but there's no way to get evens only (changing the initial value of Test = 1 instead of 0 doesn't qualify, because then you can't get odds only).
I remember discussing this a couple of months ago, before 1.5.
Then too I thought you could make smoother animations by using wait(0), but it turned out I was wrong and it just moved my objects faster (parameters were incremented twice before it moved anything..) than wait(0.0625), creating a silly illusion of smoother movement and more frames.
Cyber Jorts
Quote from SouLCarveRR: GoI would suggest you avoid trying to code in a manner that relies on tracking so many cycles per second.
There are quite a few factors that will cause it to run different on different peoples computers and on bnet as well.
There are functions that need to run in order to create smooth looking animations. Blizzard gave us a tool to assist us for Moving units or changing their facing (Move Unit instantly with BLEND) and face unit to angle over X seconds.
However, those two tools don't always cut it for certain circumstances. Also, the jump from 16 fps ( frames per game second) to 32 fps (frames per game second) is TREMENDOUS and noticeable, whereas the jump from 32 to 64 fps is no where near as noticeable. So whatever toolbag at Blizzard decided on a 1/16 second clock instead of 1/32 should have his teeth kicked in.
EdwardSolomon Regular ShmoeI know in the past, the "Wait 0 game-time seconds" would allow you to update a trigger 32 times per second (0.03125 seconds) instead of 16 times per second.
However, running tests upon the 0 wait, I haven't been able to achieve this effect, which leads me to believe it was patched for some aweful reason (why would blizzard remove functionality?). It is possible though that the triggers I'm using to test this theory aren't appropriate. I put the triggers below:
Then I had it display the integer variable in a separate trigger: