An event with a long wait time
- Thread starter Bluemith
- Start date
you could make use of the timer, though I'm personally not too fond of the timer. Another way to do it is using a variable. Set it to 20*number of seconds you want to wait, and then have a prallel process event doing "control variable (var) - 1"
followed by a conditional branch "if var == 0" do something
followed by a conditional branch "if var == 0" do something
Map events you put on parallel process will stop processing when you change map. When you come back to the map it will start from the beginning.
Common events you put on parallel process will restart when you change map. Therefore only using large wait commands is not a good idea if you expect map changes.
This is where variables come since they do not change upon map change.
Here is an example of a common event you can use for waiting a specific amount of frames:
http://img216.imageshack.us/img216/3223 ... apsxu5.png[/img]
This works by waiting 4 frames, then subtracting 4 from the Wait Frames Left variable.
Afterwards we check if there are no wait frames left. In this case we change another switch to signal that the wait is finished. Then we turns the activating switch off (for the common event).
If we change map then we could have a restart after 3 frames wait thus making us wait up to 3 frames more per map change.
You can increase the amount of frames to wait for each subtraction. This will use less resources but increase the potential wait.
If you decrease the amount of frames to wait for each subtraction then it's more resources but a more precise wait. I personally prefer 4 wait, hence my usage.
For this to work you must set the Wait Frames Left variable to the amount of frames you want to wait. (1 second = 20 frames)
Do this before turning the Wait Across Maps switch ON.
You may notice that in this example the wait is separated from what happens after the wait. You can reuse the wait if you want. You can create more common events like this where you only change the switches and variables used.
This will allow you to have several timers running at the same time.
You can also decide to integrate the functionality after the wait into the wait part.
Try to judge what would be the best in your specific situation.
@Beran:
I would advice you to use "if var <= 0" instead of "if var == 0" since it prevents the possibility of a never ending wait. (I.e. an error happened and the variable got below 0)
I would say that using <= instead of == is a more robust solution.
*hugs*
- Zeriab
Common events you put on parallel process will restart when you change map. Therefore only using large wait commands is not a good idea if you expect map changes.
This is where variables come since they do not change upon map change.
Here is an example of a common event you can use for waiting a specific amount of frames:
http://img216.imageshack.us/img216/3223 ... apsxu5.png[/img]
This works by waiting 4 frames, then subtracting 4 from the Wait Frames Left variable.
Afterwards we check if there are no wait frames left. In this case we change another switch to signal that the wait is finished. Then we turns the activating switch off (for the common event).
If we change map then we could have a restart after 3 frames wait thus making us wait up to 3 frames more per map change.
You can increase the amount of frames to wait for each subtraction. This will use less resources but increase the potential wait.
If you decrease the amount of frames to wait for each subtraction then it's more resources but a more precise wait. I personally prefer 4 wait, hence my usage.
For this to work you must set the Wait Frames Left variable to the amount of frames you want to wait. (1 second = 20 frames)
Do this before turning the Wait Across Maps switch ON.
You may notice that in this example the wait is separated from what happens after the wait. You can reuse the wait if you want. You can create more common events like this where you only change the switches and variables used.
This will allow you to have several timers running at the same time.
You can also decide to integrate the functionality after the wait into the wait part.
Try to judge what would be the best in your specific situation.
@Beran:
I would advice you to use "if var <= 0" instead of "if var == 0" since it prevents the possibility of a never ending wait. (I.e. an error happened and the variable got below 0)
I would say that using <= instead of == is a more robust solution.
*hugs*
- Zeriab
thanks a ton : )
-
ive been through the variable tutorials that i can find here and on other forums, but im still having a tad bit of trouble interpretating this. so im going to explain what each line means to me. could you tell me if i have it right?
sigh, this reminds me of math in highschool : P
line 1 - Wait 4 frames - waits 4 frames, i get that
line 2 - Control Variables: [0001: Wait Frames Left] -=4 - attaches a number (the 4 frames) to the 0001 variable
line 3 - COnditional Branch: Variable [0002:Wait Frames Left] <=0 this one tells the game what to do when the wait is up
line 4 - Control Switches: [0002: Wait Finished] = on - allows the regular event to continue when the condition is turned on
line 5 - Control Switches: [0001: Wait Across Map] =off - this turns off the switch so it dosnt loop, i get that
is that a correct way to interpretate that?
-
ive been through the variable tutorials that i can find here and on other forums, but im still having a tad bit of trouble interpretating this. so im going to explain what each line means to me. could you tell me if i have it right?
sigh, this reminds me of math in highschool : P
line 1 - Wait 4 frames - waits 4 frames, i get that
line 2 - Control Variables: [0001: Wait Frames Left] -=4 - attaches a number (the 4 frames) to the 0001 variable
line 3 - COnditional Branch: Variable [0002:Wait Frames Left] <=0 this one tells the game what to do when the wait is up
line 4 - Control Switches: [0002: Wait Finished] = on - allows the regular event to continue when the condition is turned on
line 5 - Control Switches: [0001: Wait Across Map] =off - this turns off the switch so it dosnt loop, i get that
is that a correct way to interpretate that?
That's pretty much correct, though the way you phrased your interpretation of line 2 is a little off
The control variable doesn't really "attach" the number to the variable, but rather subtracts the amount waited from it. The variable needs to have a number attached to it before, or when, the wait begins
The control variable doesn't really "attach" the number to the variable, but rather subtracts the amount waited from it. The variable needs to have a number attached to it before, or when, the wait begins
it should be attached to the variable when you start the wait, so that it knows how long to wait.
i.e.
@>Control Variables:[0001:Wait Left] = 400
@>Control Switches:[0001:Wait Across Maps] = ON
That would initiate your wait event and have it last 400 frames
Also, if you've previously used Zeriab's little system, you might also want to turn the "Wait Finished" switch OFF again.
i.e.
@>Control Variables:[0001:Wait Left] = 400
@>Control Switches:[0001:Wait Across Maps] = ON
That would initiate your wait event and have it last 400 frames
Also, if you've previously used Zeriab's little system, you might also want to turn the "Wait Finished" switch OFF again.