MugHug

I was wondering if someone could asnwer a question for me. Using the in-game browser of the most recent demo I noticed something odd about the reported pings for some of the servers. Instead of an actual number, the browser displays a question mark. I have noticed that within our LAN, this is not an issue with our dedicated server, but once I switch the browser to Internet, it comes up with the question mark. Any advise would be welcomed.

This is a shot in the dark as I cannot verifiy it since my upgrade went well. In OFP I could get similar types of error applying patches. I remember that with applying the patches in OFP I had to turn off DMA settings in my motherboard BIOS to patch successfully. Once installed I restored my DMA setting to original. I experienced this with some of my AMD based systems and cannot talk about Intel systems. I never found out why, but it did work.

That's what tactics are for. If you can't reach the tank, move to somewhere where the tank cannot reach you without also exposing itself. Eg. a reversed slope position. FDF mod has TOW's etc. but they require two men to carry, and are not too flexible on attack. But in plain vanilla ArmA the closest you have is Humvee with TOW's. With the scope of ArmA and the various missions on public servers, your solution does not even come close to the actual problem that caused me to post. Example: Flag area on a small hill in a large CTF (Can think of quite a few missions on public servers like that). Defenders have to stay at least in the area to hold it, plus it is a respawn point. A very popular range of CTF maps on public servers use this type of situation a lot. Think they are called Berrzerk or something. Problem: Tank at higher elevation being used to lay down a random barrage. Â To quote one of your solutions: Using a reversed slope position on many missions removes you from maintaining an effective defensive position. Next, driving a Humvee with TOW's from it's respawn point across a great distance is not the ideal solution if you even get there alive or in time. As most public servers play on cadet mode (which us players have no control over), you might as well put a big flashing sign on top to advertise you as a target to all the enemy helos and planes. If you just look at the multiple variation of situations that can occur, just moving away will not always work. Therefore you are still left with the original problem!! In light of the real world on public servers and the greater areas, missions encompass now, it would be more sensible for infantry to have some kind of effective threat such as the Javelin. I support that it should be limited to visual range attacks. Even limit its power if it is too un-balanced for the game. It is not a case of tactics but a case of a possible un-balanced game play situation created by accident to correct a previous issue over game play balance!

Just an informed ArmA player here. It seems that the decision to not upgrade the T-72 in OFP to either the T-80 or T-90 in ArmA was short-sighted. While not being an expert, I suspect that the alternatives would at least be more balanced. I know there are various views on the realistic aspect of tanks in ArmA, but I did expect more improvement to this aspect of the game. From BIS's point of view, maybe it's an issue of game play balance such as the class issue in games such as Everquest or SWG!! Think about it before you dismiss the idea because there are similarities. Do we really know what motivated BIS to have it the way it is? If this is the case, maybe the message to BIS is that many of us play ArmA because of what it simulates and would accept an adjustment in the game play balance if it takes us one step closer to the real experience. Just my view, but hopefully something to think about.

If the Strela air to air missle works then there is no reason for the Javelin not to work as it would be very similar code. I still find that infantry under bombardment from a tank at extreme visual range have no effective means to attack. I am fairly good at using the M136, but at the ranges I am talking about, the odds of hitting the tank are worse then winning the lottery. With the landscape in parts of the island, this gives the tank a killing field against infantry. By the time you get within range of the M136 a lot can happen and the effort ends up being pointless. I expect the tank to be a tactical advantage, but at least provide infantry with some kind of long-range threat against such attacks, as exists in the real world. In the real world, no decent tank crew sits there bombarding at long-range in the view that they are safe against infantry!!

For the normal person, what does protected mean? and how does it affect the use of the weapon in the game? Thank you.

Need the 1.04 to 1.05 patch. Downloading the v1.04 to 1.05 patch at 4.52kb/s to complete in 16 hours. Filesize 226Mb. Now downloading the v1.02 to 1.05 at 51.7kb/s to complete in 2.5 hours. Filesize 461Mb.

At last downloading the file. Well, my initial impression will come in about 16 HOURS due a download speed of approx 5kb/s. Actually my pre-initial impression is not good as they did not providing enough mirrors, considering that the world and everyone including BIS knew this would be a high demand download once it was released.

Impressed that I cannot even start a download from any of the sites for English v1.05 due to what looks like over demand for the file. To be honest, clearly more mirrors would have helped all around.

