Changing or circumventing max number of instructions per game loop

[VDOgamez]

The code I'm running right now for a level has an adjustable parameter of how in depth the calculations it does will be. Computational complexity increases exponentially with that parameter. At low levels (1-4) the code executes perfectly and instantly, so I know there are no bugs causing this. At values of 5 or higher, though, I get the error of "WARNING: Exceeded max number of instructions(1000000) per game loop". I'm fine with a single gameplay step taking significantly longer than normal for the purposes of this level, so is there any way that I can tell the engine to disable or extend this limit? I think I've worked out while typing this a way to get around this by saving my position in the execution, but I'd like to see if there's a better way first.

To be fair to the engine, I doubt that what I'm trying to do with this level is something that would occur if I weren't making a rather silly gimmicky level. The offending code is a minimax game state tree search algorithm, because I was trying to see how far from the standard gameplay I could get in the level editor and implement a board game.

[Karsten75]

The limit is hardcoded in the game and cannot be bypassed or circumvented except by altering the code.

[VDOgamez]

All right, thanks. I guess I'll get to the workaround, then.

[knucracker]

Yeah, the max op limit is hard coded.  To do more than that, you have to split execution across game updates (like I think you are talking about doing).  Do a bunch of stuff, then exit.  Next time around continue.

[Lost in Nowhere]

You could also split it between multiple cores, but that leads to issues of getting them to work together correctly.

[planetfall]

Is the limit per core, or per script per core? If it's the latter, you could just put the same script multiple times on the same core, and then have them work on a series of variables stored in a different script.

[Lost in Nowhere]

...I don't know the answer to that. Time for experimentation!

Doing a quick test, it appears that the limit is handled individually per script.

[Grayzzur]

The catch there is I don't think you can guarantee which order the scripts on one core or the scripts from two separate cores run in.

[Lost in Nowhere]

Yes, that would cause some issues...
Depending on what you're doing, though, that may not matter anyways.
If it does matter, you are either stuck with a system that would effectively be the same as using a delay, or using some convoluted system to determine which core executes first; pretty simple with only two cores, but becoming markedly more difficult as the number increases.

[Karsten75]

The catch there is I don't think you can guarantee which order the scripts on one core or the scripts from two separate cores run in.

Perhaps this is something Virgil can formalize.

[Annonymus]

I think there has already been a thread on this (order of execution of different scripts) somewhere in the coder's corner, but I don't remember the answer.

[planetfall]

The catch there is I don't think you can guarantee which order the scripts on one core or the scripts from two separate cores run in.

Really? I thought it executed in the order the scripts appear in the core editor window. Otherwise there would be no reason for the move up and move down buttons.

[J]

I don't know in which order scripts are executed, but V changed it so that the order is now saved in savegames so it won't mess up after saving/loading.

[warren]

Oh crud. Do you know how many instructions it takes to correctly move a beam weapon's field? Apparently just over 1000000. The loop is only width*(range+width)*sqrt2 (twice, once to delete the old field). In the loop, there are about 170 instructions:(calculate distance along beam, distance off centre, mix beam strength parameters, then for both C and AC mix normal and perpendicular force components.)

[Grayzzur]

Have you considered starting a new thread, posting your code, and seeing if someone can help you optimize that loop a bit?