I can confirm this. I saw this, but only once. As if the game was an earthquake. It was impossible to stop. When I restarted the editor, everything ended

yes, I experience this too since 1.38 patch.

after you leave a chopper, it starts, it won`t stop until you close to grenade explosion or jet/chopper flying close to you overhead. (so essentially it wont stop until a "new" shake-effect is triggered)

pls fix =)

I'm seeing this too since 1.38.

As csathdfw says, I think it's a 'shake' effect that is stuck on.

I also noticed that quiting the game and rejoining MP did not fix this. Even shutting the game didn't fix it.

Is the shake similar to this? http://feedback.arma3.com/view.php?id=22394 (Video link in ticket description)

Yes, except that the shame lasts for half a second, then stops for a couple of seconds, then starts again. rinse/repeat.

Same issue here. Sadly this is unplayable :(

The issue occurs after flying with an Orca. The camera keeps shaking while on foot. The issue persists through restart of the game. So, when I log back into the MP session I still have the issue as infantry.

to bad that a an admin/moderator i need to explain to players that it's NOT the server but the game and in SP they have no problems. what an explaination come on Bohemia fix it ASAP

So far I've only encountered this issue on the Ahoy World Invade & Annex. A custom Insurgency mission from my buddy doesn't have this issue. Then again, it's rare and I might not have spent enough time in that latter mission.

Try disabling camera shake in the Difficulty meny, see if it helps.

As I can tell, this is not limited to I&A only. It's happened on different map types as well. Definitely a real pain and makes conducting overwatch almost impossible. Sniping and lasing of targets is non-functional as a result. There doesn't seem to be any time correlations nor game mechanic correlations. The shake is similar to what a player experiences when on a DayZ style server and the character is in pain. Or as if there's constant feedback from a distant arty impact.

BI please investigate this issue and respond. Gotta love game updates...

Happens in Domination too.

+1 this is unplayable :(
+1 As if the game was an earthquake.
+1 since 1.38 patch.

Same here.

You can download a video here: https://drive.google.com/file/d/0B21N48lT4v2TTHVjdWtiN0pVVGc/view?usp=sharing

Soldier just spawned, no injuries.
Tried several server, all the same.

I get it in the editor.

enableCamShake false;

Run this command in debug console (global exec), or place in init.sqf to prevent issues. Will do for now as a temporary fix.

pls fix (*bump*)

sometime it wont happen for 60-90minutes after server has restarted, but then it start, everybody gets the shake, nothing help anymore... until next server restart everyone has the shakes. (additional to the shakes there are lagspikes/freeze-frames like every second, fps and ping are stable tho)

in real-life, after 1hour sitting at ammobox in base or in battle... soldiers get parkinson, I really like how arma3 is that good sim :D

@MisterGoodson:
enableCamShake false;
seams NOT to work have effect again right now.

Options > dificulty > from list turn off camera shake > problem solved.

No, not 'problem solved'. You are disabling a feature in doing that.

Hello,
we are aware of the problem, however are not able to reproduce it in our condition. Is it possible to provide some steps for reproduction of the issue?

Iceman, i think it's gone in the current DEV branch. At least i never had it since. And i think it always happened simultaneously to the "Overflow / Matrix Spam". Maybe it's related?

Same here, happened to us when RPT was spammed with Overflow / Matrix Spam.

Yep.

This bug is extremely active within Phoenix Realism server. It's using the Domination maps customized by Xeno. This bug makes the game almost unplayable, unless the weapons are locked guided to their target. Even guided rockets are missing because of this bug.

From my perspective, this could be network lag causing camera shake? Like I"ve stated, the bug is reproducible on Phoenix Realism server using the Domination map customized by Xeno.

This bug also seems to be being caused by the server. I've restarted the client, and the bug still exists. Upon first joining the server, and apparently after a fresh restart, the bug was not present until once I died. And then after death the bug became persistent. I think I smell a hot fix!

I also tried disabling camera shake within the Difficulty settings which had no effect. Possible the camera shake is mandated by a server side setting?

After reading all the comments, the overload on logs can cause this with overloading the network, but I'm speculating.

I have also had this happen a few times when playing(KotH), at first I thought it was just me it was happening to, like some random thing that happend to people with the patch but as rogerx said, it seems to be tied to the server.

Last time it happend to me I joked about it in chat as I usually do, that my guy needed his coffe fix. Thing is others said that they also just started shaking, im not sure if its the entire server that gets it but it does seem to come from the server and affects multiple people at the same time.

I also think this has only occured when I have been using a sniper rifle, tho it does stick to you and switching weapons doesnt help after you get the shakes.

This bug is directly related to the 'CAMERA SHAKE' effect when heavy vehicles pass by at close range.

Disabling the 'camera shake' in the options (server side) resolves this as a temporary fix :-)

2-17-15
Having this issue online as well.

Playing in MP, this bug often occurs, after Halo jump, grenade explosion, vehicle passing nearby. It seems linked with cameraShake effects affecting the player. No need to be wounded (still occur with damage 0 & hitpoints damages 0).

Per FeralCircus's post above, Comment #0087903, I heard someone state they may have disabled camera shake on the Phoenix Realism server within the past day or so.

I cannot confirm the work around for this bug, aside from the fact I haven't seen this bug within the past day or so. (Not enough time to set up a server within Windows', dealing with DRM, etc..., easier & quicker debugging on Linux... etc.)

Another possible past related issue, I remember the camera shake in ARMA 3 Alpha/Beta or early release versions of ARMA 3 while within the AH-64 gunner seat. If auto-hover was enabled, camera shake would occur while looking through the gun camera. Disabling auto-hover would cease the camera shake. I somewhat assumed this was an issue with the joystick axis, and think I created a dead zone to either relieve this or a fix was published.

As already noted above, very likely related to Bug #0022394, "UAV camera shake at specified altitude"

have not experienced this glitch anymore since a few days now

I had this on invade&annex coop servers, but now its gone.. I assume most of the serveradmins disabled the camerashake in the options as temporarly fix?

The problem should be fixed in the next update.

Somebody has stated that there is no server side option for enabling or disabling camera shake.

I've found "enableCamShake false;", but somebody else has also stated this is a global variable on the server side, that can be modified by user modifications. I would imagine the fix to this is defining the variable as static or local to the server?

Looks like this issue is still occurring on Phoenix Realism servers regardless of this setting.

2015.02.26: I just did some grepping of the Phoenix server mission files (ie. Phoenix_Domination_V4* -r -e CamShake) and found several files resetting Camshake values, likely re-enabling CamShake server side and regardless of whether the server explicitly disabled CamShake. These mission files should not have access to the CamShak server side variable, hence should be a local/static value and not globally accessible. Hence, the likely fix.

I would love to say that fixed it rogerx, but the map is still having issues even after I wipe out that CamShake command from the pbo. Confirmed issue on all three servers

Playing on some of the demo servers using the RC (developer) build, I think there is still the reminiscent camera shake bug still present. (Come to think of it, I still think I have camera shake turned-off on my client here.) It's almost like the server is spamming the client, creating a sporadic screen jitter.

What's making it really difficult to further test, there are very few demo multi-player servers for testing in or very few other players. As well as some set to night without night vision and with non-working flares. The AI difficulty are also set to experts. So basically bump the expertise of the AI to dumb & dumber so they don't take over the compounds within two shakes (or two seconds), and provide night vision or please fix the flare lighting bug.

(Within the next day or so, I'll bump back down to stable version, log into Phoenix and download the map and grep the script to verify you commented the two script lines re-enabling the camshake upon death. But since it's only two lines, I don't see how anyone could have missed them. So I'm swayed to believe you likely did disable camshake.)

W. Carruthers: Make sure there are no routines calling fn_injuredBloodloss.fsm or bloodloss.fsm, as I can obviously see something calling reset resetCamShak and addCamShak. Matter of fact, I do not remember seeing these calls previously, unless I was just searching for "CamShake" without prefixed spacing. But with Bash history here, I'm using a previously used fgrep incantation! Did you just add these in?

roger@localhost4 /cygdrive/c/Documents and Settings/roger/My Documents/Arma 3/missions/Phoenix_Domination_V4G.Altis

$ fgrep ./ -r -e CamShake

I just updated to 1.40129533 and it does seem like the CamShake bug is solved using the Phoenix_Domination_V4G.Altis map. I just ran the chopper into the antenna tower, respawned and all is well still.

./fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
./fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
./scripts/ais_injury/fsm/bloodloss.fsm: " addCamShake [15, 999, 0.7];" \n
./scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;"/*%FSM</STATEINIT" "">*/;
./scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;" \n

I think I've successfully proven this bug still exists within 1.40129533 version.

If you have TrackIR, you can reproduce by flying and sometimes either zooming in (with your head) or moving your head to the border region of the extent of head movement. You'll immediately notice the shaking is extremely reminiscent of the CamShake bug. Briefly looking elsewhere or doing something, the problem quickly dissipates, however very annoying while aiming at something.

If you don't have TrackIR, you can likely reproduce by using Free Look.

I'm using the Phoenix Realism server.

@rogerx:
I also experienced the effect you described in 1.40129533.
However: I have the feeling it's different to my original posting. The shaking is very strong and - furthermore - it's permanent in comparison to the one I originally posted where it was more or less rhythmic - like the heartbeat.
As I have no idea about the internals of ARMA3, I cannot say if the problem derives from the same origin.

@BI:
Keep up the good work guys!

If you notice, the shaking we experience now is the same rhythm as the prior persistent shaking. Just much less, and almost apparently completely omitted while using scopes and binoculars.

Also mentionable is the fact this same shake bug (in it's current state as documented within Comment #0088612)) I'm now experiencing, has been in ARMA 3 since likely alpha or beta, but isn't usually seen unless users make constant use of free look, or use TrackIR which makes explicit use of free look.

Hence, the root of the bug is still likely there, it's just back to being not noticeable or not detectable by the normal everyday user, or users not knowledgeable.

I'm pretty sure they only fixed half of this bug. If you also notice, there's almost absolutely no shaking when looking through scopes & binoculars, while the shake I experience now documented above within Comment #0088612, is only seen or provoked usually within third person usage. That's the other thing, camera shake is more noticeable within third person usage.

If they did hack around and now are negating camera shake while using scopes and binoculars, might be a good idea to omit or apply the same fix for this massive camera shake bug within the third person as well. But from a player's face value point of view, or from an unknowing point of view, this bug might only "look" fixed.

I have also just fgrep'ed the Phoenix Realism mission game files, and definitely see the only reimplementation or reactivation of CamShak is also apparently commented-out via double quotes.

$ fgrep Phoenix_Domination_V4G.Altis/ -r -e "CamShak"
Phoenix_Domination_V4G.Altis/fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
Phoenix_Domination_V4G.Altis/fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
Phoenix_Domination_V4G.Altis/scripts/ais_injury/fsm/bloodloss.fsm: " addCamShake [15, 999, 0.7];" \n
Phoenix_Domination_V4G.Altis/scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;"/*%FSM</STATEINIT""">*/;
Phoenix_Domination_V4G.Altis/scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;" \n

However, CamShake is definitely somehow being reactivated by some other means than just the Mission Files on the Phoenix Realism servers. As I try to read this scripting, it looks as if the double quotes, are just quoting a further embedded listing of commands? Hence, "resetCamShake" should also be further deleted/removed? (Actually, the recommended method is likely just commenting the sections out within C style /* */ comments.)

After some testing using the Editor and entering similar scripting commands posted above, it would appear this bug is localized to the Phoenix server and it's usage of resetCamShake, more specifically and like the addCamShake. Likely this specific scripting is proving dysfunctional and acting erratically when using TrackIR hardware and/or using free-look extensively. Although CamShake appears to work well within my Editor, on Phoenix servers, the camshake feature is acting extremely odd, or not fluid with movements or experiencing significant Internet lag or a bottleneck whenever a CamShake movement is experienced.

This bug is still not fixed on Phoenix servers. There are still a few statements constantly resetting camera shake! (ie. The statements start with double quotes within the scripts, and contain camshake commands.)

This still has not been fixed. How come its marked Resolved?