killswitch

Yep, I had it. Unplugged my USB joystick and the controls in the demo then worked. POS coding, per the standard of console conversions...

This is a collision detection (or whatchamacallit) issue in the game engine itself - even if you can clearly see and put your aim at another soldier in said forest, revealing him with RMB will not work since there are invisible graphical parts in the way. This also happens when you see someone just beyond and near the corner of a building. In short: it's a feature. To reveal things in a forest with its many objects, you have to move around a bit until it works. We can only hope OFP2 improves on this aspect a lot.

I'll have to echo the recommendations for the "No One Lives Forever" series. That and Deus Ex (the first), if you haven't played it. Immersive and highly entertaining, IMHO. Stay far away from: MOH series ("Spawning Nazi Asteroids". BS gameplay), R6 series (only-top-of-forehead-behind-stack-of-crates-laser-beam-insta-kill design flaw. Kills immersion dead immediately)

The "big" picture: it is not sufficient to "open the ports". You have to make the traffic coming in to the router on those ports reach your own machine hosting OFP. So, hooah, what you need to do is to read up on "Port Range Forwarding" in the Linksys BEFSR4 User Guide (page 65-66) and set the router to forward UDP packets on ports 2302-2303 to your computer. You also have to configure the router to give your computer the same internal IP# every time (this is if you're using the DHCP service on the router, which you probably are). How to do that I'm sure is explained elsewhere in said user guide. PS. While you're at it - might as well grab the latest firmware for your router, currently at version 1.46.2. How to check what version you have? Again, its in the user guide... Keywords: router ports firewall port forwarding NAT DHCP server host hosting

ofpchaos, can you post that in its original language, in other words, German? That way we can translate it into english and perhaps help you. Regards

Piece of cake. Both showMap and showCompass are local in scope. In other words: make sure you only execute "showMap false" on the machine where the player who should have no map is. Same goes for the compass. Some examples: Lets say the mission has a poor downed pilot. The pilot is named "pilot1" in the editor.In the mission's init.sqs, just have this snippet: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? player == pilot1: showMap false; showCompass false That way, he'll be the only guy without a map and compass. Something similar can then be done to give back the compass only when player's pick something up or use a "take compass" action. In that case, we have to remove the compass from all(?) players on mission start. This can for example, again, be done in a mission's init.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; Remove players' compass showCompass false Then, later, they pick it up somehow. If this 'somehow' is by way of a user action added to an ammo crate or something, the action script will be very short: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">showCompass true But... Why then does Jirix feel that "The [showCompass true] command works for everyone at the same time and refuses other parameters " Answer: I think you are doing the "showCompass true" bit in the On Activation field of a trigger. Triggers are triggered on *all* machines, thereby running that command for all players. That way, you don't get the result you want. Again, the trick is to only do it on the machine where it's needed.

I think this trick will do it:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">enableRadio false [aP] join grpNull enableRadio true