Members of MugHug's Marauders are split between version 1.02 and 1.04 which has put us on hold here. Once v1.05 patch comes out we will be on-line most nights. Imagine with v1.05 we should see things improve and then with ArmA release in US stores, numbers will increase again. Things will be getting better sonn.

Having run two OFP squads with one entering the War Games CTF ladder and winning first time, I cannot accept your view as based on a valid and balanced argument. ArmA offers exactly the same advantages and disadvantages as OFP and CTF at it's best was always team-work and good communication. My squad member have found that exactly the same tactics work in ArmA as OFP. I can still take the flag single-handed at times, but other times I cannot. Cannot expect to carry out the equivalent of taking a flag down from a pole in a hot-combat zone and not expect to be fired upon at if any defenders are near. We accept that a flag defended needs teamwork. Some to draw out and deal with the defenders and others to take the flag.. Even when we defend we have at least two members hided away making it very difficult to take the flag. The better players work as a team to deal with us or the single player first works on us before the flag. Sounds like common sense. Maybe a re-evaluation of skills and tactics by you and your friends are in need. To blame ArmA does a dis-service to BIS who have delivered one of the best tactical combat simulations available to the general public up to date. Like everything it is not perfect, but as nothing can stand-up and compare to it's scope and versatility, put your blame elsewhere. NOTE: Have any of those players that support the original poster's views ever considered that just like in real combat you need to secure an area before doing things like taking flags down. That sounds like a no-brainer considering it is advertised by BIS as 'the most realistic warfare experience ever seen on a computer' Go back to your arcade games, if you cannot handle ArmA. Regards, MugHug [M.H.M] Â

Hi, Just a bit of info to think about. I have tried every trick in the book, on the Avon Lady FAQ, W2K/WinME/WinXP and all the alternative drivers out there, but I still get the odd crash or reboot on my workstation. Having experienced problems running OFP on a VIA chipset motherboard I decided to move away from VIA totally. After having read the reviews on the stability of the SIS 735 chipset I upgraded the motherboard and RAM. All other hardware was changed except for the video card. I still get the same problems. The one common item in all of this is my GF2 GTS/Pro 64Mb video card. It runs stable in all other situations I find it hard to believe that it is faulty, etc. I am no expert, but I am suspecting that the problems are clearly related to OFP video issues. The DS Server that I run is fine if run as as DS, but when I tested it by running it with the normal executable it develops the same problems. Three different makes of chipsets and hardware and the problem is still present. I think that the VIA chipset is used as an excuse and the issue is more generic with OFP and mainly video hardware. Regards, MugHug

This is really a question for the BIS Staff. Currently I run a DS using W2K Server, 900Mhz AMD Thunderbird, 512Mb PC133, KT133 chipset and ATA66 hard drives, etc. The possible alternative DS is a 1.4Ghz K7, 512Mb PC2100, ATA100 and SIS735 chipset. By upgrading the system to a faster motherboard, 1Gb of PC2100+ DDR, faster CPU and hard drives, will this make a marked improvement in the FPS numbers when the DS is under load? Would a dual CPU arrangment improve OFP DS performance? I am not really looking for ideas but hard facts based around how OFP will respond, to guide me in my plans. I realize that the Internet connection plays an important factor but this is not an option at the moment. Regards, MugHug

Thanks Mister Frag, A very good point and one I will look into. Regards, MugHug

Mmmmm, 'my favorite past time is watching Ping rates to my server or the ones we use' That explains your fixation with numbers. Try to get out more. And if I need to explain anything to you, it shows the gaps in your knowledge and experience!!! I will tell you one thing, I have worked in the field of computers for the last 20 yrs. I still find there are things I do not know. I still find that because something works once, it may not work exactly the same way again. I still find that paper does not always translate to the real world exactly 100%. Maybe my trouble is that I live in the real world!!! If networking and the Internet was so cut and dry as you seem to put it, them why do companies spend so much money on IT staff and training?? I would like to wish you a merry Xmas and a Happy New Year, but no doubt being the expert, you will have something to say about that!!!. Anyway, have a nice Xmas and New Year. Oh, on Xmas day stop checking your 'PING' and spend it with your family. Just do not bore them with you tech talk. MugHug (Edited by MugHug at 1:56 am on Dec. 24, 2001) (Edited by MugHug at 1:59 am on Dec. 24, 2001)

Not exactly informative and really common sense, so no real point in stating. I think I will wait for BIS to reply or e-mail them directly. MugHug

