Quick followup. Attempted to run this with DEV and ran into the same crashing problems.

Hey Ben85 - Agree that they still need to fix this. In the meantime, there is a workaround using Game Logic, but it's a bit of a kludge depending on what you're doing

First, create a Game Logic object almost on top of the object you want the trigger attached to. Then in the Game Logic's init field add this:

trigname = nearestObject [gamelogicname,"ObjectClassName"];

Then in your trigger simply set the condition to '!alive trigname' and it should work.

For example in my mission I had a trigger attached to the small radar at the end of the main airstrip on Altis watching for it to be destroyed.

I created a Game Logic Object on top of it called 'glR2' and put 'trigR2 = nearestObject [glR2,"Land_Radar_Small_F"];' in the init field of it. Then I simply created a trigger nearby with a condition of '!alive trigR2' and it works.

Of course, that means you need to go through your whole mission and redo all the triggers, but once you do it, it should stick from patch to patch.

Still...Devs...fix the changing of ID #'s...

Issue happened again with the latest patch 0.76.

I've figured out the problem, but I don't know if there's a fix. The ID #'s of buildings/objects are changing between patches. So a trigger attached to an Object ID #, will continue to stay attached to that Object ID # after a patch, but the Object ID # will be attached to a completely different object.

For example, in Beta Stable v 0.76, the Radar Array at Air Station Mike had an Object ID # of 68508. I had a trigger linked to that Object ID # and it worked fine.

I upgraded to the Dev version (0.77) and found that the Radar Array now had an object ID # of 123297. The trigger I had placed on the radar array was still there, but it was still grouped to Object ID # 68508 which was now attached to a wall at the airport.

Almost a year and this still hasn't been fixed? Has anyone figured out a work around to force AI to sprint?

Just means your trying to make your CPU run faster than it's supposed to. Lot of times you can get extra power out of it, but it can cause instability, and did exactly that in my case. Anyways, hope they figure out your issue!

Anything...just a quick question, are you overclocking your CPU at all? I had the _exact_ same problem and once I stopped Overclocking it went away. Seems crazy because the machine wouldn't crash and I ran Prime95 for hours without a problem, but A3 would crash every 15 minutes or so when I was overclocked.

I was running a i5-3570K.

Tested this out a little bit more. This does not happen in the HEMMT and Quad, but still seems to be happening in the Pickup. In the other two it does appear your player catches his breath.

