terox

Maybe he is running a client server and not a dedicated, he doesn't make it clear

The ssd will only improve start up, it wont have an effect on performance for a server (only a client) For the client it speeds up loading of textures and creates a non stuttering frames The server does nothing with graphics. Have a word with Dwarden too and get hold of the latest performance server.exe if you are running stable

Hi Roy, Before I move suggestions about Orbat and Recon to the dev heaven tracker, I thought it might be more prudent to get opinions from others who follow this thread So here is my complete overview in one post ------------------------------------------------------------------------------------------------------------------------------------------------ If I were to mod this, this is most likely what i would do...... (Much of this is already implemented) _________ OVERVIEW __________ <<< UNIT CLASSES & ROLES >>> Available equipment is restricted by role Available roles are restricted by unit class The orbat is made up from the following classes CLASS ---------- ROLES ---------- SPECIALIST ROLE ---------- SPECIALIST EQUIPMENT "Officer" C.O Mission commander slot X.O Mission Commander assistant Access to Artillery GUI & Squad management GUI Access to UAV if no recon element present Ideal slot for the admin "Recon Paramedic" Recon Leader Range finder, Thermal Imaging scopes Recon Scout (UAV trained) Range finder, Thermal Imaging scopes & UAV equipment Recon Scout (F.O)/JTAC Trained Range finder, Thermal Imaging scopes & Laser designator Recon Paramedic Range finder, Thermal Imaging scopes "Medic" & "Expl spec" Leader Range finder & a simple Thermal Imaging scope Rifleman Basic grunt can also drive light vehicles AT AT weaponry MG MG/AR weaponry Grenadier UGL Marksman Marksman rifles (Without High powered zoom scopes) EOD Specialist Explosive ordinance (Only available for "Expl spec" class Medic Medic kits (Only available for "Medic" class Possibly more roles (see notes *b* at the bottom of this post) "Repair specialist" "Support" Combination Driver/Pilot Defensive weaponry and satchels so they can destroy their vehicles These are the only class that can drive heavy vehicles or pilot aircraft Possibly "Squad leader" class see Notes *a* at the bottom of this post This would remove the leader role from medic, Explosive specialist class and place it for selection in this class. A group leader shouldnt really be getting involved with medic or EOD duties There is an oversight in the squad management ability to swap players roles. You are allowed to keep equipment from your existing role and then add to that equipment from the newly assigned role and could therefore become elitist (AT Sniper Medic) Its also possible to cheat by dropping your equipment on the floor or storing it in a vehicle or ammo crate (Not so easy to script against) My fix for this would be........... Changing roles removes all equipment from the unit, automatically replacing it with a basic kit for the new role VAS can then be used to customise the loadout further with restricted equipment To avoid cheating with this functionality, a player can only be reassigned a new role if they are within the base perimeter The player assigning the role, eg the Admin or group leader, X.O, Mission commander can assign the role to a player from anywhere. If the Admin/Group leader is assigning a role to themselves, then they must be within the base perimeter ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ <<< ORBAT >>> 36 players, (add another rifle squad if you want to bump it up to 42) 1 * Command group 2 man group (Base class "Officer") By default set callsign to "HQ" 1 * Recon group By default set callsign to "RECON" 4 man group (Base class "Recon Paramedic") 3 * Rifle Squads By default set callsign to "ALPHA, BRAVO, CHARLIE" respectively 8 man group made up from 6 * Explosive expert class 2 * Medic class *a* see notes below 1 * Support Group By default set callsign to "DELTA" or "SUPPORT" 6 man group (Base class: "Repair specialist") These are dedicated vehicle operators and the only class that can drive/pilot heavy vehicles and aircraft They cannot be reassigned to a different role They can only be equipped with defensive weaponry + dems for taking out their vehicle They can however be moved from 1 group to another (This will cater for small group sessions where only 6 or 7 players are on the server) There is no restriction for other crew positions such as Gunner/Commander, any unit can take this position <<< VEHICLE USEAGE >>> Only Support group can drive heavy land vehicles or pilot aircraft Any class can crew a vehicle, eg gunner position or commander position (This does not include co-pilot for aircraft) Any class can drive light vehicles, (Hunters, quads etc) Vehicles should automatically carry support ammunition for Rifle Squad roles <<< CAS >>>>> Gunships are too powerful (This has already been pointed out on the forum thread) Removing them, or possibly just removing their thermal imaging may help or add more AAA It may be more prudent to go with Fast air and Light helo gunships only This would further reinforce recons role, especially JTAC <<< ARTILLERY >>> Artillery as it stands right now is too powerful (This has already been pointed out on the forum thread) Available to Officer class or Recon F.O only Limit available types of ordinance (No H.E for example) <<< UAV >>> Only allow recon drones, nothing weaponised UAV control is only available to Recon UAV operator, or if that role is not filled, the X.O role in the command group <<< COMMAND >>> It can be very difficult commanding, when the group you are in is full of players spamming teamspeak or voip group chat So I believe it is best to command the mission from a small group of say just 2 players. This is the management group, so they should be able to reorganise players between groups and assign roles for the entire orbat They should also be able to control support assets such as Artillery and UAV's if no other player is fulfilling that role <<< RECON >>> You have to be careful here, not to, let recon become a spec ops unit To enforce the reconnaissance role, I would not allow any recon class unit to carry any offensive weaponry, AT, AR, Sniper rifles etc They should remain covert and not in direct contact with any enemy forces They would only be equipped with defensive weaponry They can always HALO even when HALO s turned off (They need to be the first on scene) I would however give them equipment to carry out recon more effectively such as range finders, thermal imaging scopes etc To make the role useful for a 4 man team, I would give them the capability to use UAV's, lase for CAS and call in Arty If played correctly and utilised correctly, this group can be a great asset <<< RIFLE SQUADS >>> These are the main "Get the job done" forces that should be concentrating on assault. They should be able to crew vehicle slots such as gunner and commander and be able to drive light vehicles such as hunters <<< SUPPORT >>> These guys should not have access to anything other than self defence weapons, carbines, smg's etc They maybe could have access to crew served weapons/backpacks to enforce their support role <<< SMALL PLAYER NUMBERS >>> There are times when you do not have sufficient players to spread out between the groups and your community may only have 7 players for example. Often in this case you like everyone to be in the same group Basing roles on unit class means that when you move a player from 1 group to another, the player does not lose or gain roles that they can be assigned. So... you have 7 men, you start with one player in recon, because you want a UAV one player in support because you need a pilot or someone to drive a tank 5 players in Alpha You merge the recon guy and the support guy into Alpha and all your players are in the same group but with the functiality of 3 groups This means you can still utilise all roles but not have excess of any options so as to still enforce teamwork If you start the night with high player numbers but towards the end of the night the numbers drop, you just get a player to reconnect, take another slot in another group then rejoin him to your group <<< UNIFORMS >>> Reduce the options, too many choices (Colours etc) Is there any reason to have more than 1 camo type, might be better to simplify this some more Recon fatigues for recon class, boonie hats etc Combat fatigues for medic, Officer, explosive expert class. Combat helmets etc Berets for officers Overalls or pilot uniforms for Repair specialist class match these with headgear so each class can be distinguished more easily <<< BACKPACK >>> 1 of each type, not 1 of each colour, reduce the options keep it as simple as possible Light packs for recon Only crew served packs for Support <<< AMMO >>> Any unit should be able to carry any ammo, this is to allow for resupply in the field <<< INITIAL LOADOUTS >>> I would set up units so that they are pre assigned roles and equipment at the start of the mission, AT soldier, AR , medic etc so the description field of the unit in the unit selection screen looks something like 1. ALPHA Squad leader (Explosive trained) 2. AT soldier (Explosive trained) 3. Auto rifleman (Explosive trained) 4. grenadier (Explosive trained) This reduces the initial organisation time when you start the mission, reducing the requirement to assign roles roles can still be reassigned, it may just help speed things up initially <<< RADIO >>> I know that you use ACRE, some communities do not, so I would re-enable Command Voip channel <<< CALLSIGNS >>> Still allowing the gui to change the callsigns, i would intially set all callsigns HQ,RECON, ALPHA etc just to make things simpler at the start of the mission B.I's idea of Alpha 1-1 and Alpha 1-2 just adds to confusion over comms and is easily fixed with setgroupID in the init fields of the units <<< ENEMY AI >>> Dwarden has released some dedicated server binaries that are optimised and allow more AI to be run on the server. These binaries will eventually become integrated into the release versions With this in mind, there needs to be more enemy AI on the map There defintely needs to be a greater depth of enemy around the AI, maybe up to 2 km out There needs to be more random patrols outside of the A.O Possibly you could have spawn camps at some of the Hill top positions that spawn an enemy group and place them onto a guard waypoint, then respawn them when the group is killed off. This could create a QRF, enemy reinforcement type of situation to the A.O and therefore cause the player and the commander to be less tunnel visioned <<< EASY CONFIG >>> You have stated in your license that you are happy for folks to mod this mission. It may be prudent both to help you modify this mission as more equipment and systems are made available to us and others who want to play around with the organisation and equipment side of the mission, to set up a single config file where all the variables that define such things as who can do what role, what equipment is available to what role basic loadouts Enemy group orbat and equipment are all defined in one file <<< BRIEFING >>> Boring work as it is, I would detail the mechanics of the mission in the briefing. Explaining the roles, the gui's, the pre game params other functionalities that are not documented <<< MISCELLANEOUS >>> I have it on good authority that the easiest smoke colour for a pilot to see is yellow With this in mind, I would allow only group leaders to have yellow smokes so that in a case where an LZ needs to be marked, the sensible squad leaders have the best colour to mark it with You could also extend this further to say something like Only medics have blue smoke Rifleman have green smokes some way of distinguishing important command net level smoke markers from say squad level ones NOTES: *a* I was thinking that the group leader could be a "Squad leader" class and have access to thermal imaging and range finders Restricting the number of players in this role to 1 per group If this were to be implemented, I would remove 1 * Explosive specialist *b* You could possibly have 2 additional roles available to the Squads ("Medic" and "Explosive Specialist" class) This could be Sniper and Spotter role, however, if this were to be implemented, I would restrict it to only 1 Sniper/Spotter team for the entire orbat Sniper has access to high zoom scopes, heavy and standard sniper rifles and ghillie suits Spotter has access to range finders and ghillie suits Each way i argue FOR or AGAINST a sniper role, I end up with a decent counter argument for it, so am on the fence on this role. I cant stand the typical sniper who john waynes it and leaves nothing for the infantry to kill I like the sniper who maybe uses 1 mag in an entire task, taking out key targets like Mortar teams etc If this role was to exist i would keep it within the options for the rifle squads, cetainly not in a recon group

I would do it the following way. Add 1 action to the object "Open action menu" This then runs a script which checks conditions for each sub action you may want to add and then adds them. (They dont exist until that point) At the same time the main "Open Action Menu" action is then hidden (Simple boolean condition or an action level number) Selecting an action from the sub menu, then a) runs that action code b) removes all other actions c) re instates the condition that allows the "Open action menu" to be visible This way the only time there are multiple actions available and in existence is when you actually need to select one of them Every condition per action is checked very often, at least every 0.5 seconds, it could even be every frame and lots of actions do effect performance I have used something similar in the past.... code below Action Inititialisation script // AUTHOR : Terox (terox_@hotmail.com) // LAST Edited : 5/8/2012 // MP MACHINE : Client // Called from : Zeus_Actions.sqf (Which is run via an addaction menu on the player) // Called using : _this call Txu_factions_MainMenu // Description : loads releveant addactions to the unit dependant on criteria // // COMMENTS : // : Addaction params // [title, filename, (arguments, priority, showWindow, hideOnUse, shortcut, condition] _obj = _this select 0; _caller = _this select 1; _actionID = _this select 2; Txu_ActionLevel = 0; Txu_ShowActions = TRUE; Txu_Actions = []; // Lists currently held actions that the player has // -------------------------------------------------------------------------------------------- // // Action Menu Spacer _title = "____________________"; _script = (Txu_Actionpath + "Actions_spacer.sqf"); _priority = -10; _showWindow = false; _arguments = []; _hideonuse = FALSE; _shortcut = ""; _condition = ""; Player addaction [_title,_script,_arguments,_priority,_showWindow,_hideonuse,_shortcut,_condition]; _title = "Zeus Options"; _script = (Txu_Actionpath + "Actions_Zeus.sqf"); _arguments = []; _priority = -10; _showWindow = FALSE; _hideonuse = FALSE; _shortcut = ""; _condition = "Txu_ActionLevel == 0"; Player addaction [_title,_script,_arguments,_priority,_showWindow,_hideonuse,_shortcut,_condition]; MAIN ACTION SCIPT // AUTHOR : Terox (terox_@hotmail.com) // LAST Edited : 5/8/2012 // MP MACHINE : Client // Called from : Zeus_Actions.sqf (Which is run via an addaction menu on the player) // Called using : _this call Txu_factions_MainMenu // Description : loads releveant addactions to the unit dependant on criteria // // COMMENTS : // : Addaction params // [title, filename, (arguments, priority, showWindow, hideOnUse, shortcut, condition] _obj = _this select 0; _caller = _this select 1; _actionID = _this select 2; Txu_ActionLevel = 1; // -------------------------------------------------------------------------------------------- // // Turns 3D Markers ON or OFF _title = "Toggle 3d Markers"; _script = (Txu_Actionpath + "Actions_ToggleMarkers.sqf"); _priority = -13; _showWindow = false; _arguments = []; _hideonuse = FALSE; _shortcut = ""; _condition = "(Txu_ActionLevel == 1) && Txu_ShowActions"; _id = Player addaction [_title,_script,_arguments,_priority,_showWindow,_hideonuse,_shortcut,_condition]; Txu_Actions = Txu_Actions + [_id]; // -------------------------------------------------------------------------------------------- // // Hides the addaction nested menu but doesnt remove the actions _title = "HIDE Zeus Menu"; _script = (Txu_Actionpath + "Actions_HideMenu.sqf"); _priority = -11; _showWindow = false; _arguments = []; _hideonuse = FALSE; _shortcut = ""; _condition = "(Txu_ActionLevel > 0) && Txu_ShowActions"; _id = Player addaction [_title,_script,_arguments,_priority,_showWindow,_hideonuse,_shortcut,_condition]; Txu_Actions = Txu_Actions + [_id]; // -------------------------------------------------------------------------------------------- // // Shows the addaction nested menu after it was hidden by previously defined addaction _title = "SHOW Zeus Menu"; _script = (Txu_Actionpath + "Actions_HideMenu.sqf"); _priority = -11; _showWindow = false; _arguments = []; _hideonuse = FALSE; _shortcut = ""; _condition = "(Txu_ActionLevel > 0) && (! Txu_ShowActions)"; _id = Player addaction [_title,_script,_arguments,_priority,_showWindow,_hideonuse,_shortcut,_condition]; Txu_Actions = Txu_Actions + [_id]; // -------------------------------------------------------------------------------------------- // // Closes the nested addaction menu's and removes the addactions from the player _title = "CLOSE Zeus Menu"; _script = (Txu_Actionpath + "Actions_CloseMenu.sqf"); _priority = -20; _showWindow = false; _arguments = []; _hideonuse = FALSE; _shortcut = ""; _condition = "(Txu_ActionLevel > 0) && Txu_ShowActions"; _id = Player addaction [_title,_script,_arguments,_priority,_showWindow,_hideonuse,_shortcut,_condition]; Txu_Actions = Txu_Actions + [_id]; // -------------------------------------------------------------------------------------------- // /* // Displays actions from previous nested level _title = "<< previous"; _script = (Txu_Actionpath + "Actions_backmenu.sqf"); _priority = -19; _showWindow = false; _arguments = []; _hideonuse = FALSE; _shortcut = ""; _condition = "(Txu_ActionLevel > 0) && (Txu_ShowActions)"; _id = Player addaction [_title,_script,_arguments,_priority,_showWindow,_hideonuse,_shortcut,_condition]; Txu_Actions = Txu_Actions + [_id]; */ // Group Leader Actions (Team management etc) if(player == leader player)then{_this call Txu_factions_Leader}; CLOSE DOWN SUB MENU ACTIONS // AUTHOR : Terox (terox_@hotmail.com) // LAST Edited : 5/8/2012 // MP MACHINE : Client // Called from : Addaction // Called using : // Description : Removes all the nested addactions and closes the action menu down to "Zeus Actions" // // COMMENTS : Txu_ActionLevel: 0 is the lowest level, displaying "Zeus Options" only // : // [title, filename, (arguments, priority, showWindow, hideOnUse, shortcut, condition] // _this // select 0: object action attached to // select 1: caller // select 2: actionID {(_this select 0) removeaction _x}foreach Txu_Actions; Txu_Actions = []; Txu_ActionLevel = 0; TEMPORARILY HIDE SUBMENUS without removing them. (May need to get in a vehicle or rearm quickly) // AUTHOR : Terox (terox_@hotmail.com) // LAST Edited : 5/8/2012 // MP MACHINE : Client // Called from : Addaction // Called using : // Description : Hides all the nested addactions but doesnt remove them // Used to declutter the menu temporarily // // COMMENTS : Txu_ActionLevel: 0 is the lowest level, displaying "Zeus Options" only // : // [title, filename, (arguments, priority, showWindow, hideOnUse, shortcut, condition] // _this // select 0: object action attached to // select 1: caller // select 2: actionID if(Txu_ShowActions)then{Txu_ShowActions = FALSE}else{Txu_ShowActions = TRUE};

