sami

Xmas should be over by now, how about next beta update before end of this week?

Hello! I tried to install ACE2+ACRE and ended up to a situation where running the game as admin was proposed solution. Symptom was following error message after mission has started "ACRE has experienced a pipe error (Most likely a timeout) and Pipe is now closing". I did some testing with sysinternal's process monitor and I found out two log files ACRE and JayArma2Extension were trying to write, but they didn't have rights to do so. After creating the log files and giving permission to write, Pipe error vanished and I can run both TeamSpeak and Arma normally without Run As Admin. Log created by ACRE: C:\Program Files\TeamSpeak 3 Client\ACRE.log Log created by JayArma2Extension : C:\Program Files\Bohemia interactive\Arma 2\JayArma2Extension.log Hopefully this helps someone, who is (like me) unwilling to let application to run as admin for no good reason. It would also be nice that creators of these applications could comply with normal windows application framework just to write files where they are supposed to be written (like %TEMP% or %TMP% or %USERPROFILE%). Windows 7 SP1 64 bit was OS if someone is wondering this. UAC level set to the second highest level. Firewall (McAfee) has permission to allow both arma2oa and ts3client_win64 traffic to/from any port needed.

Hello! I think some of the error messages are due that most missions and mods are created under Windows platform. I did some light testing with Vmware player and created Centos 6.3 64 bit environment. I copied the Arma2OA environment from my Windows workstation to Centos ext4 partition and tried to get it working. Quite many errors when starting the server. Note that I did have full BAF, ACR and PMC installed. My second test was to create second DOS (vfat) disk and I allocated this to Windows XP under vmware. I installed Arma2, Arma2OA, patch 1.62 and ACR lite to that installation. Next I moved this disk from XP to Centos and mounted it as /arma, uid=arma, gid=arma. Many of the warning errors vanished. I also had FDFmod installed on both environment and the error messages I gave also vanished. Some random missions started right away. Can arma2oaserver handle file and directory names within mission file or mod file, if they are created on Windows, and they contain uppercase characters? I assume it can not. There needs to be some kind of standardization layer under windows, when creating file or directory and this layer should handle file name conversion under Linux, too. Like having little-endian or big endian-data. As an workaround, you can just create a small vfat partition and install all arma stuff in it. At least you get rid of a lot of warnings. Comments? BTW: How about that bash script at dev-heaven to get rid of the C-script and need to have full c compiler on Linux arma2oa server?

Is about 246 MB.

Hello! I installed one version older server binaries and using that version I got squad xml working. The data was saved to two different directories: server_root/tmp and server_root/tmp2302. Then I updated dedi to the latest binaries and after that NO squad stuff exists in game or in the two directories above. But using tcpdump I can see that the server is doing some http requests and it got some replies, too. HitmanFF, can you tell if you have squad stuff in server_root/tmp and server_root/tmp2302 directories with the newest version installed? And if you remove them, server will download them during connection phase? I also tested this without iptables running and with no server.cfg installed (and with server.cfg having MaxCustomFileSize=51200 commented out). Still I can't have the squad xml functionality working.

Hello! No lag anymore with squad.xml. But on the other hand, server does NOT load tags and information anymore (stuff in the Players page). 18:19:20 Player connecting. 18:19:24 Player connected 18:19:35 Player disconnected. 18:20:13 Player connecting. 18:20:17 Player connected 18:20:19 Player disconnected. 18:20:39 Player connecting. 18:20:43 Player connected I had to check and re-check that the squad.xml was actually in use :-) And when connecting to windows-dedi, it worked ok.

Hello! The new binary does still have long connection time feature. With correct squad USL: 21:21:01 Player connecting. 21:21:35 Player connected When doing 'tcpdump port 53' on the other console, it seems that the system asks DNS information two times and there is no lag with DNS response. 21:21:04.828318 IP arma-server-host.32775 > DNS-server.domain: 35616+ A? squad-domain. (33) 21:21:04.853891 IP DNS-server.domain > arma-server-host.32775: 35616 2/3/2 CNAME[|domain] 21:21:19.944190 IP arma-server-host.32775 > DNS-server.domain: 26024+ A? squad-domain. (33) 21:21:19.951951 IP DNS-server.domain > arma-server-host.32775: 26024 2/3/2 CNAME[|domain] Using CentOS 4.5 (2.6.9-55.0.6.EL) 64bit running under VMware 1.0.3 (under 32 bit XP). E6400, 2 GB $ md5sum server-1.08.tar.bz2 c384d79041062b654854fae94330cb31 server-1.08.tar.bz2 I'm going to update VMware if it helps (1.0.3 -> 1.0.4).

