stick_hogue

I need expert help from the Arma dev experts here to understand a fundamental behavior difference between hosted/editor and dedi-MP. * Nutshell: ObjectX (not a vehicle, has no brain) was placed in the editor at Position 1. The sole player in the mission starts near Position 1 but is teleported *very far* away (>10km) to Position 999. The player takes action that tells the server to perform a REMOTEEXEC target=0 SETPOSASL command on ObjectX to move it 100m to Position 2. * Expectation: ObjectX should be at Position 2 on both the server and the client. * Actuality: In hosted/editor runs ObjectX is at Position 2 on both the server and the client even when the player is at Position 999, but on dedi-MP ObjectX is at Position 2 only on the server but remains at Position 1 on the client, regardless of what the mission scripting does with information age commands ON THE CLIENT (setTargetAge, Reveal, disabling dynamicsimulation). I've confirmed in dedi-MP that ObjectX on the server has moved to Position 2 by executing a 'localize' command to dump a getpos ObjectX to the server .rpt file. I've confirmed using Debug Console on the client that ObjectX on the client remains at Position 1. * Confusion: Even with the dynamic simulation system disabled entirely this still happens. Since the player is at Position 999 very far away, information age issues are expected, but they should be controlled by setTargetAge and Reveal commands. * My guess: Maybe dedicated servers are by default configured to override a mission's control over information age? I don't see a setting in dedi server .cfg that could change that. What the frakkin frak is going on??? <<edited 5/31: ObjectX has dynamic simulation DISabled, by the way. But I suspect the game is applying dynamic simulation anyway at long distances>> <<edited 5/31, pt2: To be clear, when the player is near ObjectX, sending the command to the server to have the server move ObjectX via that remoteexec call works just fine. But when the player is very far from ObjectX that's when that same process simply does not move ObjectX on the client. (even with dynamic simulation disabled for that object and disabled via enableDynamicSimulationSystem false, even after setting "prop" setDynamicSimulationDistance 60000;. (Also, as an aside, the reason this is an issue is because I'm trying to attach a camera object to ObjectX to use from afar, sort of like a UAV but not a UAV.)>> <<edited 6/2, pt3: Is it possible that static objects are *always* treated on dedicated server similarly to dynamically simulated objects, but separately from the dynamicSimulation system? (I could see it being like that, since normally static objects are always just that, static.) If that's true, it could explain everything I'm seeing. If so, any idea if there's a workaround aside from making a descendant class as a mod and altering whatever property(ies) cause this? <<edited 6/2, pt 4: I'm going to have to conclude that on dedicated server, dynamic simulation is always enabled beyond a certain distance, regardless of mission settings. Dealing with that will require some radical re-thinking of my approach, but I do have some ideas. Admins, you can retire/delete this post if you like.>>