From a server admins point of view The servers are all privately owned and privately run by volunteers who normally are a bit older than the normal gamer, have a bit more money and tend to have families, so time management is everything to them The server admins approach is more to do with the hassle and complications that addon packs can cause 3rd party mods are not made by professional studios and therefore often come with quality performance and balance issues. Addon packs can be problematic and time consuming to manage Servers open to the public are often there as a recruitment tool to vet and then invite "quality" players into their communities inner circle The more obstacles you place in a players way to join that server, the less clientel you are capable of attracting to your public server. You have to white list addons not black list them, so this again requires more time and management from server admins The addon must have a public key so the admin can add it to their white list if they so wish (Many addons do not come with public Bikeys) Once you stray away from client-side addons to "common" addons where the client and server both require them, then the time spent on back-end admin increases a lot (Full blown mods, such as ACE etc are a much easier and simpler to manage. These do not exist for A3 yet, but am sure that will change) The only way you can run an addon server is to have sufficient clientel who regularly play who are willing to download an addon pack and have sufficient mission makers who want to create missions using those addons. Once you have an addon pack, your regular players wont want to play vanilla anymore This will kill any chance of recruiting new blood unless your marketing skills are fantastic From a players point of view As a player your view on addons is purely selfish and I dont mean that in any disrespectful way. You see an addon you like and you want to play with it.

