[JASS] Wc3 JASS Myths

Level 31
Joined
Jul 10, 2007
Messages
6,306
Well, after some testing in wc3, I've so far disproven two myths.

Myth Number One: The Thread Limit of Warcraft 3

According to many, the warcraft 3 thread limit is 72. This means that each player gets 6 threads to work off of. This is completely false. The actual thread limit is unlimited.

Myth Number Two: String Leaks

The current accepted fact by JASS veterans is that whenever a string is used, it causes a permanent leak in warcraft 3 that cannot be removed. Even by nulling the string, the leak is not removed. This is due to a mistake on the blizzard developer's end.

This myth is half true. While strings do cause permanent leaks, these leaks are not stored in the game cache, meaning they will not cause your game to lag at all. Instead, they are stored on your computer's cache. These strings will not cause black screens in your map etc. Now, if you do use enough values, wc3 will crash after using about 712 megs of memory. This value was achieved when there was still an incredible amount of room left on the computer system's cache, still more than enough ram and vram, etc.

Now, the common mistake is mis-understanding how wc3 deals with strings. First, you need to understand that wc3 stores all data in an 8k storage area. You can easily see this with arrays (8192 limit). When you go above the limit, data isn't stored and you simply recieve empty variables (.....)

Now when you go above the 8k limit, it'll slow down drastically because the next largest storage area is either 2.12 billion or 2.17 billion for an array. Now don't worry, it won't stay slow. Remember, the strings transfer over to your computer's cache asap, so it'll go back down to 8k.

This doesn't resolve people who use the game cache though. This is completely different. The speed of the game cache is not a resultant of string usage, it's a resultant of using the game cache itself. It simply wasn't designed for speed, so a system running off of the game cache is not recommended at all.

Myth Number Three: Using Index 0 and 8192 in any given array

Most veteran JASS Programmers stay away from index 8192 in an array. Why? Because it's said to corrupt saved game files. Now, from reason and logic, I've come up with a hypothesis that runs off of the fact that wc3 only has an 8k storage capacity. This means, when you use index 0, the actual storage capacity goes from 0 to 8191. If you weren't to use 0, it should go from 1 to 8192. 8192 is set as a max in GUI because the developer's didn't expect beginners to use 0.

I'm going to be looking into this myth and I will come back with the truth soon. According to the myth, this shouldn't mess up gameplay at all. It only has to do with corrupted saved game files. I believe the only thing that would cause this is using index 0 and 8192 if this really happened. But I don't think this myth is a true one.

I shall be back with more myths and the answer to Myth Number 3!

-----------------


If anyone knows of any other myths that they have so called facts that they have doubts about, simply PM me and I will look into the matter.
 
Last edited:
Level 31
Joined
Jul 10, 2007
Messages
6,306
apparently you didn't read. I stated witin the third one that I hadn't looked into it yet, so until then, I gave my own theory about why the myth might occur.

Next time, read please ^_^. I very clearly stated everything. It shouldn't be difficult to understand what I've tested and what I haven't yet.

Thank you

Clearly Stated in Myth 3:
I'm going to be looking into this myth and I will come back with the truth soon.

Clearly Stated at the very top of the post:
Well, after some testing in wc3, I've so far disproven two myths.

^_^

And what's up with your quote...
 
Level 6
Joined
Jun 30, 2006
Messages
230
I did read, I merely stated you were attempting to prove something with something that isn't proven, hence, it was unclear why you posted it to me.

As for the quote... it is something of a joke among forums.dota-allstars.com bug reports. People say things happen all the time, and the common response now is "Replay or it didn't happen"
 
Level 11
Joined
Aug 25, 2006
Messages
971
Hey I like the myth busting, its very interesting.

Theres been many discussions about how long 'TriggerSleepAction(.01) takes. Some say it varies from multiplayer to single player. Many say it takes at least .29 seconds. My own tests showed about a .1 second wait in single player. Could you look into how long it really takes to complete a TriggerSleepAction(.01)?
 
Level 31
Joined
Jul 10, 2007
Messages
6,306
I did read, I merely stated you were attempting to prove something with something that isn't proven

Are you asking for a replay? If so, the answer's no. I'm not using theory in any case.

