killswitch

The missing addons ec_m1911a1 error This comes from the recently released Douglas C-47 Skytrain, specifically from the addon "EC_m1911a1". It and the other addons in the C-47 archive have addon dependency errors, which is why you get the error. Trenchfeet and the guys now know of this problem and it will be fixed in a (hopefully near) future update. If you want to fix it yourselves in the meantime, see this thread: C47 feedback thread on the WWIIEC forums where I describe the problem and the fix. The Blackhawk/Pave Hawk choice I'd say replace the Pavie with the basic BAS UH-60L (class name "bas_uh60l". This one isn't a specops variant, but a bog standard troop transport/utility version and fits the original BIS UH60MG perfectly. It just looks odd with an Air Force helo hauling Armstrong and the boys around...

For the problem of how about....this<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; ; takeflag.sqs ; ; Usage example: aid = someflag addAction ["Nick flag","takeflag.sqs"] ; ; Called from an addAction action on a flagpole. All user actions such as this ; recieve the following data in its "_this" parameter: ; ; [<object the action is attached to>, <unit that activated the action>, <action id>] ; _flag = _this select 0 _unit = _this select 1 _actionid = _this select 2 ; Loop yield to minimize CPU hogging in the loops _yield = 0.001 ~3 ; Update garrison structures. Find the flag in the correct garrison town through... ; (horror movie crescendo) linear search (screams of agony) _gc = count tx_AllG_towns _gi = 0 #gloop ~_yield _garrison = tx_AllG_towns select _gi _gtc = count _garrison _gti = 0 #gtloop ~_yield _gtowns = _garrison select _gti _tc = count _gtowns _ti = 0 #tloop ~_yield _town = _gtowns select _ti _tflag = _town select 0 ?(_tflag == _flag): goto "found" _ti = _ti + 1 ? _ti < _tc : goto "tloop" _gti = _gti + 1 ? _gti < _gtc : goto "gtloop" _gi = _gi + 1 ? _gi < _gc : goto "gloop" ; We end up here if not finding the flag in any of the garrison towns hint "takeflag.sqs: this flag is not under any of the garrson towns' influence" exit ; Bingo! Now update the "flag taken" attribute in the corresponding ; "tx_GxTy" array stored in tx_AllG_towns #found ((tx_AllG_towns select _gi) select _gti) set [3, true] ; Finally, change the flag and remove this action from the flag pole _flag setFlagTexture "usa_vlajka.pac" _flag setFlagSide west _flag removeAction _actionid hint "Flag taken, action removed" Disclaimer: usual caveats about "not tested", "not the only possible solution", YMMV and so on applies... /me dreams of more complex data structure support in OFP2... aaah....sets...dictionaries... hash tables... the good stuff

I can think of a lot of possibilities if weapons and magazines had the ability of having something like event handlers attached to them, reacting to such things as "take", "drop" or "put". Also, which isn't related strictly to weapons, a "low-on-ammo" event for units would be *very* nice. Just like the "fuel" event, you know. But all this is probably matters for the OFP2 suggestion threads in a nearby forum...

Let's see now... you have an XP2500+ cranked to 2.46 GHz (from its default of 1.833 GHz) and an overclocked 9800Pro... then this followed by I have beeped Captain Obvious, but he seems to be out at the moment... Right... let me compose myself before continuing... there, ok... here's what you can try <ul> [*] Get a bigger PSU with stabler output. The Rolls Royce of PSU:s is PC Power&Cooling. Overpriced as hell, but good, they say. [*] Get better cooling in the machine. CPU, chassis, everything. Better != louder. Water cooling is an option. [*] PC2700? Please tell me you're only multiplier OC:ing and not expecting 200+ FSB from 166 MHz rated memory? [*] Abit motherboard? I have one... don't see why humans should be allowed to purchase them... Last but not least: the better thing to do: sell parts of that rig (keep the radeon) and get an Athlon 64 3400+ or something. That'll beat the snot out of that old clunker and improve OFP while your at it.

I like DKM. They have fixed that bug now and have a version 1.35 of the DKMM_RSC addon used by (among others) VIT's APC pack. Head on over to DKM mod home page and look for it under Downloads-> Tools/Scripts (RSC). Then replace any and all instances of DKMM_RSC.pbo that you have in your OFP folder(s). Tada. BMP-3:s with ARENA now work again. Thanks DKM!

Great stuff this APC pack. Found a problem though - there's a syntax error in a script in the included DKMM_RSC addon. More specifically in the script handling the ARENA feature: DKMM_RSC\scripts\VIT_APC_arena.sqs. The first line of that script begins See that little equal sign just after the reserved word private? That's what stuffs it up. This should read Had a hell of a time track that one down. Noticed it while testing the ARENA BMP-3 using ECP... Again, AKM, thanks for a great addon and keep up the good work. Cheers, KS!

