Darth_Rogue

That still requires that all connected users have that pack and load it when they join the server in order for them to see the items.  I wouldn't recommend doing that, but it's up to each server admin to decide.  

I was able to get this to work very easily.  The image files you need for the updated icons are already in the dayz_code.pbo, so everyone already has them.  There is no need to copy them to the mission file.  All you have to do is pull 'player_UpdateGUI.sqf' from "dayz_code\compiles" and place it in your mission file in a folder called "fixes".  Then edit your compiles.sqf to point to the player_updateGUI.sqf from the fixes folder.  See below.
player_lockVault = compile preprocessFileLineNumbers "\z\addons\dayz_code\compile\player_lockVault.sqf"; // control_zombieAgent = compile preprocessFileLineNumbers "\z\addons\dayz_code\compile\control_zombieAgent.sqf"; //player_updateGui = compile preprocessFileLineNumbers "\z\addons\dayz_code\compile\player_updateGui.sqf"; player_updateGui = compile preprocessFileLineNumbers "fixes\player_updateGui.sqf"; Pay close attention to the paths in the code below referencing the .paa files and you will see that they are being called now from the "status" folder in dayz_code.  You can either edit the paths to your liking as I have, or you can copy and paste the entire contents of the file into yours.  The code below is the complete player_updategui.sqf file.
private ["_display","_ctrlBlood","_ctrlBleed","_bloodVal","_ctrlFood","_ctrlThirst","_thirstVal","_foodVal","_ctrlTemp","_tempVal","_combatVal","_array","_ctrlEar","_ctrlEye","_ctrlCombat","_ctrlFracture","_visualText","_visual","_audibleText","_audible","_blood","_thirstLvl","_foodLvl","_tempImg","_thirst","_food","_temp","_bloodLvl","_tempLvl","_color","_string","_humanity","_size","_friendlies","_charID","_rcharID","_rfriendlies","_rfriendlyTo","_distance","_targetControl","_humanityTarget"]; disableSerialization; _foodVal = 1 - (dayz_hunger / SleepFood); _thirstVal = 1 - (dayz_thirst / SleepWater); _tempVal = 1 - ((dayz_temperatur - dayz_temperaturmin)/(dayz_temperaturmax - dayz_temperaturmin)); // Normalise to [0,1] _combatVal = 1 - dayz_combat; // May change later to be a range of red/green to loosely indicate 'time left in combat' if (uiNamespace getVariable ['DZ_displayUI', 0] == 1) exitWith { _array = [_foodVal,_thirstVal]; _array }; _display = uiNamespace getVariable 'DAYZ_GUI_display'; _ctrlBlood = _display displayCtrl 1300; _ctrlBleed = _display displayCtrl 1303; _bloodVal = r_player_blood / r_player_bloodTotal; _ctrlFood = _display displayCtrl 1301; _ctrlThirst = _display displayCtrl 1302; _ctrlTemp = _display displayCtrl 1306; //TeeChange _ctrlEar = _display displayCtrl 1304; _ctrlEye = _display displayCtrl 1305; //_ctrlHumanity = _display displayCtrl 1207; _ctrlCombat = _display displayCtrl 1307; _ctrlFracture = _display displayCtrl 1203; //Food/Water/Blood _ctrlBlood ctrlSetTextColor [(Dayz_GUI_R + (0.3 * (1-_bloodVal))),(Dayz_GUI_G * _bloodVal),(Dayz_GUI_B * _bloodVal), 0.5]; _ctrlFood ctrlSetTextColor [(Dayz_GUI_R + (0.3 * (1-_foodVal))),(Dayz_GUI_G * _foodVal),(Dayz_GUI_B * _foodVal), 0.5]; _ctrlThirst ctrlSetTextColor [(Dayz_GUI_R + (0.3 * (1-_thirstVal))),(Dayz_GUI_G * _thirstVal),(Dayz_GUI_B * _thirstVal), 0.5]; _ctrlTemp ctrlSetTextColor [(Dayz_GUI_R + (0.3 * (1-_tempVal))), (Dayz_GUI_G * _tempVal), _tempVal, 0.5]; // Color ranges from iceblue (cold) to red (hot) _ctrlCombat ctrlSetTextColor [(Dayz_GUI_R + (0.3 * (1-_combatVal))),(Dayz_GUI_G * _combatVal),(Dayz_GUI_B * _combatVal), 0.5]; /* Blood: round((r_player_blood / 2) / 1000) = _bloodLvl (6 = full, 1 = empty) Thirst: round(_thirstVal / 0.25) = _thirstLvl (4 = full, 0 = empty) Hunger: round(_foodVal / 0.25) = _foodLvl (4 = full, 0 = empty) Temp: round(dayz_temperatur) = tempLvl (>= 36 = full <= 28 = empty) */ _blood = ""; _thirst = ""; _food = ""; _temp = ""; _tempImg = 0; _bloodLvl = round((r_player_blood / 2) / 1000); _thirstLvl = round(_thirstVal / 0.25); _foodLvl = round(_foodVal / 0.25); _tempLvl = round(dayz_temperatur); /* diag_log format["DEBUG: bloodlvl: %1 r_player_blood: %2 bloodval: %3",_bloodLvl, r_player_blood, _bloodVal]; diag_log format["DEBUG: thirstlvl: %1 dayz_thirst: %2 thirstval: %3",_thirstLvl, dayz_thirst, _thirstVal]; diag_log format["DEBUG: foodlvl: %1 dayz_hunger: %2 foodval: %3",_foodLvl, dayz_hunger, _foodVal]; diag_log format["DEBUG: templvl: %1 dayz_temperatur: %2 tempval: %3",_tempLvl, dayz_temperatur, _tempVal]; */ if (_bloodLvl <= 0) then { //_blood = "\z\addons\dayz_code\gui\status_blood_inside_1_ca.paa"; _blood = "\z\addons\dayz_code\gui\status\status_blood_inside_1_ca.paa"; } else { //_blood = "\z\addons\dayz_code\gui\status_blood_inside_" + str(_bloodLvl) + "_ca.paa"; _blood = "\z\addons\dayz_code\gui\status\status_blood_inside_" + str(_bloodLvl) + "_ca.paa"; }; if (_thirstLvl < 0) then { _thirstLvl = 0 }; //_thirst = "\z\addons\dayz_code\gui\status_thirst_inside_" + str(_thirstLvl) + "_ca.paa"; _thirst = "\z\addons\dayz_code\gui\status\status_thirst_inside_" + str(_thirstLvl) + "_ca.paa"; if (_foodLvl < 0) then { _foodLvl = 0 }; //_food = "\z\addons\dayz_code\gui\status_food_inside_" + str(_foodLvl) + "_ca.paa"; _food = "\z\addons\dayz_code\gui\status\status_food_inside_" + str(_foodLvl) + "_ca.paa"; if ( _tempLvl >= 36 ) then { _tempImg = 4 }; if ( _tempLvl > 33 and _tempLvl < 36 ) then { _tempImg = 3 }; if ( _tempLvl >= 30 and _tempLvl <= 33 ) then { _tempImg = 2 }; if ( _tempLvl > 28 and _tempLvl < 30 ) then { _tempImg = 1 }; if ( _tempLvl <= 28 ) then { _tempImg = 0 }; //_temp = "\z\addons\dayz_code\gui\status_temp_" + str(_tempImg) + "_ca.paa"; _temp = "\z\addons\dayz_code\gui\status\status_temp_" + str(_tempImg) + "_ca.paa"; _ctrlBlood ctrlSetText _blood; _ctrlThirst ctrlSetText _thirst; _ctrlFood ctrlSetText _food; _ctrlTemp ctrlSetText _temp; /* Visual: */ _visualtext = ""; _visual = (round((dayz_disVisual / 100) * 4)) min 5; //if (_visual > 0) then {_visualtext = "\z\addons\dayz_code\gui\val_" + str(_visual) + "_ca.paa"}; if (_visual > 0) then {_visualtext = "\z\addons\dayz_code\gui\status\val_" + str(_visual) + "_ca.paa"}; _ctrlEye ctrlSetText _visualtext; /* Audible: */ _audibletext = ""; _audible = (round((dayz_disAudial / 50) * 4)) min 5; //if (_audible > 0) then {_audibletext = "\z\addons\dayz_code\gui\val_" + str(_audible) + "_ca.paa"}; if (_audible > 0) then {_audibletext = "\z\addons\dayz_code\gui\status\val_" + str(_audible) + "_ca.paa"}; _ctrlEar ctrlSetText _audibletext; /* Fracture: */ if (!canStand player) then { if (!(ctrlShown _ctrlFracture)) then { r_fracture_legs = true; _ctrlFracture ctrlShow true; }; }; /* Flashing: */ if (_combatVal == 0) then { _ctrlCombat call player_guiControlFlash; }; if (_bloodVal < 0.2) then { _ctrlBlood call player_guiControlFlash; }; if (_thirstVal < 0.2) then { _ctrlThirst call player_guiControlFlash; }; if (_foodVal < 0.2) then { _ctrlFood call player_guiControlFlash; }; if (_tempVal > 0.8) then { //TeeChange _ctrlTemp call player_guiControlFlash; } else { _ctrlTemp ctrlShow true; }; if (r_player_injured) then { _ctrlBleed call player_guiControlFlash; }; /* Opt-in tag system with friend tagging */ _targetControl = _display displayCtrl 1199; _string = ""; _humanityTarget = cursorTarget; if (!isNull _humanityTarget and isPlayer _humanityTarget and alive _humanityTarget) then { _distance = (player distance _humanityTarget); if (_distance < DZE_HumanityTargetDistance) then { _size = (1-(floor(_distance/5)*0.1)) max 0.1; // Display name if player opt-in or if friend _friendlies = player getVariable ["friendlies", []]; _charID = player getVariable ["CharacterID", "0"]; _rcharID = _humanityTarget getVariable ["CharacterID", "0"]; _rfriendlies = _humanityTarget getVariable ["friendlies", []]; _rfriendlyTo = _humanityTarget getVariable ["friendlyTo", []]; if ((_rcharID in _friendlies) and (_charID in _rfriendlies)) then { if (!(_charID in _rfriendlyTo)) then { // diag_log format["IS FRIENDLY: %1", _player]; _rfriendlyTo set [count _rfriendlyTo, _charID]; _humanityTarget setVariable ["friendlyTo", _rfriendlyTo, true]; // titleText [format[(localize "STR_EPOCH_ACTIONS_17"), (name _humanityTarget)], "PLAIN DOWN"]; }; // <br /><t %2 align='center' size='0.7'>Humanity: %3</t> _color = "color='#339933'"; _string = format["<t %2 align='center' size='%3'>%1</t>",(name _humanityTarget),_color,_size]; } else { // Humanity checks _humanity = _humanityTarget getVariable ["humanity",0]; _color = "color='#ffffff'"; if(_humanity < -5000) then { _color = "color='#ff0000'"; } else { if(_humanity > 5000) then { _color = "color='#3333ff'"; }; }; if(_humanityTarget getVariable ["DZE_display_name", false]) then { _string = format["<t %2 align='center' size='%3'>%1</t>",(name _humanityTarget),_color,_size]; }; }; }; }; // update gui if changed if (dayz_humanitytarget != _string) then { _targetControl ctrlSetStructuredText (parseText _string); dayz_humanitytarget = _string; }; _array = [_foodVal,_thirstVal]; _array The only thing I don't like is how small they appear now.  I will work on finding a way to increase their size to increase visibility and post an update once I'm successful.
 
