| 11-22-2003, 12:22 PM | #1 |
I just decided to create a thread (my first thread ever!! woah) to directly approach the aspect that unbelievably many people have a poor image of how to use Local Player, and in fact, they believe that using Local Player instantly causes de-sync in multiplayer games and causes players to disconnect... Now this is not true, and i'm setting up a reference here, both to catch your atention on this truth, and to complete my own knowledge of the matter. Q. What is Local Player stuff? A. The Local Player works like a variable that holds data about which player you are in the game. By using it in a simple "if" statement, you can cause your computer to perform a piece of code, but not other players. F.ex., the following line: if (GetLocalPlayer() == 0) then actions endif When it comes to this part of the code, all the computers will check which player they are, but only player 1 ("0" in jass-code) will get this condition as true, and thus do it's actions. Basicly, you can then have "specific" player for actions that normally do not take a specific players, and believe me, there are alot of them ^^. Q. Then what is De-Syng? A. Having control over the local player is a very powerful tool, but it's easy to mess something up. If you do mess something up, f.ex. say you set the global "nrOfPlayersKilled" to 15 for some players from the original 10 number... then there will become a difference between your instance of the game, and the others players instances of the game (becouse normally all players follow the same code). So in your memory, this variable now stores 15, but for all the other computers, this variable stores 10. Now when the computers keep using the script, they'll soon realize that you aren't synced with them, as suddenly you start to have different properties (variable-values) than them, and thus, you de-sync. And this leads to disconnection. So obviously there are alot of things you can't do with local player. NOTE: It's highly reccomended that you use jass for working with local players, mainly to have clear and easy access to local variables (which can be important when working with local players) and such. And also... the thing i list here below do ONLY work if you do them right, and it can can require a little logic to do it correctly. I will not teach you how to do these things correctly in this thread. List of things that "DO" work on battle.net for a local player[list=1][*]local Multiboards - Personally Vitnessed[*]local Leaderboards - Not Personally Vitnessed, but should follow the same logic[*]local Fog Of War - Personally Vitnessed[*]local Black Mask - Personally Vitnessed[*]local Environmental Fog - Personally Vitnessed[*]local Floating Text - Not Personally Vitnessed, but reported by others...[*]local Fade Filter - Not Personally Vitnessed, but reported by others...[*]EDIT: Dialogs naturally can apply for specific players (tnx AIAndi)[*]local Text Messages - Confirmed by AIAndi[*]local Sound Effects (and most likely music too) - Personally Vitnessed (tnx to AIAndi again)[/list=1] List of things that do "NOT" work on battle.net for a local player (causing de-sync).[list=1][*]Letterbox Mode/Cinematic Mode NOTE->*[*]Logical stuff like global variables, units, stuff like that. **[/list=1] * Under normal cirqumstances, Letterbox Mode and Cinematic mode do cause de-sync if used for a local player. And that is becouse of one (or a few) bad function-calls that these modes do internally that cause logical de-sync. DaKaN has already submitted a version of these two functions that work fully for local players, and include almost all the functionality of the original (you won't notice any change atleast). **I will not list every single thing that does not work for local player as it's quite logical/obvious most of the things, But i'd apreciate if people could submit some below, and i would add them. I would really like to get more entries into that list, as i have not tested everything yet. I would like to get secondary confirmation of the things not confirmed personally above, I would like to get more things i forgot (as i likely forgot alot of things) and I would like to know if stuff like if local Special Effects work (f.ex. the game engine automatically spawns a gold-effect when you get bounty that only you see). Another thing to note, is that i'm not sure if there is another condition that causes local-use de-sync, f.ex. if one uses local player for a working (not de-syncing) local-statements often enough for different players, if that eventually causes de-sync...although logically it should not, as if it works a few times (f.ex. the fog, i played a 30 min game where each player was switching to different fog all the time for fun) it should work forever... Cubasis Ps. and if a mod thinks this should rather be in the tutorial section, it very well may, but i'd like to grab peoples atention of the subject first, and also discuss the matter (submit more instances where local code works)...so i'd rather move to the AI/Jass forums than the tutorial forums. :) |
| 11-22-2003, 12:58 PM | #2 |
Dialogs do support specific players so that is not an instance of local player usage. Another thing that does work for local player is displaying text. You can also alter the selection of the local player. This can even be used to sync unsynced info like camera target. |
| 11-22-2003, 01:05 PM | #3 |
ah, interesting. Tell me, what text message function is that, that supports local code? As i heard a long time ago (RoC days) that one couldn't do local "normal" text messages (normally for force...). But one had to use another hidden (or not so hidden) function in blizzard.j/common.j that naturally specified a player. I don't remember it so well, and i do not remember if this function by default uses local player to display it's player-specific stuff. Edit: the Game - Display text to "player".. function in umswe is the one i'm talking about that by nature works for specific players (and does not de-sync it seems) Anyways, Thanks for the input Cubasis |
| 11-22-2003, 01:12 PM | #4 |
The Display natives do take a target player but it needs not necessarily be run on all computers so you can do things like that: Code:
function DisplayToAll takes string s returns nothing
call DisplayTimedTextToPlayer(GetLocalPlayer(),0,0,15,c2s(GetPlayerColor(ai_player))+s)
call StartSound(chatSound)
endfunction
function DisplayToAllies takes string s returns nothing
if IsPlayerAlly(ai_player,GetLocalPlayer()) then
call DisplayTimedTextToPlayer(GetLocalPlayer(),0,0,15,c2s(GetPlayerColor(ai_player))+s)
call StartSound(chatSound)
endif
endfunction |
| 11-22-2003, 01:15 PM | #5 |
Oh yes!, sounds, hah, how could i have forgotten :P, lol, to say the least, i have a very special easter egg in my multiplayer project ^^ tnx again, oh, and why do you suggest these functions, don't the DisplayTextToForce, work well enough? not that i ever use it :P lol, actually, i think i never have used it :) Cubasis |
| 11-22-2003, 01:55 PM | #6 |
That is pretty much what DisplayTextToForce does. This just uses the IsPlayerAlly function directly instead of building up a force first and also plays a sound at the same time. I just copied these from AMAI as an example. |