faatal

That is nice that modders can do that, but we need to make sure that vanilla is going to work on many years worth of PCs, Mac, Linux, consoles and lot of different GPUs. Currently, the game barely fits in Xbox Series S memory and quickly runs out as you try to play it, so memory is a great concern and we are doing a lot of work to reduce usage of. Streaming/unloading will help, but that is not a Unity strength, so some programming time is going to trying to improve that, without lag spikes loading data.

That would require a clothing mask texture being made for each zombie for the tint areas or additional textures made. Either approach would push up memory use, so that would need to be evaluated too. The artists are busy working on all the previously mentioned art.

Completely different people. The various water changes were done by three different programmers, who can not do zombie art.

The game tick rate is .05 ms, so that might be what your were seeing. Don't know where you got .01 from as most code runs at frame rate, physics fixed update rate .02 ms, or the previously mentioned tick rate.

We are trying to finish A21, so certainly not wanting to make large engine changes now.

I didn't get some of the other things you were saying, but thanks for info.

Well, the goal would be to give you reasons to not want to be in the water. 🌊

Definitely. Games with many features grow massively as they are developed, because at the start they don't have all those features and often when features are added they are basic and then grow over time.

The water simulation changes don't really effect the raft. It could have worked with the old water as well as the new. Large bodies of water are just idle voxels in the new simulation. Holes would cause the raft to hit a bump, but large bodies in the old sim rarely had holes in them.

The raft model has been in the project for years and the plan was to eventually do something with it. I made the vehicle system generic enough to support vehicles floating on water. I always have dozens of tasks I could work on, but some days you just want to have fun with something new, so back in September I spent a day setting up the prefab and xml to make it work and it does.

I showed it to the team and we had a laugh about what we could do with it someday, but it needs many more days to polish it up, so it was not deemed to be something we would do for A21. That work is not wasted, but simply set aside until in can be properly finished and combined with other water related features like say a shark and better shapes and quantities of water in the world, so you would actually want to make a raft to get around. I'd love to have a water map full of islands.

Game development often has creative rabbit trails where y...

Well....there is that raft prototype I did last year. Works, but with a few bugs. That may become a feature at some point.

You can now do this which I'm putting on the forge xml as a hint (is default without it defined).

No xml. The prefabs are simply setup to have a child object named 1 for for tool slot 1, named 2 for second and so on.

Friday, I started on the forge mesh showing/hiding each tool and it seems to be working. This will probably make it into A21. Code supports all workstation types, so will be simple enough to do the rest as new models/features are added.

It should be no surprise to anyone that we discuss fast travel as many games have it, hence the helipads. The vehicle teleport is one of my main issues. We think the vehicle should go with you without it being annoying. I'm thinking it teleports to an open parking like area and finding a free spot. I'd prefer it be a very limited system, but it could end up as whatever makes sense or not doing it at all. It could easily not be in A22, yet show up later.

Zombie pathing is already cheap and runs off the main thread. I did fix a bug last week with only 1 path per frame being sent to the threading system and since it typically only takes 1 frame to make a path, it was a bottleneck for say 100 zeds making paths each second. A fairly simple change now has it requesting up to 8 paths per frame of which the threading system can provide about 6. This tested well with around 150 zeds on a server spread across 6 players.

1 It is just a reset time in days. It works at the POI/chunk/region level. The engine does not track player made blocks.

2 Hard to say. So many things change that you can't just load an old world and stare in the same direction and see if it is x FPS faster, because that world won't load and if it did, POIs have changed or new blocks and some blocks converted to props. A lot of it is situational with where you are, what you are doing, your hardware and your options. The simple answer is it runs a bit faster and RAM use is a fair bit less.

Yes.

I started at TFP at the beginning of A17 and later in that alpha, took over AI and made large changes to how AI for zombies and animals worked. Until A21, there were dozens of big things and hundreds of smaller things for me that were higher priority than bandit AI. The new bandit work, which started during A21, is based on the current state of the AI systems, not prototype code/data from 6-7 years ago.

Interesting. I'll keep an eye on that thread. If it works well, then we may support it.
Thanks for the info.

I made an 8k map the other day and it took 3.5 mins. Granted, this is on my new PC, which is a AMD 7950x.

No. That is the water surfaces level in a voxel, not how many voxels deep. We have bodies of water of a variety of depths. The water mesh is only created for the top, otherwise you would have layers upon layers of meshes, leading to visual issues and slow rendering.

They showed the worse use case. The current water is meant to be contained, not dumped on flat ground. Neither RWG or POIs have water dumped on flat ground.
The water mesh generator is the old mesh code with some cleanup and the programmer working on it is still making changes. The mesh generator makes meshes at a fixed height, which does not tapper off currently.

1 - A20.7 has a few minor changes to reading the world file header. It will not effect existing A20 saves. It will simply show A21 saves in the list without throwing errors.

2 - A20.7 saves are the same as 20.6 saves. A21 will not read those saves due to many changes that are not compatible.

A20.7 has a few minor changes to reading the world file header. It will not effect existing saves.

As I said a few times in the stream's chat, it will be x amount of weeks. Rick gave a more specific guess, but really it could be 3 weeks or 5 weeks or more and comes down to fixing any bugs that we do not want in even an experimental release once we finish features and polish we are doing right now.

There are 63 must fix tasks right now, of which maybe half need to be done to release experimental and more will be added as we go.

LOL. Not working herd dued!