Background: I decided that since Arma 3 is stable now I should try to revamp my StickSub scripting (and remove Nimitz mod dependency using USS Freedom objects instead, and other important improvements). General implementation: The sub is a static object ("Submarine_01_F") instantiated on the server, and controlled by a master loop script. Clients make changes via dialogs which use setvariable commands to change the commanded speed, commanded depth, and commanded heading of the sub. The helm/pilot's dialog includes cameras attached to various positions on the sub, and the NavINT dialog creates a Remote Designator object attached to the sub for use as a periscope. Each client creates 2 local markers in elliptical shape to represent the submarine, and those markers are constantly updated to the position of the sub. The immersion works like this: when you board the sub, you are SETPOSed to the theatrical set off map (USS Freedom interior). When you open your map, it centers on the sub. When you exit the sub, you are SETPOSed back to it. It doesn't take much smoke and mirrors - you immediately feel like this is all real and you're getting on and off the sub like it's a real boat. All that works splendidly with hosted server. I only recently gained local dedi testing capability. Problem: Dedicated server and hosted server behave completely differently in one way: on hosted server, the static object is synched with the clients even if they are far away from it on the theatrical set, and so the markers also correctly move in synch with the location of the sub, and the remote cameras attached to the sub show it moving through the world. But on dedicated server the static object is not synched with clients who are on the theatrical set far away, and so the markers also never move, and the remote cameras show the sub not moving. The moment I exit the sub and am SETPOSed to it, the game updates its position to my client, and so the markers update, too, and the cameras reflect the new position (when I return to the theatrical set and open the helm control dialog), but then they remain frozen in the new position again. What's been tried: EnableSimulationGlobal true EnableDynamicSimulation false SetTargetAge "Actual" Reveal EnableDynamicSimulationSystem false Hell, I even created an AI diver, set it to TriggerDynamicSimulation true, and attached it to the sub, and still the sub is not synched with clients who are far away (although I can see the diver marker on the map). All the setvariable data sent out by the server's control loop is fine, and the setvariable based info in the dialogs correctly reflect its movement, but the object location never updates for clients who are far from it on the theatrical set. My theory: There seems to be an in-built dynamic simulation system for static objects that's independent of the one for 'live' units controlled by the above-listed commands. I've seen comments that seem to confirm this, but nothing substantive. Does anyone know of a way to force a dedicated server to broadcast a static object's data to clients who are far away? Is this just a fundamental game optimization that can't be beaten? thanks in advance, Stick_Hogue

Background: I decided that since Arma 3 is stable now I should try to revamp my StickSub scripting (and remove Nimitz mod dependency using USS Freedom objects instead, and other important improvements). General implementation: The sub is a static object ("Submarine_01_F") instantiated on the server, and controlled by a master loop script. Clients make changes via dialogs which use setvariable commands to change the commanded speed, commanded depth, and commanded heading of the sub. The helm/pilot's dialog includes cameras attached to various positions on the sub, and the NavINT dialog creates a Remote Designator object attached to the sub for use as a periscope. Each client creates 2 local markers in elliptical shape to represent the submarine, and those markers are constantly updated to the position of the sub. The immersion works like this: when you board the sub, you are SETPOSed to the theatrical set off map (USS Freedom interior). When you open your map, it centers on the sub. When you exit the sub, you are SETPOSed back to it. It doesn't take much smoke and mirrors - you immediately feel like this is all real and you're getting on and off the sub like it's a real boat. All that works splendidly with hosted server. I only recently gained local dedi testing capability. Problem: Dedicated server and hosted server behave completely differently in one way: on hosted server, the static object is synched with the clients even if they are far away from it on the theatrical set, and so the markers also correctly move in synch with the location of the sub, and the remote cameras attached to the sub show it moving through the world. But on dedicated server the static object is not synched with clients who are on the theatrical set far away, and so the markers also never move, and the remote cameras show the sub not moving. The moment I exit the sub and am SETPOSed to it, the game updates its position to my client, and so the markers update, too, and the cameras reflect the new position (when I return to the theatrical set and open the helm control dialog), but then they remain frozen in the new position again. What's been tried: EnableSimulationGlobal true EnableDynamicSimulation false SetTargetAge "Actual" Reveal EnableDynamicSimulationSystem false Hell, I even created an AI diver, set it to TriggerDynamicSimulation true, and attached it to the sub, and still the sub is not synched with clients who are far away (although I can see the diver marker on the map). All the setvariable data sent out by the server's control loop is fine, and the setvariable based info in the dialogs correctly reflect its movement, but the object location never updates for clients who are far from it on the theatrical set. My theory: There seems to be an in-built dynamic simulation system for static objects that's independent of the one for 'live' units controlled by the above-listed commands. I've seen comments that seem to confirm this, but nothing substantive. Does anyone know of a way to force a dedicated server to broadcast a static object's data to clients who are far away? Is this just a fundamental game optimization that can't be beaten? thanks in advance, Stick_Hogue

