killswitch

Same answer as in the OFPEC thread: replace [crew _chopper] with crew _chopper, i.e. drop the "[]" around the crew command, since crew returns an array. NB: crew returns everyone in the helo, cargo included and not, like the name suggests, only the pilot and gunner.

Tonal bridges are aligned for "normal", so any MP missions where you need to have good-looking, "working" bridges will have to do a "setTerrainGrid 12.5" somewhere (To avoid questions: in init.sqs for example). If the mission takes place elsewhere, there might not be a need to change the terrain detail level, of course.

Yep, I know what you mean (XP 1900+, GF2 32 MB ). However, the non-aligning bridge segments one gets unless using normal terrain detail level is an OFP "feature". The only way, if I'm not mistaken, would be for the poor BAS guys to re-do the whole island and make a version for "low" or "very low" terrain detail, but that's just far too cruel IMHO and not going to happen. Ok, send them a cool million $/€ and you might get one, but...

Could it be that this so-called "wrong placement" disappear if you set the OFP terrain detail to "Normal"?

Hooray! Now there's at least three of us now that know the importance, nay, compulsoryness (is that a word?) of properly specifying requiredAddons in the configs. Keep spreading the word! Karr, did you know that there's a newer version of Hawk's 2s19 piece? Nowadays its "hwk_2s19" to comply with the OFPEC Tag system. Its a moving target and he updates it every now and then, but the latest version seems to always be at hwk_2s19.zip Back to RTS:ing! Its marvellous, K!

I'll second Tannethals explanation up there, Doolittle. Like he says, there are a few different sets of config properties governing a vehicles usage of its weapons: <ul> [*]The detection range (irScanRangeMin and irScanRangeMax). ("Red blips on the radar") [*] The engagement ranges (min/mid/maxRangePropabilities and so on in the ammo definitions) [*] The cost for a certain ammo type vs the targets value What you experience in the BIS "M2A2" is that you never get red blips/squares in the commander's radar. He might still get whiff of enemies, but that's by using his game-simulated eyesight. If there's any normal BIS ofpor armor around, that never happens, though, thanks to express delivery of some 125 mm love or some ATGM from the nearest BMP. This is due to the Brad being "IR-blind" and the others not. For testing, I have used the Real IFV pack by Ash et al. and modified it to step into the world of Resistance configs. (requiredAddons[]={bradley}, irScanRangeMin and Max to 500/4000 as normal). I also did some changes to the ammo definitions to have the Brad's use their TOW's out to 3750 m instead of chipping away the paint on T80:s with the cannon. Properly re-configured, I can assure you that the Bradley is one nasty little bugger on the battlefield. There's nothing quite like a large open desert area with high view distance and a tank battle supported by properly configured Brads and BMP:s.... missiles galore. Therefore, I offer this info to any makers of new Brads to beware of that nasty irScanRange* inheritance bug and configure them to use their arsenal of munitions properly. A word of caution: if you think this is "off-topic", you need to Drop that O2 right now and step back! You are one of those weekend addon makers FlipeR mentioned.

Yes, Si, da, ja! Quite possible as one solution to the problem of some events not being broadcast.

I'm waiting for addons that, on release, have their addon dependencies done completely right (an easy thing to do). This way, it wont add itself to missions where it isn't used. It also wont give players "Cannot load mission: missing addons <someaddon>" when they load missions that dont have that addon in it. Further, it will make dedicated servers load their missions without mysteriously just returning the players to the mission selection screen or give them a "Cannot load mission: missing addons <somebrokenf-ing-addon>". I'm also waiting for already released addons to be fixed and re-released as proper working addons in this regard. You can add more of your fancy textures and animations and whatnot later. Make them work properly first, no matter where they are installed (base Addons folder, Res/Addons folder, or in a mod folder) Yeah, that will do for me.

And a little addition to that will make you even less irritated: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> "D:\Operation Flashpoint\FLASHPOINTBETA.EXE" -nosplash -nomap The -nosplash removes the splash screens you see when loading the game.

