terox

Updated the links, thx m8

a mod folder is a folder which requires the following structure at its most basic @Modfolder\addons addons folder contains 2 different types of files addon.pbo addon.bisign There is no limit to the number of addons that you can place in a mod folder, nor any technical reason why you can't place them in the same folder. If they work in seperate mod folders together, they should work in the same mod folder together The only reason you need to split them is for manageability, updating etc and in the odd occasion because you may need an addon loading before another addon (Not sure if this is a problem anymore) the way it works is You add -mod=@ModA;@ModB;@ModC to your commandline When you start the client up, it will load all the addons in each mod folder you have listed The more addons you run the more likely you are that bad coding will cause a conflict. That's the risk you take.

The access you have on a rented server and what mods they will allow you to run on it would be down to the providers They would most likely set all or most of this up for you. This is a complete tutorial for a full install of ArmA onto a server and everything that is needed to get it set up and running. Eg as if you own the server, have installed the o/s and now want to get ArmA running on it

put them all in 1 mod folder or a lot less mod folders

the engine is based on code that is over 10 years old. I believe it is a mammoth task to rewrite and engine to utilise multicores. So basically your answer would be... too difficult at this moment in time Maybe we get that in A4 who knows

setdir needs to be run where the unit is local, finish this with a setpos and all the other clients should see the unit pointing in the right direction as this updates the unit fully to the other nodes. Just one of those finnicky arma things.

any function defined in cfgfunctions with the tag preinit=1 will automatically run before the mission.sqm is launched. This will allow you to define any functions, global variables required for any code after. This works for both addons and missions. XEH init eventhandlers were used to start code in addons for A2 to get around having to place a gamelogic in the mission. The latest system cfgfunctions makes all this redundant

The performance binary is available from Dwarden, it doesnt come automatically with any patch. It is a seperate development from the main A3 development and stable branch and will only work with the stable release. It's just an arma3server.exe with a different filename. Download it copy it to the A3 install and run that exe instead of the default one There are some BI Devs working on this area specifically to try and improve Multiplayer performance. They are having successes and when they do, they make it into the next stable. Sometimes we get a performance boost, sometimes it takes a hit but overall its going in the right direction To keep up with this you need to join the Server Admin skype group PM sent with details

The stock BIS missions are stored in an addon somewhere (not sure where, never looked for them) Its possible that the Server dedicated package doesnt have them, the Full client/server install does) The reason for clearing all the 3rd Party MpMissions out is.... When the server starts up it reads through all the description.ext files for each mission.pbo. I assume it does this so that it has a ready made list of missions to display in the mission selection screen. If one of those missions has an error in the description.ext the server fails to start, so by removing the third party mission list, it solves that potential problem and helps to prove the integrity of the install Also if the mission cycle class defines a mission that doesn't exist, eg syntax error , the server will also fail to start fully.It will hang on the Stratis loading screen (It could possibly also hang on the Altis loading screen if the mission island listed was Altis) So by commenting that out in the ****.cfg you remove that potential issue as well when trying to prove the Stock vanilla installation eg // MISSIONS CYCLE (see below)class Missions /* { class Mission1 { template="co_xx_mymission.stratis"; difficulty="Regular"; }; }; */

You can do this with the steam client by selecting 1) Library 2) (From the left column with all the games are listed) Right Click on ArmA3 3) Select Properties tab 4) Select Local files tab in window that opens 5) select "Verify Integrity of game cache" Alternatively, you can run a batch file with the following Edit as per requirements for branch, installation directory etc The "VALIDATE" bit does that automatically This will check all the vanilla install I'd only run the performance binary after you have proven the latest stable server.exe I'll do Anything to speed up the release of DAC for A3 :-)

