I noticed this as well. DXDiag logs attached

Yeah someone else shared that with me earlier today. Thanks for the info though. :)

I also can confirm that this only happens when another player comes within ~ 400 meters of your position. It will force your weapon to be "put away" onto your back from your hands, and if you already have a primary weapon on your back, the weapon in your hands will be dropped to the ground.

This has been tested by my group about a dozen times in the last two days. Sometimes it was members of our own group meeting up and other times it resulted in encounters with other players in high traffic areas, such as the Myshkino and Kamensk military areas.

This is a HUGE bug, not only because of the inconvenience of having your weapon slung or dropped at inopportune times, but also because it effectively gives players ESP since it allows them to know when other players are in the vicinity.

I'm having a similar error as well. Screenshot added.

Had a similar problem, but I'm not sure mine was related to memory issues. DXDiag and crash dump files can be had here: https://www.dropbox.com/s/qt82xagc0yiustp/DayZ.zip?dl=0

File was too big to attach locally.

Many times you can drag the items into your hands and THEN place them into your inventory. Sometimes that works and sometimes not. It's easy to confuse this bug with the bug where you pick up an item but it remains visible on the ground or table afterwards, even to other players.

Had this happen to me the other day. I was stalking a couple guys and had planned on taking them out, but soon as I stood up and raised and lowered my weapon once, my character tossed it. Needless to say I grabbed my rifle and ran out of there since my confidence level went from 10 to -5 in a heartbeat. :/

With the Navmesh being implemented now I'd say that around 2GB ram usage is normal.

Thought there was a ticket on this already but I guess not. Played for an hour tonight and experienced 5 freezing incidents, each lasting around 5 seconds. Log files are attached. CPU usage remains constant during freezing episodes while GPU usage drops to 0 until the game responds again. Freezing incidents occurred at 8:07, 8:23, 8:29, 8:33, and 8:58PM local time. Hopefully you can compare those times with the log files and find something of use.

Had the same problem. Froze for about 5 seconds while running through a field. CPU usage stayed constant. GPU usage dropped to nothing. But the game recovered and I was able to play as normal until the server restarted a few minutes later.

This is a consistent problem and is present on the current experimental AND stable builds. Pick up a weapon from anyone else, whether they gave it to you willingly or they died and you take it from their corpse. If anyone has handled the weapon before you get it, it will not fire until you log out and back in.

Still crashing for me. It's better than it was though. Here's a link to the dump files of the crash that just happened.

https://drive.google.com/file/d/0B1NA-tLSw7MhREl1WThPMFA1WjA/edit?usp=sharing

Same here. It happens several times over the course of a few hours of play.

Log files: https://drive.google.com/file/d/0B1NA-tLSw7MhRUs1ODI4U0VvTTQ/edit?usp=sharing

This bug is also present in the current experimental build 0.45

Yes this is still a problem and has not been fixed. Had it happen to myself and a friend yesterday.

Confirmed for me as well. Lost a yellow protector case just after the patch.

It definitely has something to do with corrupted textures on old gear. I had a yellow protector case that was full of food and drink items that were obtained pre-patch. The textures for the items were glimmering and appeared brown-ish in color. I dropped the items, ran about 200 meters away from them and my FPS shot back up to the 60s where they usually are for me.

This was further reinforced when a clan mate joined the game shortly thereafter close to my position. He also experienced the same bug. I had him check his inventory for glimmering items. He found several cans of food and a mag pull attachment for his M4. He dropped the items, we ran away from them and both of our FPS rates went back to normal again.

We noticed when in a few towns that the FPS was poor again. So it's hard to say if that was a texture problem with one of the buildings in town, or if someone else had also found and dropped inventory items that were giving them texture issues.

Same issue here as well. Doesn't matter if it's in cities or woods. Seems to get worse after being in game for about 10 minutes. Only began after update to 116 stable branch patch.

I usually run between 50-75FPS depending on where I am. Now it's staying mid 30s and drops into the teens regularly. Totally unplayable right now.
On my second monitor I have been watching CPU and GPU usage. GPU usage is dropping below 20% on both cards. CPU usage is dropping to less than 30% on all 4 cores. There's definitely a problem somewhere.

System Specs:

i5 3570K OC'd to 4.2GHz
8GB DDR3-1600
2x GTX 670 in SLI
256GB SSD
Win 7 x64

I can confirm the excessive memory usage. When loading into game memory usage was about 800MB. Over the course of 30 mins it ballooned to nearly 1.8GB, at which time GPU usage went down to around 10% on both GPUs. Follow link for screenshot.

http://imgur.com/Xon4BVu

Rocket stated on Reddit a little while ago that they will be investigating a memory leak for this issue on Monday.

http://www.reddit.com/r/dayz/comments/1xa8zr/anyone_else_notice_a_huge_drop_in_frame_rate/

I had one and dropped it and tried running for a while without it. Made no difference for me. Others have reported having this issue but not even having a weapon at all other than a hatchet.

Not sure if it's related but I also noticed several cases of texture flickering on various items in game, including soda cans, food tins, weapon attachments and even zombies and buildings.

You can also open the can of food and keep it in your inventory. This will change the texture used which will eliminate the problem as well.

