World Editor Bug

Wondering if anyone else has encountered this bug:

When in the trigger editor, creating two arrays of size 8192 caused all of my triggers to stop working. As if they didn't exist. When I removed the second array my triggers worked again.

I also tried changing the second array to size 8000 which made the triggers work again. But when I added a third array of 8000 they stopped working.

Does the world editor have a limited memory space in which to assign variables when you use Test Run?

Biggest bug in WE is actually the lack of the ability to explain things correctly.

Like giving the name "regions" to "rects"

Or calling GUI "Triggers"

Or for example giving the name size to what should really be "total indexes to be initialized"

All arrays have the size 8192.

If you set "size" in the variable editor you just tell the editor to add a script that will put default values for (size) indexes of the array.

Of course, if you initialize 2 arrays to the big size 8192, and there are other arrays/ things in the main init thread. The thread will crash because of lame limit eventually.

If the thread crashes it cannot get to the moment where it initializes the triggers, the triggers don't exist - they don't work.

The solution is to leave a 1 as size there.

If you really need the arrays to be initialized to 8192 indexes. Then just initialize the arrays manually in a trigger that has "map initialization" as event.

there it 33333 (lol number) loop limit, there is max number of actions per function, it very hard to met...

That 'loop' limit number is wrong (it depends what you are doing in the loop) and the limit is not at all hard to meet.

this limit for a empty loop.
if loot have no "exitwhen" if will be 47k

but it really hard to meet inside triggers.
only massive function can reach it

erm... no. You reach it quite easily. As said, initializing 2 8192 arrays can even do it.

Im wondering, how did you get the number of times a loop looped if there's nothing inside.

Increment global, endloop, no exitwhen, read off count when thread dies. With absolutely nothing inside the limit is 300k, but from within JASS obviously you can only infer that.

for further reading, bits and pieces of the VM are documented here.

This bug is rather easy to explain, it's more in the game engine than in the WE. Variable initialization runs before triggers are registered. And with that many assignments you hit the call limit and crash the initialization thread before triggers are even registered.
This is also the reason why preplaced doodads, unlike units, are not placed via the jass script but directly from the .doo file.