The issue here is usage of the cyrilic in the path. We will prepare a fix but in the meantime a workaround would be not using any cyrilic characters.

Arma 3 Launcher is not mandatory for running Arma 3 with BattlEye. It just makes it much simpler. See here for details http://forums.bistudio.com/showthread.php?190426-BattlEye-service-implementation&p=2910511#post2910511.

Hi, pls try running the game with '-nosound' command line parameter. Also, try searching the windows directory for 'xapo*' and post the results here, you should probably see something like:

c:\Windows\System32\XAPOFX1_0.dll
c:\Windows\System32\XAPOFX1_1.dll
c:\Windows\System32\XAPOFX1_2.dll
c:\Windows\System32\XAPOFX1_3.dll
c:\Windows\System32\XAPOFX1_4.dll
c:\Windows\System32\XAPOFX1_5.dll

serverCommandAvailable now behaves as it did before and a new command serverCommandExecutable has been created that can be used to check if a command can be executed via serverCommand (https://community.bistudio.com/wiki/serverCommandExecutable).

Quick update - we have the fix ready and are testing it internally. As already mentioned it will be part of the upcoming 1.32 stable patch which should be released this or the next week. It does not change the release date of the Helicopters DLC.

Hey guys,

as Dwarden said exploits like this one are of the highest priority to us and we are currently hard at work on the fix. We are targeting the upcoming stable patch version 1.32.

Thanks for your patience.

The issue should be fixed in latest dev version. Check pls.

Caused by the extended memory limit (up to 3072MB) added recently, reverted back to 2GB. Should be fixed in the next dev build.

Duplicate of http://feedback.arma3.com/view.php?id=19121.

Priority acknowledged, fix is in progress.

zx64: correct on both accounts.

If this behavior breaks some specific mission or mechanic please report it as a separate issue.

Fixed in 116348. Pls check when a new dev build is released.

Fixed in 115833. Pls check with next dev update.

Hi, one of the crashes seems to be related to PhysX and we have done some PhysX fixes in the dev version recently. So I would recommend trying the dev build to check if it's more stable.

What exactly is the relationship between the crashes and kicking? You mean that one client crashes other clients get kicked in response? And server is still running without problems?

Try running the server with these parameters '-enableSteamLogs -debug_steamapi
', it will output more information into the RPT.

Should be fixed in 115784. Pls test when it hits the dev branch (should be tomorrow).

42 to 30 is a pretty big difference for 14 tanks. Can you attach the test mission so we can investigate?

Should be fixed in current dev version.

Should be fixed in current dev version.

Should be fixed in current dev version.

Can you try renaming the 'keys' directory to 'Keys'?

DaOarge: you can use for example http://ge.tt to upload the core dump.

Should be fixed in current dev version.

Should be fixed in current dev version.

Should be fixed in current dev version.

Should be fixed in current dev version.

Should be fixed in current dev version.

Yep, already fixed in dev branch. It will come to the main branch with next patch.

Fixed, will be included in the next steam dev update.

Hotfix for the stable branch is up (1.02.110654). Test pls.

SaOk:

According to your crash dump it seems to be a different issue (which we will look into as well). We tried to repro in your mission using fast traveling but no luck so far - it was stable.

Good news, good news :).

A fix has been uploaded to the steam dev branch (version 1.03.110653) and if everything will be smooth it will get to the stable branch tomorrow.

Test, test, test.

Hey guys, we got your crash reports and we were able to reproduce the issue in our environment. It's obviously the biggest priority for us at the moment and we will deliver a fix ASAP.

Thanks for your patience :).

This should be fixed in rev 109859 which should be released in one of the dev branch updates next week.

First thing - you should add an empty Arguments class inside the FollowMe class to prevent script errors.

The crash itself is fixed in revision 110023 which should be released next week in a dev branch update.

Seems to be caused by the latest nvidia beta drivers - 326.19, 326.41 and 326.80. We are investigating.

The stuttering issues in general are hard to investigate so pls try to give us as best repro as you can (along with the files MadDogX hase requested). We need to reproduce the problem to be able to solve it.

Apart from that, it might be possible that the stuttering is caused by something else in the update than the 32bit hotfix. So try running the game with -nologs and check if it happens in editor, official showcases or community missions. Is it happening right after starting the game or is it necessary to play for a longer time? Single player or MP?

I have checked the code and it's true that setDamage is only a wrapper for setDammage but the wrapping overhead is optimized away by compiler. So MulleDK19's measurements make sense - there shouldn't be any difference.

