faatal

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.

I checked the randomness of loot containers a few weeks ago. Was working fine. 75% of 1 means you have a 75% chance to get 1 and a 25% chance to get 0. That also applies to any partial amount. 5 items on 50% loot means 2.5 items, so a 50% chance to get 2 or 3.

There was this change: "Change "Boss Volume" to "Quest Exclude" on sleeper volumes", which repurposed the boss volume flag we never used to allow designers to exclude volumes from a quests requirements. Like a garage outside a house could have sleepers in it but not be required to fulfill a clear quest.

If only it were that simple. Water runs fast for me normally. I've been around and under water during testing a lot in the last several months. It has never acted like it did during the stream.

Bugs that rarely happen on your own computer are often very hard fix.

Like I found a way that backpacks can be lost and can reproduce it fairly well now, but I needed to add code to move the backpack constantly to make it happen regularly. The reason the bug was so hard to find is it requires the backpack to move between chunks as the chunks unload and chunks save. That stuff is complicated with 2 different threads and after debugging all day, I still am not sure what is going on other than the chunk the backpack is in does not always save. Hopefully get that one fixed Monday.

I have not noticed that. I don't think it is doing anything fancy. Mostly changing the FOV I think.

1 Is not the fix I'd want, since the message should not happen period.

2 There are many console messages that are in the game for the devs, not for you. Those messages should never happen and are supposed to be in our face, so we fix them. The values in the error are very close, so it could be a floating point precision issue and just needs a bit of tolerance.

Thx for the info.

Spawn 'randomness' is from the name you chose for the world. Pick another name or add some numbers to it.

Sorry, I have other features to work on.

That would not buy you much. Passive sleeping zombies are already low overhead.

Yes and no. It is from load on demand, but mostly from block entities. I've already made block entities preload again. Looking at other ways to reduce texture memory use. Unity streaming is not working as well as I'd like. What a surprise.... 🙄

Bags normally drop and get unloaded (destroyed), because you respawn some distance away, so those chunks unload, then they reload as you get near the chunk. The reloading is where I think the bug is.

That is why we have testers and I have not heard of any of them having issues. Dropped in on a lot of streamers this weekend and have not seen any of them having load delays either.