overclock the cpu, get the fastest stable clock speed you can achieve Thats it

This is just a point of view and may not fit into your overall image of your mission, but here goes anyway. I see a role for a recon element (4 man max) Basing the units on medics, not explosive experts These units would be the only units with access to UAV's preferably non weaponised Thermal imaging scopes (With the exception of the AT sights which are available by default with the AT launchers) Recon uniforms, (Boonie hats, bandanas, all the spec ops type uniform bits) They would have the following special roles only available to them Recon_JTAC (Laser designator) Recon_UAV Operator Recon_Medic Recon_Leader Take note of the omission of any Offensive type role, eg Sniper / AT / MG etc A recon role if played correctly should be, wherever possible, covert and non aggressive and therefore the omission of any elite type weaponry should be enforced so as not to attract the wrong type of player to this group The player who takes this role would not be interested with a high kill score Their HALO option would always be on, regardless of the Param settings for HALO How do I see this role played. New task is spawned Recon Halo in Find a suitable OP designate safe LZ's for the assault groups for helo insertion Mark targets Relay intel of enemy movements, size and type of force etc Observe friendly force deployment and their movement to forward positions Observe flanks Possibly act as a CSAR unit if required [*] Remain non combatant wherever possible [*] Mission ends [*] Extract to base [*] New task given >> goto 1 They could also take the role of forward observer for the artillery Removing UAV's from other groups enforces their reconnaisance role and makes at least 1 slot in the group very specialist Not allowing access to high powered weaponry stops the group from turning into a spec ops role The role does not suit every player, but there are players out there that love the immersion that this type of role can give ______________________________________________________ _____________________________________________________ Side Note Artillery support, with all types of munitions availablle is way too powerful I would suggest Removing HE Only allow specialised munitions such as laser designated etc

