faatal

I can't really verify that, because there have been many reports of crashing on a variety of hardware, often second hand reports, and you can't tell the average player to check their thermal paste or OC settings when they don't know what that is. That makes it not a simple issue for them. I do know one of our testers with consistent crashes is on a 3060 TI, so not an old GPU. If Unity allowed us to switch gfx jobs in realtime, we could have a gfx option, but they don't.

Players and zombies should not be doing it at all from origin shifts. Vehicles seem to have something still happening, but not seen it myself since origin changes. Turrets do their own ray cast. I have never seen one fall after I made the origin changes, but have done limited testing on those since.

It is probably Unity graphics jobs. I enabled them a few weeks ago, since that is now the default for Unity projects and they are supposed to improve performance. Two testers started having random crashes and they have reports of others crashing. I disabled it today, which will be in next exp. When we get our new consultant from Unity, that will be one of his initial tasks of why Unity is doing that. We will give it another shot once we switch a21 to 2021 LTS.

Pathing is not our bottleneck because each path is calced on a thread, so little hit on the main thread. Updating the entities, animating, colliding and rendering them is where the cost is.

No, the pathing system looks at the health of pairs of blocks to determine path cost. We have lots of blocks with different health values. SI is based on distance not health and there is a block glue value for collapse calc. Yes, the old pathing favored doors, which made sense, so I added that to the current system.

We are a company of many people with a variety of ideas on how things should work. Over the years you also get new people coming onboard with new ideas. Opinions also change over time, so what I thought 4 years ago when I started, may be different now. AI uses rounded block health in their pathing calculations, not SI. It is tower defense and we want them to be able to reach you, but since we can't do massive piles of zombies, smarted ones will do. My zombies have xray/heat/magic vision that lets them see weak spots in blocks and their semi functioning brains lets them decide to go there. They also have a dim recollection that doors allow them to get places, so they favor them. My lore for now until I change my mind or the company decides to have some official lore.

Not that I know of. Our Vulkan support comes through Unity. We have little control over it beyond enabling it. The game is always going to have random FPS slowdowns, because the world, what is going on around you and what you are looking at changes a lot and the game has to do data cleanup at times like garbage collection. The goal would be to minimize it, but it will never go away completely until we have computers so fast that you can't tell when it drops from 300 FPS to 100 FPS at times.

This is a different test than I was doing, since I used the most common case for testing and time is limited since we are wanting to get some experimental versions out there. Now that destroy area changes are in, I'll try this. Terrain or normal block colliders are similar, so the bug applies to either.

Allan committed a fix for it and similar blocks today. He changed the colliders and xml tags, so path raycasts can now see the colliders. It was a general fix for things falling through the world, which also effects vehicles. One of our testers retested vehicles and it is better, but he still found cases of them moving, so more testing when I get back to it.

The problem was that falling AI that had a path to the player were not trying to enter destroy area due to a bug. They would only enter destroy area on a long path, which is a fairly low percent. Now that the code is fixed, you are seeing the full extent of it working as intended. Falling zombies also don't just enter destroy area, but can trigger others into destroy area. Dedi is no different than SP, since AI only runs on the server, but with the increased zeds multiple players will get, it means increased chances the of them triggering each other. This just sounds like the percents need to come down and maybe cap the sharing.

Yep, that is what I did, time based shifting that I typically ran at .2 seconds. Stress testing is important and programmers often don't abuse their systems enough. The rays are not hitting the ground. The ground does not have a rigid body. It is just a mesh collider.

Rigid bodies are not the problem. They collide using their collider just fine. When ray/sphere casts to the ground fail in large sections of the world, then objects relying on them for physics fall through or in the case of vehicles, think they are falling through and move back. The code I did is visibly fixing it 100% in the case of the player and zombies, but I just don't know about vehicles and turrets yet, because I have not seen one move in days, which does not prove it is fixed, just that it might be fixed.

Yes

Nope, as far as I can tell this is a Unity bug with the internal physics collision data. Origin shifting moves all the transforms at one time, there are no delays. It works most of the time, but when it fails, all physics casts in parts or all of world fail repeatedly frame after frame until something changes that causes the physics collision state to update. Even the editor Physic Debug mode won't highlight the collider when you mouse over it. Strangely, rigid bodies, their colliders and world colliders still collide fine, which is why a vehicle would not fall through the world, but the raycast to check if a vehicle fell into or off the world would fail and try to fix it. It appears I now have it fixed by detecting failed raycasts and shifting again and checking again. I did move the shift to FixedUpdate, but that alone did not fix it.

