Hello, Could you please attach video showcasing the issue? Thank you.

I dont know how it is with licensing. But a good Workaround is the CUP Weapons Pack. Just search the Steam workshop.

-bump

BUMP any help?

If your game crashes please upload the Minidump. The Path is %appdata%\..\Local\Arma 3\ or C:\Users\<Username>\AppData\Local\Arma 3\

http://feedback.arma3.com/how-to-user.html

if anything at all performing those steps just seems to make the game crash faster.

Crash at start when logged in MP invade & annex play:

Mods: Arma 3
Extensions:
Distribution: 0
Version 1.46.131175
Fault time: 2015/07/08 12:53:52
Fault address: 0160A22E 01:00AE922E C:\Program Files (x86)\Steam\steamapps\common\Arma 3\arma3.exe
file: co60_AW_Invade_Annex_2_82D (__CUR_MP)
world: Altis
Prev. code bytes: 88 84 01 00 00 51 8B C4 53 FF 74 24 74 C6 00 08
Fault code bytes: 8B 01 FF 10 8B 5E 0C BD 01 00 00 00 85 C0 74 09

Registers:
EAX:02D51D48 EBX:00000000
ECX:00000000 EDX:3C0AABC4
ESI:3C0AABC0 EDI:3BD2AB00
CS:EIP:0023:0160A22E
SS:ESP:002B:02D51D40 EBP:00000000
DS:002B ES:002B FS:0053 GS:002B

Flags:00010202

note: Minidump has been generated into the file C:\Users\Utilisateur\AppData\Local\Arma 3\arma3_2015-07-08_12-51-04.mdmp

this may seem weird but none of these fixed it and when i get into a car say the hatchback the game instantly does it but when i was in a helicopter it was fine.the game ran for around 20 mins

Hello, it seems you are experiencing Access violations. You can find potential fixes for the issue here: https://community.bistudio.com/wiki?title=Arma_3_Unusual_process_exit&redirect=no#0xC0000005_-_ACCESS_VIOLATION

Thank you for your feedback.

Hello, it seems you are experiencing Access violations. You can find potential fixes for the issue here: https://community.bistudio.com/wiki?title=Arma_3_Unusual_process_exit&redirect=no#0xC0000005_-_ACCESS_VIOLATION

Thank you for your feedback.

Hello,

issue is fixed in DEV branch and will be part of Eden update.

Thank you for your feedback and have a very nice day!

Hello, sorry for late feedback. Issue is fixed in 1.49 DEV branch and will be part of stable 1.50 update.

Thanks for you feedback and have a very nice day!

Roger that!

I think it can be closed....

Ah seems you don't like to play that challenge! here is screen shot of that target which I never could find:
http://dc303.4shared.com/download/e6LritYBce/2015-08-15_00001.jpg?lgfp=1000

Could you please attach a screenshot of the issue? thank you.

I'm unable to reproduce this issue. The target is there 5 out of 5 attempts, but it's *very* well hidden by dry brush. There is another target near the car wreck which is, by design, only there with a 40% chance.

Please can you try to look for the target again? Scan using magnified zoom and move around in the CP area. Thanks!

IF you just play that mission you see issue, screenshot just show no target, nothing more.

Yeah BIS, I have to agree! Most of the fixes or replacement fixes are usually 5 steps back. I also think that you really need to start listening to mission makers and Mod makers as we have more experience than a weekend Script Kiddies. Proven example you changed the run cycle to a slower unorthodox run, not only does the animation look like he's Jogging but really what should have been done was leave the old full out run with hands down on the side and then added this new run as an additional slowing animation during stamina loss thus adding a new script line to allow the Mod makers and Mission makers to chose what they feel was good for their missions or mods. So far you guys remove great features and start handing us supporters of the game useless and just game breaking crap. This is common with other software that will have a great feature, then all the sudden lets remove it and give them something they can't use. Seen this with facebook, skype, Microsoft Operating systems the list goes on and on, what is there a backdoor deal with this give everyone a taste of greatness and then Take it away? Please BIS You should really leave the original alone and add into with options to script it out or not on our end.

Please fix, I love this element so much. Thanks.

@Dwarden: I don't want to offend anybody at BIS, but many fixes you guys do are often hit-or-miss. I'd much prefer to have options, at least while the issues are being worked out, because it's clear that the syncing stuff was served a bit undercooked. I do hope that the situation improves in v1.48, as you suggested.

Example:

Every frame the server increases Arma's internal clock which is basicly diag_tickTime. When the framerate on the server goes down, seconds themselves actually take longer. This breaks the time / weather sync because clients internal clock is actually running at the correct rate. Because of this, servers that sometimes have low frame rate can sometimes never actually reach night time, even though the clients do. Once the sync interval is reached all the clients are forced to be set to another time older then what it is supposed to be causing massive lagg spikes.

"Disabling something instead of fixing it isn't exactly an option"

What and implementing updates that constantly wreak havoc on community servers is?

disabling something instead of fixing it isn't exactly option ...
with such approach you can toss whole weather feature off window ...

anyway there is 1.48.131439 release candidate available and includes weather sync fixes so please test it there

also the problem you mention sounds more like mission issue cause it's trying use obsolete approach how force weather

All this worked fine about 8 to 10 months ago from what I can recall. Please BI, get this sorted out as soon as possible. The game is already riddled with enough bugs and awkward issues that we are forced to put up with.

Unless you guys make weather *AND* time sync less performance intensive and fix it so it's not dependent on server framerate. Then we at least need a option to disable it.

Everything was perfect before you guys added in this auto-sync thing. Least we could get an option to disable it.

