hambeast

Lesson 2: Handling JIP clients
 
What is JIP? JIP stands for "Join in Progress" aka players who join after the mission has already started.  
 
You know how to change a players skin by sending out public variables but how do you make sure every player who joins has their skin changed?
 
For this example, we will assume there is an event running and for some reason you want to make sure every player who joins the server knows the event is running and if the event is started, lets make sure they get their skin.
 
We will also be introducing the idea of server side and client side event handlers in this lesson.
 
Brief flow of events:
* Client connects
* Client asks server if event is running
* Server checks to see if event is running
* If event is running, server changes players skin
 
Server Side JIP Check and Validator:
This code will handle requests from the client.
// server side check, make sure only the server runs this code if (isDedicated) then { // DEBUG: Manually set our event to running... You would normally do this thru a menu etc. // note, that this variable is only set on the server itself, so the client has no idea of the value // if you wanted, you could pass this thru instead of a skin but that's out of the scope of this tutorial Server_Event = true; // expects: [player] // Handles our client JIP requests "PV_JIP_Event_Check" addPublicVariableEventHandler { private ["_packet","_player","_owner","_skinClassName"]; // deserialize our packet _packet = _this select 1; _player = _packet select 0; _owner = owner player; _skinClassName = "FR_GL"; // my personal skin // check to see if Server_Event has been set by an admin/script. if (!isNil "Server_Event") then { // validate Server_Event is true, if true, our even is running if (Server_Event) then { // our event is running, change skin of JIP player PV_ChangePlayerSkin = ["FR_GL"]; _owner publicVariableClient "PV_ChangePlayerSkin"; }; }; }; }; Client Side JIP Check:
This code will be fired off when the client finishes loading their mission.
// client side, JIP checker, this runs whenever the user loads their mission file if (!isDedicated) then { // call our JIP check to see if a mission is running PV_JIP_Event_Check = [player]; // only send the public variable to the server! publicVariableServer "PV_JIP_Event_Check"; }; Client Side Skin Changer:
A slightly modified version of the 1st lesson's skin changer PV handler.
// client side, Skin changer, this runs whenever our server sends the PV to the client. Modified to use less bandwidth // this line says ONLY run on the ClientSide. The server will see this and ignore it. This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then { // expects: [_skinClassName] "PV_ChangePlayerSkin" addPublicVariableEventHandler { private ["_packet", "_skinClassName", "_playerUID", "_characterID"]; // handle our packet. _this select 0 returns the PV name, _this select 1 returns our input packet _packet = _this select 1; // should contain [_skinClassName] _skinClassName = _packet select 0; // since we are only running this on the local client, we don't need the playeruid and characteruid passed // we can just grab them from the local player object _playerUID = getPlayerUID player; _characterID = player getVariable ["CharacterID","0"]; // set our player to the skin [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph; }; }; Place all of this code (in this order if you like) at the bottom of your init.sqf in the your mpmission.
 
Now when a player connects to your server, they will have their skin changed.   If you want to play around with this, You could add a custom menu in "fn_playerActions.sqf" that only admins see that sends a PV to the server to say set "Event_Status" to true of false.  However, this guide is quick and dirty so it will always set a player skin, since we declare "Event_Status" as true.

FYI, this guide is for advanced arma coders.  This guide will assume you know how to pack/unpack PBO's, edit files, and are comrfortable with coding.  You must also have an understanding of locality as in client vs server side.
 
A note on locality:  Your mpMissions folder is NOT only client side.  When I started coding I made this assumption and I was wrong.
 
 
Lesson 1:  Event Handlers Basics
 
Event handlers are the bread and butter of Arma2 MP coding.  They are little logic functions that the server sets aside until they are called by a public variable.  In my experience they have very low overhead so don't be afraid to make use of them.
 
