Help with common event: Bell striking the hour in a Day/Night system

[GumpOtaku]

Hello all, I have just done a day/night system. I intended to have a bell strike the hour, so I prepped the SE into a common event and set it to parallel. It works, but I just can't get it to stop. I have enclosed a snap of the event logic so you can help me out.

 

[xabileug]

because you placed 6 or more. make it just equal to 6 and the minutes to 0.
if its parallel, then it runs on the map. you could just make the condition dong dong switch on, then switch it off

 

[GumpOtaku]

because you placed 6 or more. make it just equal to 6 and the minutes to 0.
if its parallel, then it runs on the map. you could just make the condition dong dong switch on, then switch it off

Can you provide me with the event logic of your solution?

 

[GumpOtaku]

Can you provide me with the event logic of your solution?

Please disregard, I discovered the logic. Thanks for your help. I have enclosed a screenshot of the logic in the hopes that it would help somebody.

 

[GumpOtaku]

because you placed 6 or more. make it just equal to 6 and the minutes to 0.
if its parallel, then it runs on the map. you could just make the condition dong dong switch on, then switch it off

Two more questions: would logic like this work, and do I copy and paste for every hour, or just three times (6am, noon, and 6pm)?

 

[Andar]

several things.

first, I would split the event into two. One is a common event with the bell tone only, trigger=none, that is called when the sound is required - because you'll have to call that multiple times and don't want to copy the entire play se/wait sequence every time.

then you need one conditional branch for each hour where you want to call that sound
basically
if hours = 6 call bell
if hours = 7 call bell
if hours = 8 call bell

and so on (with other conditional branches for any other checks required).

and if you have your time evented (as indicated by your first common event name), then you might want to include those checks in that event as well - it will make the logic a bit more complex, but reduce the additional lag from running two parallel events for similar functions.

 

[GumpOtaku]

several things.

first, I would split the event into two. One is a common event with the bell tone only, trigger=none, that is called when the sound is required - because you'll have to call that multiple times and don't want to copy the entire play se/wait sequence every time.

then you need one conditional branch for each hour where you want to call that sound
basically
if hours = 6 call bell
if hours = 7 call bell
if hours = 8 call bell

and so on (with other conditional branches for any other checks required).

and if you have your time evented (as indicated by your first common event name), then you might want to include those checks in that event as well - it will make the logic a bit more complex, but reduce the additional lag from running two parallel events for similar functions.

This is the logic for the time system. is this what you mean?

 

[Andar]

yes.

you should consider adding a wait(9) and changing the condition of the time count to >60 instead of >600
the wait would skip nine frames of time, resulting in one tick every ten frames instead of one tick every frame - that reduces the lag while still having the same timecount.

and then inside the conditional branch where you set minutes to zero and count up hours, you check for the hours=6 to call the bell - at that place you don't have to check for minutes as that is already done, and only have to check for the bell switch and what hour it is (after counting up the hour)

 

[GumpOtaku]

yes.

you should consider adding a wait(9) and changing the condition of the time count to >60 instead of >600
the wait would skip nine frames of time, resulting in one tick every ten frames instead of one tick every frame - that reduces the lag while still having the same timecount.

and then inside the conditional branch where you set minutes to zero and count up hours, you check for the hours=6 to call the bell - at that place you don't have to check for minutes as that is already done, and only have to check for the bell switch and what hour it is (after counting up the hour)

A 120 frame wait is in the common event which calls for the bell.

 

[ATT_Turan]

A 120 frame wait is in the common event which calls for the bell.

That has no effect on your parallel process in post 7 (which is the point of parallel processes, they don't stop for other events).
Unless you put wait commands in that process, it's getting evaluated by the engine every frame, which is unnecessary and can contribute to the overall performance/lag of your game.

 

[GumpOtaku]

That has no effect on your parallel process in post 7 (which is the point of parallel processes, they don't stop for other events).
Unless you put wait commands in that process, it's getting evaluated by the engine every frame, which is unnecessary and can contribute to the overall performance/lag of your game.

wait commands in where? the common event which calls for the bell or somewhere else? if it is the latter, then where in the time system common event?

 

[ATT_Turan]

wait commands in where? the common event which calls for the bell or somewhere else? if it is the latter, then where in the time system common event?

...exactly as Andar described in post 8. Change the number in your conditional to a lower value and put a wait command at the bottom.

 

[GumpOtaku]

...exactly as Andar described in post 8. Change the number in your conditional to a lower value and put a wait command at the bottom.

...like this?

 

[ATT_Turan]

Whatever you tried to link there isn't working. Try attaching it to the post.

 

[GumpOtaku]

Whatever you tried to link there isn't working. Try attaching it to the post.

my bad...

 

[Andar]

wrong place for the wait - the wait has to be on the same level as the control variable for the count, for example as the first command in the event, above all other commands.

at this moment it is inside the count > 60 branch, which means that the branch is only executing the wait once per count - to get the same time as with your previous count of 600, the wait needs to be before the conditional

 

[GumpOtaku]

wrong place for the wait - the wait has to be on the same level as the control variable for the count, for example as the first command in the event, above all other commands.

at this moment it is inside the count > 60 branch, which means that the branch is only executing the wait once per count - to get the same time as with your previous count of 600, the wait needs to be before the conditional

done.