Enjoy!  :)

I wish the RHS guys would include an optional PBO you can add that would disable all scripts in the RHS stuff.  Would make things a lot easier for folks not wanting to run the Escalation mod per se.  

Unofficial PHP Battleye Builder
 
Q. What is it A. It builds the epoch BE filters from a default set   Q. OK so what does it do. A. It builds the epoch BE filters from a default set AND applies any modification you want to make by merging them   https://github.com/Dwarfer/phpbebuilder   ** ALWAYS TAKE BACKUPS ITS YOUR OWN FAULT IF SOMETHING GOES WRONG AND YOU DON'T HAVE ONE **
  Features Merge custom filters with the default epoch ones pull the default filters from the Github for better automation Override the BE filter level using the merge file automatically writes the publicvariable.txt.original to work alongside Watchdog   an example output from the run $ php bebuilder.php Building addbackpackcargo.txt Writing default addbackpackcargo.txt Building addmagazinecargo.txt Writing default addmagazinecargo.txt Building addweaponcargo.txt Writing default addweaponcargo.txt Building attachto.txt Merging the diffs writing attachto.txt Building createvehicle.txt Writing default createvehicle.txt Building deleteVehicle.txt Writing default deleteVehicle.txt Building mpeventhandler.txt Writing default mpeventhandler.txt Building publicvariable.txt Merging the diffs writing publicvariable.txt Building publicvariableval.txt Writing default publicvariableval.txt Building remotecontrol.txt Writing default remotecontrol.txt Building remoteexec.txt Writing default remoteexec.txt Building scripts.txt Merging the diffs writing scripts.txt Building selectplayer.txt Writing default selectplayer.txt Building setdamage.txt Merging the diffs writing setdamage.txt Building setpos.txt Writing default setpos.txt Building setvariable.txt Merging the diffs writing setvariable.txt Building setvariableval.txt Writing default setvariableval.txt Building teamswitch.txt Writing default teamswitch.txt Building waypointcondition.txt Writing default waypointcondition.txt Building waypointstatement.txt Writing default waypointstatement.txt

