faatal

Indeed. PvP is nothing like bandits. If I go into a POI with 10 bandits waiting for me, I expect to win. If I enter a POI with 10 players in it, I expect to die.

I want to be the hero of the world and overcome a variety of obstacles. Players need to be evenly matched to be fair, so you will not be overcoming many of them unless you are a pro and most of us are not.

Yes. We have one of our new consultant programmers working on it.

Any amount would be better...

The next required wipe should be a21, which is many months away.

Thanks for the vote of confidence, but I am planning on doing bandits in two phases that will span two alphas as we are hoping for shorter alphas in the future by moving away from giant monolithic changes.

Normal stealth checks would not be desirable in the attack volume case as the zeds are often around corners, enclosed or facing the wrong direction and the player may be making little noise which means default unskilled stealth would mostly work, yet the designers want the zeds to attack.

The one time check is to allow stealth to be useful as a skill you can put points into and allowing for variation in the way you entered the volume compared to zed locations.

The attack uses SetAttackTarget, which is a standard way of the tracking you and used in cases like when you hit them or they see you. I am reducing the trigger's call of SetAttackTarget from 60 to 20 seconds, which seems more reasonable for the attack to time out, since it refreshes anyway if they see you.

Maybe a few weeks.

Bandits in vehicles is near the bottom of my list of what they need to do. You know what happens to the bottom of game dev lists? They generally get cut, but it could happen.

The person who made the video did not notice he is in broad daylight when he tested the attack volumes, so yes they saw him as his stealth was horrible.

Not having shadows on also makes it hard to know when you are in sun or moon light!

They do the normal stealth checks and are actually worse at detecting you since they can only hear you and not see you. A sleeper in the open could see and hear you.

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.