Thanks. I'll go to the editing forums. The point behind my scripts is that they do not require a mod. There's definitely a segment of the Arma population that would prefer to keep mods to a minimum. Plus, there are differences between those mod subs and mine.

Meister Grimes, My guys have a drag script that's very similar to this one, and possibly was based on an earlier version of it. Thanks for that. But they have stopped using it because of a variety of issues that happen in special-but-unfortunately-not-rare-enough circumstances, like if someone disconnects while being dragged, or just getting broken animation states, or breaking TFAR, etc. I'm convinced that the issues have to do with using the attachto command for the drag, because attachto undoubtedly does things to player objects that BIS doesn't protect against in the rest of the game engine (why should they? that'd be a lot of code just to protect against exactly this odd situation). So I've begun experimenting with replacing attachto (and its closeout detach) with something like this: [_target] spawn { params ["_target"]; [_target,player] remoteexec ["disableCollisionWith",0]; while {FAR_isDragging} do { try { if (!isNull _target && alive _target && !isNull player && alive player && ((lifestate player) in ["HEALTHY", "INJURED"])) then { [[_target,player],{ (_this select 0) setposatl ((_this select 1) modeltoworld [0, 1.5, 0.092]); (_this select 0) setdir (getdir (_this select 1)); }] remoteexec ["call",0]; uisleep 0.1; } else { FAR_isDragging = false; }; } catch { FAR_isDragging = false; }; }; }; I'd be curious to know if you've had complaints about problems that you think might be related to attachto in the drag functionality, and whether or not you've ever tried an approach like this. It's really a simple idea: setpos/setdir instead of attachto. Why not? attachto must cause problems with player objects - we've all seen it. Thoughts? Anyone? Anyone? Bueller?

I just had the same problem develop magically overnight on the latest A3 release. On my end it was network protection related. After removing old Arma related exclusions and making brand new ones with TCP and UDP 2302-2303 ports allowed in Windows Firewall and my anti-virus software, it’s working again. My anti-virus software was also apparently downloading an update for itself when this happened, so it may have interfered. Either way, it's probably good to clean out old exclusions and try again, especially if old exclusions didn't specify the allowed ports. good luck, -Stick

I understand. We do what we can. No, thanks, I've already implemented the teleporting. What would really be nice is for the bridges to be destructible, too. I manually did setdamage 1 and they didn't blow up. My goal for the workaround was to only allow the teleporting if all segments of the bridge were still intact, but alas, I couldn't blow up the bridge segments. Best wishes, all.

Ack! I love Isla Duala from my "Limited Assets: Isla Duala" experiences, so I'm trying to make a new mission on it, but AI drivers (even with VCOM running) are coming to a dead stop on the Hazena bridge. I tried using a trigger to jump them past whatever might be stopping them, but it seems like they stop hard anywhere in the middle of the bridge (starting from a position about halfway between the first two pairs of street lamps on the west side of the bridge going east - haven't tried any other configuration yet). I have terrain setting on "high" and the AiA Lite pack. Could it be the Lite version causing this trouble?

I echo this request. My application really would benefit from being able to use camera objects as sources instead of units with MP/JIP support. Thanks for your work (so far) and thanks in advance if you add support for camera objects! Stick **EDIT** That said, using allowdamage, disableAI, hideobject and enablesimulation I'm cheating the system by using units as cameras. This is not ideal because they occupy space, but if it works I'm going with it for now. :)

TrooperWally, BIS_fnc_MP runs a script snippet you define, with whatever parameters you want to pass in. I don't know that it has limitations on which commands work and which don't. I think the idea is that it's just a platform for making sure code is run on all clients. Here's an example. In your init.sqf you define this function: SwitchActionMP = compileFinal " (_this select 0) SwitchAction (_this select 1); "; //parameters for SwitchActionMP are [unittoanimate, animationstring] And you call it like this: ... _Operator = unitwhatever; ... [ [_Operator, ""], "SwitchActionMP" ] call BIS_fnc_MP; //parameters for SwitchActionMP are [unittoanimate, animationstring] unless I misunderstood your request... (watch out for your nested quotation marks in the function definition, of course - and it seems to disallow comments inside those function definitions) -Stick

