Gijs-Jan

Most of the current high-CPU usage (when everything is "idling") is coming from the dynamic batching that Unity is doing as most meshes haven't been statically batched. Given that we're in a destructible environment that's rather hard to do and we want to wait until late in development where we better know which usecases we can easily batch, and which ones we cannot. Having said that - High CPU temperature is mostly because the machine is simply using what's asked from it. I can "optimize" the game (to give more FPS), but I'll always ask the hardware to give it's fullest potential. In a game you tend not to want to leave performance on the table... A framelimiter does mitigate this if FPS is high enough for you and I'll add it as a task for the settings screen for Chris to review.

Can you maybe provide a screenshot of what you mean? I'm having a bit of a hard time following what you mean by "go run back out of cover to get around them the long way".

While I appreciate trying to help in the issue, the problem is most definitely in the code and is an issue we should fix. To be clear, doing the above will not fix the issue and I do not recommend it for this issue. :-)

The error is popping up in the interaction between logic and animation - a pretty notorious (in it's instability) section of Unity's API. That specific code is not multi-threaded (90% of our core logic is single-threaded, only the FOW calculations run off-thread and they are isolated). We have been able to replicate the issue once or twice (in the past two years) on build, every time adding new logging and getting a new piece of the puzzle. If there is anything unique about your setup I suspect it might be in how you issue orders.

You seem to have a knack for finding this specific bug somehow, as it's not popping up from anyone else. And to top it all off, I need to add in specific logging because the crash itself doesn't make much sense! Having said all that, keep the Q/A coming, and thanks for all your hard work!

Thank you for the detailed write up, I managed to perfectly replicate it and find the issue. It should get in in the next patch.

Yeah, he's away on a short holiday (he needs one!). I've added it to the morning review on Monday so it won't get forgotten.

Thanks for trying out the build on Linux! I suspect issues, if any, are mostly in Ground Combat with regards to shaders. Feel free to report any issues in either this thread, so we can collate them, or through the F12 bug report but make sure to mention you run on Linux for custom bug reports. Having said that officially we won't support a Linux build at this moment. Unofficially I'll keep an eye on this thread and those reports.

Got it in the issue tracker as well, looks to be a bug in the auto-dropping of items to the floor.

Aw man, I already lost so much sleep the past few weeks :'-( Kidding, we're glued to the issue tracker at the moment and patching what we can!

Out of curiosity, how does it slow things down?

There are a lot of different things contributing to this issue, and it also depends on what type of rendering setup you are using (forward/deferred, lightmapped / realtime etc). One of the big underlying causes is that Unity doesn't really deal well with dynamic environments where there are a lot of non-static GO's. This in particular starts to break down when certain rendering paths don't properly support batching. The end result is that the CPU spends a lot of time creating dynamic batches that are straight up ignored and cause individual render calls in parts of the render pipeline (stalling the GPU). The solution we've tried inhouse is to manually combine meshes and objects for those parts of the level that are indestructible after the scene loads, which already gives a mighty speed boost and solves both above issues. The other issue is that Unity simply doesn't like runtime combining of scenes with lightmaps, which is making completely randomized maps quite a pain to implement. I want to assure everyone that we know the issue, and we've been testing solutions to this throughout development and I'm confident that we can get orders of magnitudes of improvement in FPS. We simply haven't implemented those solutions as they would slow down the work being done on nailing down the level design workflow.

Lot of assumptions there! Adding in multi-tile pathfinding will definitely require a bit of extra code. I'm not saying it's impossible, but it'll definitely require some work. This is mostly because Chris wants to avoid the various issues that multi-tile units introduce.

@Skitso To be honest, I'd refrain from blaming anything on your end before I really start on the optimizations! And when I do and you still have issue, and you have the time, we can probably take a look at what specifically it is on your machine that might be bottlenecking it. :-)

It's definitely planned. Hmm, interesting. I wouldn't expect such a hard drop-off, especially with your hardware (I've got a 1070 here as well). And you're right in that the Simple to Fast is the point where all dynamic lights get shut off. Suspect it's the shadow handling then, which is also tied to the lightmaps. Earlier you mentioned that there wasn't any AA btw; the whole reason we're still using forward rendering at the moment is for AA, and it should be enabled upper tiers.