xp, is a stripped down client version of 2003 so that probably wont run 7 is the client version of 2008, so if you are running the latest service pack for it, you should be okay

MinBandwidth Important... If you see information within this post that is innacurate, please let me know ASAP so I can edit it This thread is part of a much wider discussion on server bandwidth optimisation Tutorial: Server Bandwidth & Optimisation Useful Links BIS WIKI: basic.cfg What the BIKI states What is known The value is defined in bits (Not Bytes) just to confuse us According to Suma The higher the value the greater the desync reported for players already on the server when a Join In Progress Player connects What we need to know: How do you discover or calculate the minimum bandwidth that is always available to the server? How is this value calculated correctly when running multiple ArmA3 servers on 1 box? (Is it simply.... (Minimum available bandwidth on the box) DIVIDED BY (Number of A3 servers that can be run simulatenously)? Would this value vary depending on the number of A3 servers you are running on 1 box How would you stress test or test this in a Benchmark mission scenario? Calculation Formulae (Not yet defined)

Official thread http://forums.bistudio.com/showthread.php?168315-A3-Patrol-Operations-Official-Thread Dev heaven repo https://dev-heaven.net/attachments/download/21305/PO3_V000_20131130.7z Armaholics mirror http://www.armaholic.com/page.php?id=23671 The Nato version is included with all the other variants in the 7z package

there should be a bikey in the servers "keys" folder )Not the private key, it should be the public key and in your mod\addons folder there should be the addon.pbo and the assosciated .bisign On the client connecting, the client bisign is checked against the server bikey, if they match, the addon will be allowed