@ Neven, edit the following file \fnc\eventhandlers\fn_setFiredEH.sqf at the top (third line) add if(TRUE)exitwith{}; so it looks like if(isNil "PO3__VAR_ETCXH_FITCXRE") then { PO3__VAR_ETCXH_FITCXRE = true }; if(isNil "PO3_protector_enable") then { PO3_protector_enable = true }; if(TRUE)exitwith{}; that will disable spawn protection permanently alternatively give the admin a localised radio trigger or action that switches a boolean (DISABLEBASEPROTECTION_BOOLEAN (from false to true and back and then you can an admin switcheable Base protection system something like

Obviously this is a pretty specific issue on your server, as it isnt a widespread issue, so I would suggest the following 1) Comment out the Mission cycle section completely from your *****.cfg, eg /* // MISSIONS CYCLE (see below) class Missions { class Mission1 { template="co_xx_mymission.stratis"; difficulty="Regular"; }; }; */ 2) Remove all the missions in your MpMissions folder (Back them up and move them somewhere) 3) Run your server as pure vanilla (No addons etc) 4) Login as admin, type #missions and see if you can load 1 of the BIS missions that will be available (Not one of the latest Zeus missions, one of the earlier ones) If you have success then the issue is with a) Your config b) any addons you run c) The most likely one, is the latest mission you uploaded to the server If you fail, delete the ArmA3 install less the following and reinstall it (Sometimes steam updater can be a bitch and corrupt the install 1) user folder 2) keys folder 3) MpMissions, although you should have backed this up and it should be clean anyway 4) Any 3rd party content, eg mod folders you have installed 5) userconfig (if it exists) One of our servers run the latest vanilla without any issues so i doubt the latest version is the real cause If you ever have problems with a server, prove vanilla first then load 3rd party content

For those of you watching this thread wondering why this reaction. There was a couple of typo's in the tutorial thread (now corrected) I basically stated in an earlier post, which I then removed within a minute of posting it something that was taken as a derogatory statement. I realised I had made a mistake for which i apologise.

Your .rpt file tells you the version of the .exe you are running and the branch The latest version is The correct parameters for selecting a branch are: (These are your ONLY options) STABLE Branch Full Install (Client & Server) SET A3BRANCH=107410 DEV Branch Full Install (Client & Server) SET A3BRANCH=107410 -beta development STABLE Dedicated Package Install SET A3BRANCH=233780 -beta Sometimes steam can be a bitch when updating. The following is your best option to defintely fix this 1) Clean install (Best method) Just delete all folders and files except MpMissions and the User folder

check the addons_auto and addons arrays in your mission.sqm. (Back up the mission.sqm before deleting any A4MP entries in there) and retest see if it loads. (You then have your backup if it doesnt. JSRS can cause the same issue). You will most likely find you have added some object from the A3Mp pack if it doesnt load. If that is the case, check your rpt get the classname and search your mission.sqm replacing the string with any BIS classname that you can then easily find and delete in the editor

Timestamp format already defined, means there are 2 entries in the file for the same thing, in other words its repeated Comment out that mission cycle bit, as per the tutorial example for now Make sure your mpmissions folder is empty, you will then see some default BIS missions when you log in as admin

if you do not define a briefing name (Description field in the editor intel window,) it will show up as the filename If you do, it will show up as the Description you added. The latter is very annoying for server admins who want all missions to follow their filename convention For example if you did that, i would remove the Description entry, and edit the filename After you have exported the mission, you can edit the filename, removing the spaces. The arma engine will load them mission perfectly well if you do this. But keep the underscores in the mission editor version

Mountain_Blast once you export it you can remove the underscore and leave a space, but for any development missions always use an underscore where a space could be and ideally that should use a general convention, eg co_20_Mountain_Blast for example a 20 player coop

the reason for this is your filename for the mission has spaces in it. When you save the mission, the filename changes the engine adds %20 to each space and none of the scripts are carried over, just the mission.sqm

get rid of useage of extended EH, replace it with cfgfunctions and use preinit=1 to automatically run your code

N0.12 states You just didnt read it correctly m8, red mist :) Comparison Yours: C:\Games\ArmA3\A3server\arma3server.exe "-profiles=c:\Games\ArmA3\A3Master" -port 2302 -config=CONFIG_Vanilla.cfg -world=empty Mine: D:\Games\Arma3\A3Master\arma3server.exe "-profiles=d:\Games\Arma3\A3Master" -port=2302 -config=CONFIG_Vanilla.cfg -world=empty

@Neven, afaik, the base protection is auto turned off when an enemy is present within the base protection zone Also any unit in support can fly

C:\Games\ArmA3\A3server\arma3server.exe -profiles=c:\Games\ArmA3\A3Master" -port 2302 -config=CONFIG_Vanilla.cfg -world=empty The arma3server.exe is in a different folder to the profile C:\Games\ArmA3\A3server\arma3server.exe C:\Games\ArmA3\A3Master"

in your commandline the arma3server.exe is in a different folder to the profile In the instructions, these should be the same C:\Games\ArmA3\A3server\arma3server.exe C:\Games\ArmA3\A3Master"

afaik you cant tun that off, if an admin is logged in it disables that Always have an admin logged in. If there isn't an admin about either shut the server down or allow chaos. You could always password it