In hosted MP mode, with the FSF unmoving, I fall right through the platform when walking from the flight deck onto the starboard aft platform. Coming up from the well deck works, just getting onto the stairs platform fails. My workaround is to use a trigger attached to the ship that sends me directly to position "well3R". Here I'm sharing how to do that. Make a 1m radius named trigger set for BLUFOR PRESENT REPEATING, I called mine “trgFSFdescendstairsâ€, and attach it to your FSF with this attach command (I named my FSF “MyFSFâ€): trgFSFdescendstairs attachTo [MyFSF,[8.68,-29.5,-6.7]]; This model position is right at the starboard aft corner of the flight deck near the stairs. Leave the Condition field just “thisâ€, and put the following in the On Activation field of the trigger: {if ( (((getposasl _x) select 2)>7) and (_x==(vehicle _x)) and (abs((asin ((((vectordir _x) select 0))/(sqrt(((((vectordir _x) select 0))^2)+((((vectordir _x) select 1))^2)))))-asin ((-1*((vectordir MyFSF) select 0))/(sqrt(((-1*((vectordir MyFSF) select 0))^2)+((-1*((vectordir MyFSF) select 1))^2)))))<45) ) then {nul = [_x,MyFSF,"well3R"] execVM "\GNT_FSF\position.sqf"; _x setdir (getdir MyFSF);};} foreach thislist The getposasl z>7 makes sure it only triggers if you're on the flight deck, the vehicle check makes sure you're not in a vehicle (if you're concerned about this triggering if you're paradropping into this location, put another z check for <10 as the flight deck elevation is about 8.5, at least for the soldier unit I used for testing). The complicated vectordir stuff is to make sure only those facing the stairs (within 45 degrees of the aft of the ship) will trigger the trigger, so you don’t trigger it when coming up the stairs onto the flight deck (just comparing getdir results versus getdir+180 is problematic because of 0/360 wraparound). Seems to work for me, and I’m liking it! (At first I added an action to the ship, but you can only see the action near the front of the ship, and people might still try to take the stairs, so this seemed like an over all better solution for me.) cheers, Stick

[EDIT] Never mind the below note; as of now it appears to be working... Unfortunately, I've learned that the weaponstate command is problematic at the moment. https://dev-heaven.net/issues/28763 That's really a shame. Are there no other methods of detecting if a weapon safety is on?

Hell, I'd never heard of the SWITCHWEAPON action until Mik and I started working with these scripts. Good stuff drives research to make it perfect. :) Another approach to the F / control F issue might be to require the weapon mode to be SAFE before allowing an attachment switch (even more realistic), then remove the SWITCHWEAPON action. So the user must go to SAFE mode first then must come out of SAFE mode after the operation is complete. I like that idea and intend to implement it, but I only know how to do it using ACE. The condition can have this added to it: and (weaponState player select 2 == "ACE_Safe") and the SWITCHWEAPON action should be removed. enjoy, Stick