Hello! With Squad URL it still takes a way too long to connect. Also it seems that nscd doesn't improve (nor make it worse) connect time. With correct squad USL: 21:31:58 Player connecting 21:32:33 Player connected 21:32:43 Player disconnected Starting nscd without any configuration: 21:33:42 Player connecting 21:34:15 Player connected 21:34:45 Player disconnected Re-testing: 21:34:51 Player connecting 21:35:25 Player connected 21:35:34 Player disconnected Using incorrect squad URL (http -> khttp): 21:37:09 Player connecting 21:37:13 Player connected 21:37:21 Player disconnected Re-testing: 21:37:29 Player connecting 21:37:32 Player connected 21:37:35 Player disconnected Clearing squad URL: 21:38:00 Player connecting 21:38:03 Player connected 21:38:05 Player disconnected Re-testing: 21:38:12 Player connecting 21:38:15 Player connected 21:38:17 Player disconnected Testing with correct squad URL: 21:38:39 Player connecting 21:39:13 Player connected 21:39:21 Player disconnected Using CentOS 4.5 (2.6.9-55.0.6.EL) 64bit running under VMware 1.0.3 (under 32 bit XP). E6400, 2 GB $ md5sum server-1.08.tar.bz2 350b811d8411ae48de0eabb0689a6900 server-1.08.tar.bz2

Heh, I found annoying bug and a feature? Bug: Adding mission file to mpmissions directory while server is running crashes the server: Cannot open file 'MPMissions\Operation_Nova_COOP_1-14.Sara.pbo' In this case, added file was 'Operation_Nova_COOP_1-14.Sara.pbo'. Renaming it to lowercase (ie. using tolower -utility in armaserver directory) fixes the problem. ArmA-server can't work in mixed upper/lowercase environment? Feature: server opens all files in mpmission directory and keeps them reserved while running? $ /usr/sbin/lsof | grep -i mpmissions server 4557 arma 69r REG 8,17 180880 983152 /arma/server/mpmissions/mp01seizethecity.sara.pbo server 4557 arma 70r REG 8,17 275970 983153 /arma/server/mpmissions/mp03armoredfist.sara.pbo server 4557 arma 71r REG 8,17 209622 983154 /arma/server/mpmissions/mp04cleansweep.sara.pbo server 4557 arma 72r REG 8,17 5449050 983155 /arma/server/mpmissions/mp06conquertheisland.sara.pbo server 4557 arma 73r REG 8,17 241308 983156 /arma/server/mpmissions/mp07capturetheflag.sara.pbo server 4557 arma 74r REG 8,17 207180 983157 /arma/server/mpmissions/mp08capturetheflag2.sara.pbo server 4557 arma 75r REG 8,17 243958 983158 /arma/server/mpmissions/mp09capturetheflag3.sara.pbo server 4557 arma 76r REG 8,17 665425 983159 /arma/server/mpmissions/mp10holdcastle.sara.pbo server 4557 arma 77r REG 8,17 65049 983160 /arma/server/mpmissions/mp11ambush.sara.pbo server 4557 arma 78r REG 8,17 128985 983161 /arma/server/mpmissions/mp12flagfight.sara.pbo server 4557 arma 79r REG 8,17 159367 983162 /arma/server/mpmissions/mp13flagfight2.sara.pbo server 4557 arma 80r REG 8,17 204801 983163 /arma/server/mpmissions/mp14flagfight3.sara.pbo server 4557 arma 81r REG 8,17 1278733 983164 /arma/server/mpmissions/mp15sectorcontrol.sara.pbo server 4557 arma 82r REG 8,17 1021739 983165 /arma/server/mpmissions/mp16deathmatch.sara.pbo server 4557 arma 83r REG 8,17 114808 983166 /arma/server/mpmissions/mp17deathmatch.sara.pbo server 4557 arma 84r REG 8,17 136521 983167 /arma/server/mpmissions/mp18pilotdown.sara.pbo server 4557 arma 85r REG 8,17 47124 983168 /arma/server/mpmissions/mp19hunting.sara.pbo server 4557 arma 86r REG 8,17 143273 983169 /arma/server/mpmissions/mp20cameldogfight.sara.pbo server 4557 arma 87r REG 8,17 1572051 983209 /arma/server/mpmissions/operation_nova_coop_1-14.sara.pbo lsof 4563 arma cwd DIR 8,17 4096 983151 /arma/server/mpmissions grep 4564 arma cwd DIR 8,17 4096 983151 /arma/server/mpmissions lsof 4565 arma cwd DIR 8,17 4096 983151 /arma/server/mpmissions

Hello! Just a quick system review, first: CentOS 4.5 (2.6.9-55.0.6.EL) 64bit running under VMware 1.0.3 (under 32 bit XP). E6400, 2 GB Second and third beta binaries start normally. The first one crashed at the very beginning. I got w3c-libwww installed quite easy using 'yum install w3c-libwww'. Seems that both 32 and 64 bit libraries are installed. Haven't tested this very much, but at least there is something to test...