Problem with time progression event

[Llov11]

Hi! Sorry to bother with this question, but I'm having trouble with a common event I've been working with, so any help is welcome.

First of all, I know there are scripts that achieves this very easily but I really love eventing.

Having said that, this is my time progression system:

First common event takes care of advancing time 10 minutes every 12,5 seconds. This way an ingame day would take half a real hour. (Changed it to 30 or 60 frames when testing)


Second common event is the one that makes the hours go by. Every 6 iterations of the first common event an hour is added in the variable "hours" and the variable "minutes" is set to 0. Also when the variable "hours" reaches 24, it's set to 0.


The third event is the one that divides the time in ranges, which allows events to behave differently in different moments of the day.


Now the problem I'm experimenting is really weird, because It's kind of random. Time goes by smoothly most of the time but at some point, which I can't seem to reproduce, when the variable minutes reaches 6, instead of turning automatically to 0 (second Common Event) it keeps going up.

I would really apreciate your help with this one because I feel I'm really close to getting it to work consistently.

Thank you!

PS: Sorry for all the spanish, but I guess it's still understandable. Besides, it's never too late to learn some ESPAÑOL.

 

[Andar]

One problem with the way you're doing it is that any map change resets all common events.
The result is that the wait(750) is restarted when that happens.
The solution is to use smaller waits and count a variable up for the time - the maximum frames lost by a reset will be the number in the wait, and 750 is a bit much in my opinion, better would be to use a wait(75) and count up a variable for ten of them.


The second problem is that you split your time control over different parallel processes. That is known to createtiming problems.
you should combine them into a single common event, checking the values each time after the counter goes up with the waits.


Third problem is that your counter conditions are a bit convoluted. Your direct problem will probably go away as soon as all three parts are in a single common event, but you should streamline the conditions as well. For example you don't need to check both limits (upper and lower) if you order them correctly - if everything is ordered correctly you only need to check for the upper limit.

 

[Llov11]

One problem with the way you're doing it is that any map change resets all common events.
The result is that the wait(750) is restarted when that happens.
The solution is to use smaller waits and count a variable up for the time - the maximum frames lost by a reset will be the number in the wait, and 750 is a bit much in my opinion, better would be to use a wait(75) and count up a variable for ten of them.


The second problem is that you split your time control over different parallel processes. That is known to createtiming problems.
you should combine them into a single common event, checking the values each time after the counter goes up with the waits.


Third problem is that your counter conditions are a bit convoluted. Your direct problem will probably go away as soon as all three parts are in a single common event, but you should streamline the conditions as well. For example you don't need to check both limits (upper and lower) if you order them correctly - if everything is ordered correctly you only need to check for the upper limit.

Thank you so much for your answer!

Yes, the time progress loss when changing map is something that I was planning on improving.

Do you think that by the way it's written, just cutting and pasting the content of the second common event after the last line of the first one should do the trick? I was worried that the larger the event, the longer it would take to run, thus messing up the timer functioning. But I guess it's still fractions of seconds for a machine.

And for the counter conditions, as I get the fact that they unnecessarily check both limits, I also guess it shouldn't make any difference as long as they are not contradictory, right? I'll try to optimize that bit.

Again, thank you so much for your help!

 

[Andar]

yes, more commands inside an event will take more processing there - but the more different events you have on parallel, the more complex the work on the main game loop becomes. And that is much worse, you should always aim for the lowest number of parallel processes where possible.

copy&paste might work, but it would result in a rather convoluted event. Especially the conditions of the second and third event can cause problems if their order goes wrong, so it's better to combine the logic instead of only appending it.

 

[Llov11]

yes, more commands inside an event will take more processing there - but the more different events you have on parallel, the more complex the work on the main game loop becomes. And that is much worse, you should always aim for the lowest number of parallel processes where possible.

copy&paste might work, but it would result in a rather convoluted event. Especially the conditions of the second and third event can cause problems if their order goes wrong, so it's better to combine the logic instead of only appending it.

Allright, I did what you sugested and worked like a charm.

The final event looks like this:


I didn't improve the time progress loss when changing maps yet, but it's working perfectly asi it is so thank you very very much for your help!

If you see something that could be improved (besides the before mentioned) I would be very glad to hear it!

 

[Llov11]

And this is how I improved Time progression loss.. Maybe there is a better way to do so

Replaced the first two lines with this: