[kh]jman

Our dedicated server (Windows Server 2003 x64) is usually very stable and as a clan we have spent many hours working on fine tuning it. It's been available to the community for over a year and a half now so I know what I'm talking about in relation to arma server's daily use. I also have commercial experience in dedicated server administration. In the last two days we have had five crashes. On reading the .rpt files the two critical crashes yesterday were caused by mission script loops that consumed all the of servers available memory until the server itself could no longer operate. In those two circumstances I had to terminal service in and manually restart the service (we use Firedaemon). Usually if the arma server crashes Firedaemon automatically restarts it after a 3 minute timer but in these cases Firedaemon could not function since the server was out of memory. The mission being played on both these occasions have been played before and contain scripts that are used on other missions that are 6-8 months old. I've contacted the author of the mission and passed on the .rpt files. After his testing he agrees with me that missions scripts that used to work no longer function correctly since 1.14. We have had a further three crashes today all of which are presently unexplained since the .rpt files for these give limited information. They have all occurred roughly one hour into the arma server's uptime. I do not agree it has anything to do with client mods. We run with signature checks on, we always have and do not let anything on which will potentially alter the server runtime. We presently run with BE on, VON on and custom faces/snd disabled. If anyone wishes further information i.e. to exchange rpt files please visit our forums.

Yawn. Like I say I'm not trying to prove anything, not palming any of it off as my own I think you need to relax and not get so worked up. I edited my post as I thought that you were referring to the other ghillie suits release! my mistake.

You can argue the rights or wrongs of this as much as you like but the fact remains that you should pack your releases so that people can actually use them, if they cannot what is the point. As for my archive, well I gain no money for doing it, I run a non-profit clan site not one of these multi 'community' gaming sites that make of money from banners or advertising. I offered the mirror to aid a fellow ArmA player. Period. ArmA has little support at the moment as it is without people like you breaking up what remains of it. Maybe I'll think twice about bothering to help out in the future it's not if I have not got better things to do. I have removed the download to prevent you further 'distress'.

Thanks Yoma

I'm not sure why you've created this thread when you already have an existing one that directly relates to all this 1. Dedicated Server. Use Search. I did. configs: http://www.flashpoint1985.com/cgi-bin....t=71279 http://www.flashpoint1985.com/cgi-bin....t=69320 http://www.flashpoint1985.com/cgi-bin....t=72486 The wiki WILL help you get up and running: http://community.bistudio.com/wiki/ArmA:_Dedicated_Server 2. Why would you want to run yet another Evolution server when 50% of all the ArmA servers are already running it and very few are populated? .

Yeah but my eyes hurt whenever I look at that page.

Someone may correct me but I think it's ceased development? Download link in the wiki is no longer available... http://community.bistudio.com/wiki/ArmAtechSquad_Dedicated_Server_Tool

Other than ArmaTec options are fairly limited. Nutty was working on something called, see Power Panel / DSTS but I'm not sure if this project is still in development. I use firedaemon (google it) which allows you to run the arma_server.exe as a windows service. It does not allow you to edit the ArmA config files directly but it has a nice GUI, scheduler and restart on crash options. The downside is than you have to pay for it but at $39 its money well spent imho.

Download Mirror: Kellys Heroes A-10A CAS/FAC

Download Mirror: Kellys Heroes Schmalfelden

Download Mirror: Kellys Heroes SWM standalone Ghillie Sniper packV1.0 & replacement

Ok I've combined all you need to get this working. Mirrored here

Nope you need to provide 'HiFi_config.pbo.HiFi_sounds.bisign' as well as 'hifi_sounds.pbo.HiFi_sounds.bisign'

Not quite you've signed 'HiFi_sounds.pbo' but not 'HiFi_config.pbo' Please sign

@ $able Please could you clarify to us what your position is on the issue of Battleye kicking players due to the 'Corrupted Memory #0'. At present very few of my members are prepared to use Battleye as many have experienced this issue and are not convinced that they have either bad memory sticks or a virus as has been suggested earlier. Could this issue not be investigated at little further by your development team?. I respect that you may not be able to discuss exactly how Battleye interacts with the system in any great depth here by the very nature of what it is, but the problem appears too widespread to be attributed to memory hardware faults for every user and I know that people I have discussed this with have no virus problems. Whilst I very much support the idea of Battleye integration into ArmA I do feel that at present it is not a viable option to have it enabled on our gameserver. As you know the ArmA 1.12b ingame browser filters out non-Battleye servers by default which is going to be a big issue for us and many other dedicated servers if the corrupted memory issue is not explored in greater depth before a final ArmA release patch is made available. Your thoughts would be welcome please.

