faatal

It had nothing to do with the map or blocks. It was raycasts failing briefly from mesh colliders updating, so the turret would see "ground" father below and rapidly move to it. The more a mesh was being updated by say damage, the more often it happened. This fix will be in our next experimental.

There are two types of stealth checks that happen.

1 Continuous - A player stealth update calcs their light level, updates noises and sets themself as noise source on AI entities if they are the higher than other player's noise. AI checks players in their vision cone based on distance vs that player light and then target the player. The player noise on the AI, if above a threshold, will wake the AI. Noise will also make it investigate and do a vision check, which could cause it to see a closer player than the one that made the noise.

2 Triggering a sleeper volume - This happens once per AI based on stealth modified light level vs distance and only determines attack vs active. They will go active in any event and continuous stealth checks may hear or see you at any time after that.

Turrets falling was probably the delayed collider mesh baking. Turrets were very sensitive to their sphere cast hitting below what they were sitting on.

Fixed turrets falling through blocks (Start cast higher, delay fall, move linearly, use current pos for entity pos and recheck hit every frame during move).

Next game maybe, but depends on how much of the stupid they fix in DOTS/ECS. We are planning on HDRP next game. I'm looking forward to using it.

They are predefined meshes of different types with tougher versions within the type. Don't know how many changes we will be able to make within a specific version as this is not UMA.

Not likely. That would be a lot of work and we are pushing features towards gold, not wanting to rewrite stuff.

Friday I started on bandits. I made the entity/sound xml and prefab. He runs around in the A pose saying mean bandit stuff, since we already have a bunch of sounds for it. None of the bandit meshes are skinned yet, but our new animator is working on it.

I don't mind. It is not like @faatal forces me to answer. Now I'm calling myself.

The origin shift had to do with falling through the world and it did happen for players and zombies. What I said was those were fixed in 20.1 and not happening anymore in .1.

That Steam video is unclear. There could easily have been the same type of zombie on the other side of the trader that followed them in.

I'm not working on optimizations. Bugs and a21 features.

You can't avoid all GC, because a reasonable amount is fine and in some cases avoiding it would very difficult. CG is incremental and does not cause much in the way of FPS spikes.

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.