AMD Athlon XP1700+ @ 1900+ (1.6 GHz) 1024 MB RAM(PC2100 / DDR266) nVidia FX5200, 64 MB @ 300/400 (core/mem), 53.03 drivers MB: Abit KR7A-RAID (VIA KT266A chipset) OS: WinXP SP1 AGP aperture: 128 MB, 4x AGP on, Fast Writes on OFP settings as per instruction. OFP alloted 640 MB of main memory in the prefs program. OFPMark 2.0 score: ~763 I need an Athlon FX-53 and I need it yesterday! That and a NV40/R420. Then again, don't we all...

Pang, try this: To add the teleport action to a player unit <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">actionid = player addAction ["Teleport", "teleport.sqs"] To later remove it <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">player removeAction actionid The script teleport.sqs <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">teleportee = _this select 0 hint "Click on map to teleport" onMapSingleClick { teleportee setPos _pos; onMapSingleClick {}} To move something else than yourself, you can use something like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> hint "Click on map to teleport" onMapSingleClick { someobject setPos _pos; onMapSingleClick {}} That would move the object called "someobject" to the map location you click.

The file effects.pbo is used by the ICP_zil addon for....well, effects. :-) It contains only scripts which is why it wont show up in the editor. A suggestion for future improvements to the addon(s) would be to rename the effects.pbo to use the OFPEC tag system, like noted by others here. Perhaps call it ICP_Effects and edit the affected addons accordingly. I love the addon. Great work, ORCS!

Great. About addon dependencies: the fact that everyone has the BIS BMP-2 is actually not enough. Any addon that depends on another addon needs to have the proper dependency chain declared. Otherwise, problems will occur when one puts addons into mod folders. Try this: make a new folder in your OFP folder. Lets call it "psc". Inside that, make another folder called "addons". Put the original BTRT_A.pbo into the OFP\psc\addons folder. Now make a new shortcut to OFP. Edit it to read something like <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">C:\Programs\OperationFlashpoint\FLASHPOINTBETA.EXE -nosplash -nomap -mod=psc (This would be for a shortcut to the beta (now at 1.96) version) Start OFP from that shortcut and load the mission "C02: Battlefields" I'll bet you'll get the error dialog "Cannot load mission: missing addons btrt_a". Seem odd, huh? I mean, that mission doesn't have the BTR-T in it, now does it? However, that mission does have BMP-2:s in it. Why the error message? The BTR-T addon depends on the BMP-2 and without declaring that dependency, one side-effect is that missions that have BMP-2:s in them will complain about missing the BTR-T even though they don't use it. Now add the dependency fix to the addon and try the same thing. Tadaa! Problem solved.

A truly beautiful addon. Great fun driving around in the BTR-T and raise hell. I had a quick look at the config and found a quirk. It's the classical old addon dependency thing. The addon uses weapons based on ones that are defined in the BIS BMP-2 addon. Therefore, in order for this addon to behave properly both when editing missions and having it on a dedicated server, one has to add a requiredAddons[] declaration. This is how the class CfgPatches part looks now: And this is how it looks after adding the proper addon dependency declaration: Another thing I noticed is the lack of use of an OFPEC tag to name the addon and parts internal to it (including any global variables an addon uses in its scripting). One can imagine this addon being called "PSC_BTRT_A" or "JOE_BTRT_A" (I don't know if either or both of these are Sebastian's tags, but you get the picture). These days, not using tags is so...2001 Again, a great addon just like all the others you have made. Cheers!

Checkout FM's page: Operation Flashpoint planes Down that page, you'll find the Phantom. Cheers!

Hint is: your gcc seems to not be properly or at all installed... What do the following commands tell you?<ul>[*] which gcc [*] rpm -qi gcc [*] echo $PATH

