damagefilter

Not the whole engine, I wasn't talking about that :) The network code was done from scratch. They scrapped the old logic and implemented a new one. And possibly a whole lot of other things were made from scratch. And now they are refucktoring the renderer which will take its sweet time again I'm sure. In C++ one doesn't simply refactor legacy code ...

That is true. We used Unity as engine of choice. That didn't change anything though. In the case of DayZ, the implemented a new server architecture called authoritative server-client networking (as far as I can tell anyway). Previously the RV engine used peer-to-peer (I think) to get networking done. Rewriting this is a huuuuuge amount of efford. Still is as it would seem as they only partially got it done so far.

See, there's that misconception. The game is really allowed to be broken. No one (apart from those that gonna hate ofc) said those things will stay broken. This is, as many disclaimers and texts stated, an unfinished product. Do you have any idea how long it takes to develop a game? At work, we're working on a multiplayer racing game (It's a trivial game concept compared to DayZ). Writing the network code alone and getting it straight took us about 4 to 5 months. And that's only a small portion of things that need coding. There's more like track logic, GUI logic, racer customisations, data backends, deployment pipelines that need maintaining ... and all that fancy crap. It's not just flipping a few switches you know. 2 years is really not that much when you're developing things from scratch.

I can vaguely remember @ctorchia talking about it not fitting to the player model and so they removed it. Would sorta make sense looking at the screenshots in the OP, the top ends are above the characters shoulders and the vest body clips through the jacket really bad.

Ah, one can never please all the people. It's a rule of nature it would seem. But the good thing is, you can just not play the game for a little while, right?So when all the things that make your personal gaming experience hell will be fixed or at least mitigated, you can come back in and have some good times.It has been said more than 10 times (far more that 10 times) that those issues will get fixed. Making it happen just takes some time and in the meantime,we can enjoy the first drafts of the hunting system and stuff. I find that to be very fair.

Ohrly. See, didn't know that one. I only went to save a friends stash every now and then when he got shot at the airfield again. So I was doing that on a dead character all the time.

Yes you can do that. But why didn't you just try it out? ^^ It's just like standing there and the backpack contents are shown in your vincinity view

There is no mouse acceleration anymore. It's all raw input and that's obvious. It's extremely sensitive now. Try updating your game, that might fix it ^^ Also, that's not a suggestion, now is it?

A fun read. Really nice and suits its purpose like a glove. A good fitting glove, mind. Not those flimsy ones without fingers.

But then, it's really a game and if the "movement input-> response" rate was any worse than it already is or if the character moves any more clumsy than he/she already does, I think that'll be a much much bigger problem. It's already feeling like steering a bus at times although the raw mouse input did a good job to reduce that by a significant margin.

Older screenshot ... not sure where that was - only that sunset looked fantastic.

Spawning mechanics are getting worked on. They are currently some kind of POC. (Causing Zeds to randomly appear behind you) Zombie AI is having some treatment too. (Causing Zeds to ignore collisions and whatnot) Hit a Zombie with a firefighter axe 2-3 times and it'll drop dead. Other than that, it's more of a difficulty to get people to not shoot you the moment you come out of your cover. So that would be the harder part of the game.

Actually that would work if one was to draw the backfaces of building polies. Only that would probably end up in catastrophic performance drops ^^ They are not drawn for a reason, after all. At the end of the day, it's probably a nicer idea just get collision detection straight and have that broadcasted to clients properly. (Which is not a trivial thing to do, I would guess)

Good morning, Svetlojarsk.

NWAF indeed stands for North-West Air Field. That's where loads of military loot is supposed to be, given it's not looted dry. Playing at night... well you can actually go and use the flashlight. It's really not that easy to spot the person who holds the thing. A possible killer would see the light cone but not the guy who's holding it. Alternatively, you can drop the turned-on flashlight to light up an area and cycle around it. It would appear though, that many people on night servers (or at night time) would just turn up the gamma and brightness settings in the graphics settings menu. Depending on moonlight conditions it may or may not help a lot.

Shadow rendering is not networked. If it was, all the lighting was networked too. And that is 110% not the case. But this would be a really nice improvement no doubt. Perhaps they can get to that some sunny, far far away day.

Ooooh ... :D Didn't know one would call that tactical. Thx ^^

I shall check out the new patch after work. Really looking forward to it - especially the black wool coats. Hell yes :D Only ... what on earth is a tactical bacon? ^^ Is that supposed to be a misspelled tactical beacon?

There is a built-in voice chat. It's distance based though. You can only hear people talking that are nearby. All the people. If you need privacy (for planning tactics to infiltrate a city, secret stuff) you should perhaps not use the in game voice chat.

That very strange behaviour. See, as I mentioned before, the draw call in itself, doesn't necessarily mean high load on your system. What does produce the high load, as Lady Kyrah hinted, are the shaders that need processing and the triangles that need to be put together to something visible. And that is a lot of stuff. But clearly, as you can see, high load on your system, doesn't necessarily mean bad performance either. Forest == (relatively)high load but still good FPS. So, the next logical step would be to assume that it's not that it's bottlenecking anything. If it would, you'd see system load go nuts. Which you probably don't. That leads me to the conclusion that it simply can't go any faster. There is a game, called KKND2 Krossfire. That's an RTS and it's pretty old. It would run on a PC made of twigs. It was designed so each player can have about 100 units on a map, give or take a bunch. You can change that value to something far beyond the 100. If you do that and then, ingame, actually build all the units (lets say 700 per player) the CPU doesn't give a flying damn (nor does the GPU). But the game still starts to suffer from FPS drops. Its algorithms are simply too slow to process all the unit data.

Nope. That is "by design" as it seems. Mouse acceleration is supposedly tied to some factors such as health of your character (I read that somewhere, not sure if that's actually true). You'll get used to it eventually but yes. It feels like steering a friggin tank sometimes.

I was not talking about texture swapping in the VRAM. And I was not saying that (well I didn't mean to say) that swapping textures in a buffer doesn't need any form of processing. Ofc it does, as you already mentioned. I was talking about the buffer that contains the texture that is about to be drawn. This is not about thr RV engine, but here's a link to the unity forums where user pete explains that muchos better and much shorter than I ever could ^^ http://forum.unity3d.com/threads/27416-What-are-Draw-calls But ofc, that thing does act quite weird. No doubt about it. Only, the point of the whole thing, lets not forget the topic here, is that I think that slapping on 64bit support and more threading is just not the solution. And the problem, in my opinion likely being too much and too slow draw calls (as CPU usage seems to be unaffected for the most part), needs to be tackled differently. If, in the end, this is all about draw calls or not - they'll see, sooner or later. Although I think I have a point with draw calls (I wouldn't have said it otherwise ^^)

I'll try to explain further ^^ A draw call, no matter how much of a beast your graphcis card is, takes a very very long time to execute, however, in itself does not utilise any of the graphics processing resources. All it does is swapping texture in and out of the buffer it uses to paint things. See, it doesn't need to process anything at this very time in regards of GPU usage. The GPU usage comes into play after the textures were swapped, when it starts painting. It cannot paint however, when it is instructed to swap the texture first. Now, if you have, lets say, 200 draw calls (entirely possible number) per frame in a scene, than we need to swap a texture in and out of the buffer 200 times per frame. To get 60 FPS that means your gfx card must swap a texture 200 times and draw a thing 200 times in the 60th of a second; Then do it again for the next frame. Physically, due to the draw calls taking so much time(because there are so many of them), you get FPS drops because it can't swap that fast. At the same time, due to what exactly is rendered (solid objects, not much transparency, simple shaders in cities), the GPU usage drops because the stuff it needs to paint, isn't that complex at all, compared to, as mentioned, a water shader, where there is vertex manipulation, refraction, transparency ... or trees, where there is loads of transparency and whatever else they put into their shader to get the effects they have. So, GPU usage in itself is independent of draw calls. It can be high, while there are maybe 5 drawcalls in a scene, it can aswell be low, depending on what needs to be painted. Cities: Trivial painting process, low GPU usage because of that but loads of texture swaps, resulting in frames taking longer to paint because lots of drawcalls. Forest: More complex painting process, resulting in higher demand on the GPU, not much texture swaps, faster frame paintingbecause less draw calls. But then again. That's only theory. Only Bohemia knows how exactly their engine works, I sure as hell don't. But, I like to think I know a bit about that kind of stuff so this makes sense to me (at least that xD).

I shall explain! In digital gaming, there exists a thing that is called a "draw call". There is a rather easy fomula to draw calls. The less, the better. Thise thigns are extremely expensive to have. A draw call is a thing that happens on your GPU. It happens the moment the GPU needs to swap a texture with a different texture, in order to put it on a mesh (for instance a house). Not swapping it in/out of the VRAM. Within that there is plenty of space for a lot of textures. Talking about the place where stuff gets drawn so you can see it. Simply speaking. We're not the tech course at the university so I suppose that'll do just fine. (For the records: I am not a student) TLDR: Draw Calls are super expensive tasks but neccessary and unavoidable that happen on your GPU. Then, there is a thing called draw call batching. That is, when the renderer is somewhat intelligent. It looks at the data it needs to render and then pushes all the things towards the GPU that share the same texture. In the case of DayZ that means: If you're out in the forest, there's a lot of demand on the GPU, due to all the transparent things, depth testing, possibly some FXAA etc. But the amount of draw calls will be low, because all the sorts of trees share the same texture. In fact, most of them are even the same mesh. So instead of 100 draw calls you get 10. For each sort of tree there is one because GPU needs to swap the textures once, for each. TLDR: Draw calls can be batched with objects that share the same material so we can save a couple of them to gain performance. And this very draw call batching, this cannot happen in a city where there are so many things that need rendering and do not share a texture. Like all the items, the terrain, some trees, each and every house, house interiour ... Now, draw call batching is not expensive in the sense of "using a lot of your GPU power". It just takes a moderately long time to swap textures. It's like when you draw a picture and then put colours on it. Changing the colour on your brush isn't really an exhausting task, but it takes time. Right. Now, I'm not the engine developer at bohemia so ofc I wouldn't know to what extend this all applies (especially draw call batching, not every renderer does that). But I hope, this sufficiently explains to you how I came to think of things like I do. Edit (because it's not enough text yet xD) That's because rendering a water shader is even more expensive. I kid you not. Feel free to look it up :) Edit 2: That whole thing is based on the fact that your FPS are directly influenced by how long a single frame needs to get painted. It takes longer when there are more draw calls as they take some time. (As mentioned) And if frames take so long to render that they cannot get up to 60 per second, well your FPS drop down ofc.

Have you ever thought why it does that? Dropping the GPU usage I mean? That is because foliage needs far more time to render than any old house. Why? Because it's transparent. The renderer needs to do a lot more things on trees / transparent objects than it needs to do on the average house, which is solid for the most part. Funny enough, RV is pretty good with rendering foliage of all sorts. But yeah, it would boil down to object density and polycount. Although (according to steam, if I remember that right) RV seems to utilise DX10 so polycount shouldn't be all that much of a problem after all.