faatal

They are only going to get so dumb. You build small bases and you limit their choices. Build bigger bases and since distance is a path expense, they will tend to not go the long way. One solution is just adding some totally stupid filler zombies.

Ha ha. I don't care for traders. Makes the game too easy. I pretty much just use them to sell junk to and buy books. Do the occasional quest. I want a survival experience, not a social one.

Trader stock would be a good setting. I'd go 10%, but when you have hundreds of things to do, features like that will often not happen or sometimes team members will object to a feature and it does not happen.

Is possible. Added to todo list.

They do still look for long paths, but they use reduced block health precision and may quit on the paths, based on intelligence, and do destroy area instead.

I don't see any news stands. We have this newspaper dispenser.

Yes, it was a console command for 100% dismemberment.

It is far from being done. It was not planned as an A20 feature, but looks like it will be in A20 for some amount of zombies. There will be a lot more tweaking as Steve and Ryan (artist) work on it and changes can continue through experimental and into A20 point releases.

Four programmers will be discussing their work.

I will be talking about optimizations, terrain, weather, AI, vehicles and block placement stability.

Should be fun!

We have a consultant graphics programmer who is doing benchmarks and has a second PC with low specs.

I dug up my 4th old dev PC (i7 860) and have it running now, but it only has 4 GB RAM and an AMD 1 GB VRAM GPU. It will run the game on lower settings, but is very slow for testing as it hits the hard drive a lot (paging) during loading and shutdown and I could not run Unity at the same time. My wife's old PC has 8 GB RAM, which should work in that motherboard, so planning on trying that RAM.

The problem with benchmarks is they tell you where you are at and maybe what is slow, but not how to fix it. Fixing is the hard part.

Cores beyond 2 will only partially be used because other than the main thread and graphics thread, everything else is tasks that do not need to be done every frame. Like the new collision mesh baking thread. It only needs to bake when a chunk loads or is changed (damage, block added/removed). The fact that it can run on another core means that when it is running, it will not steal time from the main thread, which would decrease FPS.

SI is basically the same. I think we increased wood to better match the others, but seems done.

Mostly bugs. Currently short grass mesh improvements and fixing normals that today I noticed were wrong.

Something can be done with hours/days/weeks of work. Not spending any time on it for A20 or maybe at all. We have plenty to do already to get the game gold.

It is planned to be stream #6 on Oct 13th.

I can't give you exact answers, since PC specs vary so much. It should have similar performance. The worse case currently is in the downtown of the new RWG cities, but they are working on a point system to help keep too many high resource POIs from being together.

The game will use around 6 cores, but cores are not used equally because there are many different workloads being run. Many tasks have to be done on the main thread in Unity, which consistently takes the most amount of time per frame. The same with the graphics thread. Beyond that, other threaded tasks like mesh creation, collision mesh baking and AI pathing are on demand as needed. I have a 12 core CPU, but it certainly does not need or use all of those cores. Extra cores are nice to have, since the OS and other programs can run without using cores the game is using.

1 Or set it based on terrain quality

2 No. I plan to remove the weapon camera someday (a21?). This is overhead that we can do without, since clipping can be done in the shader. FOV is an issue that needs to be resolved, which is why I have not done it yet.

The feature does nothing with what sounds like a bug.

No plans for bullet holes.

He seemed to be joking. Either way, not happening.

It was already done like that. My opinion came after. That is how development goes. People do things. Others make comments. Sometimes things change. Round and round it goes. I often do things without input because I think it will be cool, then sometimes you have to go back and refine it from other's opinions.

It will be the same as the past experimentals. They will probably load, but not recommended. Often people will get bugs using previous versions as we adjust data throughout the experimental period.

I have pointed this out. The more distinctive they make then, the more repetitive it looks. I see 5 soldiers and they all somehow died the same? Having special characteristics be optional would be a good place to get to.

Sure, I can always see it.

555 555

500 500

555 555

005 005

555 555

When switching to exclusive mode, wait 10 frames and check if Screen width/height what you wanted. If not then switch back to the res you wanted in windowed mode, so the user can try again.

Possibly later. I don't know that we have the time before A20 experimental to upgrade and test it.

Probably Oct 6.

I increased the clamp by 5 degrees. That should help and still looks fine.

Why not use names instead of index? The names may not be that consistent either.
Maybe tags? (Actually I added a E_BP_EYE tag on those last week).

What about LODs? They have multiple GameObjects for those, so if 0 they would be 0,1,2 or 0,1,2,3, since LODs vary in count.

Yes. Zombies ducking down so they don't hit their head and get stuck on blocks.

No changes there. Sounds like polish for later.........