The OOOOO map protection?

I was taking the liberty of hacking someones map (the reasons being for a little personal learning exercise, not breaking the protection and changing stuff) and noticed that the JASS script had been obfuscated by making all the variable names strings of O's, of varying length, making the thing barely readable and very hard to use a "replace" function to make the variables names more readable.

But this ALSO ballooned the JASS script to an uncompressed size of over 3 mb. Granted, all the O's compressed well so the script was a accebtable ~67K in the w3x, but heres my question: Do all the obscenely long variable names and sheer weight of the script file reduce performance? In other words, is the script compiled when the map is loaded, or interpreted at run time?

Empirical evidence seems to suggest that this map (which uses A LOT of complex triggers) is indeed running quite a bit laggier since the change in protection, there doesn't seem to be any feature upgrade to account for the increased lag. If the large script file is indeed a possible cause of lag then I'll have to take it up with the mapmaker.

What map are you talking about?

notice if he says it, he'll be crucified across the boards...

Come on, someones gotta know something about this. Is a 60fold increase in script size (but not complexity) going to increase lag?

I don't think that the game cares about how long the name of the variables are and how they are written.
It MIGHT slightly increase lag but not noticable.
I'm not sure

that should be a dumb obfuscation method, ExtProtect and HeavyLock use other kinds, ExtProtect changes the names to the smallest possible, and HeavyLock's are always six characters long I think

Anyways, the script is compiled when the game is loaded, proof to this is that a syntax error in the map script makes the map unloadable

Uh, that alone doesn't constitute proof, a map cannot be saved (normally) if it has syntax errors, but that just means it's checked for syntax errors. Same could hold for when it's loaded in WC3.

Ok, then another proof is that it doesn't run incredibily slow.

Okay lets explain. The uncompressed and unobfuscated script (from an ealier version of the map using protection but no obfuscation) is ~300k - compressed in the MPQ it's 43k. Once obfuscated the script is ~4mb, now if you know anything about compression you'll know strings of a single character compress VERY well, so in fact it compresses to 67k, which is not much larger than the unobfuscated script.

Here obviously is the justifaction for the long strings of O obfuscation:
A) It compresses very well, so the MPQ itself will be not significantly larger despite the script being MUCH larger.
B) It is incredibly hard to read, not least because the long name make a single line several hundred characters wide.
C) It is hard to use a simple search-replace method to make the obfuscated script more readable, because most variable names are a substring of a longer name, you need to use a proper script parser or atleast regular expressions to do search/replace - if I really cared I would just make it replace every variable with a O followed by the number of O's - as a number. (ie O56, O121)

As I reveal in this thread long strings do indeed impair perforance, the creator of this obfuscation method either didn't know or didn't care. It probably wouldn't matter anyway if the map doesn't need to do any number crunching. (ie 98% of maps out there)

Come on, you've done programming in "real" languages right? Does a simple for loop, like:
Take a significant amount of time to run? hell no, in c or something it runs in milliseconds or a fraction of a millisecond. In JASS the equivilant would take a whole second. If thats not incredibly slow, I dont know what is....

The other day AIAndy was sure JASS were converted to some JASS2 language on loading, but if what you say is right then it isn't , And those are good news cause a protection like extprotect that uses the smallest names possible will actually improve performance too.

Such a large loop will reach the limit very fast and of course run long due to the forced waits.
I am pretty sure that JASS is compiled when the map is loaded and then those long variables only affect the run time of the lexer. Of course such long variable names might cause strange effects there.
Not compiling the script at the start of the map would be stupid as JASS is a language that is easily compiled and executing the compiled code is much faster. Since script errors are recognized at the start of the map the code is definitely parsed there and why would you discard the result of that work and do it again later.

Actually, I've been thinking and if JASS wasn't compilied, there would be a way to pass jass commands in game, just a theory.

But If long variable names make the game slower, I don't really know what is happening.

I think we should really ask blizzard about this.

Edit: http://www.battle.net/forums/war3/th...hreadID=151480

Regarding compiled or not compiled, the only thing that can be said for sure is that the variable names are kept intact.