Sorry for a lack of response. I got your report so we'll check if we can do something about it. But it will take time since it's a random crash with no repro.

Fixed in latest dev (rev 114204).

Should be fixed in latest dev version. Please check.

Other occurrences for reference:

Night showcase (14:07-16:00)

http://www.youtube.com/watch?v=7aVlPnpD8R4

Combined Arms showcase (3:33, 11:54)

http://www.youtube.com/watch?v=E79XXZXZSnQ

I have a hard time reproducing this. If anyone would have exact repro steps or a save game that would be sweet.

Fixed, pls check dev build tomorrow.

Should be fixed in dev, test pls.

Hey there, the heli crash should be fixed already, can you check? Thanks

Should be fixed by now, can you confirm?

This problem is connected to a doppler effect bug, I believe. Fix is incoming soon.

Unfortunately we haven't been able to reproduce the crash, even with the repro mission. If you happen to get any new information pls let us know.

Should be already fixed.

The game is freezing because the mission executes a script (LV_functions/LV_fnc_ACpatrol.sqf ) which calls findEmptyPos function:

line 48: _newPos = _newPos findEmptyPosition[1, _disPAI];

with parameters that take too long to process (max distance seems to be too big) - actual values:

_newPos = [6775.55371, 0.264826298, 4654.58057] findEmptyPosition [1, 1835.78528]

Moreover, the call is inside a loop so the freeze might be even longer.

I suggest revising the script.

Should be fixed in dev version, check pls.

False alarm it seems.

Glad to hear that :).

Can you give us those configs to help reproduce the problem? Do you have any crash dumps (.bidmp or .mdmp files)? Whole rpt and log would be useful as well.

Hotfix in progress, we don't want to force you to switch to dev servers as well :).

So far it seems that the problem is fixed already in the latest dev version, please confirm.

Just adding a note for clarification - this is related to dedicated server (correct me if i'm wrong).

Was the MP mission started by loading a previously saved game? If so, was the mission saved in previous game version? If so, what version?

Should be fixed in latest stable (and dev), check pls.

I was unable to reproduce the crash with FaceTrackNoIR 1.7 beta but I might try later with different hardware.

Anyway, could you provide exact steps to reproduce the problem (what tracking app you have used, what version, when did Arma 3 crash, what was on screen, ...)? Could you also provide crash dumps?

Thanks

I have tried to reproduce the issue and encountered a crash when Arma 3 tried to initialize TrackIR. The thing is that FreeTrack emulates TrackIR's behavior by providing it's own NPClient.dll which provides a bunch of functions we call in Arma 3. The crash actually occurs in one of these functions (NP_GetSignature) in the library itself.

FreeTrack is not updated since 2008 so I simply suspect that its functionality no longer matches the functionality of TrackIR and thus the functionality we support in Arma 3.

There's not much we can do here, sorry, so closing.

Nice repro video, happy to work with bugs like this one :).

Thanks for the video, we'll try to reproduce.

Any repro pls?

We've seen this problem a few times now but it's difficult to pinpoint it's source without a repro. If you guys could come up with one that would be much appreciated :).

Should be fixed in latest stable and dev.

Should be fixed in dev version, check pls. Character sounds should be working properly as well.

And it gets better, fix is on the go, will be ready next week :).

Processed, thanks :)

Nou: please create a separate bug for the attenuation problem and again, try to describe for what weapons or equipment it doesn't work. These problems might be connected but it's easier to track when one report describes one specific problem.

Perhaps just post a link here so I can easily find it.

Hey guys, so far it seems that explosions (mines, grenades, ...) work correctly while shooting (soldiers, cars) does not.

Could you also test other situations, weapons, equipment, vehicles? Single player and multi player separately, please.

Thanks a lot.

Hey guys, sorry for the lack of info on progress here. We are well aware of the performance issues and it's a great help having feedback from so many people with different HW specs.

We have identified several areas with not exactly ideal performance and we are working on optimizing them. Smooth gameplay is a high priority for us (as well as for you) and we are focusing on it more and more the closer we get to beta and release.

Sorry for a little vague reply but it's too soon to give specific results. Please have some patience :).

CottoN:
Did you lower the settings using the Overall Quality combo box? If so, I suppose that your fix procedure would mean that in the end you have simply lowered view, object and shadow distances. Which would explain the perf gain.

Can you confirm this? What settings have actually changed for you?