It's NOT necessary to rewrite these scripts. The first error you're seeing is because the loadingscreen is not included in that TWAT.Desert sample mission. Don't bother adding a preload manager module, just comment out the loading screen commands (there's an endloadingscreen command at the end of the init.sqf, too). There are other errors which may be related to race conditions or overloading the menuing system - they may be innocuous, I haven't proven that, but I do know they are random. Sometimes it's one weapon (not the one I'm holding), other times it's other weapons. If it's not innocuous and random weapons are broken every time you load, then the solution is to restrict the number of weapons using this TWAT system. Edit the initweapons.sqf to remove the ones you don't need. My buddy Mik and I tailored this only for the M4A1SOC and fixed a couple of issues: 1) you no longer need to press F or control F to get back to firing mode - using the SWITCHWEAPON action fixes that (the chosen index in the was-now code below might be specific to this weapon, but for other weapons you can experiment to find the index that works, and it might always be 1), 2) we removed the restriction on being near a crate, but to represent a delay and prevent you from switching modes essentially between rounds fired, there's a "bandaging" animation that closes with a "kneeling with weapon idle" animation. The bandaging animation actually places the gun on the ground, so it does appear as if you're working on your weapon. If you want a longer animation to force a longer delay, choose a longer animation (http://community.bistudio.com/wiki/ArmA2:_Moves). If you want to do this, edit your fn_menuDef.sqf files (all of them) to include the changes shown below: WAS: ["Add Suppressor",{ player removeweapon "ACE_SOC_M4A1"; player addweapon "ACE_SOC_M4A1_SD_9" },"", "", "", -1, 1, (primaryweapon player == "ACE_SOC_M4A1") && player distance box1 < 10], ["Remove Suppressor",{ player removeweapon "ACE_SOC_M4A1_SD_9"; player addweapon "ACE_SOC_M4A1" },"", "", "", -1, 1, (primaryweapon player == "ACE_SOC_M4A1_SD_9") && player distance box1 < 10] NOW: ["Add Suppressor",{ player removeweapon "ACE_SOC_M4A1"; player playmove "AinvPknlMstpSlayWrflDnon_medic"; player switchmove "aidlpknlmstpslowwrfldnon_idlesteady02"; player addweapon "ACE_SOC_M4A1_SD_9"; player action ["SWITCHWEAPON", player, player, 1] },"", "", "", -1, 1, (primaryweapon player == "ACE_SOC_M4A1") ], ["Remove Suppressor",{ player removeweapon "ACE_SOC_M4A1_SD_9"; player playmove "AinvPknlMstpSlayWrflDnon_medic"; player switchmove "aidlpknlmstpslowwrfldnon_idlesteady02"; player addweapon "ACE_SOC_M4A1"; player action ["SWITCHWEAPON", player, player, 1] },"", "", "", -1, 1, (primaryweapon player == "ACE_SOC_M4A1_SD_9") ] obviously leaving the weapon classes as is (just add the playmove, switchmove and SWITCHWEAPON commands and remove the && player distance box1 < 10 from the condition. Mik reconfigured the options for the M4A1SOC to A) remove the M203 because we would not screw around with adding or removing that in the field and if you want one you can get a weapon that already has an M203, B) remove the CCO because if you have a Holo (which allows for the 4x option) why bother with a CCO?, and C) added an option to have the 4x Holo attachment if there's no suppressor. So you can do long range or close quarters and in long range mode you don't have the suppressor option, and all these are "reasonable" to be changed out in the field, so we think. Having removed the F / control F interruption but adding the animation improves the immersion while preventing instant switching "between rounds fired", and we feel that's better than restricting it to crate proximity (if you're near a crate, just pick a different weapon). many thanks to the source authors, enjoy, Stick

It's been a long time since I messed with this on Limited Assets, but I think I had it working as follows: Passing _name into an onplayerdisconnected.sqf script: _connectedplayername = _this select 0; if (_connectedplayername == (name playerAssault_1)) then { playerAssault_1 setvariable ["lastconnectedplayername", _connectedplayername, true]; }; if (_connectedplayername == (name playerAssault_2)) then { playerAssault_2 setvariable ["lastconnectedplayername", _connectedplayername, true]; }; if (_connectedplayername == (name playerAssault_3)) then { playerAssault_3 setvariable ["lastconnectedplayername", _connectedplayername, true]; }; //etc. for each playable slot I also passed _name into my onplayerdisconnected script and did stuff like this: _disconnectedplayername = _this select 0; if (_disconnectedplayername == (playerAssault_1 getvariable "lastconnectedplayername")) then { _disconnectedunit = playerAssault_1; Assault1teamkilled = false; publicvariable "Assault1teamkilled"; }; if (_disconnectedplayername == (playerAssault_2 getvariable "lastconnectedplayername")) then { _disconnectedunit = playerAssault_2; Assault2teamkilled = false; publicvariable "Assault2teamkilled"; }; //etc. for all playable slots dostop _disconnectedplayername; //etc. (This was back when I was still using publicvariable and transitioning to the "new" setvariable/getvariable commands.) hope this helps, Stick

Let my map sit unattended overnight in HOSTED mode. When I returned the game had crashed with this error shortly after the onplayerconnected had fired: Exception code: C0000005 ACCESS_VIOLATION at 0059D1E2 graphics: D3D9, Device: ATI Radeon HD 5800 Series, Driver:aticfx32.dll 8.17.10.24 resolution: 1600x1200x32 Addons: <long list of loaded stuff omitted> Mods: ca;expansion;Expansion\beta;Expansion\beta\Expansion;dua Distribution: 1485 Version 1.52.72107 Fault address: 0059D1E2 01:0019C1E2 C:\Program Files\Bohemia Interactive\ArmA 2\Expansion\beta\arma2oa.exe file: co@13_LAID_OAv2_2 (__cur_mp) world: isladuala Prev. code bytes: 87 94 05 00 00 6B F6 24 8B 74 30 0C 85 F6 74 DB Fault code bytes: 83 BE E8 02 00 00 00 7E D2 8B 86 E4 02 00 00 8B Registers: EAX:1E48A800 EBX:2C3B1000 ECX:2C3B1578 EDX:00000007 ESI:66664565 EDI:2C3B1000 CS:EIP:0023:0059D1E2 SS:ESP:002B:017DF690 EBP:017DF7DC DS:002B ES:002B FS:0053 GS:002B Flags:00010206 ======================================================= None of my code has ever crashed the game with a graphics error like this, so I wonder if it's possible for a client player with a custom face or other such tweaks to crash a hosted server. DXDIAG reported system info: Operating System: Windows 7 Home Premium 64-bit (6.1, Build 7600) Language: English (Regional Setting: English) BIOS: BIOS Date: 07/15/09 10:09:10 Ver: 08.00.15 Processor: Intel® Core i7 CPU 920 @ 2.67GHz (8 CPUs), ~2.7GHz Memory: 6144MB RAM Available OS Memory: 6136MB RAM Page File: 1870MB used, 10397MB available DirectX Version: DirectX 11 User DPI Setting: Using System DPI System DPI Setting: 96 DPI (100 percent) DWM DPI Scaling: Disabled Card name: ATI Radeon HD 5800 Series Chip type: ATI display adapter (0x6898) DAC type: Internal DAC(400MHz) Display Memory: 3824 MB Dedicated Memory: 1012 MB Shared Memory: 2811 MB Current Mode: 1600 x 1200 (32 bit) (60Hz) Driver Name: aticfx64.dll,aticfx64.dll,aticfx64.dll,aticfx32,aticfx32,aticfx32,atiumd64.dll,atidxx64.dll,atidxx64.dll,atiumdag,atidxx32,atidxx32,atiumdva,atiumd6a.cap,atitmm64.dll Driver File Version: 8.17.0010.0024 (English) Driver Version: 8.732.0.0 DDI Version: 10.1 Driver Model: WDDM 1.1 Driver Attributes: Final Retail Driver Date/Size: 5/4/2010 20:18:36, 584704 bytes Driver Strong Name: oem17.inf:ATI.Mfg.NTamd64.6.1:ati2mtag_Evergreen:8.732.0.0:pci\ven_1002&dev_6898 Video Accel: ModeMPEG2_A ModeMPEG2_C DDraw Status: Enabled D3D Status: Enabled AGP Status: Enabled

This describes an experience in MP on hosted server, as the host, with First Aid Simulation and Battlefield Clearance modules running. I've had the issue for a long time that you can be shot in a vehicle and be in an agonized state in that vehicle with no way to eject, but in all my previous experiences (on the same map in Arma2 now ported to A2OA) I would eventually bleed out and die. Then Norrin revive would eject me and open the "waiting for revive" dialog. But in OA 1.52.71816 flying the Arma2 Ka-52 I was shot and agonized, landed the helo and never bled out. I decided to let it sit for 10 or 15 minutes to see if it would bleed out over longer period but it never did. Then I suspended the session and the game immediately crashed with an out of memory error. This is the first time I've ever experienced being agonized in the Ka-52. For all I know this has always happened, even in Arma2. Or maybe the new damage related code isn't recognizing legacy Arma2 vehicles the same way it recognizes A2OA native vehicles. Or some such. But either way, you should eventually bleed out, and it should not crash your game with out of memory error. (I have not found an explanation of the First Aid: Action module so I don't use it. For all I know it fixes this sort of issue...?) Otherwise I like what they've done with OA and look forward to the main bugs being fixed (e.g. ammo crate MP crash).