example 1: Change players skin
Add this code to the bottom of your init.sqf (in your mpMission)
// expects: [_playerUID,_CharacterID,_skinClassName] // this line says ONLY run on the ClientSide.  The server will see this and ignore it.  This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then {   "PV_ChangePlayerSkin" addPublicVariableEventHandler {     // handle our packet.  _this select 0 returns the PV name, _this select 1 returns our input packet    _packet = _this select 1;  // should contain [_playerUID, _characterID, _skinClassName]    _playerUID = _packet select 0;    _characterID = _packet select 1;    _skinClassName = _packet select 2;       // set our player to the skin    [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph;   }; }; Ok so now we got our event handler set up, if any client sends the PV "PV_ChangePlayerSkin" all clients connected will execute this event handler.  Here is how we send the command to all players.  This code can be called anywhere, on a client, or from the server itself.
 
example:
  PV_ChangePlayerSkin = [_playerUID,_CharacterID,_skinClassName];   publicVariable "PV_ChangePlayerSkin"; But you may be asking, how do I set just a single player's skin instead of everyone on the server?   We do this with publicVariableClient.  I am unsure if you can call this command from clientside as I only use it serverside but here is how you do it regardless. // lets assume we want to set our cursorTarget's skin (the player we are looking at) _player = cursorTarget; _owner = owner _player; // owner command returns the client # we will need for the next step. _playerUID = getPlayerUID _player; _characterID = _player getVariable ["CharacterID","0"]; _skinClassName = "FR_GL"; // my personal skin PV_ChangePlayerSkin = [_playerUID, _characterID, _skinClassName]; _owner publicVariableClient "PV_ChangePlayerSkin"; // only send the PV to the specific client  
Now when we send our public variable we only send it to the client we wish to.  There are a myriad of ways to get player objects loaded into memory but that will be covered later.

wow what a duchebag.
 
Can you be more pretentious?
 
Seriously, this is a mod based on a MILITARY SIMULATOR.  If you don't like that fact, then IDK what to tell you.
 
Oh and by the way, DayZ (which epoch was based upon) had blocked out all militarized vehicles and "too op" weapons completely by overriding their classes in the config.bin file.
 
DayZEpoch was one of the first major DayZ mods that opened this all up for us to play with.  There was another, forget the name but it was poorly implemented.  Hell, that's one of the reasons I stuck around with epoch when it first came out.  None of the other mods allowed admins the amount of control over their own server like epoch did.
 
So get off your high horse and try to understand that people may want to play this game a bit more differently than you do and quit trying to stifle creativity!