Have you disabled server events?  If not, try it and see if you don't see an end to those random dips.  

From Dwarden on Reddit, replying to my comments about the community needing better education on editing the basic.cfg:
[–]DwardenTech Community Manager[S] 1 point an hour ago there are several factors which play role but the thing is, after 1.46 the old basic.cfg might not be true (since 1.42 we optimize networking) also by my fastest servers usually up to 40-50 players the server had flatline 50fps over 50 players the FPS slowly drops, over 72 players negative effect gets multiplied each 2 players playable 20+ fps threshold is 100-110 players which I would like to push to 128 in future if optimizing goes well So by having this knowledge and adding in the knowledge of our current performance levels that we're talking about here in this thread, we can extrapolate that by using the Epoch mod and whatever other addon scripts we have, it's dropping server performance by about 40-50% more than a stock Arma server.  One thing that we have to keep in mind is that BI can only optimize their own code so much.  They can't possibly take into account whatever mods or scripts are out in the wild.  If they're aiming for 20 server FPS with 128 connected players on a stock server, then probably the best we can hope for is going to be around 70 players with our current script packages.  Granted, the script addons package (welcome messages, death messages, status bar, respawn loadouts, etc.) will vary from server to server, and consequently the performance and player count will vary right along with it, but that's probably a solid baseline to shoot for.  As Epoch development continues and they have a chance to optimize the final code it may get better over time, leaving a little more headroom, but we will have to wait and see.  