Here's an example of Arma2 gameplay that suffers due to poor physics. I have a map on which designated Engineer units can build several kinds of objects, including camo blinds. We routinely put blinds over our vehicles in enemy territory to help prevent the enemy patrol chopper from finding and destroying them. Under some circumstances the poles of a camo blind can touch a helicopter "in the wrong way", setting the helicopter into a jitter frenzy, trapped under the camo blind, until finally it explodes! It's hardly a "bells and whistles" situation to expect a helicopter to NOT jitter and explode because a small aluminum pole touched it. It should've knocked its own camo blind down before damaging itself at all, and it should not have jittered at all anyway as a result of a small pole hitting it. Having engineers build blinds is a perfectly legitimate example of Arma2 game play, the kind that distinguishes it from simpler games. And this is an example of how the vehicle physics ruins this superior game play. It's taken me a while to warm up to the way Arma and now Arma2 handle helicopter flight, and now I'm a fan, so I would not want the flight simulation to be ruined by changes to on-ground physics. That is, if going to a realistic representation of gravity and weight ruins the flight simulation, don't do it, but if you can apply weight to ground vehicles and aircraft that are on the ground, please do. Thanks.

Seems to me this can't be *that* hard for them to fix, since tankbuster proved that simple missions cause the problem to happen, and they must know which part of the code artificially drives VD down and creates fog to keep frame rate up, and testing doesn't involving recreating any special circumstances other than waiting. I'm holding out a fool's hope that they'll fix this eventually...

