faatal

I was referring to it spawning from a sleeper volume. There is no coordination across sleeper volumes. I added that to my todo list, but it will probably not be in A19.

Not likely to change much. Way too expensive checking line of sight to all the potential blocks you could see.

People make a lot of guesses as to why the AI does something and it is often wrong. I see people test their designs with a bunch of the same zombie thinking the other types will do the same thing, which is sometimes not true.

Blood moon spawner does attack your base from multiple directions, but not all at once, it changes over time, because that is more efficient for pathing. The typical dumb zombie will not go very far to find a weak spot or opening, often preferring to beat on a wall near it instead of walking a bit to go through an opening. Yesterday I was just looking at that issue of being too dumb and beating the walls around a cemetery POI instead of using the opening, but really that is correct, since those are set to be that dumb. Thick walls would change that behavior, just like many things can change their behavior.

No zombie auto targets you except for blood moon spawns and POI volumes set to attack.

Probably not.

That was probably from the streaming bug reducing texture mipmaps one extra level, which is why streaming is off now when texture quality is not Full.

I already fixed that message showing with the values in your picture.

It now does otherHeight <= -.001f. If you still are seeing it, then I need the new # it is showing.

I told the programmer who works on music what you noticed.

You can turn music off. I play almost all games with music off, so have not noticed it in 7dtd.

Normal entities don't load up front like they used to and hundreds of oversized textures were reduced, so the game does not need more VRAM. VRAM use can also be misleading since Unity's texture streaming does not free unused textures until it needs some space to load a new one.

Technically a chunk is 16x256x16 and has 16 layers each 16 tall, but people and myself often call a chunk 16x16x16 even though code calls it a chunk layer.

I don't know the details of what works or not currently. Just guessing. I have not touched that code and the creator is probably one of the programmers no longer with TFP. Like many features, it needs to be tested and reevaluated someday when someone has time.

Today I fixed some issues with electrocution, so it may be better.

Vertical blocks should matter, since an opening is letting in cold air. Temperature would matter as much as rain in a survival situation where we determine if you are freezing or burning up.

It is not as simple as can the block above me stop rain, because blocks can be rotated. A plate or half block can or can't fill a vertical or horizontal hole depending on the rotation.

We will probably fix heat/cold survival before gold, which would include checking if enclosed, but not until A21+.

I have thought about doing brute force raycasts, but raycasts are not free and you would have to do hundreds or thousands of them and may still miss holes or things just out of range. If you built a big 10x10x10 or 20x20x20 room, but left off a wall are you inside? It would block some wind or rain, but you would still freeze if it was not fully enclosed. Say you built walls of center poles, columns or other partial block shapes, they would probably be seen as solid, yet they are full of holes and not really make you inside.

Placing a block about your head does not make you 'inside'. Imagine standing in a field in snow with a block above you. How are you inside?

And then the screen fades to black as they suffocate....aha, oxygen tank to the rescue....land shark then swallows them whole.

Inside vs outside is a very vague concept in a voxel world made out of all kinds of odd shapes. Not easy to determine and not fast.

Not easy. Chunks are many pieces of data distributed across different arrays in a type of compression and it is not simple. Then you have tons of code that says give me the block at xyz or set the block and now it is multiple blocks? Some hybrid? To be sane, it would need to remain a primary block at a location, but possibly a secondary block could be added for visuals, but I would not be doing separate heath and collision resolving for it or it just gets more complicated and slower.

I'm already done with those performance changes.

gfx st x are streaming commands and forceload is a Unity debug option that just makes streaming textures load, which would not help if a texture was slow because it is in system RAM.

Friday I actually disabled streaming when texture quality is less than Full, since both features are doing a similar reduction in textures and due to what seems to be a Unity bug were not working correctly with each other leading to blurrier streamed textures.

Testers found that some FPS drops were actually biome particles, so today I fixed that:

Fixed Particles in snow and desert cause major FPS drops (balanced sand, smoke and snow particle rates to a reduced max count of 150).
Changed "Water Particles" video quality option to "Particles", which now also decreases world particle count.

Games always have lists of lowest priority ideas and they never get done, because you run out of time. You want something actually done, you don't make it the lowest priority.

I have a bug ticket for it. Some of the fat zombies do it to. I don't know why anyone would want such a feature, so yes, it is a bug, probably from some of the colliders changing.

Load order, current VRAM use and then where the OS decided to put textures would make it somewhat random what is in VRAM vs system RAM.

----

Hopefully the disappearing backpack bug is now fixed. That was not easy to track down.

There was about a 5% chance, depending on when random chunk saves happen, that a newly dropped item would be lost when you teleported away, because its chunk might not save.

A19 has a variety of rendering changes. Many textures got larger and more objects with textures were added, so there are probably more textures running out of system RAM for you. The next release will have 100+ textures that Justin shrunk down, so it might be better.

Console messages are not as bad as you make them sound. For years the game has logged plenty of console messages as you play. It takes dozens/hundreds in a short time period to start lagging unless you have some weird issue with it writing to the file.

Now the code that is logging the message might be running slow, but that is not from the message itself.

If they don't take any damage then it is probably a bug, but I would not want them taking much damage even if we fix it, because people would make low resources corridors full of campfires to kill zombies. Yes we should fix it, but it would be way down the list of things we need to worry about.

b169 did not load block entities up front, so less VRAM use, but added lot of loading lag, so that change was reverted in b173. One of our artists lowered texture sizes on many textures last Friday, so texture memory use will be somewhat less in the next release.
It is probably a memory issue on that GPU. How much VRAM does it have? Wiki says 2 GB or 4 GB. If yours is 2 GB, then that not much and you would need to put all texture quality settings to the lower choices.