Ooh! Nu Brads! Me happy. A word of caution/tip to anyone out there doing a new Bradley - the original BIS Bradley has a rather serious config bug. Here's the deal: The BIS Bradley inherits from the M113 class. Looking inside the M113 config, we see, among other things, this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ... irScanRangeMin=0; irScanRangeMax=0; ... and the Bradley is configured thusly: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ... class Bradley: M113 ... and it never restores those properties to the same values that almost all other BIS Tank-based vehicles have (BMP,BMP-2, T55,T72,T80, M60, M1A1 with the Shilka excluded). What do they have? Well... <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ... class Tank { ... irScanRangeMin=500; irScanRangeMax=4000; ... } Can you say "Uh-oh". Now you know why the BIS Bradley in many ways is a useless death trap, blind as a bat. And, on a more general note, stop using the likes of irScanRange=900 in your tanks/APC:s. Use the irScanRangeMin and irScanRangeMax values and leave the middle ages of CWC 1.46 configs. Also, if your new Bradley inherits from the BIS Bradley, remember that at least a minimal requiredAddons={bradley}; is needed for a working addon. Eagerly awaiting properly configured, good-looking BFV variants. Greets!

The inability for AI helos to rearm/repair/refuel hovering above a support truck is something that appeared with 1.91, if I remember it correctly. I too was playing Bagel's "Tour of duty" and had ammo trucks at FARP:s out in the field. They might pick up one or two mg/cannon shells while slowly passing over the ammo truck, but they "never" get fully loaded. I mentioned this in one of the old 1.90/1.91 beta threads, but it has either slipped by BIS eyes or was deemed less important. Here's to BIS seeing this and having the time to take a look at it. Oh, while I'm at it, an "ammo" event would be very useful for these situations. I mean, we have "fuel" and "dammaged". Fix for at least one of the bas addons by yours truly on page 28 of the Tonal Island thread. Some of the others need some work too, though...

On the contrary - the beauty of UA is that you roll your own artillery piece as a separate addon ("pbo"). (It still requires the CoC_Arty addon, of course.) How you do that is hinted at/outlined in broad strokes in the CoC_Arty_Documentation.doc, however, a specific "how-to" isn't there yet. IIRC Dinger has hinted at doing some sort of tutorial at a later date. Right now, I wish him and the other chaps a well-deserved vacation from the CoC Labs I know its possible since I have been able to do a "wrapper addon" around a 3rd party arty piece and made it work with UA, but it took some time and involved digging through a lot of scripts in the UA suite. And no, I wont let that one out the door, since its not my addon and I need to get more acquainted with the inner workings of UA. In time, when UA stabilises I will probably approach the original maker and suggest him to add UA magic to his addon, or ask permission to release the "Frankensteins Howitzer" I hacked together.

Yep. The new one has he same things as the old one. The difference is that you use the Kegetys version with Resistance. That's exactly why :-) Ok. Check to see that GameSpyWare has the correct path and uses the right executable.

One thing... you´re not starting the old 1.46 OFP executable, "OperationFlashpoint.exe" from GameSpy, now, are you? The correct one is FlashpointResistance.exe (version 1.75 and up) (Or FlashpointBeta.exe for the 1.94 beta, Flashpoint192beta.exe for, yep, you guessed it - 1.92)

Excellent suggestions. Some more: * I'd like to see the "killed" event be broadcast to all machines. As an example, GMR:s Realistic Explosion mod could use that instead of CPU-heavy @condition scripts * New events "ammo" (when unit runs low on ammo, coincident with "nn, AMMO LOW") "eject" (like suggested above) * Extensions to the config.cpp syntax: - Constructs enabling adding event handlers, not overriding them. - Have skill of soldiers in CfgGroups not be rank-dependant, but with, say, a minSkill and maxSkill and have the units skill be randomized inbetween. * Scripting command extensions: - Ability to read properties from config via scripting. Example: To read the main/backRotorSpeed from helos to be able to simulate tail rotor failures and correct torque-induced spinning direction. - createMarker, setMarkerText, getMarkerText - createWP or something to add not only ad-hoc move WP:s, but also guard, sentry, hold and whatnot instructions to units. - a command to query the existance of an addon/class, to do things conditionally if a user has, say, the OFPEC Blood addon or not. - have radio triggers indicate who called the radio in its thislist * Server logging - Concur with Pennywizes suggestion. Add to that the logging of in-game chats. Ok, thats about it for now. Right, sign me up for key bindings too. Alt-E for eject!

Mod folders or bust! OFP/Addons? Thats where broken trash addons go until I can't stand it and fix them. (and island intros, of course) OFP/Res/Addons? Not a single non-BIS addon and there never will be nor need to be.