Aw, damn. Thanks for the info. I posted on that thread to confirm it does happen on hosted server (that's my situation) with a repeating weather script running. (fog seems to be ignored, but I have experienced changes in rain after the VD and fog set in) stick

This *definitely* happens on HOSTED server, too. I have a map that I always run hosted. It has a perpetual random weather script on a 30 minute timer with 30 minute transitions. After a few days the game stops responding to the fog setting, but continues to respond to rain, and possibly clouds except I can barely see far enough to see clouds due to the reduced VD and persistent fog. fwiw, stick

I didn't get a chance to post this before discovering beta 71275 is already up. I was running beta 70951 with a mission/map that runs for days (there's so much to do on it). I noticed that nighttime conditions have changed a lot since the last time I played nighttime conditions. This map generates random weather, but the nighttime implementation of the engine seems to have overriden the fog parameter. Visibility is something like 180m at night, even on a crystal clear moonlit night. After daybreak there's a persistent fog - the fog weather parameter seems to be overriden by it. And the visibility is so low that it appears as if this fog is what is causing the ridiculously low nighttime draw distance. So: at night there's 180m draw distance, after daybreak there's a fog that makes an equivalent draw distance, possibly from that same fog which is overriding weather fog parameter. You can't see squat, but apparently the AIs can see a little farther than you. Maybe this only happens as time progresses into nighttime and then daytime, as opposed to when you initialize mission time to night. I know a lot of maps don't run as long as mine so maybe nobody has experienced this happening as time progresses. For me this ruins the game. Wanted to register it here just in case. I'll go look for comments about this in recent beta threads.

