SC2Mapster

I have something like

while(flag)
{
    if(condition)
    {
         dosomething();
    }
    else{}

}

It does not work(says the function took to long to execute), what kinda of function can I put inside that else? It worked with Wait, is it the best solution? Thanks for your time.

@LucasRocha: Go

I think if you leave the Else empty then the script engine won't be able to leave your While loop and execute other triggers because it keeps waiting for the While to resolve, you need a Break or a Wait for it to be able to move on.

Anyway a Wait(0) instruction in the Else should be just fine since it doesn't actually wait (if it does it waits something like 0.03125 seconds at most) but allows the next triggers to execute.

Btw I think this kind of problem usually doesn't turn up because people use a Periodical event with conditions rather than a While loop that always runs, even though they probably work the same way in the end.

Periodic:
Each tick, the actions are executed no matter how long they take. By using this method, you can have multiple iterations of the same actions running in a short period of time, which is very CPU-intensive and could cause either crashes or triggers going very wrong. Basically, periodic effects happen simultaneously if the time needed to execute all actions in the set exceeds the time between each tick. Avoid this as much as you can. It used to cause huge lags on BNet in my Ikari Warriors map, I got rid of them all, switched to Repeat Forever loops instead, and gained 10 to 20 FPS instantly without any additional bug. This was probably the most helpful advice for my map I received from one of our members, in terms of optimization.

While/Repeat loops:
Basically, in a loop the set of actions has to be finished before another set is executed. It's almost mandatory to add a wait in the "If Then Else" action. Without the Wait, the result is pretty close to a Periodic event. The reason you get errors when the Wait is missing is that the loop is repeated as many times as it can in a second, so basically 1s/0.03s = 33.3 times! The loop breaks and the trigger fails, you get an error because a set of actions is not supposed to be repeated 33 times a second. Obviously it's not good, so just put a Wait in your Else set of actions. It will basically do the same as a Periodic event, except it is impossible to have multiple iterations of the same loop (which is also better in terms of memory usage, by the way). If you want the loop to stop you'll have to break it, if you want multiple iterations you'll have to start them manually.

The worst combination would be a periodic trigger executing Repeat Forever loops. Any computer would crash in seconds.

There are times in C programming where waits in an infinite loop are appropriate.

Galaxy is different; play it safe and play it stupid because the language does not work like C under the hood.

I suggest you post the complete code. We (or at least I) cant tell what youre trying to do.

This reminds me gameloop. For example in .NET you do Application.DoEvents() to unstuck entire application, otherwise as expected it will freeze everything.
SC2 have limit on loops to simply prevent players clients from freezing.

@ZealNaga: Go

Eh? I thought the minimum tick interval was 0.0625? Did they change it?

What I'm trying to do is wait until condition is true. Should I try another way then? since waiting multiple times is not a viable solution.

edit 1: are to is

I believe your issue lays in way you designed this. post or explain what it does, there should be other way around

also did you tried adding wait 0.0625 as FuzzyD suggested?

With your current method, you obviously have an infinite loop, which will never stop, because theoretically code execution is handled, as if no time passes. So, in simple terms, if the execution of your loop takes too long, the game will be paused, until the execution of the loop caught up (-> lag). So, your condition will NEVER become true, if it isn't from the start, because nothing is supposed to happen, before your loop runs out; so nothing could take place, which could affect the outcome of your condition. SC2 has a failsave, which cancels such basic infinite loops, thats whats causing your error message.

So adding a wait would probably be the preferred method, or is there a specific reason, why you don't want to use a wait?

Quote from FuzzYD: Go

Eh? I thought the minimum tick interval was 0.0625? Did they change it?

You can use a 0 wait to get a 0.03125 interval, but I am not aware of any practical use for it, because most relevant systems for us run at 0.0625.

@Kueken531: Go

It makes trigger-based animations and movements smoother, that's about it.

@Kueken531: Go

Thanks for clarifying that

Quote from Forge_User_62748943: Go

It makes trigger-based animations and movements smoother, that's about it.

Are you absolutely certain? I thought I did read in various topics, that there is no difference in animations, because technically the wait runs at 0.03125, but the visuals are only updated every 0.0625 anyway. Also, if you are certain, could you provide proof of some sort? A link, testmap or a quick experiment which makes the difference obvious, maybe? Not saying I wouldn't believe you, I am just interested ;)

@Kueken531: Go

if you mean trigger visuals they can't be applied at different rate then you call them. that's just not logic :p
non trigger pushed visuals are updated at your fps rate.

From my understanding so far, triggers can indeed run at 0.03125 interval. Visuals are rendered at your FPS rate; aka much faster. However the visuals need to receive updated information from the triggers, which is handled at 0.0625 like most other update rates in the game; everything inbetween is either disregarded or interpolated.

So basically, the trigger updates 2 times in 1 update interval for the visuals; effectively skipping each 2nd update, which results in no visual difference between 0.0625 or 0.03125 interval for triggers affecting visuals. Correct me, if I am wrong.

€ just made a simple testmap, the marine and marauder get teleported rapidly between 2 points. The marine is teleported every 0.03125, and he is visible only at one point; the marauder is updated at 0.0625 and is visible at both locations, supporting the theory, if I am not mistaken.

Also, giving orders to the marine results in a strange facing behavior, the facing for the marine updates, as if you give the order to a marine at the other teleported point. If you order the marauder, it tries to change its facing after every teleport. This would suggest, that, while the visual marine is at one point, the physical marine unit is always at the other point. Since both visuals and "physicals" update every 2 ticks, I assume, that visuals get updated at even ticks, and physicals, or maybe just the orders, at odd ones (or vice-versa ;)).

Buut this does become a little off-topic ;)

I guess I will keep an wait inside the else and use 0.03125 timer, thanks everyone.

@Kueken531: Go

Sorry for the late reply but to clarify, I mostly experimented with actor messages since those let you change height and pitch:

        General - Repeat (Actions) 900 times
            Actions
                Variable - Modify car_x: - 0.125
                Actor - Send message (SetPosition2DH car_x car_y) to actor (Actor for Civilian Cars [166.58, 211.69])
                General - If (Conditions) then do (Actions) else do (Actions)
                    If
                        car_x <= 98.0
                    Then
                        General - Break
                    Else
                General - Wait 0.0625 Game Time seconds

Changing 0.0625 to 0 here will not only make the animation smoother but also double the car's speed.

Okay, this would mean, that actors from units get updated every 0.0625, but if you update the actors manually via trigger every 0.03125, it works?

Quote:

...but also double the car's speed.

That is to be expected, even if the visuals only update every 0.0625, the trigger will still run 2 times in between, of course it will move twice as fast. The important thing is the smoother animation, unfortunately, this is usually a subjective opinion. So you could be right, but you might also be wrong; I am not 100% convinced yet.

€ just tested the same thing with my own testmap and unfortunately, at 0.03125 the actor is still only visible at one of the locations, ever. This still supports the previous statement, that the visuals cannot handle an interval faster than 0.0625 at all.

Please let me know, if you see a flaw in my logic.

@Kueken531: Go

I tested more thoroughly and I think I'm wrong, two cars set up to test for this case look exactly the same when moving side by side :(

Guess when I sped up an older animation by using Wait(0), I noticed it was smoother because of the speed increase then thought it still "felt" smoother when I changed the delta to compensate for the increased speed, but didn't test.

I guess the only things Wait(0) is useful for is making internal game logic more responsive..