It should be like 4 or 5mb otherwise i will get int robule, i have already like 1.22mb and i have jus tlike 15-30% of my triggers written down and they are compressed as much as possible
There are no real workarounds. At least not at the moment.
What really buffles me how you could reach 1.22 MB of triggers that fast.
I mean, I have a project open right now with 1200 lines of script code, which makes 25 KB.
for you to have 1.22 MB you'd need.. (opens calc).. 60,000 lines of code o0
My largest project ever was about 18,000 lines and I needed 2 years for it.
Again, this is not about file size. It's about memory allocated in the script. Neither of you have anything to worry about.
Ex: int[8] myIntArray; will use approximately 32 bytes of memory, each int being 4 bytes.
And you're using the wrong file size anyways. The "triggers" file has nothing to do with the triggers.
MapScript.galaxy is the real code.
If your processed script code exceeds 2 megabyte it won't work. That's what I've read at least, and afaik they tested it, too.
Quote:
We found out that this limit includes globals, locals (aka. the stack), and compiled galaxy bytecode all together. This is very serious! It means that if you have 1.5 megabyte code in your map (which may happen for bigger projects), you can only have 500 kB globals and stack.
If your processed script code exceeds 2 megabyte it won't work. That's what I've read at least, and afaik they tested it, too. Quote:
We found out that this limit includes globals, locals (aka. the stack), and compiled galaxy bytecode all together. This is very serious! It means that if you have 1.5 megabyte code in your map (which may happen for bigger projects), you can only have 500 kB globals and stack.
Exactly, the processed script code. Compiled bytecode is going to be significantly smaller than the text version. :)
I honestly wouldn't even worry about it unless you're doing a project like a Maze generator or something.
I was able to improve my codings so that i was able to lower it from 1.19mb to 292kb, so the 2mb could be fine for me now.
somehow it were just 2 triggers out of more than 70, i deleted one and redid the other one all other codes are perfect
The 2MB limitation has to do with the addressing space of the Galaxy language, it's not an arbitrary limit, nor is it there for performance reasons. Pointers in Galaxy have 11 bits reserved (presumably for type tagging) leaving only 21 bits for addressing which gives you an address space of 2MB.
To put the memory limit into perspective, we have 2^21 bytes of memory available for our use. That's 2,097,152 bytes. Assuming that an int is 4 bytes (usually is), we can have 524,288 ints stored at once in our triggers, before we hit the limit.
So unless you're doing very stupid things like int[1000][500] you almost assuredly will never hit this limit in normal practice.
It should be like 4 or 5mb otherwise i will get int robule, i have already like 1.22mb and i have jus tlike 15-30% of my triggers written down and they are compressed as much as possible
@BeLugh: Go Memory allocation, not file size...
@BeLugh: Go
yeah odds are you will not hit this. but yeah it should be more because i know this will be a problem for me.
I really need to have 4-6mb for that out of the 10,5mb allowed for a single map otherwise i cant finish my project
Edit: OR a workaround to add more content
There are no real workarounds. At least not at the moment.
What really buffles me how you could reach 1.22 MB of triggers that fast.
I mean, I have a project open right now with 1200 lines of script code, which makes 25 KB.
for you to have 1.22 MB you'd need.. (opens calc).. 60,000 lines of code o0
My largest project ever was about 18,000 lines and I needed 2 years for it.
Or are you simply having a million variables?
@s3rius: Go
Again, this is not about file size. It's about memory allocated in the script. Neither of you have anything to worry about.
Ex: int[8] myIntArray; will use approximately 32 bytes of memory, each int being 4 bytes.
And you're using the wrong file size anyways. The "triggers" file has nothing to do with the triggers.
MapScript.galaxy is the real code.
@MotiveMe: Go
If your processed script code exceeds 2 megabyte it won't work. That's what I've read at least, and afaik they tested it, too.
Source: http://www.sc2mod.com/board/index.php?page=Thread&postID=227#post227
Exactly, the processed script code. Compiled bytecode is going to be significantly smaller than the text version. :)
I honestly wouldn't even worry about it unless you're doing a project like a Maze generator or something.
I was able to improve my codings so that i was able to lower it from 1.19mb to 292kb, so the 2mb could be fine for me now. somehow it were just 2 triggers out of more than 70, i deleted one and redid the other one all other codes are perfect
i stick to some simple rules now, like destroying any dialogs i create and stay away from periodic events.
Now that the game's out, does the files' size restrictions of triggers still holds at 2MB? Anyone?
The 2MB limitation has to do with the addressing space of the Galaxy language, it's not an arbitrary limit, nor is it there for performance reasons. Pointers in Galaxy have 11 bits reserved (presumably for type tagging) leaving only 21 bits for addressing which gives you an address space of 2MB.
This is good practise but won't affect in any way the 2meg limit :)
@vjeux: Go
To put the memory limit into perspective, we have 2^21 bytes of memory available for our use. That's 2,097,152 bytes. Assuming that an int is 4 bytes (usually is), we can have 524,288 ints stored at once in our triggers, before we hit the limit.
So unless you're doing very stupid things like int[1000][500] you almost assuredly will never hit this limit in normal practice.
Hmm, just to be sure I'm hearing this correctly - so the 2MB limit for total trigger file size is actually referring to compressed size?
But what about this link here?
http://www.hiveworkshop.com/forums/starcraft-ii-editor-help-zone-647/galaxy-editor-epic-fail-167008/
No the 2MB limit is addressable space by the Galaxy language. It really has nothing to do with file size.
seriously if your triggers manage to break because they take up too much file size your doing something wrong......
@RileyStarcraft: Go
Right, I see now what you mean.
So is there some kind of measure to see how close a map's memory allocation come close to this limit?
You picked the perfect little Avatar, have I mentioned that?