This is still happening in .47 experimental

Had the same issue. Took a full 10 seconds to do a reload. Moved to kneeling and tried again and it worked fine. It's definitely something linked to being prone and reloading. Still happening in the 114.8 build too.

Happened to me as well on lookout tower at NWAF. Had weapon shouldered and went to climb down ladder. Soon as I pressed down to climb down my character did a "climb over" animation and fell to my death. I know I didn't press that key since my vault and down keys aren't even on the same side of my keyboard.

This is still occurring in the new .46 experimental build. Had to press '1' 8 times to get it to change weapons. The server was somewhat full at the time but other actions such as eating and drinking were much more responsive. Please look into this!

Still occurring in new .47 experimental. :/

This is still a problem in the current .48 build of experimental. Takes multiple key presses to pull out anything on the shortcut bar. This occurs even with only 8 to 10 people on the server.

My latest incident with the hotbar not working correctly was in experimental, .47 build, of which all servers should be 64 bit according to Rocket. As far as I know there's no way for us to know which stable servers are on 64 bit. I haven't seen any details stating if it's limited to only certain providers or what the story is. My best guess is that some GSP hosts are having to move servers around, since the requirements for 32 bit servers versus 64 bit will be slightly different, at least from a memory standpoint. The initial server requirements were up to 7 x 50 slot servers per quad core cpu (plus hyperthreading I'm guessing) and 8 GB of memory. But now seeing as how each server can use WAY past 3.25GB of memory EACH, that has likely changed. That being the case, they will either need to be reducing the amount of servers they run on each physical box or increasing the amount of physical memory in each physical box. Either way, it takes money and time to get up to speed. Now that's not to say that each instance of DayZ will always use more than 3.25GB of memory, at least not yet. But they need to allow for room to expand as needed, so they won't want to be shoving too many DayZ servers on each physical server box.

No. He said experimental is on 64 bit and has been for some time. And half of ALL servers were as well. Better read that Tweet again, friend.

64 bit servers have been active on experimental for a while now and the problem still persists. It's present even in .47.

Ok but again, in a low FPS situation you would think that it would be randomly dropping various functions, where sometimes you can't use the hotbar, sometimes you can't eat or drink, sometimes you can't reload your weapon. But this is very consistent, regardless of server load. And even if that were the case, the hotbar should be one of the LAST things that the server drops functionality for. The whole purpose of the hotbar is so that you can get access to important items quickly and reliably without having to fumble for them in your inventory. So if the server is dropping hotbar functions *first* then they've got things very backwards.

@MrDouille I don't think that's how the system works. It doesn't prioritize certain traffic or functions over others. It receives commands and processes them on a first come first served basis. But in this case, the hotbar commands seem to be completely ignored.

This is not a lag problem. If you experience the hotbar being unresponsive you can immediately go into your inventory and place your weapon in your hands, you can move things around, you can eat and drink. It's just the hotbar that's affected. If it were lag there would be severe delays in eating and drinking during the same time as the hotbar isn't responding, but that isn't the case with this. It's also not dependent upon a high server player count. I have it happen with 6 people on the server.

This is still occurring and is really bad in the current exp build .46.

@komin - I approached it from multiple directions trying to get any reaction. At that time I got none at all. It happened again today but the zombie eventually responded to me. I also noticed that swinging my ax at it was not doing anything until after it noticed me. Then I could do damage to it. It's possible it could have just been server lag, although there were only 5 other people on the server at the time, so I doubt that was the case.

Click on "Internet" in upper left hand corner to make online servers appear.

Should have been this way all along, IMO

Uploaded zip file containing all crash logs from the time frame in question. There may be something that's consistent in all of them.

RPT file from the same time added.

This is now happening on version 1.48 as well. Crashes to desktop as soon as I join a server and load into the world. Running Windows 10 Build 10240 and NVidia driver version 353.30.

Complete info and logs can be found here:

https://www.dropbox.com/s/91iktz9zoab9esg/a3_148_error.zip?dl=0

I've experienced this as well.

Here's 2 crash dumps from today. The game plays with very low FPS (10-30) and as soon as I go into the menu (ESC) it crashes every time.

https://www.dropbox.com/s/f57pyv4ymg9bv4f/A3%20Crash%20Logs.zip?dl=0

This has been happening since 1.44. I've seen it in stock Arma as well as in Epoch mod. Updated and rolled back video drivers and problem persists. Also occurs on both Windows 7 and Windows 10. Happens every time you load into the game. As the OP says, changing the cloud detail level to anything other than what it's currently set to will fix it. Also noticed that I tend to see this in my client RPT when it happens: "13:46:10 SimulWeather - Cloud Renderer - noise texture file is not specified!"

I'm getting this as well.

14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]
14:05:38 control[CA_ServerDetailExpansion]: Unexpected control type [0]

Happening in version 1.4. I downloaded a fix as notated on the forums here:http://forums.bistudio.com/showthread.php?189485-control-CA_ServerDetailExpansion-Unexpected-control-type-0

And it seems to work fine now.

Getting this same problem as of today with Windows 10 x64 and NVidia driver 349.90 and 349.60.