How doas a map script work, exactly?

Im generally new to JASS (as in full coding in it, not a syntaxual understanding) and im wondering: How exactly doas wc3 call a map script?

I see quite a few main functions setup to handel initialization, global variable initialization, a "main" function, and a "config" function and all that.

Now, one can easily surmise that the main function is called when a map is initialized. What about the rest of it? f.ex, the "config" function contains information needed before a map is initialized, so doas InitCustomPlayerSlots. How do these fit in to a maps script? Are the needed values also stored elsewhere? Doas WC3 call these functions when the information is needed prior to map initialization?

well, im not quite sure about what u want to say, but as i understand ur like talking about the melee initialization triggers, if that is the case then they are just some triggers - simplified of JASS made into GUI (graphical user interface) - to set up a melee map, like how much gold a player starts with, how is the victory condition ect...

If you want to learn about how map triggers/scripts works, then there are few tutorials around in the tutorial section for you :)

And for a quick start, if you look inside a trigger, u see an event,condition and action part, the event is when this trigger will be run, the condition tells what is required in order this trigger to be run when the event occur, and the actions are basically what will happen.

And about jass, it's a script made to run wc3 maps, it's quite complex, but as long as u know some programming then you should be fine

No no. Im talking about how WC3 handels the script as a whole, not just the individual triggers you can edit in the world editor =) Theres more to a map script then triggers. And i wanna know how it all works x)

But a good attempt at help ^^

why would u know tat^^ as long as the functions in jass works i wouldnt mind about how the entire thing runs :P

I think he's referring to, say, the script you can put in next to the Map name in the trigger editor in WEU?
As in, code the map evaluates and pre-loads before everything else (I think).

Unfortunately I can't give much help on this cause I was just about to ask the same sort of question, heh :)

If that is what you are referring too, anyways... >.>;

Some of a map script, such as player slots and such, aren't used from the script itself.

When choosing a map in the ingame menu it uses(I believe anyway) information contained in all those funky little files inside the map MPQ.

The map script, to my knowledge, comes into play once the map becomes initialized, basically during the load and such. At this point it will create units, fogs, rects, all those fancy little preset things you can make happen.(these units refer to PREPLACED units).

Now, as to how it handles it. Like any language it is interpreted by WC3. Similar to how a C++ compiler would handle a cpp file into an EXE, except in this case instead of running directly into machine code as in an EXE it runs through WC3, so I guess you could think of WC3 as an environment, but meh.

There is much more to it, but to go right into it you would need to know how a computer actually handles code, and since I have heard that WC3 is done in C++ I guess that would be your best bet at gaining an understanding of this stuff.

Config is run after you hit start game, this is what you see when you load the game. This setsup doodads unit placement etc. It preloads things if you set up preload.
Main is run about 90% in your load bar. Main launches all triggers that are set to run on map start. Every other trigger is registered.

You can only declare globals once. Any jass function can call a jass function above it. It cannot call jass functions below it. You can not have mutually recursive functions in jass. (You can with a bit of trickery). I mean consider

Won't work.

Handles are not first-class-pointers. There is a memory hash where all handle objects are stored. Each time a handle is created an entry in the hash is made, there is a broken refernce counter in jass which handles how the memory layer recycles spaces. The reference counting system forgets to decrement the counter on local variables. You have to manually set the variable to null. Arguments do not have such a problem. Its unknown if globals have this problem, and it shouldn't be an issue if they do.

warcraft III has an emergency garbage collector. Unforutantly its mostly useless due to the broken reference counter. But, if warcraft III determines too much memory is being used and may result in crashing/desyncing the game (I have no idea how it does this), it will release all handle objects that do not have anything pointing to them in game. (this is very safe, units won't get released, locations will). The problem is the broken reference counter may say the object is still in use. Thereby it may not release much memory at all.

Jass cannot and will not run threads in parrallel. If you somehow suceed in getting threads to run in parrallel you will get it to crash hard. (Its been impossible since around 1.03 to get them to run in parrallel). Your shred sort with its o(n) time will not work as you expect.
Jass is call-by-value. (Why would you think otherwise?) It is not tail-form-optimized. (Why do you think this would work?) It does not have functions as first class objects (heres a pro-tip nothing is firstclass in jass), nor is it an implementation of the lambda calculus. HOWEVER, you can store function under the code datatype. Oddly enough code is the only data type you cannot declare an array of. Theoretically, could implement continuations, however, you do not have annonymous functions, or the ability to call a function from a variable with arguments.

You can not declare object types. All datatypes are fourbytes long. Reals are floats. Integer are ints, booleans are 0 for false, anything else for true. (internal reprensentation). Strings have a reference counter system as well. This isn't broken. This does make string comparisons very easy! You can merely
There is no string parsing though. Everything is done with substrings. The reference system makes this particularly slow. In short, don't use them to much.
Jass has structs for all object types, things like custom abilities are loaded on a by need basis. This creates lag, obviously. You should preload all custom abilities that are going to be added to units.

All threads in multiplayer are synced and run off the host players computer. Even if the thread has instant suicide for all other players except for player 2, they still have to be run off player 1s pc. Do NOT luanch local threads. DO NOT create local objects. DO NOT DO ANYTHING LIKE THIS. They will desync the game. This for instance is very bad.
You can modify local objects to your delight though.
These should be visually and audio changes only, though. Anything else could cuase problems.

There you go lots about jass.

There is a built-in delay for jass, this is to smooth out multiplayer gameplay. This sucks for us coders though, as its REALLY noticible if your not the host how slow things are. (especially item systems).

Wish somebody had done that for me when I was learning JASS =P. Nice overview.

I think it's more along the lines of all commands get sent to the host, and all state changes get sent back. So it's like someone else was ordering your unit on a different computer. This is the only way to maintain sync, I believe.

I think function arguments don't increment the reference counter. It is probably something intrinsic with the "set" statement that does this which is not part of function arguments.

How would you get threads to run in parallel? What is shred sort? How could that possibly depend on multithreading? it's not like there's ever "true" multithreading on a single core machine.

In beta and early patch versions of war3 you could get threads to be parrallel. It was hard, but totally possible. Things like building two triggers that launched off the same event. Or launching a timer at 1 sec, and then 1.0001 second. It'd cause war3 to crash painfully.

There are many sort algorithms which "violate" the O(n*log(n) ) lowerbound. Some do it by not being comparison sorts, and others do it by having multiple processes. I think a shred sort was basically an odd-even sort, that made the buble sort actually effecient. Its certainly possible for the environment to emulate multiple threads. (this will of course not be the best course of action), and these days practically every chip on the market is dual-core, or hyperthreading.
There is a built in delay to smooth out lag. Even in a lan game with no lag what so ever. There is a small delay.

Arguments probably have to increase the counter. It would be awful if the egc ran during a function and killed an object that had no references except for an argument.