faatal

Once an alpha is stable, we won't break saves for that alpha unless it is some major issue we can't work around.

Our goal was to get it out before Christmas and it was close. January should see a 20.1 addressing bugs and other issues.

In the future, keys or some such mechanism will address that.

When I wrote those words, I figured I would be hearing from you. 🎄

Many things don't feel good but are not fixable in practical terms. Sometimes things can be changed, but they are not worth the investment. Redoing resource management would be nice, but would take months of time and then may only get little to no gain.

There is a fixed cost, since it has to scan all loaded resources, so doing it say every minute would be more annoying to only save .1 secs. Games typically hide this stuff with loading screens between levels/stages/whatever, which we don't have. Maybe someday Unity will have an incremental way of doing that.

Being Unity (or really any engine), there are often uncontrollable things we have to live with. Code can only be improved so much before you hit a performance wall.

I have 32GB, so maybe, but I've never heard of Unity doing anything different with 64GB.

F1 key opens the console.

I changed the default to land claim only. Full seems to be a noticeable drain on some computers.

Performance demands vary greatly in the game from in a forest looking up at the sky (a good best case test) to in a dense city surrounded by buildings and zombies (a good worse case test), blood moons even more extreme. Since we spawn you in a forest, people may think that is the typical FPS they will be getting for the options they chose, which is not the average or worse cases.

They spawn as you get near the volume. Size does not matter. Distance to an edge is what it uses. Vertical is much closer than horizontal. Grouped volumes should spawn them together and trigger together.

Edit:
And network latency is important. You move, server receives, server spawns, server tells you, you spawn, then it gets rendered. That is 2x your latency plus the instantiate and rendering delays.

It may be a bug, but I actually like it. A reason to get out of the forest and go some place. I'd probably also like it if the forest burned down on day 21 and you had to leave or die.

Never seen. Does it happen again on game restart?

There have been no changes to spawn in distances. Sleeper volume positions/sizes and sleeper locations do vary by POI and are up to each designer to place. Vertical separation is strict to keep performance up, so climbing into a ceiling combined with nowhere to hide the spawn may be what you saw in that case.

My 3900 takes about .5 to 1 seconds. Worse case maybe 2 seconds. Don't know how you manage that long with that CPU. Never seen an hourglass while it happened. 3 other devs just told be the same thing. Not that long and never an hourglass.

Are you using any mods?

Not happening in this game. Would require switching the rendering pipeline to HDRP, which would require a rewrite of our gfx system and that would take a lot of time.

No change from A19.

That is a unload unused resources call. It is on a timer and has to happen sometime or memory use would keep climbing. Slower computers take longer.

Same call using same rules as A19.

Basically yes, but is the unload. Garbage collection is incremental (multiple frames) and runs every few minutes and is rarely noticed.

Any pole health reduction should be balanced with a reduced zed damage buf, but I actually forgot that code was even in there until I saw in forum discussion. Things are a bit hectic around here with a lot of back and forth on a variety of bugs and balance issues.

No. Profiling requires Unity editor to attach to game. Game has to be a dev build, which makes it run quite a bit slower, so you don't want to be playing a dev build.

Profiling is also not as great as it sounds. Knowing something is slow is easy, I see lots of that whenever I profile. Trying to make it faster is the hard part.

Cities are going to be slower by their very nature. More objects/blocks/zombies. More is going to render slower. To handle more, you turn down settings to reach a reasonable FPS vs quality tradeoff.

Music loading will need a rewrite to use another method to improve performance issues, which is not happening now. Months away.

Mesh baking moving off the main thread should not make it worse, since the main thread is the most loaded thread.

Already changed that today. Upgrade, repair and harvesting all scale.

We are still testing and thinking about these changes like many parts of the game. I'm currently leaning towards two buckets. 25% (or 33%) and 100%. The 25 being the obviously flimsy/weak/small blocks that should not be stopping anything from breaking through and anyone should be able to look at and say that is not going to protect me.

Bars were intentionally excluded because they are primary window and elevated defenses. Plates would probably move back into the 100%, but we are still discussing. Changing stuff to see what happens is what game development is about and some major changes can and do happen during experimental.

CPU may show as low because task manager shows you all cores together, which will never get near 100% if you have many cores, since the game can't use them all and can not use them all equally. Many Unity task have to happen on the main thread. GPU will typically not be at 100% as the game is usually CPU bound.

I will not do what that mod does. I don't want to disable AA on the weapon cam as it looks worse. The weapon cam may be going away at some point anyway. The increased blending they use also makes ugly motion blur, which the artists and I don't like.

In every case I've looked at, lowering settings will increase FPS regardless of what your peak FPS is. Be it 60 to 120 or 10 going up to 20. It sounds like your CPU is running very slow. Have you rebooted? What other programs are you running? Disk getting hammered by some OS update, backup running or a virus?

1. Not likely as I've never seen anims being expensive.

2. No, since gravity is always trying move the player down anyway.

Yes, since burning shaft makes light between a candle and torch in brightness.

Mod LightValue was actually broken, so fixed and balanced all the LightValues.

Yes, the normal test is how lit your are vs distance, but if you are making light, like holding a torch or a switched on flashlight in hand/head/weapon, then you automatically fail the check.

Yes, 65535 now. It was treated as signed, but now unsigned.