No, but we move the CC around in many cases and it is not an issue and it would not help AI or vehicles, since they don't use Unity's CC. Raycasts also break.

There was a reason the origin was changed to shift more often. Weapons shaking in hands. If we could do it less often, we would. Even if shifted much less, it still causes the physics bug, so still needs to be fixed.

What I posted before is about that issue: "All or most of the issues with players/zombies/turrets/vehicles falling through ground appear to be caused by the world origin shift. It happens about 4 times more often in a20, so these bugs are more apparent. It seems to be a random Unity physics update problem after the origin changes, causing physics casts to fail. I've tried a ton of stuff and added a rapid origin shifting mode to repro it quickly. I now have the Origin code doing extra physics updating that reduces the problem to one frame and a raycast which detects when it happens, so I can try even more adjustments to fix it. " This is not an easy bug to fix as it is an internal Unity engine issue with their physics values not updating after we shift the world origin. After a week of experiments trying to repro it and come up with fixes, it seems better, but it still is not 100% fixed, so come Monday I'll be trying more things. We have to shift the origin or you get jittering animations as you move away from the world zero point.

There should be no changes to that. They should just be firing away with whatever part they target and random hit variation each weapon has and possibly hitting the demo charge.

Stability fix is done. The second issue we found was actually just a display issue with the show stability view, which is now fixed. All or most of the issues with players/zombies/turrets/vehicles falling through ground appear to be caused by the world origin shift. It happens about 4 times more often in a20, so these bugs are more apparent. It seems to be a random Unity physics update problem after the origin changes, causing physics casts to fail. I've tried a ton of stuff and added a rapid origin shifting mode to repro it quickly. I now have the Origin code doing extra physics updating that reduces the problem to one frame and a raycast which detects when it happens, so I can try even more adjustments to fix it. I've not started on it yet. There are bugs that need fixing first for a20.1 and we are still sorting out what is going into a21 and who is doing what as we have added several new programmers to the team.

The main issue is fixed, but testers found some secondary recalc issues, so I'm going to look at it again. There will be an experimental, but not until a collection of issues are fixed. It will be announced in the forums when released.

It was not a large amount of work. I was the only one who worked on it and I probably just spent a few days on it. I work on a lot of different stuff, so it gets hazy over the years. Digging is also not just for horde nights. It is useful to the AI in POIs when you get below them and down would be the best path. We don't spawn hordes so they can do nothing. The intent is for them to reasonably try to get to you and you to reasonably try to defend against it. If you don't want to interact with hordes, then turn them off, which is why the setting is there. One of our devs was even playing a game with them off recently, since he was trying something different. Shooting a crossbow is quiet, not silent. Feral sense makes it 2.5x as loud to zombies (dog and zed bear are slightly different multipliers), so your quiet is not that quiet. It was OP, so you should have to put points in stealth and use appropriate gear to be effective. It is. Things falling through world and stability issues (half fixed) are my top two bugs.

Sure, it was not a good test of a low end system, because it is not a low end system, but that is all I had the time to test. We know tree high detail LOD complexity is an issue with gfx and shadow fill rate, but artists don't want ugly trees. We have a very capable programmer looking at trees and we shall see what he finds. Yes, I've noticed that player trees could use more space between them. I have no interest in spending time making old school circle shadows. Would rather people just turn shadows off on low end systems. There is no clear cut indoor vs outdoor. Occlusion outdoors often hides objects behind buildings, which applies more so in cities, so I'm not spending time trying to guess which is better. Low end CPUs could have it default to off, but that needs research, which I am not spending time on that now. Zombies have varying degrees of dumbness in their pathing based on a settings in xml which also covers a random range. They tend to abort long paths, put less value in block health differences and can't open doors. Bandits will try long paths, fully consider block health and open doors. They will also spawn in smaller numbers.

Not in my testing. If I was in stealth and quiet enough, nearby zombies did not wake. Distance from zed being a big factor.

Yesterday I tested 100 zeds and various shadow settings and did not see that much difference on an RTX 2070. I do have Unity's gfx jobs enabled, which may have some effect on that even though FPS generally seems the same with it enabled. I moved the gfx jobs change into the project, so it will be on in a20.1. Object quality setting matters more than it used to, since we have more block models, which cause more draw calls. One of our new programmers is researching trees. I fixed it today. Fix will be in 20.1. I don't want canned pathing, if that is what you mean by common. The AI should react dynamically to whatever block combination is presented to them and make a reasonable job getting to you. Bandits, once in, will do the same.

Does it happen with Dynamic Mesh off?