This has all the info you need to edit your *****.ArmA3profile http://community.bistudio.com/wiki/Arma_3_Difficulty_Menu

As everyone else is stating. Typically this engine and the missions created for it by the community would not require balancing of the sides. most likely the opposite would be a requirement If you want TDM, Battlefield does it better This simulator caters for much larger scale warfare at a slower pace and god help us if B.I ever lose sight on that.

There is an issue with MP performance, however, this is only seen when large numbers of players are present. There seems to be a threshold somewhere between 20 and 30 players when running 150 + AI that causes the server FPS to drop very low. We currently run Patrol ops which is probably the best mission out there that dynamically creates tasks. This is very well optimised and runs better than anything else. We currently roll with around 20 players per session Add headless client to this and you should be able to support well over 30 players with it. A3 is a different beast to A2. I woudn't go back, the anims are great, the scenery and island terrain are great, its a vast improvement on A2. That being said, it still has a long way to go before it achieves the performance that A2 has. As always with B.I game engine releases, they always take time to get the game running well. 6 months to a year typically. Its very playable but if you are a large community, it may cause issues for you. The DEV branch is soon to get some debugging tools and there are steps being taken to try and identify the performance hog....... its just a matter of time. I havent tried the alive addon yet. Having read up a little on it, i would suspect their AI caching system would alleviate a lot of the problems.