Just for grins I opened up the editor, stuck one player and a helicopter on a empty map and previewed the mission. In about 10 minutes I crashed to desktop. I'll attach the rpt and bidmp file, but here is the end of the rpt file. Since I can't attach the mdmp file (it's 20 MB), I uploaded it to dropbox here: https://dl.dropboxusercontent.com/u/64136645/arma3_2013-07-11_22-42-25.mdmp

Mods: A3
Distribution: 0
Version 0.72.107486
Fault time: 2013/07/11 22:48:28
Fault address: 5E179560 01:00038560 C:\Windows\SYSTEM32\XAudio2_6.dll
file: test
world: Stratis
Prev. code bytes: FC 83 7D FC 00 74 2C 83 7D E8 00 7C 26 8D 4D FC
Fault code bytes: 51 8B 4D D0 81 C1 6C 01 00 00 E8 D1 04 00 00 89

Registers:
EAX:00000000 EBX:0C959368
ECX:17CDFEB4 EDX:5E18BAC0
ESI:0C9753B8 EDI:5E1862CB
CS:EIP:0023:5E179560
SS:ESP:002B:17CDFE80 EBP:17CDFEB8
DS:002B ES:002B FS:0053 GS:002B

Flags:00010246

FollowUp Info. After doing some searching online, someone else had this issue and fixed it by deleting the DLL folder and re validating files through steam, and another person completely deleted the Arma 3\DLL folder.

Tried both, but neither worked. Saw this in the end of the RPT files.

Re validated

Mods: A3
Distribution: 0
Version 0.72.107486
Fault time: 2013/07/11 14:33:53
Fault address: 68F51D41 01:00010D41 C:\Windows\SYSTEM32\nvwgf2um.dll
file: Showcase_Combined_arms
world: Stratis
Prev. code bytes: 8B 7D 0C 41 83 C7 04 8D 51 FF 89 7D 0C 89 4D EC
Fault code bytes: 3B 55 14 0F 82 66 FE FF FF 8B 7D 14 8B 4D F0 80

Registers:
EAX:00000000 EBX:00000002
ECX:00000005 EDX:00000004
ESI:00000006 EDI:2094AAFC
CS:EIP:0023:68F51D41
SS:ESP:002B:10E8FCB8 EBP:10E8FEF4
DS:002B ES:002B FS:0053 GS:002B

Flags:00010206

Deleted DLL folder.

Mods: A3
Distribution: 0
Version 0.72.107486
Fault time: 2013/07/11 16:51:51
Fault address: 41E147AE 20CB998:01165321 Unknown module
file: COOP_8_Static_Loop
world: Stratis
Prev. code bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Fault code bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Registers:
EAX:41E147AE EBX:0B689000
ECX:020CEB14 EDX:2C5E3A40
ESI:020CEB88 EDI:020CEB14
CS:EIP:0023:41E147AE
SS:ESP:002B:020CC5AC EBP:020CEA84
DS:002B ES:002B FS:0053 GS:002B

Flags:00010203

I don't believe this is actually fixed. Was playing with a bunch of friends last night and it kept happening, but in my case, it kept pulling out my AA launcher. There was no rhyme or reason when/why it happened, but it was happening times I either got shot or took damage (explosions, etc).

You guys arguing against this don't seem to understand that not all of us that want autorun want to get up and walk away from our computer. We just don't think that holding the "W" key for 15 minutes has any bearing on what's 'realistic' for a military sim.

If you're running in real life, do you sit there and think every two seconds, "Keep running forward, keep running forward, keep running forward..." Why does having a button that saves you from holding down the W key make the game any less realistic than what someone really does when they're running?

Being revived/respawned after you die isn't realistic either, but for the sake of making the game enjoyable, it's in there. Why punish the rest of us with carpal tunnel just because you want to hold down a key for 10 minutes?

To those that say you should just find a vehicle, that's not always an option in some missions/scenarios where vehicles are not prevalent all over the place. And speaking of vehicles, it's not entirely realistic than any soldier on the field can jump in any vehicle, heli or boat and know how to drive/fly/sail, but you can, once again, for the sake of making the game enjoyable.

I just don't understand this hate on so many people seem to have with the concept of an autorun key.

Nesquick and Adam - Can you validate how the new fix works? As in, how can mission makers take advantage of it? Do you need to just set initial weather on the server at mission start and everyone will stay in synch (including folks that connect later in the mission), or do you need to continuously send out some weather info from the server to clients?

Yeah, it's not working yet in my testing. Set a dedicated server to be heavy clouded and rainy through script on mission start with forceWeatherChange in the script and I connected two clients, and neither saw clouds/rain.

I then tried to add forceWeatherChange into the init.sqf for everyone near the end of it's run (and much later than the weather script ran on the server). One client saw rain/clouds, another client did not.

Awesome, I'll give it a shot. Thanks!

simulWeatherSynch has actually been out for a while and I use it to force cloud cover updates.

As for forceWeatherChange, there any documentation of it anywhere? I don't see it in the biki, and I didn't see any other posts in that dev thread about it. To immediately change weather, do you just need to run it on the server at weather change, or do you need to run forceWeatherChange on the clients as well?

I don't believe this is resolved yet. Weather may stay in synch during a mission, but weather set on the server by script at mission start does not synch out to clients.

Agreed, I can't see how weather would create any network overhead problems. Sending 5 or 6 variables to all clients every few minutes about current weather conditions can't even compare to network traffic dealing with AI/Unit positions...

I've been attempting to figure this out on my own in the meantime. I've got a semi working script to do this, but it's not the best, and it would be much better if the game just synchronized all MP clients to the same weather forecast by default.

http://forums.bistudio.com/showthread.php?164140-Creating-Dynamic-Weather-in-Arma-3

Please get to this asap. I know there's lot's of other issues/bugs floating around to deal with, but this pretty much kills most Multiplayer and since 90% of the game is now multiplayer it's a major issue IMO.

Playing any type of players against other humans will end up with someone having an unfair advantage over others when they have nice sunny weather and the other player has fog or rain and visibility drops.