Did you try the other value Suma suggested in his "custom settings suggestion", i.e have you tried <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Sockets { rcvBufSize=10000; maxPacketSize=1490; }; and seen if the problem remains. As a note, I'm connected to internet via ADSL over PPPoE and have my computer(s) behind a router. I use the the following: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class Sockets { rcvBufSize=10000; maxPacketSize=1492; }; and its seems to be fine. Of course, I didn't have any troubles before adding this, so... Also, you could try connecting to one of the Zeus game servers (See Shrike's signature above) and see how that works out. The server machine is located in Germany, which should help you get low pings. Should that turn out to be fine, I can describe more in detail what the Zeus server settings are.

I've seen this problem when people name their servers something containing spaces, underscores or other characters that are not allowed in a proper DNS name. Could that be it? What's the name of the server? (Control panel->System->Computer name)

I dont even want to know why your runnin 3 servers on 1 box, i saw that on the eye and almost choked Heh... must be a two- or four-processor machine unless all three game servers only have one mission: a two-player chicken run using bicycles on desert island... Joking aside, their IP could also be a router and they have three distinct machines behind it.

If you need the local variable _vcl to refer to the last vehicle created, assuming the vehicles are created like bn880 shows above, you'd have to do a <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> .... call format ["%1 =""m113"" createVehicle getmarkerpos ""Respawn_West""",newM113Name]; call format ["_vcl = %1", newM113Name]; ... Now wether this combination of tricks is useful or even a good solution for your exact problem is another matter...

Whatever. I never promised it would. I should have mentioned that what I did was present you with syntactically correct code to "cover more groups in the same trigger". On to the problem... how about trying this somewhere in the intro:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{ _x addEventHandler ["dammaged", {(_this select 0) setDamage 0}] } forEach (units fg1 + units fg2 + units fg3 + units fg4 + units fg5)

Try using either of these as trigger conditions: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">( { damage _x > 0.5 } count units fg1) > 0 or <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">({damage _x > 0.5} count (units fg1 + units fg2 + units fg3 + units fg4 + units fg5)) > 0 And then either of these in the On Activation field <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{ _x setDamage 0 } forEach units fg1 or <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{ _x setDamage 0 } forEach (units fg1 + units fg2 + units fg3 + units fg4 + units fg5)

marine*, I'd suggest you uninstall whatever ECP you have installed (If you have used the ECP installers, then use the uninstaller programs). Remove (delete) the @ECP folder completely and start over again. Even though the installation process is described on the ECP page (see first post in this thread), people might need it in even simpler step-by step form. With that in mind, follow the instructions I wrote in this OFPEC posting, and you should be able to enjoy ECP and DR together: ECP DR help Especially note that in order to actually play with ECP, you have to start OFP with that mod activated, i.e you need a shortcut to OFP that includes "-mod=@ecp". So, again:<ul> [1)] remove all traces of ECP from your current OFP installation [2)] follow the instructions in the thread I linked to. [3)] Happy happy, joy joy.

At the time of this writing, there are linux versions of the 1.92, 1.94 and 1.95 servers available. In a few days there might be (or not, who knows) a v. 1.96 dedicated server made available too. Check the Flashnews forum for details and download links. 1.96 clients can play on 1.95 servers.

The problem with multiple instances of the Nimitz in MP lies inside the \hwk_uss_Nimitz\scripts\build.sqs script and the fix is simple. The why build.sqs is run by the init event handler within the Nimitz addon. Since OFP 1.92, the init event is broadcast to all machines (a *very* good thing, thanks BIS). Therefore, the build.sqs script will be run on every machine in a MP session. Because of this, we have to alter build.sqs so that only the server will create the whole carrier from the base part. We do that by making sure build.sqs only continues to run if the carrier is local to a machine. (It will be local only to the server) The how This is how build.sqs looks right now: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _vehicle = _this select 0 ;building ship model (...more code follows...) Just add one (two with the comment) line(s) to that, like so: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _vehicle = _this select 0 ; Build the carrier only on one machine ?!local _vehicle: exit ;building ship model (...more code ...) That'll keep her from doing the old cloning dance Now, if CoC would only get their fixed(?) 1.1 version of the CoC Torpedos pack out so planes firing torpedos wont collide with the just fired torpedo, I'd be a happy puppy.

In the init line of every vehicle you want on deck, put <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">this setpos [getpos this select 0,getpos this select 1,19]

Thanks for the re-opening. I'll add some meat to the bug description: Bug: (MP) Inability to disembark player-controlled AI:s from vehicles not local to that players machine Examples: Imagine a player having an AI squad and that they are all loaded into the cargo space of a vehicle. Here are a couple of scenarios: <ul>[*] A heli driven by another human lands to drop them off. Result: player cannot order his AI:s do disembark. The Mount (4) menu is empty [*] An AI-driven truck transports the player and his squad somewhere. Again, when stopped, the player cannot order them out in any way. Some "solutions":<ul>[*] If the player driving the transport vehicle gets out first, one can disembark the AI squaddies. A complete PITA if the mission requires a helo pilot to shuttle troops around. [*] You can Action - Eject (6) your squad either on a safe height or just before the truck (for example) comes to a halt. Often leads to ejection injuries. It seems that this bug has been with us for a while, which is unfortunate. Reading comprehension help for those about to reply Clever remarks about using UNLOAD TRANSPORT waypoints and <unit> Action ["EJECT", <vehicle>] solutions are misplaced and beside the point.

Hmm...odd... linux 1.95 + ECP/DR 1.065 starts fine here (the Zeus server machine, SLES8+SP3, basically). config.cpp and resource.cpp copied from @ecp/bin to the base ofp server dir as per normal.