It seems to be fixed for me

same issue: 0015842

I've got the exact same issue, DxDiag inside DayZ folder here: https://www.dropbox.com/s/5ohoqbr6brcw562/DayZ15minutecrash.rar

A fix would really be appreciated since I can't play the game until this is resolved.

The game keeps on running untill I try to click "yes" when it askes me if I'm sure I want to quit (after hitting escape when I get "no message received). Then the game just freezes and I have to use task manager to kill the process.

same issue: 0015889

I also did a clean re-install, didn't help.

I have exactly the same issue. First the screen goes black, then windows appears and the game even seems to react normally judging from the sounds I hear and what my friends tell me over teamspeak.

I've uploaded my folder and dxdiag to the issue.

Got the message several times, all after recent update.

If you have a loaded gun or a knife, I'd say yes.

Sometimes it is rearranged in such a way that some items don't fit any more and therefore get deleted. (sawn off shotgun mostly in my experience)

I'm kind of baffled by the lack of logic in reasoning in a lot of these replies.

Let me break it down for you guys
Games have settings. Settings are meant for users to optimise gaming experience. Changing these settings is fair by default because everyone can do it. If changing the settings results in lack of functionality we can call this a bug.

There is functionality loss with any FOV other than default. This way you also have a disadvantage when you lower your FOV. Or would you rather state that is to compensate for the benefit you get from lowering your FOV?

Basically: If we can manipulate it in settings, it should be working properly.

@deewd22: Because the difference in angle from your eyes to the edges of the computer monitor can vary more with computer monitors. Having your screen closer and or bigger than normal will result in a far greater change in FOV compared to difference in TV screens since those are much further away.

I think this is fixed

Might be a newb question but isn't this something that can be handled client side? Wouldn't that decrease server load and make the game more responsive?

If it's related to server performance then the jumping being just as unresponsive is probably the same problem isn't it? In that case it's related to issue 0000225

Slightly off topic:
Would it be an idea to make the hot-bar not directly connect to an item but to an item category? I'd imagine it would work as followed: You drag a pistol to your hot-bar, and the button keeps working for any pistol (choosing the one you dragged onto your hot-bar as a first option if it's still in your inventory)

And if you use a certain arrangement it could perhaps be saved to your profile. So when you die and lose everything, but pick an item up in a certain category it will automatically be assigned to the hot-key you've reserved for that category.

I think that would really help in not having to fiddle with the hot-bar every time you drop something or get killed.

Perhaps it's time this got acknowledged?

The sun does cast shadows doesn't it?

The (dynamic) street lights go through walls btw.

Well if something (in this case the engine) is broken there are three options to resolve the problems it's giving: fix it, improvise or get a new one. In this stage I'm guessing it would be best to improvise.

Can't this issue be fixed with some kind of status check? The main problem is when you are inside, you don't want people to know you're there, so you don't want textures outside the building to be lit when you are inside. Textures could be divided into 2 categories: textures on (1)the inside of a building and (0)other textures. Then with a regular status check perhaps there can be checked if a player is (1)inside a building or (0)not inside a building. So I'm thinking something along the lines of: If PlayerInside=1 then the only textures affected by flash light textures with the status attribute TextureInside=1

I'm not an expert, but that would be a way I'd try to solve the problem. It would probably result in not being able to shine outside through a door or a window, and have textures in the buildings next to you be lit as well. But I think it we'd all prefer that to how it functions now.

Keep up the good work ;)

I don't understand why you guys keep sending your specs etc. It's most likely a waste of time because the information you're providing is about the old renderer, and since they're implementing a new one they're obviously not going to fix this one. Target implementation is in the first quarter of 2015: http://dayz.com/blog/dayz-moving-into-2015

Thank you for the response and the acknowledgement Accolyte. We know you guys are busy.

Am I correct in concluding that you guys don not think it has to do with occlusion culling being absent or broken? Or perhaps do some buildings have a geometry that interferes with the occlusion culling?

@Anon13: Don't exaggerate, I don't think flaming is going to help us here.

@exa: I would expect feedback.dayzgame.com to be the proper medium to communicate directly with the people that actually took the time to report or vote on a specific issue. I don't see the point in scrolling through the dev's twitter feeds when I know that if they comment here it will be to specifically address this issue.

Anyway, I'm glad to see that at least Dean acknowledged the issue on twitter. Still I'd like to know what the dev's think is the issue, and if they will be able to fix it.

It might be worthwhile for the devs to check out the hardware occlusion culling on nvidia cards. (http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter06.html) As I understand it, it's just a question of 'asking the videocard' if the object should be rendered or not.

Just like I said, occlusion culling. I don't understand how Bohemia could have developed the engine even until Arma III and not incorporate this into the it. Not having proper occlusion culling basically guarantees a low FPS in an object rich area.

With nearly 1k of votes and over 200 reporter comments since the "need more info" status that has been attached over 2 months ago I'm getting the impression that this issue is being ignored.

Now can some developer please comment on this issue?

Might it perhaps be time to acknowledge report number 247? In my opinion this is one of the core performance issues of the game...

Occlusion culling

It appears that a lot of objects that are not visible are still drawn. In the cities my fps is still low when looking at nothing but a wall inside a building. This tells me that the occlusion culling might not be working properly. Objects that are not visible but inside the frustum are probably still being rendered. Since my fps is a lot higher when looking away from a city compared to looking at a city I assume the frustum culling is working properly.

DEFFINATELY OCCLUSION CULLING

I've been testing it some more. Zooming in and out and looking away from and towards cities does seem to make quite a lot of difference. So does looking down and up. So the frustum culling seems fine even with a variable FOV. The FPS drop seems to be related to the amount of objects within the frustum. The amount of occluded objects doesn't seem to affect the FPS.

Simply: Objects are being rendered even when they are being blocked from sight by another object when they are within the field of view.

This is still a thing, and I think jumping has ceased to work entirely when you're standing against the object you're trying to jump over.

Perhaps it's time to acknowledge this?

For me the amount of random Z sounds has increased since .42