For loop with Wait action not behaving as expected

Problem Description

FOR loop with WAIT action doesn't pause the FOR loop for the wait duration. WAIT action in beginning of the FOR loop will pause the FOR loop for the duration of WAIT and then process all steps immediately but does not yield per loop. WAIT action at the end of the FOR loop will yield at that point, but again doesn't actually affect per loop.

Attach a Capx

https://dl.dropboxusercontent.com/u/238 ... Issue.capx

Description of Capx

ForWaitIssue.capx contains simple test where a function is called at beginning of layout and the function runs a FOR loop with WAIT action. Orange square (named almost appropriately) should move once per step per second until 9 steps are made (from top to bottom of screen).

Steps to Reproduce Bug

• Add Sprite to scene
• In event sheet add System -> FOR loop
• Add bigger than 1 to the end index so that FOR loop is run more than once
• Add WAIT action with any observable second amount to the FOR loop
• Add action you wish to loop, in this case add cumulatively something to Sprite position

Observed Result

The Sprite moves all the cumulative steps in one frame.

Expected Result

The Sprite moves one step per FOR loop cycle with WAIT amount of delay per cycle.

Affected Browsers

• Chrome: (not tested)
• FireFox: YES
• Internet Explorer: (not tested)

Operating System and Service Pack

Windows 7 and SP 1

Construct 2 Version ID

Release 178 (64-bit), free edition

This is not a bug, it behaves as expected.

The for loop is executed in one tick, so it moves "instantaneously". Also, expressions are executed from top to down, so your wait action actually has no effect!

You could try with this to get the behavior you expect:

for "i" from 1 to 9 -> wait loopindex seconds

Set Y to ...

I've attached a simple capx to demonstrate when the for loop is executed. Please check the browser console (ctrl+shift+j) to see in which tick is the action called!

While I agree it is most likely behaving as intended (as was proven with the wait loopindex), it is unnecessarily complex way to handle it. In almost any engine/language you can do a normal yield/sleep with time in any point off a loop to add delay. The case is normal here too, except you can't directly type in time, but have to use set variable and adjust from there.

Clear, simple, something user can randomly conjure up, follows logic Construct 2 uses everywhere:

For loop 1 to 9

---- System Wait (1.0)

---- Do stuff

Same (mostly), but less intuitive for user:

For loop 1 to 9

---- System Wait (loopindex)

---- Do stuff

Thank you for solving my issue though

Edit: Ah! But it should also work as:

For loop 1 to 9

---- Do stuff

---- System Wait (time)

The reason why it should work is because it should run loops from top to down and a loop at a time. So it should first "Do stuff" then pause (loop index 1), after the pause it should run next index. It definitely should not run all indexes first and then pause the current loop indexes.

In the current system if I do:

For loop 1 to 10000000 (10 million)

---- System Wait (loopindex)

---- Do stuff

It runs the loop cycle 10 million times and just sets different wait times per cycle? To me, it sounds extremely inefficient VS running each loop separately with Wait (1.0) and continuing to next index once last one is completed.

p.s. I'm not a real coder. Just Unity game designer who discovered Construct 2 and forgot what I did before, so my explanations might not follow any real code logics

I agree with JohnnySheffield , it is a feature,not a bug.

Actually. wait action is not perfect enough. For example, wait action under a function call. The parameters of this function call will all missed after wait action.

Moreover, javascript does not support coroutine, coroutine will cause more memory usage to keep the context of each pending task, they said.

Closing as not a bug, this is by design. It is documented here: http://www.scirra.com/tutorials/56/how-to-use-the-system-wait-action

For backwards compatibility reasons we will not change how it currently works. Further, how it currently works is actually completely consistent since it uses the same algorithm no matter where you use it; making it work like you want it to in this particular cause would mean making 'wait' use a different algorithm under specific circumstances, which I think is actually more counterintuitive, not less.

Ashley

Just a suggestion, SDK (engine) might provide some features for coroutine. For example, supporting this case (for loop with wait) in 3rd plugin.

Since it is not official feature, user need to take a risk by himself.