I've also provided data along with a sound and logical argument for each case. For myth number 4, I didn't provide data because I never ran any tests for that. I already knew the answer. For one, I didn't know what the actual thread limit was but I was sure it wasn't 72, so I tested it out and discovered it was 800. That's the application's thread limit. For myth number 2, everyone kept saying strings were permanent leaks and I needed to see for myself. It turned out they were wrong.

I decided to post my findings concerning both myths.

For myth number 3, that is quite plausible. I've yet to look into it because I haven't the time, but I'm 100% sure it's true. It is completely possible -.-, unless the devs did something strange. This is why people either use 8192 or 0. Most JASS veterans try to stay away from 8192 because they do use 0. It's just a common rule, and a lot of them don't know why. Most beginners stay away from 0 because it contains an evil spirit (spooky) lol.

With myth number 4, I already knew the answer and I knew why. There was no point in me testing it out. The problem with this is that I couldn't support actual data. However, the estimates I provided are probably very close to the real data.
 

Dr Super Good

Spell Reviewer
Level 62
Joined
Jan 18, 2005
Messages
27,083
The actuall massive lag that occures when the limate is exceeded is because it uses more processor power to run. Thus suddenly there is nearly none left for running WC3 graphics so FPS drastically falls.

I also do not think WC3 is really that threaded. But what you say about the pathing makes sence. It is because WC3 expects threads to always be ready to move units and so does not store up move orders. Thus WC3 units never come to a stop, they just move insainly slowly in dhort bursts with huge delays.

Also note that JASS is not converted into C++, infact WC3 does not use C++ at all, it uses bitecode (compiled C++) to work and so JASS is compiled on map launce also into byte code.

I recomend you investigate the opperation limate trigger threads have, as that can be annoying for people.

I also recomend you investigate how the target aquisition system in WC3 works, as if a large number of units aquire targets,the game really lags.
 
Level 31
Joined
Jul 10, 2007
Messages
6,306
You know what I meant by converting to C++. I was saying that the JASS runs through the C++ by calling the commands etc. I wasn't being literal : P.

Also, I agree with you on the second one because the next thing to 8192 is 2.7 billion I believe it was. I was going to post this, but you beat me by 6 hours. Kudos to you : P. I know the number was massive. With a storage limit that gigantic, it'd slow down wc3. I'll change that information.

I will be more specific and literal in the future so people don't get the wrong idea about what I mean : P

And I'll look into target acquisition. There is a value in the object editor that has to do with target acquisition. I believe that the game checks for units within that range, meaning it can run off of a single thread through a loop. Every unit runs off of its own thread like normal. When a large amount of units acquire targets, you will have more threads running at once.

Now another possibility is that it does it purely through looping, but I really doubt this as it would be more efficient and faster through multi-threading. They can also use triggered events via the object database -.-. It's already set up in WE, so I imagine that it would be even better this way so that the functions in C++ are only called when the cell goes off.

So, my final conclusion without the testing is that targets are acquired through triggering the databases that are already set up. This is the most efficient and fastest way to design a system such as this, and because there is already a value you can edit, well.. = P.

Now, I will look into how the targeting system works because I can't know for sure until I look into it. All I can do is theorize about it until then. I'll add it to the list later. I'm really exhausted atm.

-------------------------------------------------------------------------
Concerning Threads:
I posted in the first post under the myth.

In short, you're all wrong and I'm right. Case closed. I'm not going to upload a replay or provide instructions as to how to perform the test. This thread is about myths in wc3 and questions. I'm going to tell you how it works, why it works like that, and the limitations. If you want to argue, you're wrong. If I find out more data, I will post it, but not in this. When a case is closed, that means the answer is final. Notice that the only myth that is closed is the first one. This means the other 2 can change as to the reasons why. The results and data will not change, but the reasons will.

Any myth that is only about data will never change and will immediately be closed. Anyone who attempts to argue the point will be told that they are wrong.

I'm tired of being told that you don't believe me or that you really doubt it. If you do, go join the people who believe you can't use 0 as an index in an array. Programming is programming. Data doesn't change no matter how many times you test it or how long you argue about it.
-------------------------------------------------------------------------
 
Level 21
Joined
Aug 21, 2005
Messages
3,699
I haven't been arguing yet. I only said that I need to see WHAT you did to get such data. An important aspect of proving stuff is things like this:

