faatal

1 Tons of code changes.

2 This is all c# code. Not much to do with Unity.

3 Way too early to tell.

No, since our current list is subject to change. Top goal is water that does not suck.

We are aiming for performant water that does not have holes in it. Beyond that, it will depend on how slow the simulations run and how much time we have.

Boats could be done at any time if we wanted to, with old or new water.
Water is still block based, but it is not a block. Meaning it is the size of a block and shares the space of a block, but any block could have water in it.

There may still be water block(s) for placement or other reasons, but when placed it would become water data.

Water is still stored in the chunks we already have. It will just not be as blocks.

Vehicle tinting and mods have already been worked on and should be in a20. Three of the mods need code support, but it is not major work.

Not sure, but currently water blocks just convert to the new water data format.

No time for playing in the dirt for a20.

A20 NEWS!!!!!!!
Started on the water overhaul this week. I'm working on the water chunk data and another programmer will be doing simulation/mesh changes.

My plan is water will not be a block, but additional chunk data, which is a pretty big change. It makes more sense, since any block could have water in it while still being whatever block it is.

I love new Unity versions, but as we are getting into a gold mindset and have been talking to Unity, we plan on using LTS releases. A20 should be on 2019.4 LTS and next year hopefully move to the 2020 LTS for A21, so would be able to get those benefits.

Not likely. Vehicle speed is limited by chunk loading speed. Last week I make an improvement to chunk deco spawning speed, but a lot more would have to be done to the total speed.

No. The current one may get a few tweaks and will probably go stable within a month.

A lot of team time is now going into A20.

It would be a performance issue in the current way it works. We need a corpse manager that deletes oldest/farthest corpses, in addition to the current timer.

Many sounds originate from the player. Hopefully that gets improved someday.

Console command spawnwh will spawn a wandering horde.

AIDirector does not spawn them at the same time, but it is one per tick, so 20 a second. 2 seconds is a lot of time and may not be feasible in POIs due to players being able to see them pop in. I added a wh spawn delay of 1 second. That may be enough in that case.

A common load delay and/or precaching solution may work, but these are not trivial changes with the randomness of spawns and spawning across different systems.

Thanks

It is not something I've tried and I don't know of anyone on the team that has one. I use a 32 inch 4k 16:9 monitor for my main.

Running in windowed mode would allow us to test any aspect ratio.

Sooner than you might guess.

That post is basically backwards. There is a huge increase going to low, which is the point of low, to disable terrain visual features so it runs faster. The difference is bigger on lower end hardware that has trouble with those features. The recent changes to the terrain shaders make those features run faster, so what they want is already done.

No specific work yet.
Probably both. Special infected will likely cover a range of behaviors allowing common zombies as the more stupid ones, but the whole range can't really be balanced across the entire game until there is an entire range to balance.

We are definately CPU bound. Profiling last week after the terrain shader update and related tweaks, show that even more. Just tested a build and 4k res is running better than I've ever seen it at high quality, which is what I normally play at.

I would be interested to see your numbers when 19.2 comes out.

Thanks

I thought the deco writes were 0 as the log says, so it was confusing what was going on, but it turns out the list is cleared before the log happens, so it is writing out, in a 8k world, about 71000 entries, totally over 1 MB. Tried on my HD, but still not horribly slow, then on a flash drive, which gave a 7 second write time! The save timer is every minute, but there is a dirty check, so it does not always do the save.

The deco save code was changed a few months ago by another programmer to fix a problem with old saves, so it might have been only doing partial saves before, but since it does the whole thing now in any event, and on the main thread, it does lead to a large frame spike.

The simple solution was to write it into a memory stream, which is faster than a file stream anyway, then another thread does the actual file save, so minimal frame spike. This probably won't make 19.2, but hopefully 19.3.

Except that save message only happens on a full save, like when you Exit the world, do a save in the prefab editor or generate a world.
I am flying around the world and blowing the ground up with dynamite and that code is never called.

Are you using any mods?

I played the game on a HD up until maybe a year ago. I did not have write issues as you describe. I would suspect your hardware/software.

Do you have a good amount of free drive space? Free up space and defrag the drive.

Is your antivirus software aggressively scanning written data? Try excluding the save folders.

Is your free RAM low when playing? Shut down other programs and/or background tasks.

Not a win for a lot of people, since a primary complaint is performance.
I actually enjoy optimizing code. One of my favorite things to do, because sometimes you do find that big win and multiple small gains together do lead to moderate gains.
Updating our terrain shader got me 15 to 20 more FPS at 4k. That is a big gain and definitely worth it.

You often don't know how it will turn out until you do it. That is life.

Those "catchers" are actually cosmetic and don't have collision data for them, so there is nothing to remove. The normal colliders would have to be moved up or suspension changed, which can cause other problems.

Do you know that this is a team with many different skill sets, like pretty much every game team? Most people on the team can't fix FPS issues, so they do spent their time working on their "stupid" stuff.

FPS issues don't have an "I Win" button you can press to make it all better. It takes lots of time to analyze performance and find bottlenecks, which then often have no easy fix, but to rewrite and retest something, which often results in minimal gains. Features have maximum limits at which they can be optimized to run.

I've actually been spending half my time the last few weeks doing that and cleaning up the project of old/unused files. For example, I found an old unneeded water depth camera, that was rendering nothing each frame. After time spend researching it, removing and testing, I saw a 3% FPS gain. Not much. Path grid updates have also been optimized, which is not something increasing overall FPS, but reduc...