"co @07 rainy season" from CoC UA (BK 1.0) wont load for two related reasons:<ul>[*]It lacks a "jam_magazines" in its addons[] part of the mission.sqm. This is because... [*]bas_opcpp.pbo lacks a proper requiredAddons declaration in its config.cpp. If it had one, the jam_magazines would be added to the mission when the mission maker previewed it in the editor. Fixes for this particular error: <ul> [*] add "jam_magazines" to the mission (in addons[] =...) [*] correct the bas_opcpp.pbo using the information I posted on...page 28 of the Tonal Island thread After this, I'll bet you will get the next error message waiting in line to tell you that yet another addon has an improper requiredAddons declaration. The huge amount of addons out there with missing/incomplete addons dependency declarations is a widespread problem that needs to end. Yesterday.

Hmm... would this do it: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ; ; ammosprinkler.sqs ; ; Usage ; ; [unit] exec "ammosprinkler.sqs" ; ; Or, to prevent the deletion of the dead corpse (possibly due to having some ; other nifty script do it ; ; [unit, false] exec "ammosprinkler.sqs" ; ; Some constants. Edit them to your liking ; Name of this script. If you choose to rename it, change _THISSCRIPT ; to the same name. Default: "ammosprinkler.sqs" _THISSCRIPT = "ammosprinkler.sqs" ; How long before the corpse is removed and the ammo is created where it was _REMOVEDELAY = 100 ; The "wait until unit is dead"-loop delay _DEADDELAY = 1 ; The "search for a WeaponHolder" loop delay and search timeout _SEARCHDELAY = 1 _SEARCHTIMEOUT = 20 ;----------------------------------------------------------------------------------- ; No need to edit below this ;----------------------------------------------------------------------------------- ?(count _this == 0 && local player): hint "Error: "+ _THISSCRIPT + " called with no parameters! Exiting."; exit ?(count _this == 0): exit _dude = _this select 0 _bDelete = true ; Someone is possibly overriding the default value for deleting the dead body ?count _this > 1: _bDelete = _this select 1 ; Script is called with all three parameters. Jump to the label indicated by ; the third parameter. ?count _this > 2: goto (_this select 2) #init ?local _dude: [_dude, _bDelete, "local"] exec _THISSCRIPT; exit [_dude, _bDelete, "nonlocal"] exec _THISSCRIPT exit #local #localwait ~_DEADDELAY ?alive _dude: goto "localwait" _wpns = weapons _dude _mags = magazines _dude _magcount = count _mags _wpncount = count _wpns ~_REMOVEDELAY ?(getDammage _dude < 0.95): exit _pos = getPos _dude _wpnh = "WeaponHolder" createVehicle _pos _c = 0 while "_c < _magcount" do {_wpnh addMagazineCargo [format ["%1",(_mags select _c)],1]; _c = _c + 1} _c = 0 while "_c < _wpncount" do {_wpnh addWeaponCargo [format ["%1",(_wpns select _c)],1]; _c = _c + 1} ~(2+_SEARCHTIMEOUT) ?(!isNull _dude && _bDelete): deleteVehicle _dude ; all done locally exit #nonlocal #nonlocalwait ~_DEADDELAY ?alive _dude: goto "nonlocalwait" _wpns = weapons _dude _mags = magazines _dude _magcount = count _mags _wpncount = count _wpns ~_REMOVEDELAY ?(getDammage _dude < 0.95): exit ; On the machine where the unit was local, a WeaponHolder is created. Here, we ; just wait for it to appear and snag it. _tstamp = _time _timeout = _tstamp + _SEARCHTIMEOUT #nlloop ~_SEARCHDELAY _wpnh = nearestObject [_dude, "WeaponHolder"] ?((_time < _timeout) && isNull _wpnh): goto "nlloop" ; Just a failsafe: Did we get it? If not, just give up, exit and hope some other dead soldier ; will generate a proper ammo pile for players to loot. ?isNull _wpnh: exit ; Ok, we have a WeaponHolder created on some other machine where _dude was local. ; If its empty, fill it to spec. If it isn't empty, it probably means ; that some other guy died nearby and we got hold of that one instead. ; If so, TS - just give that holder even more ammo. _c = 0 while "_c <= (_magcount - 1)" do {_wpnh addmagazineCargo [format ["%1",(_mags select _c)],1]; _c = _c + 1} _c = 0 while "_c <= (_wpncount - 1)" do {_wpnh addweaponCargo [format ["%1",(_wpns select _c)],1]; _c = _c + 1} ; all done non-locally exit That contraption monitors units both locally and everywhere else. When unit dies, it sleeps for _REMOVEDELAY seconds and then replaces the corpse with a WeaponHolder and fills it with the weapons and magazines the deceased had at the time of his demise. I have only briefly tested it by starting both a dedicated server and a client on my computer. This means that the script hasn't been properly tested under adverse conditions, i.e. with network delays and all that real life stuff that scripts succumb to. NB: If a new guy respawns, he needs to have that script attached to him again, both remotely and locally. How to do that is left as an exercise... Ok, pick it apart, bash it, abuse it and see if you can make it suit your needs. Peace, out!

It should be<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">CoCIFNoSplash=true

I wonder if this is: 1. a Windows limitation? 2. an OFP limitation? 3. some other error your friend caused? It might be one or both both (1) and (2): <ul> [*] Windows itself has a limit on the length of the command line. At some point you'll see that you cannot add more characters to the sommand line in shortcuts. (Could it be 255 chars?) [*] OFP 1.92 has a problem with a -mod=... part longer than 80 characters (including the five chars making up "-mod=") where trying to host a MP game with said 80+ mod-part will give you the old CTD. This is fixed in 1.94 and is not present in 1.91.

Nah, I'll settle for one bottle of a good single malt. Â Glad to be of help.

Yes. This problem has popped up a lot lately in this thread, but here it goes again, phrased in yet another way so as to possibly help people recognize it: the "Cannot load mission - missing addon bas_opfor" problem can be fixed by editing the config.cpp of the bas_opcpp.pbo the way I describe in my post on page 28 of this thread. Its an addon dependency problem. (You may want to browse page 52 too, where it is also mentioned) Note: BAS are aware of it, so there's no need to bother them with that problem anymore. Await their fix or DIY in the meantime. Note, however, that the UCE units are, if I remember them correctly, pre-resistance units and therefore also part of the problem in that they are somewhat lacking in the "config strictness" department, so you might still experience problems after fixing the OPFORs. Â You might want to consider replacing UCE:s units with the reconfigured-for-Resistance variants by SDOC. See SDOC-UCE units

Here's a suggestion for finding some of the answers to your questions: Try it! Put this in a lone player soldier on an island in the editor and preview. Then click around and see what it does. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> onMapSingleClick {hint format ["pos: %1\nunits: %2\nshift: %3\nalt: %4",_pos,_units,_shift,_alt] } Yes, there are three values in the position array. It seems you get a negative z-value for the contour altitude in the map position you klick. The z-value seems to be from the 0-plane below the ocean floor. I guess one can approximate it to say the height value is "ASL".

I find myself reluctant to answer anything but a firm "No" on this. The reason being that the four first points are "academic assumptions" or, as I would express it, "something only a suit-wearing capitalist hippie high on glue" could reasonably believe in: See, companies are bound by law to do one thing, and one thing only: make more money. While a game might be great, points 2-4 will inevitably fail in reality. Case in point: Cornered Rat's "WWII online". Its, what, two years since release and still a steaming pile of something you dont want to step in. This is but one of the many subscription-based abominations that keep popping up. Sadly, this seems to be where it's headed. And do believe me, that you will never get a good software product, even after having spent $500 over the years for it. Corporations and software quality dont work together in the same sentence. It's up there with "peace in our time". Now, don't get me wrong. I suppose that in a world where we could have honest companies giving us all that Avon listed, I'd see it as an alternative to a one-time purchase. I just dont see it happening in a satisifying way for customers. As a company, I'd do exactly what they are trying to do right now, i.e boil the frog slowly and promise all suckers out there that things will be better if you "hook up with some of my fine shi*". Remember, the first ride is for free, kids.

Ok. I've read this about ten times now and tried to turn it into english...but here goes: The simple install: <ul> [*]Skye.pbo and all the other addons in SkyeV2.zip goes into your OperationFlashpoint/Addons folder [*] The "map" (called "mission" in OFP) should be put in your OperationFlashpoint/Missions and/or the MPMissions folder [*] The mission file is "TheSkyeVirus v3.03.Skye.pbo", btw What *not* to do: <ul> [*] Do not put anything in the "Worlds" folder [*] Do not put "TheSkyeVirus v3.03.Skye.pbo" in any Addons folder [*] Do not put SkyeV2.pbo and the other addons into any Missions folder Also, as a last note: you don't need to vent your frustration over people not responding to your questions within 5 minutes of posting it in other threads. This is "whining like a baby" and is generally frowned upon. Good luck with the zombies!