- Statement
- How you got the data you base your statement off
- Your theoretical reasons explaining this statement.

Right now, you gave us statements and theoretical reasons to why this statement is true. Yes, I agree with you that if you have the data in front of you, there's no discussion required about the statement but rather about the reasons. However, an important aspect I'm missing here is how you got this "data". Without that, making statements is not valid, thus you can't proceed to finding reasons to the statement...

It's like proving an apple falls down.
First you make your statement: apples fall down
Secondly, you prove it by throwing an apple up, and you tell us how to reproduce this so we can "see" the statement
Finally, you tell us that apples fall down because of gravity.

Without the second step, this proof isn't valid...
 
Level 13
Joined
Nov 20, 2005
Messages
1,156
Why should we trust assertions from someone who can't handle the English language? Especially someone without any credentials to back him up.

Even Vex/Pipedream would be expected to give their data and methodology (and they've been known to be wrong).

EDIT: I seem quite capable of having over 1600 threads running simultaneously in JASS, without any problems. No threads crashed.
 
Last edited:
Level 31
Joined
Jul 10, 2007
Messages
6,306
This thread is just about disproving myths and so forth. It's not about questions and answers and stuff. For example, super's question is not a valid one because everyone already knows that it's true. People just don't know why, thus it's not a myth ^_^.

Also, for the thread maximum test, you need to make sure you did it properly. If it was only one line, then you're results are very wrong.

Here's how to do the test if you are all really interested...

First, create your trigger variable, set it up to create a new trigger. After this, create a function, inject it into main function (call it in the main function). Make another function. In this function make a pretty steady loop of atleast 8000 (you can set an integer, do w/e. As long as it's not unique string values, you'll be ok).

After this, in the first function, create a loop of around 2000 or so, doesn't need to be that high. From here, call ExecuteFunc("empty loop function name"). This will start up your empty function that just takes up processing power ; P. You just need to make sure that the thread you started up will continue to run through the entire test. From here, display the integer for the loop for the function that executes the other one. This will say how many threads have started. If you do this properly, you should come to 800 threads.

For the second one about strings, you pretty much do the same thing except that you add trigger events to go off every .01 seconds. I suggest 6 events for the trigger (6 threads). From there, you create a function and load it into the trigger (add action). Create a global integer variable and name it whatever you like. After this, just set it to +1 every time the trigger goes off via your added function. Then display the text to the player and add whatever you like to it. You don't really have to add anything though. This will create a unique string every time the function is called. I suggest also creating a stopper. Add an if statement to the end of the unique string function and say if your variable > 105,000 (this is the value I used), then clear all actions from your trigger. From here, wait until the game slows down to normal speed. Make sure you add units to your map (I used 4 footmen). When the game goes back to regular speed, try moving them around. If you can move them around without any delay, this proves that strings do not leak.

The next one, just try out any timer and you'll see that it's true.

The next one isn't a myth. We all already know that it's true. The questoin was just why does that happen. This isn't a thread for that discussion, so I will not be going into why =).

If you follow all the steps above, you will come out to the data I came up with. I'm sorry about being crabby, but just realize that every time I try to teach someone something, they say I don't believe you. At one point, it gets really frustrating. I may not have credentials, but I understand the JASS language extremely well. It took me about a minute to create both of the functions I said above (this includes planning, structure, etc, most of it was just typing). I also regularly teach people about JASS. So far, my record for teaching someone all about JASS (a complete beginner) was 10 minutes.

Now please guys, this is a thread about disproving myths. If there is a value out there you aren't really sure about (the 72 thread limit value -.-, the myth about corrupting save games if you use index 8192 or 0, string leaking) the come here and post it. I'll look into it and get you an answer as to whether it's true or not. I will even explain why it's true or false.

If it's something you already know to be true (game lagging when there are many target acquisitions), don't bother posting it because it isn't a myth. Treat this like myth busters where nobody reallys knows the answer. If you just want to know why, ask me to start up a new thread as to looking into why things work the way they do, why things lag, etc. : P.

Thank you all for posting. Keep in mind that if I'm really crabby, I've probably had a really rough day at work and I probably don't want to read about people doubting me about set data.

Now, if you follow my directions properly and come up with different data, feel free to PM me about it. Please remember to include the code you used (I expect a JASS File attatched or I expect to see it pasted : P), this way I can see why you got different data. If the test is fully legit, then we can look into it from there.
 
Level 13
Joined
Nov 20, 2005
Messages
1,156
Also, for the thread maximum test, you need to make sure you did it properly. If it was only one line, then you're results are very wrong.

Two lines in a function is all you need for a thread. A wait and then something after it to show that it doesn't crash.

Here's how to do the test if you are all really interested...

First, create your trigger variable, set it up to create a new trigger. After this, create a function, inject it into main function (call it in the main function). Make another function. In this function make a pretty steady loop of atleast 8000 (you can set an integer, do w/e. As long as it's not unique string values, you'll be ok).

This is quite possible to hit the op limit...which brings into play something you aren't testing.

After this, in the first function, create a loop of around 2000 or so, doesn't need to be that high. From here, call ExecuteFunc("empty loop function name"). This will start up your empty function that just takes up processing power ; P. You just need to make sure that the thread you started up will continue to run through the entire test. From here, display the integer for the loop for the function that executes the other one. This will say how many threads have started. If you do this properly, you should come to 800 threads.

Just post a map with this in and I'll test and disect it. My own tests disagree with you. It could well just be that under excessive CPU activity WC3 simply ceases crushes threads on a whim (I wouldn't be suprised).