As I stated, in OUR EXPERIENCE we have found that a good connection is only the start of working out what a certain DS can handle in the number of players. According to your post your server can handle approx. 30 players and therefore you must have a T1 or similar based on your info. The original post was in connection with aDSL. If anything my connection is more closely matched to his then yours. Therefore I saw a close relationship between his situation and mine and felt I could maybe help. Remember our experience is based on real-world testing and monitoring and not just figures. We have also found contradictions in OFP MP, which cannot always be explained. I could sit here and write a thesis on networking (being an active MCSE and employed as an IT Manager), but the purpose was to keep it simple and offer some helpful tips that can be applied in the REAL WORLD, unless everyone is a networking professional and we all want to go crazy over technical points!!!!. I am not going to debate over your use of 'Totally False' that you chuck around. Not worth the time. Everything I stated could be confirmed, so no point in wasting my time. I wrote a general non-technical post based upon OUR experience in the hope it may help someone. It is not the definitive guide nor can it be applied to all situations. It can only help to give ideas to people or to point them in a certain direction. Your comment about v1.40 is 'Totally False'. V1.40 has only been out for a few days. Even if you worked for BIS, it is clear that their real-world testing ability is limited considering certain problems with the various patches. How much real time have you spent monitoring v1.40s performance in relationship to various connections?? How many setups have you tried it on??. Have you tried it on aDSL, cable, T1 and T3? Explain why the FPS can go down in what looks like direct relationship to high pings??, or is the #monitor command lying?? Spurting out facts and figures is fine, but try not to lose focus of the whole point of my post. It was to offer real-world experience and tips based upon a cheap typical aDSL setup run and paid for by just me at home (Similar to the original post). When I started an OFP DS, I wish I had some simple basic tips to help me get it running smoothly. Not fancy calculations or stories about how wonderful our T1 connection is or that we can host 30 players. Too many people out there think they are experts!!!!!!! MugHug

Just some info for consideration. I run a 24/7 DS using w2K Server, AMD K7 900Mhz, 500Mb PC133, etc over a 1.5Mb DL/384Kb UP connection. Using bandwidth testing at the above sites, we seem to have an excellent connection. Based on the numbers in the post above, it is clear that this cannot answer the original question by its self as evidence indicates other factors involved. In our experience we have found that a good connection is only the start of working out what a certain DS can handle in the number of players. One must consider the following factors essential in running a decent DS. 1) The ping of your clients. a) We find that many people will try to connect and wait in the pool with crazy high pings. Careful monitoring of this and asking the person to leave or kicking them helps a lot. b) When a client joins your server, it seems to increase everyones ping dramatically untill they have fully connected. c) One bad ping slows down everyone else. For example, I am 3 feet away from the server on a LAN, but my ping and lag will go up in this situation, so it must be worse for others connecting from outside. d) Due to experience we limit the max ping to 250ms. 2) How many AIs in a mission? a) This has a real world effect on use of your DS bandwidth. b) MP maps with just humans seem to perform better. 3) Are helos, tanks, jeeps and aircraft involved? a) We find that the use of these can drop the FPS right down on the same exact map. b) Try to avoid people pairing up in the same helo or tank as this can cause major problems. c) By default, the Maruaders will normally only have one person in a helo at a time. d) Multiple helos or aircraft taking off at the same time can cause major problems. 4) The size of the battle area. a) The further apart players are on the map seems to increase pings and lag. 5) The type of map and number of objects involved. a) If the map is complex or has too many objects, this can slow things down. b) Simple maps with players only on foot can keep our FPS above 47 most of the time. 6) The state of the connection between the DS and your clients. a) A very important point is that anywhere on the connection beyween the DS and your clients can affect the performance. b) An example is last night. In the early evening the same players used certain missions and our FPS was very good. Late at night for no known reason, the same players on the same missions caused the FPS to drop right down. 7) In-game voice communications. a) This seems to use a lot of bandwidth. b) We use a independant alternative on a different IP which dramatically helps. c) We find Roger Wilco or TeamSound to be the best. 8) The connection bandwidth must be used just for the OFP DS. a) I run our server on a small LAN at my home. If the wife gets on her PC and uses the Internet, this can cause issues. 9) Designate your DS Server just to run OFP. Run only essential foreground and background tasks. Our recommedations: 1) The design of the mission plays a real factor in how many players the DS will handle. Avoid eye-candy!!!. So many maps we get are wonderful in design but suck in use under load on a DS. 2) Map designers must test their maps on a live DS under load. To test it just on your workstation will give no indication of how it will perform in MP. 3) Remove all un-essential objects, etc. from your maps. 4) Avoid your wonderful soundtacks as this just adds to bandwidth needs. 5) Use the #monitor command to learn how your server performs under certain situations. Firstly, you can identify a high pinger connecting and kick him before it cuases problems. 6) The #monitor command and the DS info from BIS now gives us some real tools to adjust server config file setting to optimize things. 7) If OFP can use up to 256Mb of memory, then it makes sense that 512Mb would be a good minimum limit in your server to accomodate the O/S, etc. 8) Trying to run a OFP server from the same copy of OFP and on the same workstation where you play is not a good idea because all the graphical work involved will rob your CPU of power and leave little to be used by OFP MP. 9) Avoid clients with pings above 250ms. 10) People in the pool/waiting room during a game can increase lagg and pings!!! and finally, do not just look at your connection speed. Look at the overall picture and learn how to run your server to the best of its abilities!!! There are many other factors to consider that are not detailed here, but hopefully this info will help someone out. What would be nice is a decent FAQ on the day to day running of a OFP DS based on solid experience from existing DS providers. Regards, MugHug (MugHug's Marauders - OFP League CTF Winners) www.mughug.net (Edited by MugHug at 10:16 am on Dec. 23, 2001) (Edited by MugHug at 10:23 am on Dec. 23, 2001)