That is due to you not having done the editing things required for using the mortars in a mission (aka "I didn't read the blooming documentation") How to properly make a mission with WGL mortars is described in the WarGames Tech Manual ("War Games Tech Manual.pdf", located in your wgl/docs folder. See page 69 and forward. There is/was a FAQ text file somewhere too that describes it, but I can't seem to find it atm. I could describe it here, but its better if you read it yourself. Besides, the WGL Tech Manual is a good read anyway and you might pick up some useful things for your future mission editing efforts. Good luck!

I *need* someone to make a nice 25.6x25.6 "island" with a big land mass. If I say that Tonal is a way too small island, you get the picture... It needs an extensive and "feel real" road network and other places. Don't just stretch a 12km world where towns are placed 10 km apart. I'm thinking something the size and feel of a four times St:David island. Or picture four FDF East Borders laid in square. When that is done, its time to move on to a 52x52 island. Sick of all the small TDM-sized islands these days. (They are however, very nice and I'm awed by the abilites of the people who create islands) So...Jake, seeing your previous works, I say THINK BIG /me continues to dream about Fulda Gap ´85 scenarios on a large island PS. For this island, can anyone re-do the BIS Nogova bridge and remove those #%$€@!! lamp posts. We all know how much the AI:s love to zig-zag into them at every opportunity. Widen the sucker.

A tip to both admins and players - I have noticed some log entries containing four specific files being flagged as modified. This turns out to be due to the old Battlesounds 1.1 sound "mod". An example from the logs (actual player nick replaced by "<playername>"): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> <playername> uses modified config file <playername> modified data file - res/addons/g36a.pbo <playername> uses modified data file - res/addons/kozl.pbo <playername> uses modified data file - res/addons/m2a2.pbo <playername> uses modified data file - res/addons/steyr.pbo So: if you see those those four, chances are that the unlucky player is "infected" with the Battlesounds 1.1 sound pack. The readme in that one specifically tells you to replace files inside Res/Addons and Res/dta (Big, big no-no). In defence of BS11 and its creator, it is from the days of yore when the knowledge of proper usage of mod folders were less widespread. In conclusion? Players: If you see those four addons being noted as you log onto a server, its time to clean out BattleSounds. Admins: see those four, tell the player to clear out Battlesounds. What not to do: start yelling

Ah, good tip there, benu. God I love iptables - quick and efficient. No fuss, no muss. Linux - when you need to just get the job done.

Oh dear god no....not UBI... Like Shadow said, the only thing worse than UBI is EA... Feck...

OFP doesn't use OpenGL? and btw, those drivers only improves performance in Doom3. Indeed, you are right. I wasn't awake enough... darn, need to finish that first cup of coffee before replying. Reading comprehension increases if you open your eyes Ok, let's go back to getting OFP working again, shall we? What to do/try, even though you don't want to reinstall the drivers: <ul>[*]Use the OFP Preferences program auto-detect feature, as suggested above [*] Work over the ATI driver settings and make sure they're all at default values [*] Failing that, yep, here it comes: reinstall the drivers

Well, its an ATI card and you know ATI and OpenGL... However, try out the beta 4.9's: http://www.ati.com/support/infobase/4547.html I haven't tried them (yet)

Indeed, "player" is undefined on a dedicated server. The problem: the same is true for SP missions in both intros or outros. So, the correct and working heuristics for determining if a script is running on a dedicated server consists of no fewer than two (2) steps. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> 1) Determine if we're in SP or MP mode 2) If we're in MP mode and player is undefined -> script is on a deddy Here's the code to do so: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _mpmode = false _dedicated = false ; ; 1) determine wether the mission is running in MP or SP mode ; ; In SP mode, the missionStart command returns [0,0,0,0,0,0]. ; In MP mode, the result is *not* [0,0,0,0,0,0] _mpmode = ({_x > 0} count missionStart) > 0 ; ; 2) Deddy or not? ; _dedicated = _mpmode && isNull player ; ; Now we can use the boolean variable _dedicated to decide what to do ; ?! _dedicated: hint "Server is not dedicated, exiting"; exit ; Code that should run on dedicated server only follows ; ... There is another method to detect SP/MP mode. This uses the playersNumber command. Like so: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ; ; 1a) Alternative to step one above: ; ; playersNumber <side> returns 0 for all sides in SP ; ... _mpmode = (playersNumber east + playersNumber west + playersNumber resistance + playersNumber civilian) > 0 ... Disclaimer: I am writing this from memory. Code is untested. Comments and corrections welcome.

I have a 256 MB 9600 (Non-XT, Non-Pro) just like you. Using the 4.7 Cat's without problems in OFP. (Athlon XP1900+, 1 GB RAM, XP Pro SP1. BIOS: AGP set to 4x, Fast Writes off, AGP Aperture 64 MB) I see you are using High terrain detail. I can assure you that a measly XP2000+ and low-level 9600's like ours are not up to the task of that. I mostly play using "Very low" terrain detail. Try lowering that and see if it improves stability. If you can't even start OFP in order to change that, you have to edit the file where the terrain detail setting is. This is the file UserInfo.cfg in the folder ...\OperationFlashpoint\Users\Dark[TM] Open that file (ie ...\OperationFlashpoint\Users\Dark[TM]\UserInfo.cfg) using a text editor (like Notepad, the editor that comes with windows) and find the line that reads <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">terrainGrid=6.250000; then change that into <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">terrainGrid=50.000000; and save it. Hope it helps!

Actually, WGL makes playing in tanks against AI:s even more hazardous. Although you as a player don't have the OFP radar screen with the white/green/red squares, AI tanks will however still detect you just as fine as usual and will quite happily send a couple of SABOTs up your stove. In other words: they still have "radar", but you don't. Now that's a challenge, I can tell you "Visual duelling" is indeed possible between human adversaries with WGL and really adds to the excitement, just as you say. Me, I prefer being on foot in WGL or safely behind the front line controlling the troops in a CoC CE mission. Tanking in OFP using WGL is...unhealthy With that said, I'm going back to the enjoying WGL in a scratch CE mission I've hacked up, trying to do a river crossing/breaching operation against the nasties on the other side. Wish me luck! /KS, CO Task Force Cojones, Nogova.

ILS handling, or "Autopilot landing" if you will, is broken in 1.96. Try any plane on any island and watch it do the merry-go-round around the airport. It never lands. (Tested: A10 and Cessna, Everon, Malden and a few other third-party islands) Very little of what the AI once could do is left in 1.96. I'm surprised they even move these days...

The problem with your description.ext is that class CfgIdentities lacks the required closing curly bracket ( "}") Now: That must be:

What an odd poll... of course I play OFP. And to highlight the multitude of game styles in OFP, I'll mirror Ganja's preference by saying that I prefer coops. CTF:s make me fall asleep, odd as it seems. The Zeus game servers are down for a little while longer (a week or less I hope), We're waiting for delivery of the new server machine. The old one is being retired, hence the downtime. Meanwhile, go outside and enjoy the sun (or rain, whichever)

Dear god what a ridiculous machine. I have yet to regain full control of myself after having visited that site and read the specs...*snif* no wait... ROTFLMAO What a hoax. And their specs/facts pages are full of terms that only a pointy-haired idiot boss-type person could have come up with... "Variable Data Depth Burst Priority"...."Enhanced Fast In-Transit I/O Buffering". No, please stop... where's the flux capacitor? I must have a flux capacitor! Please have a look at the rabbit on page 1 of this thread again. $3999 for an overclocked P4 with 256 MB? Listen, do you need a bridge too? I have one here. Slightly used, it's in Brooklyn, NY. It can be yours for only $9999. Damn...they should be taken to court and imprisoned. What a load of tripe. No, I don't have the time to dismantle in technical detail all that BS that they are trying to sell. By now, there ought to be info about this on the net. Goodness gracious. In short: do not take a bank loan to buy a computer, especially not what those scumbags are selling. That's sort of like mortgaging your house to buy exclusive Cuban cigars. For the love of your future marriage, stay far away from those snake-oil sellers, Ninja_STO.

Ah... the age-old problem of CTI missions bogging down all known machines. Well... try with and without -nomap on the server and see if there's a discernable difference. I'm rather sure there won't be. That said...CTI suffer from one thing: there is no such thing as a fast enough computer for OFP and CTI today. Another way of putting it is "OFP scales real well with CPU and mem bandwidth". Try overclocking the server - hike the memory up from 333 MHz to 400 and see if the CPU can follow. Should help somewhat. PS. Hmm... what network card does the server have? One of those on-board Realtek POS variants? If so, that's where your CPU cycles are going. No, really, they are utter shite. Get a real server NIC to do the job. Intel or Broadcom chipset-based. That's where the good stuff is.

Nope, -nomap doesn't "add" extra CPU strain in that way. Far from it. Of course, if the server is on a XP Home machine with 256 MB of memory and is riddled with spyware and other crap and has ATA DMA transfers disabled, its another matter Then, the endless swapping will surely peg any CPU all day long. Is there a problem with the server or is the admin in question blaming server problems on players using -nomap or not on their client machines? (The latter would be crazy-talk, btw) I smell a case of PEBKAC here, but please add more info as to what and where the actual problem you're having is...

Tigeros, the symptom you are seeing is typical of many addons, especially older ones but even newer ones suffer from it. The reason The reason you get the error message is that Ash's RealIFV addon depends (i.e needs) the original BIS Bradley and BMP-2 addons (which you have) but doesn't declare that dependency. When one then puts such an addon into a mod folder (Res is technically a mod folder, albeit an implicitly loaded one), the "Cannot load mission, missing addons..." messages start to appear. You'll even see that message when trying to load mission that doesn't have any of Ash's IFV:s in them (such missions, however, have either the BIS Bradley or BMP-2 in them, which is why you get the odd error message. Incidentally, this is another way the lack of a proper dependency specification manifests itself) Fixes? The quick and dirty one that might hide the problem: put the offending addon into the base OFP\Addons folder, i.e not into OFP\Res\Addons folder. That helps somewhat. The proper fix involves editing the config.cpp within the ASH RealIFV.pbo so as to make it correct. One has to add a requiredAddons property to it. Here's the relevant part of it for those who want to fix the addon for themselves: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class CfgPatches { class AshM2IFVReal { units[]={"AshM2IFVreal","AshM113real"}; weapons[]={"AshM220TOW","AshBushmaster","AshBushmasterHE","AshBushmasterAP","AshM2Coax","Ash50calIS"}; requiredVersion=1.85; requiredAddons[]={"Bradley"}; }; class AshBMPreal { units[] = {"AshBMPreal","AshBMP2real"}; weapons[] = {"Ash73mm","AshBMP30mm","AshAT3","AshAT5","AshBMPCoax"}; requiredVersion = 1.85; requiredAddons[]={"bmp2"}; }; }; However, if you're not accustomed to messing about with the internals of an addon, I'd just move the addon into OFP\Addons (create that folder if you don't already have one) and see if it helps.

Somewhat - here's why it doesnt work the way you want it: by the time you see the MP player selection screen, the init.sqs of the mission has not yet run. This means that whatever group id the playable group(s) has/have will show (Alpha Black in your case). Later, as the mission is started, however, the init.sqs will be run and your setGroupId commands will give the desired result. (NB: Doing the setGroupId magic in the playable units' init lines wont help, since they haven't been read yet either.) We can hope OFP2 will have the ability to name/handle group Id:s even during MP setup or even show further info about the different playable groups (Imagine having "HQ section", "Scout team", "CSAR pilots" and titles like that during MP setup. That'd be great, don't you think?) <span style='color:green'>EDIT:</span> Ok, as I was creating this post you figured it out already. Sorry for the redundance and good luck with your mission editing!