For the second one about strings, you pretty much do the same thing except that you add trigger events to go off every .01 seconds. I suggest 6 events for the trigger (6 threads). From there, you create a function and load it into the trigger (add action). Create a global integer variable and name it whatever you like. After this, just set it to +1 every time the trigger goes off via your added function. Then display the text to the player and add whatever you like to it. You don't really have to add anything though. This will create a unique string every time the function is called. I suggest also creating a stopper. Add an if statement to the end of the unique string function and say if your variable > 105,000 (this is the value I used), then clear all actions from your trigger. From here, wait until the game slows down to normal speed. Make sure you add units to your map (I used 4 footmen). When the game goes back to regular speed, try moving them around. If you can move them around without any delay, this proves that strings do not leak.

It proves no such thing. The slow down could well be due to the creation of strings, and it then takes a while for WC3 to catch up again. Looking at the memory usage in the task manager is much more accurate.

Okay, 100,000 strings at, say, 1kB each is a mere 100 MB...which can be easily absorbed by most people's RAM. I'll test it properly with the task manager tonight.

The next one, just try out any timer and you'll see that it's true.

If you're talking about waits being inaccurate, we all know that.

If you follow all the steps above, you will come out to the data I came up with. I'm sorry about being crabby, but just realize that every time I try to teach someone something, they say I don't believe you. At one point, it gets really frustrating. I may not have credentials, but I understand the JASS language extremely well. It took me about a minute to create both of the functions I said above (this includes planning, structure, etc, most of it was just typing). I also regularly teach people about JASS. So far, my record for teaching someone all about JASS (a complete beginner) was 10 minutes.