From Dwarden on Reddit, replying to my comments about the community needing better education on editing the basic.cfg:
[–]DwardenTech Community Manager[S] 1 point an hour ago there are several factors which play role but the thing is, after 1.46 the old basic.cfg might not be true (since 1.42 we optimize networking) also by my fastest servers usually up to 40-50 players the server had flatline 50fps over 50 players the FPS slowly drops, over 72 players negative effect gets multiplied each 2 players playable 20+ fps threshold is 100-110 players which I would like to push to 128 in future if optimizing goes well So by having this knowledge and adding in the knowledge of our current performance levels that we're talking about here in this thread, we can extrapolate that by using the Epoch mod and whatever other addon scripts we have, it's dropping server performance by about 40-50% more than a stock Arma server.  One thing that we have to keep in mind is that BI can only optimize their own code so much.  They can't possibly take into account whatever mods or scripts are out in the wild.  If they're aiming for 20 server FPS with 128 connected players on a stock server, then probably the best we can hope for is going to be around 70 players with our current script packages.  Granted, the script addons package (welcome messages, death messages, status bar, respawn loadouts, etc.) will vary from server to server, and consequently the performance and player count will vary right along with it, but that's probably a solid baseline to shoot for.  As Epoch development continues and they have a chance to optimize the final code it may get better over time, leaving a little more headroom, but we will have to wait and see.  

I totally understand and agree.  However, once you make that suggestion people can't help themselves but to start pointing fingers back and forth between the private/public development debate.  There's pros and cons both ways.  Yes, more large scale testing is needed.  But what are the devs supposed to do when they can't get more than 20 people on any of the testing servers?  Giving the unfinished code to a public, more populated server isn't a good answer either, since if it's buggy then players will complain and leave, and likely start bad-mouthing the mod since they don't fully understand the process.  
 