I have to agree with Senshi, in reference to enemy numbers. I would also like to add that depth of enemy is too shallow (Meaning outside of a certain perimeter of the A.O, there is no enemy. It would be nice to see a gradual reduction in enemy concentrations from the focal point of the mission to say 2km or more out. Am talking the odd perimeter patrol here, nothing too heavy (A couple of fireteams or squads out on the edge). Just something that makes you a little more careful when approaching the A.O. Maybe an extra couple of levels of params in Mission Difficulty would get us there. This however may cause a problem with the current state of Multiplayer optimisation, which grinds the server cpu down to a crawl, effecting client fps inadvertently. For now the only answer to this is HeadlessClient, lets hope B.I improve this soon

There is currently a bug that can hide the chat message bar, that's one issue The second cause is the fact that this mission disables Global chat command chat system chat. disableChannels[] ={0,2,6}; Seen in the description.ext I suspect this has something to do with ACRE support, maybe Roy can explain ---------- Post added at 16:49 ---------- Previous post was at 16:48 ---------- There is currently a bug that can hide the chat message bar, that's one issue The second cause is the fact that this mission disables Global chat command chat system chat. disableChannels[] ={0,2,6}; Seen in the description.ext I suspect this has something to do with ACRE support, maybe Roy can explain All support role slots are by default Engineers. (I believe Roy has plans to replace these with Repair specialists) An engineer equipped with a tool kit should be able to repair vehicles

Quick question.. Any reason why the Support units are engineers and not repair specialists ? It would make sense for them to be the latter but be able to carry 1 dems charge to blow their vehicles up

My HC doesnt auto slot (only csat version tested)

Ref HC Would it be possible to create a designated slot for HC. Perhaps a civilian slot as one would not normally try to take that slot (Theres always the exceptions though) Reason for this is so that the avatar that the HC creates just doesnt sit in spawn waiting for an idiot to shoot it or run it over

Excellent quality on release. Just a few tweaks from what i can see of the mission so far, I've added 3 tickets to DEV heaven. Thanks for the considerable effort and long hours that have obviously gone into this.

We use respawn in a fair few of our missions and dont suffer from any obvious signs, maybe it is just down to a specific mission and therefore down to bad coding ?

Question for B.I Dev I dont believe this question has ever been asked before, so would appreciate it, if B.I could provide us with their expectations of what a correctly configured A3 dedi server for the following 4 listed specs should be capable of, when running the 2 listed scenarios The clients connections in all cases should be seen as average. I.e Ping less than 100 typically 50 Upload speed 0.5mbps Download speed 10mbps I5/I7 cpu and a mid range gpu Scenario 1 (Basic Co-op Mission) Based on Altis No scripts No 3rd party addons A maximum of 3 simple triggers for the mission ending scenario All A.I present from the start How many players should the server be able to support for the following number of AI before the server fps drops to an unplayable level (less than 15fps)? 200 AI 400 AI Scenario 2 (Basic PVP Team death match Mission) Based on Altis Urban area No scripts No 3rd party addons A maximum of 3 simple triggers for the mission ending scenario how many players should the server be able to support before the fps drops below 15? -------------------------------------------------------------------------------------- Server spec 1 (Home based Server run on a high end gaming rig ) CPU: Intel Core i7-4770K, 1150, Haswell, Quad Core, 3.5GHz 8GB ram Connection: 10mb down 2 mb up Scenario 1 (200 AI) = How many players Scenario 1 (400 AI) = How many players Scenario 2 = How many players -------------------------------------------------------------------------------------- Server spec 2 (older intel xeon server based at a data centre) CPU: Intel Core Intel Xeon X5570 16GB ram Connection: 100mb up and down (Running 1 instance of A3 dedicated server) Scenario 1 (200 AI) = How many players Scenario 1 (400 AI) = How many players Scenario 2 = How many players -------------------------------------------------------------------------------------- Server spec 3 (mid ranged server based at a data centre) CPU: Intel Core Intel Xeon E3-1225 V2 @ 3.20GHz 16GB ram Connection: 100mb up and down (Running 1 instance of A3 dedicated server) Scenario 1 (200 AI) = How many players Scenario 1 (400 AI) = How many players Scenario 2 = How many players -------------------------------------------------------------------------------------- Server spec 4 (High end server based at a data centre) CPU: Intel Xeon E5-1660 @ 3.30GHz 32GB ram Connection: 1GB up and down (Running 2 instance of A3 dedicated server) Scenario 1 (200 AI) = How many players Scenario 1 (400 AI) = How many players Scenario 2 = How many players ________________________________________________________________________________________________________________________ This should give us some guideline as to what we should be able to achieve.

that is why I defined what must be a very basic scenario

the only mods that are allowed is in the client pack m8, you don't need them, they just help

Kju, they should know, afterall they are the developers............................... If they do not, something is drastically wrong This should be core knowledge on the Network DEV side of things surely ?