Whilst you have provided the server public key 'HiFi_sounds.bikey' in your release archive, you have not provided the respective bisigns for 'HiFi_config.pbo' and 'HiFi_sounds.pbo'. Please provide these bisigns and repack your release so we server admins can allow this mod client side. For a full explanation of how you need to prepare your bisigns, read my earlier thread here

Please could you explain why there would be a performance impact I thought it would have been fairly negligible for a mod such as this like this. I'd like to try it on our server but not if it's going to have a major effect on performance.

Well the following will make your mod/addon compatible with multiplayer signature checking which I think is what your asking (your mod may not actually work in multiplayer perhaps it's only singleplayer compatible I wouldn't no). To create a .bisign for a .pbo locate the file called DSSignFile.exe which is included in the ArmA tools package. Use the following syntax: dsSignFile.exe private_key_filename file_to_sign_filename replace private_key_filename with the name of your biprivatekey that you created. file_to_sign_filename is the name of the target .pbo to sign. If you have created a .bikey (using DSCreateKey.exe), package it up with your .pbo's in your final archive. Server admins put the .bikey into their server's 'Keys' folder thus allowing the mod/addon to run clientside if signature checking is switched on serverside and the .bisigns are present clientside. Keep your .biprivatekey safe and use it to sign all of your release mods. Never distribute your .biprivatekey. Include your public key (.bikey) in every subsequent release incase servers do not already have it from one of your previous releases. You do not need to create a new bikey with every release just use your existing one that was created with DSCreateKey.exe and always sign your new .pbo with the associated .biprivatekey Never distribute your .biprivatekey. If you do anyone could sign their own mods using it and thus allowing their mods through on a server that has your public key (bikey) installed. So to recap in your release archive you need your .pbo's, associated .bisign's (that were created using your .biprivatekey) and your .bikey (that was created when your .biprivatekey was created). Note: if you do not include the .bikey file there is no point in distributing .bisign's for your .pbo's as the .bisign's uniquely reference the .bikey that you signed it with unless of course your only signing your .pbo's for use on your own dedicated server or other dedicated servers already have your .bikey file installed.

For XAM 1.4 the CfgPatches entry is XAM_Markers thus the following will block XAM 1.3 & XAM 1.4 *EDITED dooacsDisabledPatches = "[""""XAM_classes"""", """"XAM_Markers""""]"; Incidently I have the XAM Ghilies and that passes the dooacs check so that must use another name but I'm not going to extract the pbo's to find out what it is as I don't think that mod in itself will cause serverside issues.

Thanks Dwarden I couldn't see the wood for the trees

Yes we have this in of server's .sqf file: dacsDisabledPatches = "[""""XAM_classes""""]"; That presumably blocks XAM 1.3 but not as LtCmdrBoon says XAM1.4. Doolittle could you explain to us what file we need to identify in any mod/addon that can be added to the 'dacsDisabledPatches' variable to block a particular mod?

Check you have all the '*.pbo.[yourkeyname].bisign' installed in your clientside addons folders also. In your server config your should have the following: kickduplicate=1; // do not allow duplicate id equalModRequired=0; // require equal mod verifySignatures=1; // enable signature checking onUnsignedData="kick (_this select 0)"; // kick users who fail signature checking regularcheck={}; // session timeout bypass onDifferentData="{}"; // allow players who's data differs You could setup a logfile using: logfile = "[filename].log";

You did restart the gameserver once you'd installed the public key(s) in the 'keys' folder didn't you? It won't work until you do that.

If the mission running required an addon vehicle for example you'd need the addon serverside as well as clientside. For your rain addon however that would work fine just clientside as it's not intregral to the mission. You would need a public key installed in the server's 'arma/key' folder in both respects once signature checking is enabled serverside. This could be done by the addon developer (with all subsequent addons created by that developer using the same private key to sign the addons) or by the server admin creating their own private key and making the bisigns available for download. I like the idea of BattleEye but to have signature checking enabled to prevent certain cheats even though BattleEye is enabled will definately reduce the amount of successful player connects on a server regardless of how well you make players aware that signature checking is enabled serverside. Trust me I know. Why not have an area on popular addon download websites where server admins can submit their public key (bikey) and bisigns so players are more likely find them/download them when they actually download the addon in the first place. This will help things immensely when the developers of addons do not make their own public keys available for signature checking compatibility. Ideally addon developers MUST create and include a public key (bikey for servers) and the bisigns for each pbo file in their addon. The addon should be nuked if it does not. End of.

Check your PM's