I've said for a long time that the devs should have a dedicated group of testers who volunteer for the process and know what they're getting into and how to actually test things.  The idea of 'Official' servers clearly isn't working as planned, since they just don't get the traffic needed to really debug anything.  There are dozens of dedicated server owners on here (myself included) who would be willing to donate our time and efforts to join a closed, passworded server run by the Epoch team where they can get a bunch of we server owners on it and do proper testing.  If everyone brought one or two people we trust with us they would have a full server in no time and the devs could get some good, real-world performance data and could make adjustments accordingly.  That wouldn't be feasible for cases like we had last week where a BI update necessitates a knee-jerk Epoch update to keep things running, but for the major Epoch updates it would definitely help.  
 
See what I mean?  People can't help but turn into an armchair-developer.  lol!

Well the root of the problem is Arma and its CPU and bandwidth usage.  Just when you think you've found the magic bullet to make everything playable, BI goes and makes "optimizations" and sets you back to square 1.  
 
 
BI's Optimizations:

Let's try to keep this constructive, guys.  Everyone can point a finger from their respective side of the fence and say 'They should have done X or Y'.  Let's just work together and try to help make it better for everyone.  

I incorporated something similar into the server restart batch.  It automatically updates files placed in a specified folder to the production server on a restart cycle.  It's a huge time saver and also helps make sure you don't copy the wrong files to the wrong place.  
 

Status Bar With Icons & Server FPS display

After seeing all the struggles people were having in other threads I decided to redo this script to make it easier for folks to understand and edit. This has much of the same functionality and generally appears similar to Scarr's build but the back end code is much simpler and should therefore be easier for scripting noobs like myself to see what's going on where and make changes as needed.

The color gradients can be edited to suite your liking, but I feel it's pretty well spot on the way it is. Your mileage may vary.

Admins can add their UIDs to have the status bar show a real-time server FPS reading and also display their world space coords, which will be very helpful when doing map edits and object placement without having to use an editor just for a few small items.
 
 
UPDATE - v1.36 Released
 
Due to multiple requests I have added a feature to the status bar where the bar will resize automatically based on player interface size.
 
To update:  Remove the current 'status_bar' folder from your mission file and replace it with the 'status_bar' folder you will download from Github.  No other changes should be needed.  BE filters are the same.  
Here are a couple screenshot showing what it looks like

For Admins

For Players

Install Instructions





DOWNLOAD

Credits: See Github

156 works fine. I've got it successfully blocking the RHS menu for all clients.

updated the scripts and added new ones to ensure crypto is removed ...

:P :D

Status Bar With Icons & Server FPS display

After seeing all the struggles people were having in other threads I decided to redo this script to make it easier for folks to understand and edit. This has much of the same functionality and generally appears similar to Scarr's build but the back end code is much simpler and should therefore be easier for scripting noobs like myself to see what's going on where and make changes as needed.

The color gradients can be edited to suite your liking, but I feel it's pretty well spot on the way it is. Your mileage may vary.

Admins can add their UIDs to have the status bar show a real-time server FPS reading and also display their world space coords, which will be very helpful when doing map edits and object placement without having to use an editor just for a few small items.
 
 
UPDATE - v1.36 Released
 
Due to multiple requests I have added a feature to the status bar where the bar will resize automatically based on player interface size.
 
To update:  Remove the current 'status_bar' folder from your mission file and replace it with the 'status_bar' folder you will download from Github.  No other changes should be needed.  BE filters are the same.  
Here are a couple screenshot showing what it looks like

For Admins

For Players

Install Instructions





DOWNLOAD

Credits: See Github

v1.5g is up:
 
M3Editor support.  You can now directly import bases/building layouts from M3Editor.  Additionally, FuMS will support translation of the base to any location on ANY map.
Static Weapon support
New AI logic for static weapons
New AI logic for posting guards in towers and upper stories of buildings
New Trigger: Zupa Capture points:  Missions can now be controlled off single/multiple capture points - based heavily upon Zupa's Capture points.
 
Some bug fixes. (see GitHub)

Great idea! I see no reason why all the server files couldn't be put on a public Git. Then we can see which files have changed and only update the necessary stuff. Or if there's a major release you can download the whole server pack as a zip.

Thanks to feedback received, I have decided to stage our server releases on the public Epoch GitHub from now on. Server owners can now can see what files have changed and get quicker access to updates and fixes.
 
https://github.com/EpochModTeam/Epoch/tree/master/Server_Install_Pack
 
Lastest Stable Server Files: https://github.com/EpochModTeam/Epoch/archive/master.zip