For what it's worth, I've been getting CTDs loading my mission into the editor since beta 71141 on an installation that's been extremely stable. It's only with the last several betas that I've started getting these CTDs. Some kind of ATI graphics related error. These last betas are fundamentally broken somehow. I'm sticking with 70951 until I see that whatever was done has been fixed. (Meanwhile I'll look into driver updates, in case that's an issue.) <update> Updated my video driver: no effect. The 71141 to 71213 betas seem to be arguing with some of my mods, but not all. A particular map definitely is not loading, using these mods: Bundeswehr, CBA, MP Compatible Fastrope, Desert Mercs & Black Ops units, Littlebirds, and Isla Duala. FWIW.

Some kind of unit level override would really, really help. I have some scripted helicopter shuttles flying in a circuit of three helipads. If an enemy far away detects them and/or shoots at them they completely abandon their assigned waypoint and go flying off into enemy territory, inevitably getting shot down. DISABLEAI "target" and "autotarget" and combatmode "blue" don't prevent this, and reassigning the waypoint or issuing a moveto doesn't bring them back. They fly away and get shot down. What we have here is a situation in which APPROPRIATE INFANTRY BEHAVIOR IS INAPPROPRIATELY APPLIED TO VEHICLE/AIRCRAFT BEHAVIOR. I like the new soft formation behaviors (with noted suggestions by others in this thread regarding retreat, healing buddies, etc.) FOR INFANTRY, but I want to be able to DISABLE IT FOR PILOTS. The behavior of investigating enemy detections and fire DOES NOT SCALE UP to aircraft speeds. ************* UPDATE ************** As it turns out, even if I disable "aware" and "combat" soft formations I still see the above described behavior when my aircraft start in "stealth" mode (I keep them in stealth mode so they'll keep their lights off at night except when landing). I assumed they were automatically going into combat mode when they exhibit this automatic, uncontrollable seek-and-destroy behavior, so I disabled soft formations. But no dice. They still fly off and get shot down when detected or shot at. There must be some way to stop pilots from engaging in infantry behavior! Ack! ********************************** thanks, Stick

***** UPDATE ******** Never mind, thanks. I see now that the folder structure does not work out of the box. I assumed "x\caa1" was enough, but I found this URL: http://dev-heaven.net/wiki/cbp-caa1/HowToStartCAA1 which makes it clear that each subfolder has to be referenced directly. I assumed this was not the case because my startup line has a limited length and referring to each x\caa1\subfolder won't fit. My solution was to copy all the files from the various addons subfolders into x\caa1\addons. Thanks anyway. Maybe this post will help others with the same affliction. ******************** I've been using the original CAA1 mod from August for months, but I'm new to Yoma Addon Sync. The first time I used it was during the period in which the repository was broken, so I've never actually had it make CAA1 work for me. Now Kju has fixed the repository. I've been through all the servers (all worlds, arma objects, autumn plants, classic plants, qg objects, vehicles, oac core) and all my files are green (no old or extra files) and my -mod parameter is the usual: "C:\Program Files\Bohemia Interactive\ArmA 2\arma2.exe" -nosplash -mod=x\oac\oac_core;x\caa1;nrope -maxmem=2047 -cpuCount=4 -showScriptErrors -world=empty The nrope mod folder is where I've put norrn_dbo_fastrope mod. I also tried this with @CBA mod, because I read somewhere that CAA1 mod now requires CBA, but that didn't make it work (I know my CBA installation works, I use it with other mods). I've tried this with and without the empty x\caa1\addons folder. I also copied the bikey files into the "Arma 2\keys" folder anticipating their use in MP situations. Help? I can't get my Sahrani back.