faatal

LOL. I would not worry about that. I skim right over walls of argument text. If it is not constructive and to the point, then I am not wasting my time.

Wilderness POI tile padding has been removed, as it could typically not reach the counts requested, so 4 times the amount of possible POIs locations. Their random positioning inside their tile is actually random now.

Wilderness roads connect in a more sensible order and can connect in the middle of each other, fixing some parallel cases. Have some optimizations I am finishing with paths, so I can add more checks for even better connections.

I am not currently looking at heights, but we have discussed it.

Kinyajuu was Nov 2023, so over a year now and the other was 2019, so over 5 years. Time flies.

Also, these features could be split up differently as well. For example, "Crossplay/Random Gen for console" was released in December as 1.2, while the reset of 2.0 is delayed and actually has some unplanned improvements in it like better RWG wilderness generation.

It is intentional to make their pathing efficient. Voxel world maps naturally to a pathing grid.

Our AI is not that expensive. AI does not constantly think. There are delays built in. The most expensive part is typically the pathing, which already runs on multiple threads.

Finding cover is a good amount of processing, but that is ray casting, which is fairly cheap and could be threaded, and pathing which is already threaded.

One bandit will probably have the overall overhead of 2 or 3 zombies, so if we can run 30 zombies coming at you then 10 bandits will be fine.

Yes, bandits are just smarter zombies. Same entity and AI systems. Animals are the same. Bandits will just have more behaviors, like find cover or heal self.

1 Programming is not working on bandits until 2.0 is out as those of us who will be doing the work are fully working on 2.0 features, bug fixes and optimizations.
2 Getting back to the work
3 Yes, the bandit code I worked on previously has wandering bandits like wandering zombies spawn. For POIs they would switch zombies to bandits and maybe both.

4 No, but we will refine them after 3.0 like we do with a lot of features.

Why don't you just do if (entity) in your code? It would be false when the entity is destroyed. That would make your code compatible with our code.

But if you check a reference to a Unity object with if (Object) it will use the bool overload to return true/false correctly or use if (Object == null) or != that also works. We do not use if (Object is null) and do not have issues as all our compares are consistent.

Destroyed objects in Unity become effectively null if not actually null all the time. This is standard behavior.
What actual bug are you seeing?

I already said the reason: "Every Unity camera has a good amount of main thread overhead"

Cameras do a lot of work to determine what to draw and then draw it. One camera vs two, means less setup costs.

The weapon camera drew your hands and items in your hands. It was probably setup that way to stop hands and items clipping through walls.

The UI is also another camera.

The removal of the weapon camera made a big difference for those of us who gave me feedback. I went from 100 FPS to 120 FPS in Unity in a specific test case. Console definitely saw a boost. Every Unity camera has a good amount of main thread overhead, but if it benefits you would come down to where your bottlenecks are. Some of the other optimizations I have been doing are for FPS spilkes, like entities spawning, which do not change your average FPS.

Convex mesh would not cause that, but failed creating window group would break the UI. Check for missing or corrupt files. Remove any mods.

Check your log for errors.

You pick None under Betas and it will download the latest stable (1.2 b27), which is also the last experimental.
If not, then Steam had just not made it available yet in your region. Different people seem to get it at different times.

Regular cities spawn in desert and snow biomes.

So you will install a mod to change lighting, but you won't move a slider from 50% down to 25%?

I played at 25% this weekend and it was great. I had to actually use torches in a basement to see (new game).

Light effects how far they can see you, so there is a big detection difference from light to dark.

Well, bug fix patches are not supposed to take long as crossplay had already passed. PS5 approval took minutes. Maybe MS is backlogged and they don't give us times.

Hold stuff and people complain. Release it partially and people complain. Lose lose. Our mistake, we should have held it a day.

No changes that I can recall.

Holding a light greatly decreases stealth.

We are not doing any analytics/telemetry currently. We do have crash/error reports now, but that is (edit:) NOT the same.

This is not just people on the forum. Many TFP employees would like it darker, myself included.
Ambient light and moon light brightness reduction only happens at a Brightness setting below 50% and 50% is the default, so it is not changing the defaults.

Helmet lamp was a sensible balance adjustment, because the range was way too long and longer ranges lead to worse performance and I actually increased the brightness a bit to compensate for the reduced range as brightness decreases with distance.

I think that our description is wrong as we already had FSR 3.1. We updated the wrapper library, so 3.1 to 3.1. The fixes we made were for how our code was using it which caused some blurring.

The 64 setting is still there, but the game was already clamping that number with multiple players. Now what the game does with that number is more aggressive. I just played two BMs with two other players with it at 64 and the reduced number of zombies was not missed. We had plenty to kill.

This stuff is not locked in stone. As hardware changes or other optimizations happen, it can be changed.