Timers produce wired errors and also some FUZE crashes
-
@ITzTravelInTime
Hi I have just tried your code from Twitter and confirm that it crashesHowever if you add a main program loop it doesn't:
timer = settimer(1 / 30, 1, sched()) loop update() repeat function sched() clear() update() print("test") update() stoptimer(timer) timer = settimer(1 / 30, 1, sched()) return voidIs there a reason that you are redefining the timer in the callback function?
-
@pianofire i use my main loop in a function called after initializing the timer and it still crashes or throws some wired errors
-
@pianofire the reason for the redefinins is that fuze don't allows for timers with unlimited repetitions
-
-
to avoid the bug all together i just use an insanely high number of repetitions for the timer call, so it should last long enought even for the longest game sessions, and so i avoid resetting the timer all together and so i can just perform a normal timer call at the start of the game's execution, that's the best way of workaround the issue for now, until we don't have an official way of resetting the timer after it runs out of repetitions or they add an endless repetitions timer
-
@ITzTravelInTime Why not just use -1 for unlimited repetitions?
-
@_JKDOS Is that a thing? the documentation doesn't mention it
-
I'm also getting alot of errors while timers are running. Shorter the interval the more likely I am to get an error. The -1 is a neat trick though. Wish I knew that yesterday
-
I've come across some odd behavior with the timer as well. I was attempting to utilize the timer for MML playback for purposes of higher-precision playback rather than once every frame (though I have it set to 1/60 just to keep it in time with the typical approach). I would store the handle for the set timer in my MML structure, but when doing this in certain spots within my initialization function or some other functions relevant to loading/playing provided MML data, I get an error regarding the function used for the timer callback about an "incorrect number of parameters for function", even though the callback function has no parameters. Other functions seem to have no issue, including when done globally (even when still assigning it to this structure). Here's the thing. The line number in the error message is ludicrous. Just now, it says the error lies on line 1848996251. Yep, almost line 2 billion. My code is barely 1,000 lines long. Sometimes, depending on where I place it, the line number will be just as bad in the opposite direction, with it being negative. It'll even crash the program when the line is move close to either the beginning or end of a function.
-
@Discostew I sometimes get the parameter error also with timers and the error report just seems to be random line number and error
-
@sys64738 said in Timers produce wired errors and also some FUZE crashes:
@Discostew I sometimes get the parameter error also with timers and the error report just seems to be random line number and error
The same thing happened to me, but this -1 solution has actually saved me
-
Hang tight, we're aware of some issues involving timers and we're working to address them in a coming patch.
In the meantime, you can work around the FUZE language timers by writing your own timers manually:
some_timer = 0 // initial timer value some_timer_max = 2 // the interval in seconds you want your timer to run at // your game loop loop some_timer += deltaTime() // keep track of passing time for your timer if some_timer >= some_timer_max then some_timer -= some_timer_max someFunction() // run whatever function you like! endif repeat -
@Willpowered Thank you, but for what reguards the programs i am working on i need timers because with those i can have consistent controls reguardless of the framerate and the use of the -1 for the repetition times fixed this to me, you should really put more info in the documentation
-
@ITzTravelInTime Same here with consistency. For my MML player, I want to give users of it 2 options. One without timers, and one with. With timers, they not only benefit from higher resolution timing for more accurate playback, but by having it on a timer, it won't stop or glitch if they have to process a lot of stuff in the main loop in one go because, unless I'm mistaken, it would/should interrupt what's being processed to process that stuff from that timer. Of course without timers, they wouldn't need to use a timer at all, allowing them to use it for other purposes.
