Gnossos

NoBrainer, no, not the HDR bug. The 18x series drivers introduced a severe flickering bug in SLI-enabled systems. I can confirm 1212PDMCDMPPM's observation the the bug has been fixed not only in the 182.05 beta drivers, but in the 182.06 WHQL drivers. There's still some rapid-fire flickering as a mission loads ("receiving"), but it stops when the mission begins. Using nHancer to associate arma.exe with the crysis sli as profile suggested in another thread sort of worked with pre-182.05 drivers, but, at least on my system (2 8800GTXs), introduced other problems with overly bright, "brittle" colors. Go with the 182.06 drivers instead.

Back in 2003, Blanco posted the following question and received no replies: I've been fooling around editing user-made missions for ffur05 and ffsx07 and discovered that any of the three save functions (a savegame trigger, the menu option, and the cheat) break custom voices, radio messages, music, and, often, the accompanying subtitles, when saved games are reloaded. To judge by the error messages -- e.g., "voice1 file not found" or something similar -- the saved games don't retain the the cfgSounds, cfgRadio, etc. data in the mission's description.ext file. Strangely, the problem only occurs when a mission is played from the OFP missions folder; not when it's played by previewing it in the editor. Careful examination of the description.ext files, the sound files, and the stringtable files doesn't turn up any obvious scripting errors. (Two of the affected missions are General Barron's well-regarded "Platoon Commander" and the excellent OFPEC contest entry "Morning Dew" -- both of which are expertly and carefully scripted). Moreover, the problem occurs in when playing the missions in plain vanilla OFP v1.96 as well as in ffur05 and ffsx07. Do any of you scripting gurus have an explanation and/or fix for the problem? Or is this just another example of the unfixable savegame bug mucking things up? Thanks in advance, gnossos

ColonelSandersLite wrote: Makes sense. I'm new to scripting and haven't yet delved into the mysteries of init.sqs. Thanks for the suggestion.

ColonelSandersLite wrote: Yes, it should have been. Mea culpa. Instead of looking at my actual script, I simply copied the code sample from your post into my earlier reply. That's what I get for being lazy. BTW, two advantages of using the script with radio triggers, are: (1) as you noted, "hintC" give you the opportunity to write the info down; and (2) with 10 radio triggers (Alpha -Juliet), you can extract the info from 10 different units during a single map preview -- a timesaver if a mod incorporates a lot of addons

ColonelSanders' code sample didn't work (for me) when I tried entering it in a unit's init field. However, it worked beautifully when incorporated into a short script file named "getLoadout.sqs" called by a radio trigger with *[unitName] exec "getLoadout.sqs"* placed in the "on activation" field. "getLoadout.sqs" is simply: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_unit=_this select 0 hintC format ["Weapons: ""%1"", Magazines: ""%2""", weapons this, magazines this] It's a really useful tool for identifying undocumented, addon weapon and magazine names in mods like ffur2005. Thanks, ColonelSanders.

SnyPir's ChopperWait script is pretty reliable. ;This loop will force a chopper to stay on the ground until the players squad has boarded. The script; ;below is used by calling the script in the activation field of a Load waypoint. ;Note that this assumes there is an invisible helipad at the load point and that we are dealing with the ;player's squad, not an AI squad (there should never be this problem with an AI squad anyway) ;if u saved this snippet as "chopperwait.sqs" you would call it with: ;[choppername] exec "chopperwait.sqs" 1n the activation field of a load waypoint. Substitute the name ;your helicopter's name for "Chopper" and your Player's name for "aP". ; ;BEGIN SCRIPT _Chopper = _this select 0 _Chopper LockWP true ; loop until all of the players squad have got in #for1 ~0.5 ? (GetPos _Chopper select 2) > 5 : _Chopper land "GET IN" ; make the chopper wait until the whole squad is in _lead = aP _playerArr = units group _lead _num = count _playerArr _incount = 0 _tmp = 0 #for2 ? vehicle (_playerArr select _tmp) == _Chopper : _incount = _incount + 1 ? _tmp < (_num - 1) : _tmp = _tmp + 1; goto "for2" ? _incount != _num : goto "for1" ; the chopper will move off on its waypoints _Chopper LockWP false ;end exit ; ;That chopper is not going anywhere now. If on the off chance that the player tells his squad to get in ;and he is the last to board then the chopper will rise but land again. ;it just checks to see if the chopper has taken off without all the player's squad aboard, and if it has it ;makes it land again. ;REMEMBER THE INVISIBLE HPAD. it is the key to making helicopters do stuff ;snYpir