Yeah.. as I think about it, Hooville shouldn't really be the cause of it. Like Levi and I were talking, "real" DLL code is only executing during game initialization. (Yes, it calls AIProc every cycle, but there's no tangible code inside AIProc besides the "RET" in most multi missions).
I thought, perhaps the internal limits of OP2 are being overrun. for example, OP2 has a limit of 256 ScStubs. Those are divided into smaller divisions, being maxes of 128 Triggers, and 128 Fight/Build/MiningGroups. If this internal limit is passed, OP2 will crash.
However in a typical LoS multiplayer mission this shouldn't be an issue at all. (There are no Groups, and only 1 Trigger). I doubt Hooville has a bug of creating groups/triggers randomly (this problem would manifest itself a lot more visibly).
(Oh, btw, I think that's why CTF crashes all the time... It doesn't destroy old triggers, just creates new ones on top of the existing ones. This in itself is a note to developers: If you create a one-shot (non repeating trigger, 2nd param is FALSE), and create more triggers during the course of the game, save the created instance in a global trigger variable. That way, at the beginning of the trigger proc, you can call .Destroy() on that trigger. A "delete var;" will not deallocate the trigger, only Destroy() will. After that you can re-use the variable. OP2 has no garbage collection on game objects, so you have to do that yourself by destroying unneeded triggers/groups).
Joe, what do you mean by it causing a loop and 100% CPU usage? If it crashed that wouldn't seem likely.
Hmm! I just had a thought, maybe the fault lies within the small runtime library we're using in the 2nd version of the SDK, named LIBCTINY.LIB.
I'm not certain whether this is the case, but this runtime might not be thread-safe. If it's not thread safe, it has the potential to crash the program. (However, I don't see why it would, again since no code is running from the DLL or static runtime library).
I'd encourage people to try something with their projects, compiling with the normal runtime to see if their project still crashes.
To do this, open your SDK2 based project in MSVC and do the following:
Go to Project > Settings. In this dialog click the "OP2Script" (root node of the tree on the left) to select the whole project. On the right go to the "Link" tab. In the "Category" dropdown choose "Input".
In the box labeled "Object/library modules" remove any reference to ..\lib\libctiny.lib or similar.
In the "Ignore libraries" box remove "libcmt.lib".
Press OK. Go in the menu to Build > Clean, then rebuild your project.
The DLL should now be about 30 KB larger. If this doesn't fix the problems, then the runtime library isn't the issue.