Weather / Time Checks happen now multiple times per second and it's not even worth it.

Even when said problem is fixed, least give mission developers the ability to handle it the way they want.

Time Sync is also broken, we need options to disable. If the server framerate goes down then the servers perception of time itself breaks and forces time and weather laggy re-syncs which causes major problems. We need the option to disable this and use our own time / weather syncing system that isn't dependent on server framerate.

Could you please attach video of the issue? Thank you.

has already been fixed on dev

AKM is a mod weapon, Breaking Point is a mod. If it's not a bug you have experienced in vanilla ArmA 3, you shouldn't even create a ticket about it.

Hey, as Seifer stated AKM is not a vanilla gun. If the issue is indeed in vanilla game and reproducible please make a new ticket. Thank you.

Hello, this only happens on unofficial mission right? If yes then your best bet would be to contact creator of the mission and report the issue to him since the missions is not made by BIS and thus unofficial. Thank you.

Fixed in version 1.48 even though not mentioned in SPOTREP. Hoorah.

Is it? I should try using the Aim Deadzone again.

After further inspection I've noticed that weapons, even with weapon deadzone enabled do not retain that feature when running while binoculars do and that is the real problem. Running and turning with binoculars in hand and weapon deadzone enabled makes it impossible to properly move around.

I noticed this and stopped using it after noticing this annoying bug.

Hello, This is a correct behaviour. The reason why you are seeing different animation in-game is due to AI being active. If you disable AI the animation will play correctly. Try putting the following code into the AIs init field in editor:

{this disableai _x} foreach ["anim"]; 0 = this spawn {waitUntil {time > 0}; _this switchMove "Acts_HUBABriefing"}

Thank you for your feedback.

... and you clip through walls or windows. RIP

Sorry but this is like saying, "my car has a flat tyre, it doesn't drive too well, this is extremely annoying".

I dunno try -autotest if you dont want to check missions for errors manually? https://community.bistudio.com/wiki/Arma_3_Startup_Parameters#autotest

Yup, still the same in 1.54 stable.

Will be fixed in the next Steam Dev update. Thank you for your patience.

Hello all,

I discovered, that this fix has been accidentally reverted. We will re-fix it as soon as possible.

Thank you for understanding!

Hello,

I finally fixed the issue. Fix is available in Development Branch 1.53.132440 (you can switch to Development Branch via Steam by right clicking Arma 3 in your Library, go to Properties, select BETAS tab, select development - Development Build and then wait for Steam to download the data) and will be part of 1.54 Stable update.

Thank you for your feedback and have a very nice day!

This issue is still present in version 1.54 Stable.

This ticket is about crash. Crash is fixed.

And yet, we still have a command that, while no longer crashing the game, spawns an item into the inventory in an *invalid* state. Either that command can not be used with magazines (or weapons for that matter); then it should (gracefully) fail, or it should just fucking work. The current state is simply not acceptable.

Granted, this might have been the case before these crashes have been introduced, and I just didn't notice that the smokes were not actually functional... Then again, this only further stresses my point: either it works or the damn game needs to let me know that I'm doing something wrong.

If you have other issues, make another ticket,
yet I advise against it [...]

Or, you know... we could just stop being this anal about how-to-ticket, given the scope of this one here is debatable anyways: the crash was just a symptom, while addItemCargoGlobal is still broken, as argued above.

There are way to many more important issues to deal with [...]

There are always more important issues.
So what? :|

[...] than adding support for magazines to addItemCargoGlobal

Again you're confusing the symptom with the underlying problem. This is about a poor API. And the costs of a poor API (for everyone; be it the maintainers or the users) are horrendous.
If one "addItem" command can only add actual items, but other "addItem" commands can also add magazines and weapons, then something - clearly - went wrong, and it needs to be fixed, instead of carrying on with a bloated, ugly and prone to error API full of weird commands. Have you ever heard of PHP? :(

Now I'm certainly not going to open a ticket for a cleaned up API; but I thought it would be valuable to give at least some (general) feedback in here while we're at it. (ye, I know; this is not a forum jada, jada...)

Because is does not make sense that you only can see it underwater?

Why would you need them over the water?

Ok, I try to explain this. This ticket is about crash. Crash is fixed. This ticket is therefore resolved. There is no point bringing up a dozen of other unrelated to this particular crash issues. If you have other issues, make another ticket, yet I advise against it as if it is about what you posted here, then this will be a waste of time. There are way to many more important issues to deal with than adding support for magazines to addItemCargoGlobal while there is a dedicated command for magazines. I hope you see some sense in what I just wrote.

oookay.
:)

Yet, at this point I do wonder:

• If addItemToXXX works with anything ("The item can also be a a weapon or a magazine." - got it), why can't this be done for the addItemCargoGlobal too?

• Why is there even a need for magazine/item/weapon variants in the first place, if one simple command could simply handle this on its own?! Or is there a catch?

• And finally: before this color smoke update, adding smokes with addItemCargoGlobal worked *just fine*. Now it does not. Was that really necessary?

The (new) A3 inventory is already complex enough, why make it messy/cumbersome to use on top of it? I just don't get it. :/

--

On a similar note: why is there a need for all these global variants? Can't the commands just be global to begin with? Are there indeed use-cases where you'd want to addItem (or what not) only locally? What's the point? (...just curious here; I don't know too much about mp-scripting)

Confirming above. Issue resolved but the smoke grenade error.
Thanks

smokes are magazines and not items. use addmagazinecargoglobal or additemtoxxxx for inventory as those have been tweaked to accept magazines.