Hi, I run a dedicated 24/7 server and most of the people who come to me use the 'ALL SEEING EYE'. I cannot remember where to download this from, but hopefully someone will be able to post the web address here. Trying to search for it on the Internet does not bring any good results up but it is out there. It is a program that connects to a main server which scans for game servers on-line. It covers OFP and many other games. If set up correctly, you can join via the 'ASE' Being honest, Many people including myself find it so much better then GS. If you still need to connect to a DS, then come to ours at 64.30.206.140, based at www.mughug.net in California, USA. The port is default so no need to change it. Regards, MugHug P.S. If I find the web address, I will post it here. (Edited by MugHug at 9:20 am on Dec. 23, 2001)

Back again. Ultimate upgrade v1.40 will not run as a DS on my W2K Server. I also tried it on my Windows XP HE workstation (different hardware) and get exactly the same issue. A Fed up MugHug

I get the same problem, even with clean install on our dedicated server. The OFP server is down at the moment and if I continue to get problems, I will just un-install OFP and install AvP2 and start a AvP2 clan and server. This is getting beyond a joke!!!!!!. v1.30 on the whole run fine. So why should v1.40 cause problems unless it was not tested properly. By the way, the server uses SIS chipset, so cannot be VIA chipsets causing problem. Have run a squad in the OFP League since the USA release. Have run a 24/7 public OFP server since the USA release. Well, tried to, except for the random crashes!!!! Have run other MP servers such as Q3 and AvP2 on same server and never ever had so many problems that I get with OFP. Just about had it with OFP!!!!!!!!!!!!!! Every upgrade brings new problems!!!!!!!!! I love the game, otherwise I would not have created MugHug's Marauders and set up a OFP public server, but I am SO FED UP WITH THE UNACCEPTABLE PROBLEMS that are still issues. MugHug of MugHugs Marauders (OFP League CTF Winners) (Edited by MugHug at 5:47 pm on Dec. 21, 2001) (Edited by MugHug at 5:51 pm on Dec. 21, 2001)

I agree with Thundercok, A multiplayer mission tested on a local PC can be perfect, but the moment you play it from a dedicated server it can fall to bits. I run a dedicated 24/7 server at www.mughug.net and I have see others and my own MP missions do exactly this. I suspected a problems with scripts not being run or loading into memory, but I find that even something as simple as a command in the initialization field of an object can seem to disappear once the mission is played on a server. It gets to the point that I now have to ensure that most of the testing is done on the server with clients connected. Even then a script or whatever may work one time or may not work the next time, the mission is played on the server. Kind of like the odds you get at Las Vegas. I feel for the people without the equipment to test their missions live on a dedicated server with clients connected. If I was in that position, I would have giving up designing missions by now. If anyone without the equipment would like to test their custom design mission on our dedicated server, please e-mail them to me at [email protected]. We will test it out and I will e-mail you back with a report on problems. Please try to ensure that you have carried out testing of the mission before senting it to me. Regards, MugHug