What we are doing: Setting up an automated build process to compile the server and mission PBO on restart
Why: Ever needed to make changes to your server but had to wait for server restart?  Ever missed that window and had to wait another 3 - 4 hours till your next restart cycle? I hate that!
Requirements: PBOmanager, notepad++, firedaemon(optional) or knowledge of editing your batch scripts, a dev environemnt (you do have a dev environment don't you?), a dedicated server
Difficulty: Advanced
 
Ok guys, as stated before it is a huge pain in the ass to have to wait till your server goes down to push changes.  Why not automate it so that you can make your changes and be done with them?
 
So to start off you really should have a dev environment that mirrors your production environment.  I'm talking about a dev server here people.  Quick and dirty, just copy and paste your folder containing the Arma2OA install (you know the folder with @DayZ_Epoch_Server in it) to another directory.  Doesn't matter what the name is but you need to make changes here before you make them on your production server so you can verify that you didn't break anything.
 
 
Step 1: Install PBO manager if you have not.  you can get it here: http://www.armaholic.com/page.php?id=16369
Step 2: If you do not have unpacked folders of your PBO's living next to them in their proper directories, unpack your pbo's so that you have a folder with the same name in the same directory.  This is where you will make your changes.
Step 3: Create a batch script to run BEFORE your server starts.  This PBO will automatically pack up the folder into a PBO overwriting your old one.
 
Here is the content of my batch script "pbopack_dev.bat" (note that this is for the dev server, your path will not be the same"
 
 
"C:\Program Files\PBO Manager v.1.4 beta\PBOConsole.exe" -pack "D:\dayz\DEV_Epoch1\@DayZ_Epoch_Server\addons\dayz_server" "D:\dayz\DEV_Epoch1\@DayZ_Epoch_Server\addons\dayz_server.pbo" "C:\Program Files\PBO Manager v.1.4 beta\PBOConsole.exe" -pack "D:\dayz\DEV_Epoch1\MPMissions\DayZ_Epoch_11.Chernarus" "D:\dayz\DEV_Epoch1\MPMissions\DayZ_Epoch_11.Chernarus.pbo"  
 
Step 4: Integrate batch script into your current server restart method.  I use firedaemon, if you use a batch script, just make sure you run the previous batch before you start your server but after you have shut it down.  for firedaemon users, just add the batch script to the "pre-service programs".  Give it a nice 15 second timeout to ensure we didn't start the server too fast.
 
That's it.  Verify it works without breaking anything and you can implement this for your production servers.
 
 
Development and Deployment strategy:
 
Ok so I touched a little about this earlier but you MUST use a development environment.  Any programmer who has worked in a professional environment will know that you NEVER EVER EVER make changes to production code.  Firstly, its dangerous, secondly, it makes you look bad if you break a critical system because you were too lazy to test it properly.  Always make changes to your dev server first before you migrate those changes to the live prod environment!!!!!
 
Ideally,  you would want to have an exact mirror of your production server so that you can accurately verify your changes don't break something.
 
Here's how I do it.
 
Initial Setup:
1. Copy entire DayZ server directory to a new one (this only needs to be done once)
2. Backup your DayZ database and insert it as a new one (I use "DayzEpoch_DEV" for this)
3. Modify your hive.ini so it points to your dev database
4. Make changes on dev server and verify results.
 
After Setup:
1. Delete "@DayZ_Epoch_Server" and "mpmissions" directories from the DEV server folder.
2. Copy over "@DayZ_Epoch_Server" and "mpmissions" from your PROD server folder into the DEV server folder.
3. Make changes you need to the folders (no need to recompile as our script above does that for us)
4. Verify changes
 
Migrating changes from DEV to PROD on a Live server:
1. TEST YOUR CHANGES IN DEV
2. Navigate to your PROD server directory and delete the PBO's unpacked folders you wish to modify
3. Copy the unpacked folders from your DEV server to the PROD server
4. Wait for server restart to automatically recompile the folders into PBOs

You should have :
 

class CfgEpochClient {     buildingNearbyMilitary = 0; //1 to allow building nearby     buildingNearbyMilitaryRange = 300; //Define radius of blocked area     buildingRequireJammer = 0; // 1 = to allow building without a jammer     buildingCountLimit = 200; // how many objects can be built within range of a jammer     buildingJammerRange = 75; // jammer range in meters     class Altis     {         blockedArea[] = { //[POS],radius                 { { 16085, 16997, 0 }, 250 }, //South Telos                 { { 12844, 16714, 0 }, 120 }, //Soldner Base                 { { 3085, 13184, 0 }, 300 }, //Kavalar Carstel                 { { 13493, 12013, 0 }, 450 }, //Makrynisi (Island)                 { { 17439, 13165, 0 }, 165 }, //Pyrgorsk Military                 { { 20084, 6728, 0 }, 55 }, //West of Selakano                 { { 25303, 21807, 0 }, 100 } //Sofia             };     };     class Chernarus     {         blockedArea[] = {                 { { 10203, 1886, 0 }, 430 }, //South Electro                 { { 6822, 2498, 0 }, 600 }, //Cherno                 { { 4612, 9670, 0 }, 140 }, //NWAF south barack                 { { 4907, 10117, 0 }, 250 }, //NWAF NE hangas                 { { 4707, 10384, 0 }, 200 }, //NWAF north barack                 { { 4069, 10778, 0 }, 75 }, //NWAF west hangas                 { { 4553, 10722, 0 }, 150 }, //NWAF NW hangas                 { { 12279, 9505, 0 }, 350 }, //Berenzino Mid                 { { 12816, 9816, 0 }, 400 }, //Berenzino SE                 { { 12991, 10147, 0 }, 375 }, //Berenzino Docs                 { { 2693, 5138, 0 }, 200 }, //Zeleno                 { { 11467, 7508, 0 }, 150 }, //Polana Factory                 { { 13092, 7096, 0 }, 140 } //Solnichniy Factory         };     }; };

description
 
class Altis { blockedArea[] = { //[POS],radius { { 16085, 16997, 0 }, 250 }, //South Telos { { 12844, 16714, 0 }, 120 }, //Soldner Base  { { 3085, 13184, 0 }, 300 }, //Kavalar Carstel { { 13493, 12013, 0 }, 250 }, //Makrynisi (Island) { { 17439, 13165, 0 }, 165 }, //Pyrgorsk Military { { 20084, 6728, 0 }, 55 }, //West of Selakano { { 25303, 21807, 0 }, 100 } //Sofia }; };

What StonXer said, all inside the description.ext now

Hey guys, working on this code tonight, wanted to take a moment to thank you all for this thread - very helpful! vehicles will give you 50% discount, I promise :D

This simple Rank script is for those that RP a military, paramilitary, or militia type groups, and would like to set a specific group rank for individuals on log in.

I've used so many great scripts from this community, it's nice that I can make a small contribution of my own.

Very special thanks to hambeast for the original script example and helpful tips for making it better.
Without this guidance I may have never gotten this far.

Please copy, steal, modify, and/or share this script.
Just consider giving credit to hambeast and myself for this effort.
Thank you.

INSTALLATION:

1. Go to your MPMission folder and unpack your map pbo (ex. epoch.Chernarus.pbo)

2. In the folder look for init.sqf. If you do not have one you can create and empty file and name init.sqf

3. Add the following to the bottom of your init.sqf and save it.
//Ranks by hambeast and Evan Black []execVM "scripts\ranks.sqf"; 4. Create a folder called "scripts" (in the same place as init.sqf). If you already have this folder skip this step.

5. Open the scripts folder and create empty file called "ranks.sqf".

6. Add the following to the ranks.sqf file.
//ranks.sqf //Original Script by hambeast //Modified and Completed by Evan Black // Wait for ingame waitUntil {!isNuLL(uiNameSpace getVariable ["EPOCH_loadingScreen",displayNull])}; waitUntil {isNuLL(uiNameSpace getVariable ["EPOCH_loadingScreen",displayNull])}; sleep 2; //Optional delay to ensure script execution // Rank/UID list. Use Example Below. //UID Example: Ranks_CORPORAL = ["7656xxxxxxxxxxxxxx","7656xxxxxxxxxxxxxx"]; no trailing comma Ranks_CORPORAL = []; Ranks_SERGEANT = []; Ranks_LIEUTENANT = []; Ranks_CAPTAIN = []; Ranks_MAJOR = []; Ranks_COLONEL = []; _playerUID = getPlayerUID player; //get player UID //check to see if our player matches switch (true) do { case (_playerUID in Ranks_CORPORAL) : { player setRank "CORPORAL"; }; //setRank to CORPORAL for everyone in the CORPORAL list. case (_playerUID in Ranks_SERGEANT) : { player setRank "SERGEANT"; }; case (_playerUID in Ranks_LIEUTENANT) : { player setRank "LIEUTENANT"; }; case (_playerUID in Ranks_CAPTAIN) : { player setRank "CAPTAIN"; }; case (_playerUID in Ranks_MAJOR) : { player setRank "MAJOR"; }; case (_playerUID in Ranks_COLONEL) : { player setRank "COLONEL"; }; default { player setRank "PRIVATE"; }; //setting default rank for all others }; 7. Add the UIDs as per the example in script.
Note no trailing comma for each ID line and don't forget the quotes for each ID. This is important.
 
You can now repack your epoch.(Map) folder to pbo, Although most servers will run with it unpacked for testing.
No BE Script adjustments needed as far as my testing.
 
Ranks is based from hambeast's original script example responce from
 
Please send a like if you enjoy this script!

Swash, I am so happy what I typed helped you out!   I think we forget sometimes, just how hard it is to make the jump into Arma coding from other languages.  But... once you get the basics, the rest will become clear.

Thanks again hambeast for the scripting help. I'm not all that familiar with sqf, but I recognize coding patterns from other languages.
I had to add in a wait for ingame and I did some other modifications to the script.
With your permission I'd like to post the final script in the A3 Epoch Resources/Scripts for others to use.
Original script credit to you of course.
 
Here is the final script I intend to post.

Thank you hambeast you are the best! I'll try this out tonight.
 
 
 
This was one of the things I found in my search, but had no clue how to implement in sqf.
I read all that page and was left saying "um... what??" lol
I wish I could give this an extra like for posting comments in the script as well, wish everyone did this!
This was more than a "gentle nudge" this was above and beyond what I expected. Thank you!
 
btw great Mr. Reynholm avatar lol

first google result:
https://community.bistudio.com/wiki/setRank
 
 
You would call this within your script block.

player setRank "COLONEL"  
 
If you're asking how to implement this in your mission file... You could hardcode your group members ranks by ID in your init.sqf or anywhere else in your mission file if you liked...
 
something like this could work... no idea if it actually does what you want though...
// ranks.sqf - called from init.sqf // we could have 1 big multi-dim array containing each users ID and Rank but... // that would make this harder to adjust in the future since this is a manual // process. If you were to load this data from a DB for instance, you might // want to keep it in a multi-dimensional array like: // [["1234","PRIVATE"],["231","General"]] Ranks_PRIVATE = [ "1234567", // Me "7654321" // No trailing ,! ]; Ranks_CORPORAL = []; Ranks_SERGEANT = []; Ranks_LIEUTENANT = []; Ranks_CAPTAIN = []; Ranks_MAJOR = []; Ranks_COLONEL = []; _playerUID = player getPlayerUID; _found = false; _rank = "PRIVATE"; // default private rank // check to see if our player matches while {!_found} do { if (_playerUID in Ranks_PRIVATE) then { _rank = "PRIVATE"; _found = true; // breaks us out of this while loop }; // ... and so on }; // finally set our players rank! player setRank _rank;

The problem I have with 90% of the youtubes out there is their lack of instructional and educational value. Way too many of them are done with a "here do this to get that to happen, it works for me" reference. They are either too simplified (ie dumbed down) or too complex to be of much use for me. I spend 59 minutes of the 60 minutes of my free time looking for one that (a)actually makes sense, (b)applies to the issue I'm trying to learn about, and ©doesn't have excessive hyperbole or narrator nonsense.

I would love to see some instructional videos that explain why things are put where. (Even for the most mundane of tasks.)

While many of the instructions for installation of some of the scripts are often sparse (and have the understandable language barriers), learning by failing is not without merit. I've learned a lot of basics by failing. A video on how to copy and paste isn't going to be very helpful in the long run.

tldnr: Kudo's for the willingness to contribute. If possible, in you class and/or video try to be concise and explain why.

Yeah, thanks for your help in understanding PVEH, making the server do stuff for me was a big weakness of mine in my scripting arsenal.  :ph34r:

Late to the party as usual but just a couple of suggestions on the code.
 
In the _playersToSend loop, count is faster than forEach if you don't need to use the _forEachIndex special variable in the loop code.
 
nearentities is also faster than nearestObjects.
 
if (isPlayer _x) then {}; will detect if the player is a human player.
 
Hope this helps.

just for shits and giggles, can you declare a clientside PVEH just to spit out some text?
// Clientside PVEH (init this in your mission.pbo) if (!isDedicated) then { // expects [] "PVEH_PlaySoundClient" addPublicVariableEventHandler { systemChat "We got our PVEH"; }; }; try placing that in your init.sqf along with your server side one.  maybe declare this one first.

hmm... try adding _clientID to the private array at the top of the expression.  It could be a locality issue?  aside from that I'm not really sure.  
 
I'll have to play with the code tonight and see if I can't generate you a sample pbo to play with

What you want to do is define a PVEH on the clientside (most likely in the init.sqf or a sqf file called from that) that when fired off, plays a sound.
 
How you fire it off is the tricky part as you probably only want people in say a 30m radius to hear the sound.  You could be lazy and just fire it off to everyone.
 
 
So here's how I would do it quick and dirty.  Note, there is probably a better way to do this but its monday...
 
So, you need 2 pveh.
 
1.  Serverside PVEH to get our call from our player and send to other players
2.  Clientside PVEH to actually play the sound.
// Serverside PVEH (Init this in your server.pbo) if (isDedicated) then { // expects [Player,Radius] "PVEH_PlaySoundServer" addPublicVariableEventHandler { private["_packet", "_sender", "_radius", "_playersToSend"]; _packet = _this select 1; _sender = _packet select 0; _radius = _packet select 1; _playersToSend = nearestObjects [_sender, ["CAmanBase"], _radius]; { _clientID = owner _x; PVEH_PlaySoundClient = []; _clientID publicVaribleClient "PVEH_PlaySoundClient"; } forEach _playersToSend; }; }; // Clientside PVEH (init this in your mission.pbo) if (!isDedicated) then { // expects [] "PVEH_PlaySoundClient" addPublicVariableEventHandler { // play sound code goes here }; }; Now please note, that the "get players within raidus" code is probably inefficient and probably buggy.  I'm sure there is a better way to do this and you are free to look into that part, I just wrote this up real quick to give you an idea on how you can do this.
 
 
edit: sorry I forgot, somewhere in your code to kick this off, you will need to call a publicVariableServer command to kick it off like this:
PVEH_PlaySoundServer = [player,30]; // [player,radius] publicVariableServer "PVEH_PlaySoundServer";

DnD feel powers I have working so far.... but many bugs need killing and settings need tweaking.
 
- Ninja Teleport                     ( puff of smoke at both points of teleport)
- Zeus Teleport                      ( lightning bolt strike before player appears) - Zeus's Fury                         ( lightning strike target) - Lucifer's Rage                     ( meteor strike type strike) - Necromancer's Prey           ( spawn 2 zombies by clicking map) - Psychic's Curse                  ( ESP, humanoids always, toggle vehicle view) - Human Torch                      ( Set on fire and fly around) - Finger of God                      ( Point and it dies) - God's Blessing                    ( Fully heal, option to make target a god) - Wanderer's Knowledge       ( Constant information on players location, dir, etc)
- Observer's Knowledge        ( Constant information on what player is looking at)
- FIghter's Wrath                     (Punch some fools)
 
https://www.youtube.com/watch?v=tisIA7cavPs

FYI, this guide is for advanced arma coders.  This guide will assume you know how to pack/unpack PBO's, edit files, and are comrfortable with coding.  You must also have an understanding of locality as in client vs server side.
 
A note on locality:  Your mpMissions folder is NOT only client side.  When I started coding I made this assumption and I was wrong.
 
 
Lesson 1:  Event Handlers Basics
 
Event handlers are the bread and butter of Arma2 MP coding.  They are little logic functions that the server sets aside until they are called by a public variable.  In my experience they have very low overhead so don't be afraid to make use of them.
 
example 1: Change players skin
Add this code to the bottom of your init.sqf (in your mpMission)
// expects: [_playerUID,_CharacterID,_skinClassName] // this line says ONLY run on the ClientSide.  The server will see this and ignore it.  This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then {   "PV_ChangePlayerSkin" addPublicVariableEventHandler {     // handle our packet.  _this select 0 returns the PV name, _this select 1 returns our input packet    _packet = _this select 1;  // should contain [_playerUID, _characterID, _skinClassName]    _playerUID = _packet select 0;    _characterID = _packet select 1;    _skinClassName = _packet select 2;       // set our player to the skin    [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph;   }; }; Ok so now we got our event handler set up, if any client sends the PV "PV_ChangePlayerSkin" all clients connected will execute this event handler.  Here is how we send the command to all players.  This code can be called anywhere, on a client, or from the server itself.
 
example:
  PV_ChangePlayerSkin = [_playerUID,_CharacterID,_skinClassName];   publicVariable "PV_ChangePlayerSkin"; But you may be asking, how do I set just a single player's skin instead of everyone on the server?   We do this with publicVariableClient.  I am unsure if you can call this command from clientside as I only use it serverside but here is how you do it regardless. // lets assume we want to set our cursorTarget's skin (the player we are looking at) _player = cursorTarget; _owner = owner _player; // owner command returns the client # we will need for the next step. _playerUID = getPlayerUID _player; _characterID = _player getVariable ["CharacterID","0"]; _skinClassName = "FR_GL"; // my personal skin PV_ChangePlayerSkin = [_playerUID, _characterID, _skinClassName]; _owner publicVariableClient "PV_ChangePlayerSkin"; // only send the PV to the specific client  
Now when we send our public variable we only send it to the client we wish to.  There are a myriad of ways to get player objects loaded into memory but that will be covered later.

ok, I think I got them all.  If you see any more let me know.

did you try turning it off and on again?

FYI, this guide is for advanced arma coders.  This guide will assume you know how to pack/unpack PBO's, edit files, and are comrfortable with coding.  You must also have an understanding of locality as in client vs server side.
 
A note on locality:  Your mpMissions folder is NOT only client side.  When I started coding I made this assumption and I was wrong.
 
 
Lesson 1:  Event Handlers Basics
 
Event handlers are the bread and butter of Arma2 MP coding.  They are little logic functions that the server sets aside until they are called by a public variable.  In my experience they have very low overhead so don't be afraid to make use of them.
 
example 1: Change players skin
Add this code to the bottom of your init.sqf (in your mpMission)
// expects: [_playerUID,_CharacterID,_skinClassName] // this line says ONLY run on the ClientSide.  The server will see this and ignore it.  This means that when a client gets this command, they and only they will execute this. if (!isDedicated) then {   "PV_ChangePlayerSkin" addPublicVariableEventHandler {     // handle our packet.  _this select 0 returns the PV name, _this select 1 returns our input packet    _packet = _this select 1;  // should contain [_playerUID, _characterID, _skinClassName]    _playerUID = _packet select 0;    _characterID = _packet select 1;    _skinClassName = _packet select 2;       // set our player to the skin    [_playeruid,_characterID, _skinClassName] spawn player_humanityMorph;   }; }; Ok so now we got our event handler set up, if any client sends the PV "PV_ChangePlayerSkin" all clients connected will execute this event handler.  Here is how we send the command to all players.  This code can be called anywhere, on a client, or from the server itself.
 
example:
  PV_ChangePlayerSkin = [_playerUID,_CharacterID,_skinClassName];   publicVariable "PV_ChangePlayerSkin"; But you may be asking, how do I set just a single player's skin instead of everyone on the server?   We do this with publicVariableClient.  I am unsure if you can call this command from clientside as I only use it serverside but here is how you do it regardless. // lets assume we want to set our cursorTarget's skin (the player we are looking at) _player = cursorTarget; _owner = owner _player; // owner command returns the client # we will need for the next step. _playerUID = getPlayerUID _player; _characterID = _player getVariable ["CharacterID","0"]; _skinClassName = "FR_GL"; // my personal skin PV_ChangePlayerSkin = [_playerUID, _characterID, _skinClassName]; _owner publicVariableClient "PV_ChangePlayerSkin"; // only send the PV to the specific client  
Now when we send our public variable we only send it to the client we wish to.  There are a myriad of ways to get player objects loaded into memory but that will be covered later.

Here's a netbeans sqf solution: http://www.armaholic.com/page.php?id=14714
 
and my personal favorite eclipse plugin for sqf:  http://forums.bistudio.com/showthread.php?124120-ArmADev-Eclipse-Plugin
 
honestly squint is pretty rough around the edges.  It throws a lot of false positives from what I've seen.  Also pretty damn ugly to work with imo.
 
both of the solutions I've posted integrate with SVN and Git right out of the box and to me that is a huge advantage.  If you aren't using version control when you are coding, you are doing it wrong!