SC2 BETA Editor findings

[Xenon]

It looks like initializing too many globals can kill the init script and ruin all the map's triggers (which is what Ricky ran into). The actual limit is about 524000, about twice the amount that kill the init thread.

I also got the editor to return an ominous "script too large" error while making a second array to test the memory allocation limit. I have no idea what causes this, or if my actual project is at risk of it.

Also, unit custom values are limited to indices 0-63. They do not appear to be lumped in with the globals in the 524000 limit. (4500*64 unit values in addition to the max amount of globals without killing triggers never stopped working.)

[Ricky_Honejasi]

You can get that "script too large" error even if your script is quite small since it considers all your array variables' taken space into account (that dreaded 1 or 2 MB limit, still not 100% sure if it's 1 or 2 exactly since it seems I have issues when it's 1 MB theoretically).

As a remainder, here's what you can do to have an idea on how close you are to hit that limit (more precisely the one that plain ignores all your triggers) :

1) The highest I could get is 65*65*65 ( =  274625) via a 3D array Integer variable (taking 4 bytes each Integer) without ruining anything yet with a near-blank script.
2) Then try similar numbers (ex : 60*60*60, 55*55*55, etc.) until your script isn't ignored in-game.
3) Use the Windows calculator or anything then multiply all those 3 numbers together.
4) Divise it by 274625 then multiply by 100 so you got an idea how in % you got left.

In my case, it only worked for me for a 3D array of 45*45*45 ( = 91125) before. Thus 91125 / 274625 * 100 = 33.18% of juice left (approximate) when I first tried.

Although now, I did it again and I could only with a 40*40*40 for = 64000 for ultimately 23.30% left (approximately again) after more modifications. Ungodly annoying limit.

[IskatuMesk]

Nice. You'll never be able to script anything significant in this game unless they change that.

I'm curious if you can use libraries to bypass that, though?

[Mr.]

Okay, this is strange.  Why is it that SC2 decides that 0.1 REALLY means 0.100098?  I mean, I guess it's not very consequential, but still, I find it very odd.  Is there a reason for this?

Also, If you use the "Move Unit Instantly" action, and put in a value for "offset by x height," it doesn't seem to do anything at all.  Awesome.  Unless, is that only for air units, or something?  I guess I could test that.  If I can wade through the data editor to try to make this unit fly.

[Xenon]

It should be 2 MB where each integer is equivalent to 4 bytes, so ca. 524000. The init operation limit appears to cut it short, however. I don't think there's currently a way to prevent it from initializining the variables during map init to do it later instead.

I suspect the "script too large" might have been intended to warn that the map init had too many operations and that the game would kill the thread, but their numbers were off and it doesn't give the error when it should.

Mr. > The game uses "fixed" reals, which in this case is an integer/4096. It approximates .1 with 410/4096, or 0.100097656. Some coders have complained of lack of precision while doing things like unit vectors (since that often involves squaring numbers less than 1).

[Mr.]

Thank you, Q.

Also, it seems that even if it's flying, it still doesn't make a difference.  Although setting it to flying helped with something else I wanted to do, but then broke another thing.  aosidgnaisogd

[Ricky_Honejasi]

Nice. You'll never be able to script anything significant in this game unless they change that.

I'm curious if you can use libraries to bypass that, though?

Possibly but probably not since the true issue is not the script size but having more variable space. For big triggering projects, you easily need more space in variables than your script.

Even in a best case scenario, the best it might do is just saving like 5-15% of that limit that can be quickly filled by the next big set of variables.

If I desperately need more space, Q's trick with unit's custom values is more likely to work despite all the weird triggering required to pull it off.

Unfortunately, even then, it would only save space off variables of Integer type (not unit-type, not research-type, not unit groups, etc. etc.). On top of it, I remember HKS saying that having more or less 1600+ units per player would prevent unit control of exceeding units + new ones until it drop back below the limit.

At least I got just enough to finish the bare minimum of my project and ill rather prefer that they increase the trigger limit in release (if I do buy SC2 at that point).

EDIT : Actually they need to raise it on Beta Phase 2.

[Xenon]

Oh, Mr., I just figured out what you said. Moving a unit to a point does not consider the height of the point. You have to change the height with another function.

Ricky> It's not so much a "trick" in my case, since many of my stored values are related to specific units anyway.

Edit: Does the KB size of the script actually matter? I think the 2MB limit is only for variables, and the "script too large" error is kind of vague.

[Mr.]

Oh, Mr., I just figured out what you said. Moving a unit to a point does not consider the height of the point. You have to change the height with another function.

I see...

Hm... Hmmmmmmmmmmmmmmmm...

I would like to get very particular with the Z axis.  Is there a way to set a unit's height relative to the Z axis, and NOT the height of the terrain?  And is there a way that you can determine where the height of the terrain falls on the Z axis?  I'm thinking that there is, because if I recall correctly, Mad Balls Arena in WC3 had ball physics where they would bounce off of walls if they were below the height of the wall?  I think? 

Maybe I'll see if I can find that map, and if it's not protected, see if I can find out anything by looking in the WC3 editor.

EDIT:  Nope, protected.

EDIT:  I thought I found what I was looking for, then I secretly didn't.

EDIT:  OKAY!  Figured out how to get the height of the ground, now to figure out how to set the height of the unit relative to that.  Which would actually be very easy right now, except since I've made the unit FLYING, it gradually increases its height as it approaches a cliff.  So now I either have to figure out a way around that, which would be wonderful, or make it ground, which would create another problem I would need to fix...

[IskatuMesk]

Mundane, arbitrary limits are the bane of men.

[Xenon]

Try giving it a modified Fly mover that uses the ground heightmap.

[Mr.]

I made it a ground mover with flying collision and that magically made it do what I wanted to.  Excellent!

[Master Jademus Sreg]

If you want to prevent the completely unnecessary array initialization, declare the variable in a section of custom script.

[WB]

Mundane, arbitrary limits are the bane of men.

Ever think that it just appears arbitrary to you because you don't know the reasoning behind it?

[UntamedLoli]

Yeah they want to hold everyones hand around the engine so they can't lag everyone with a slower computer, I'd like to see the reasoning behind limiting cliff heights.

The AI's performance also takes a nose dive if theres a cloaked unit around a large amount of units that can't see or attack it and by nose dive I mean 2-3 fps.

Every step forwards they are just taking more steps backwards.