Teaching someone all about JASS, in 10 minutes? Absolutely impossible. JASS is convoluted, silly and often downright retarded. It has various random bugs and exploits in it; the function names are inconsistent and hard to remember. So you taught a complete beginner, without any knowledge of JASS (or C/C++/C#/Java/etc.) in 10 minutes? Bull.

And even if you did have credentials, you'd still be ignored unless you could provide evidence.

Thank you all for posting. Keep in mind that if I'm really crabby, I've probably had a really rough day at work and I probably don't want to read about people doubting me about set data.

Now, if you follow my directions properly and come up with different data, feel free to PM me about it. Please remember to include the code you used (I expect a JASS File attatched or I expect to see it pasted : P), this way I can see why you got different data. If the test is fully legit, then we can look into it from there.

We won't PM you, we'll have an open discussion here, not in PMs. Post your stuff, or shut up. I suggest you never drop by WC3C in this arrogent manner that borders on trolling.
 

Dr Super Good

Spell Reviewer
Level 62
Joined
Jan 18, 2005
Messages
27,083
Some of what you are saying is believable (especially the thing about unit movement threads and the stuff about strings) but other bits are not.

Unless you are a blizzard employe who knows for sure how it was done, then there can always be the factor of false hypothisis. Thus inorder to win people over to believeing your theroy, you have to prove to us why is is plausable in a better way.
 
Level 31
Joined
Jul 10, 2007
Messages
6,306
Well, the GC (gamecache) cleans up the strings, but I didn't mean to sound arrogant. You asked how I did the tests and I posted how with step-by-step instructions ^_^. Like I said, I did make all of the tests in about a minute, so I didn't put much thought into them not to mention the fact that I've been getting about 1-2 hours of sleep for the last 3 months : P. But uhm, rawr. If I ended up testing the op limit, it would be 4800, and I agree with you in full griffen, it's much better to test threads out with sleep commands, hm... Same with the strings... Imma try something out now..

I'm trying out 905,000 unique values to see how it modifies memory usage, commit charge, physical cache, and kernel memory.
 
Level 13
Joined
Nov 20, 2005
Messages
1,156
Okay, tested.

100,000 strings created (and nulled).

RAM / VRAM

87,220 K / 78,892 K

to

102,076 K / 94,340 K

Giving an average increase of ~0.15 KB (note: quite short strings, non-repeating numbers from 0 up; actual usage may result in higher average memory usage).

Isn't de-allocated.
 
Level 31
Joined
Jul 10, 2007
Messages
6,306
I know, I just tested it too.

Now, there is one thing that needs to be noted. The strings don't act as regular wc3 leaks because they aren't stored in the game cache, so using strings will not lag up your game. In fact, it won't be noticeable. They will not create black screens etc. Now, they will make wc3 need to restart if you use an inane amount, but don't worry about it. Now, it increased from around 33,000k of memory to 215,000 so far. The average new game does 300k. Keep in mind that this is also after an incredible amount.

Now, the reason for the major slow down is because it is first stored in the game cache (8192). From there, it is transfered to your machine's memory. It only does this when it goes above 8192. Before this, it shouldn't add anything extra to your computer's physical memory cache, kernel memory, PF Usage, etc. In essence, going up to 8192 will not cause any true leaks because they will be cleaned up. If you go above this limit, that's where you get your leaks, and these are not your regular memory leaks. The game will never crash from these with a memory error. Your computer will crash.

Memory leaks like these are why computers can't just stay on forever, but need to be restarted etc.

So, what I said before is true in a sense that it won't lag your game, but it does leak into your computer's cache.

So it is safe to use strings etc

Strings are still fast and safe, they will not slow down your game.

This test used 905,000 unique string values.

also, I re-tested the thread limit and it seems that it's completely dependant upon the host's computer. I tested out 16,000 threads. It also seems that whenever you use more memory in wc3, it stays in there, so when you start up a new thread, it takes up more memory. Once again, it won't lag the game. It will stay in the system cache though.
 
Last edited:
Level 19
Joined
Aug 24, 2007
Messages
2,888
I think
This timerfunction wont crash game in 10 days
but it will slow in about 3 days I guess
udg_count is a global integer variable
and period is 0.1 seconds

function TimerFunc takes nothing returns nothing
call BJDebugMsg(I2S(udg_count))
set udg_count = udg_count+1
endfunction

If you so worried about string leaks go play DotA
 
Level 31
Joined
Jul 10, 2007
Messages
6,306
it's not about your computer, it's about wc3. My computer is insane, 4 gigs of ram, quad-core, etc. Wc3 gets its very own CPU to run on.

The fact is, wc3 crashed at 712,000k memory. I had a butt load of Cache space left, butt load of ram left, etc. My computer wasn't slowing down in any way. I dunno, I could be wrong. I think a magical elf played around with my comp >: (

lol ^_^
 
Level 31
Joined
Jul 10, 2007
Messages
6,306
It's not wrong anymore : P

Oh, btw, wc3 can only handle 32 pieces of 8k information ><

So you could only have up to a maximum of 32 fully declared arrays.. you wouldn't be able to declare anything else, it would crash wc3.

I found this out while working on MOPS, so I need to change its definition systems... I'll give it the capacity to hold maybe 8 fully declared arrays that store the same piece of data (8 world object arrays, 8 data object arrays, etc). But I need to put checks so that it doesn't go above the 32k limit : P. Also, nulling variables will keep under this limit, so whenever someone unloads something, I need to undeclare a piece of information... I doubt anyone will have more than 32,000 units on a map at once anyways. But it could handle more..

Eeps... null your variables or else bad things will happen! : o...
 
Top