bj_forloopA(B)index(end)

I just thought of something that would work, but some people may think it is stupid and screw up code. An easy way to get rid of wasted integer variables is to just use what blizzard gave you. Instead of creating your own local integers why not just use the bj_forloopA(B)index(end). As long as your code didn't use trigger sleep action or modified periodicals these can be used to transfer stuff between functions such as ability/unit ID's because they are global variables that you don't have to define. And the GUI sets these to their proper variables before each loop, so I think it would be fine to use them. Does anyone disagree?

Erhm, :)

Sorry to burst your bubble, but we've been doing that for a long while. Just check out many of the older functions in Jass Vault....Always when we create a new thread (trigger) to do something, we pass it stuff using these variables (that is, before Game Cache came along).

Cubasis

Heh, I've actually been able to code my own stuff for about 2 weeks now, so I guess I had been doing JASS back in the RoC days I probably would have figured it out the same time you guys did. I have a stupid little question though. What the heck is GetLocalPlayer()?

Using those globals at a point, where you could use locals, is no good idea, as you increase the amount of code that might influence the value of that variable by a lot. That makes debugging a harder job.

Aiandy is right. All varables should be as local as possable! :D

Well...... I agree with you that locals should be used for trivial things like loops and such, but what I am talking about is transferring data between triggers. Triggers that have actions you can't pass args to. Anyway, how does GetLocalPlayer() work? I saw the play a sound for one player in the vault and it used it, but I am not sure what it does.

The name is actually pretty self-explanatory. And it's (almost) the most useful function in the API. As you likely noticed by now, it takes nothing, and returns a player. But, it returns only the .... "local" computer playing in the game. So, in MultiPlayer, if 10 players are playing, and you use this function, it would return different player-objects for each player.

This can be it's great, and it can be terrible. As this is one of few functions that return localized data, and if not handled correctly, can easily cause hard-to-find De-Sync.

The most typical use for this is to compare the return of it with a certain player, like this:

if ( GetLocalPlayer() == Player(3) ) then
####
endif

So, then when this statement runs, it will have different comparisons on every computer. Player 1 will compare "Player(0) with Player(3)" and ofcourse be false, and thus, not run the stuff inside the if-statement. But Player 4 will...as the if statement returns true for him. But be careful with whatever you do inside those if-statements, as it can easily cause de-sync.

Another common (and a bit cooler) way is f.ex. the following

call MultiboardDisplay( udg_MultiBoards[ GetPlayerId( GetLocalPlayer() ) ], true )

As you can guess, that will show a different element of udg_MultiBoards to each player.


There are also a few more functions that return localized data, like "GetCameraEyePositionLoc", and others, so keep a eye on them too when working with them.


But basicly, GetLocalPlayer effectively allows us to do alot of things for 1 player that we normally couldn't do. Like MB's, Cameras, Text Tags and other stuff, but note, we can't create local Special Effects, or local Units, as that causes de-sync (locically).

Cubasis

If you're writing specific functions for your own map, its better not to use those variables for passing data, but define your own global variables. Less chance of messing things up. The exception is publicly distributed functions, like those in the JASS vault.

With the advent of the gamecache revolution you really should avoid using globals in jass vualt type functions as well its much easier to use cache specific variables so you don't mess with the predefines.

@Cubasis
So what you are telling me with the multiboard thing is that this bit of code will display each players names in their own personal multiboard?


I know the syntax on that is probably horrible, but I am too lazy to go look up proper syntax for it. You get the picture right?

Yup, that's absolutely correct, just again, be careful with what you do with it, cause de-sync bugs are often hard to find. But that's generally ok.

Cubasis