is it correct that the "execution took to long" error accures, if one trigger in itself including all custom function- and action calls takes to long to execute?
just that i get i right.
Pretty sure from what I understand that will indeed create a fork to a new thread but that's kinda ignoring the underlying thing this error is trying to tell you which is the trigger's activities could likely be done in a better way that's more optimized for the engine. Definitely something to look at on a case by case basis though.
Just don't make infinite loops, even with wait time. If you do, your design is flawed. Check if your while loops can always end (variable just to count number of loops in and modify it +1 every loop).
i don't have endless loops, but a function with many for-loops wich I can't leave. so adding waits could maybe solve that error?
hmmm, let's test is out... :)
The generic for-loop built into the galaxy editor is notorious for being a very badly optimized function, I'd highly recommend changing the logic to use while loops instead that cycle the data instead. Believe me I'd been using two giant for loops in a function when they hit that dreaded error and by merely shifting to using while loops that do the same thing it cut the CPU time needed to 25% of the for-loop version.
Its the way the game detect infinite loop and destroy it. Usually happen when you loop too much, nested loop, around 300 000 calculation/function in a single loop run. Either optimize your loop, or adding wait if you can
I'm pretty sure its literally the CPU time needed to complete a thread that triggers the error, as I posted above I didn't change the amount of calculations each run was doing but by shifting the method of looping to whiles instead of fors it reduced it down to under .5 seconds (which I'm thinking is the threshold) and it didn't complain after that. Unless for loops count as more calculations then while loops going through the same data, which could be entirely possible. I'd also met another instance of that when a single trigger was handling a whole pile of these sorts of things in a row (not nested, just happening consecutively) and just by splitting them up to different threads it stopped complaining then too.
hello guys,
is it correct that the "execution took to long" error accures, if one trigger in itself including all custom function- and action calls takes to long to execute? just that i get i right.
@Mille25: Go
it means basically too much in one thread is happening at once, like if you make an infinite loop with no wait time, it will just give you that error
@LinkD: Go
so if you add a wait, this ould not occure?
@Thenarden: Go
Pretty sure from what I understand that will indeed create a fork to a new thread but that's kinda ignoring the underlying thing this error is trying to tell you which is the trigger's activities could likely be done in a better way that's more optimized for the engine. Definitely something to look at on a case by case basis though.
Just don't make infinite loops, even with wait time. If you do, your design is flawed. Check if your while loops can always end (variable just to count number of loops in and modify it +1 every loop).
@uiasdnmb: Go
i don't have endless loops, but a function with many for-loops wich I can't leave. so adding waits could maybe solve that error?
hmmm, let's test is out... :)
@Thenarden: Go
The generic for-loop built into the galaxy editor is notorious for being a very badly optimized function, I'd highly recommend changing the logic to use while loops instead that cycle the data instead. Believe me I'd been using two giant for loops in a function when they hit that dreaded error and by merely shifting to using while loops that do the same thing it cut the CPU time needed to 25% of the for-loop version.
Its the way the game detect infinite loop and destroy it. Usually happen when you loop too much, nested loop, around 300 000 calculation/function in a single loop run. Either optimize your loop, or adding wait if you can
@progammer: Go
I'm pretty sure its literally the CPU time needed to complete a thread that triggers the error, as I posted above I didn't change the amount of calculations each run was doing but by shifting the method of looping to whiles instead of fors it reduced it down to under .5 seconds (which I'm thinking is the threshold) and it didn't complain after that. Unless for loops count as more calculations then while loops going through the same data, which could be entirely possible. I'd also met another instance of that when a single trigger was handling a whole pile of these sorts of things in a row (not nested, just happening consecutively) and just by splitting them up to different threads it stopped complaining then too.