Cacker

same. this was fixed in 1.03, and it's now occuring again in 1.04 ><

I thought of that, after all, I am trying to run it on desktop machines (XP), but ArmA dedicated server never crashed when running Warfare. Anyway, I had tried this once, I stopped all non-essential services and programs, so the sys tray basically had the time and the speaker icon :) Made no difference, it still crashed after a couple of hours.

Okay, I tried the -maxmem 640 on both servers, same thing happens. Still haven't had a Warfare game complete, every game has ended with the server crashing. The longest it survived was a test run, whereby i connected to the Server, started the Warfare game, let AI take commander and then left. I periodically re-connected to check everything was okay. It ran for six hours. I got some friends to connect. They started playing for 30 mins or so, then bang, crashed >< Well at least BI are getting alot of Error Reports via microsoft :( Don't know what else to try to be honest. Have noticed that we get disconnections now and again, the old 'xxx is losing connection'. I happened to have a repeating ping to google running and the latency was spiking when a player was trying to rejoin, i promptly then got the 'losing connection' .. i was disconnecting ... then it crashed. might have been coincidental. There doesn't seem to be a pattern in the crashes :mad:

I've set up on a separate PC as a dedicated Arma 2 server. Installed, patched to 1.02 and then downloaded the dedicated Arma 2 binary. Around 3-4 of us are playing 05 : Superpower (aka Warfare in Arma I) and the server has so far crashed during every game after around 1.5 - 2.5 hrs. It's a plain ole AppCrash (we've played around 8? games, every single one of them ended up crashing). We then tried crcti 0.4 mod, I downloaded those pbos into the MPMISSIONS directory. We started playing. After around 5 minutes of building the first few buildings .. it crashes again. Is 05 : Superpowers buggy ? or ? I've tried it on two separate servers, one was underpowered slightly, but i moved it to a dual core 1.86 ghz, 2 GB RAM machine, and i was monitoring it and it never went above 80% cpu, using both cores, with a 1gb spare ram. So it wasn't even stressed. #monitor ingame was reporting around 47fps. Anyone else had crash issues with the dedi server ? It's on a home network, virgin media 20 mbps / 600 kbps connection. network utilisation though, is low too and in game everyone's connection is fine. However there are the odd instances of people 'losing' connection, but they are usually able to reconnect thanks to JIP and after syncing up are able to carry on.

Hi, I was having the same issue as others in this forum, after extracting files and starting the update, it would immediately throw an error claiming a pbo was corrupt (000000 != 000001). I have Windows 7 x64, and I had noticed it had installed in \Program Files\, whereas it should by default install in \Program Files (x86)\. Anyway, i uninstalled, installed it to the correct directory and the patch worked fine. I'm not sure the directory name *is* the real issue, more probably that i reinstalled. Anyway, just for others to try who are on x64. Cheers, Cacker

I'm glad that the latest MFCTI beta will be released. We are still playing this on our server and it does no harm to put out Betas. We were recently hampered by the heavy factory bug, which was frustrating, but heard by word of mouth about the 'replace 200 with 500' in script xxxx which fixed it. Much fun was had as we could build the Heavy Factory and get some Armour ! As long as you release it on the premis that it is a Beta and its for bugfixing, you can only benefit from any new bugreports. You have an audience of testers, use them I was thinking about the JIP issue and publicvariable as the only means of syncing client/server data. How much data are we talking about ? I mean i've had a look through the scripts and I can't believe the volume of data is high enough to cause server/client problems. If the sheer volume of data is the problem, i wonder whether some mechanism might be employed to pack the data. This might increase client/server processing but it would greatly reduce data transmission, which is currently killing the whole JIP issue. By packing data, what i mean is, for example, instead of having 8 different boolean variables, you could pack this into one variable, with a bit for each flag. You could probably write some global functions to pack and unpack the data. The other option though, is probably to put all the MFCTI code to one side as a reference and start again with JIP as part of the remit.

Just to continue the 'JIP' conversation from the previous thread, I think JIP is pretty important. It was one of the features we were looking forward to. It's always a pain to get everyone there at the exact start. Plus of course, users crashing, disconnecting etc, that was it, OUT of the game. With CTI games taking hours, i think not having JIP would be a real shame. I am assuming the biggest issue is that MFCTI wasn't coded around the concept of users joining in half way through and hence it's more of a MFCTI design architecture issue. Or are there actually limitations/problems/bugs from ArmA 1.05 that are causing problems ? Chairs, Cacker

Hi, I unpacked the CTI mission (mp06) and put these files in my user missions directory. I wanted to edit it, change a few objects, add a few objects. Mainly to just tweak it, but also it's good experience seeing how it's done properly (missions). Anyway, when i bring up the editor and try and load the mission it comes back with - "Cannot play/edit this mission; it is dependent on downloadable content which has been deleted" Any ideas what on earth this means ? WHAT downloadable content .. and where is it ? Is it just something i've done wrong in the whole 'take the mission and edit it process' .. or is this some kind of intended block. Cheers, Cacker