Moved content to: http://maca134.co.uk/arma-3/redisdump-arma-3-epoch-backup-tool/

CPS affects AI calculations mainly.  The higher the CPS value the more responsive AI entities will be to player interactions and the environment.  For instance, low CPS will cause things like Sappers to run around randomly instead of seeking out players based on their location, or AI units at missions to not accurately respond to incoming fire.  FPS is more of a measure of how responsive the server is to player interactions, like how quickly the inventory window is populated when you bring it up while looting, or how often position updates are sent when there are multiple people riding together in a vehicle.  Of the two, FPS is more important since player perception is what matters, but part of the experience is having responsive AI too, so it's best to keep them both as high as possible.  

Great idea! I see no reason why all the server files couldn't be put on a public Git. Then we can see which files have changed and only update the necessary stuff. Or if there's a major release you can download the whole server pack as a zip.

Hi Guys,
 
I have been wondering for awhile now if it would be better to detach the BattlEye Filters from the main epochserver package for the following reasons.
 
1) Every time 1 line needs changing we have a new epochserver package to download and install, I know that generally you just need to copy the one file from the package and update just that file however the majority of the community think they have to re apply the whole server update again and this is causing confusion.  I for one have been asked online and offline about 10 times in the last 3-4 days about what needs to be done to update.
 
2) Server owners to save themselves some hassle pick though the BE filters to find out what has changed, Yes we can use the varius diff but would it not be nice just to be able to see the diff's in one place ?  I for one would vote for this
 
3) Quicker reactions to problems/bugs or hacks.  Without having to compile X or Y.
 
4) Automation.  I for one could easily see a way to automate BE filter updates directly from the DEV's and apply my own additions automatically every restart thus moving hassle away from Admins and also giving the players a better experience. 
 
I am sure there are more but these were some of my top list.
 
Q. How could this be done
A. Easily. Version Control AKA GITHUB
To show what I mean I have setup  the following on github as I believe example are always better :-)
 
https://github.com/Dwarfer/a3epochbattleye
 
If you look at the following page you can start to see how this would work (click on one of the codes like fc16bb9 and 64dc4da)
 
https://github.com/Dwarfer/a3epochbattleye/commits/master/battleye
 
example
https://github.com/Dwarfer/a3epochbattleye/commit/64dc4da2c6e42ad9d60e8f83099e1a2adf137ac0#diff-eebd98b941739af49105df774982d418
 
This also shows A nice easy place to see changes
https://github.com/Dwarfer/a3epochbattleye/tree/master/battleye
 
Nice Release View and easy to download most up to date (easy scripting place)
https://github.com/Dwarfer/a3epochbattleye/releases
 
This shows you what the differences are between the release thus making it easier to apply the updates.
 
For those who are wondering how you would use this as a base to mod your own lines in. Well you can use various tools to append, find, replace and change any number of lines or even a simple merge.
 
I personally am happy to keep this up to date as best I can if people think it would help but ideally it would be great for the DEV's to run as I think it will be more helpful for everyone.
 
I would be happy to write some documents and howto's and even videos on how server admins would/could use this.
 
** I should say that the DEV's will already be doing this anyway within the private github however what would be the harm of just making the BE filters public ?
 
As I side note I also think GSP's would find this very useful for keeping there servers up to date.
 
What do people think ? Does this sound like something that would help the community and or DEV's ? or is this just the ramblings of a Humble Dwarf who has been trying to help other server admins out
 
Dwarfer
 
P.s.
If the dev's want to to take do the Hub let me know.

Thank you, Awol and team, for all that you do!  Please don't feel that your efforts are not respected and appreciated, because that couldn't be further from the truth!  This update today blind-sided most of us.  I can't speak for everyone, but I had no idea there was an Arma update coming today or that there was even a 1.44 RC out, which is surprising because I'm normally on top of that stuff.  Had we known the update was coming we could have prepared our players a day or two ahead and let them know that there could potentially be some issues, as should be expected anytime there's an Arma update.  
 
Perhaps you could create a e-mailing list or a news section on the forums only for verified server hosters so we can stay up to speed on the things that are coming down the pike.  Then we can take that official information and distribute it to our players in advance.  That would definitely help things go over more smoothly among all the various communities.  There will still be complainers, as there always will be, but it will help.  

**cough** Dedibox **cough**   :ph34r: