Cr0wst0rm

No, I was just curious about the comments. It seems there are already very mixed opinions on the twitter page, so I guess that explains the reasoning behind it...

Why the comments are turned off? Are you afraid of negative reception?

Im curious how such vulture is going to hold itself in the air with so few feathers.... lol

I havent modded 7days to die but other unity games, but basically you want to include all the code for that api in unitypackage which you then import as a mod. So you need to put in that api

You could add this api on a mod level.... Either way, they will never do this. And it wouldn't even make sense tbf.

As I said before, thread the living *profanity* out of the game, I see no other way of making it work. Slicing technique is not a good way of optimization if you end up slicing too big portion of them anyways....

And that is the point, if you have time complexity of O^2, no system will handle such workload effectively. That is why threading should be used more. Because there are cases where you just cannot optimize the game because of the impact on the outcome, so you should offload it to other threads which are not required to come in time with game thread. -Will the pathfinding be done later? That is fine, now i have to render, so give me the data after you finish the pathfinding process and I will do my part. We are no longer in 1998 where systems had just 1 core for processing. Argument that you should buy better HW is just invalid. Every game uses threads. (UEBS 2 is one nice example) And I agree, while Unity is very constrained when it comes to threading (various different safety checks), it still allows data manipulation. The concepts are same. You should access data only once at a time. For example in Unreal you cannot update transformation from non game threads as this is for rendering security. The general concept is that you "manipulate the data" on thread, then you "consume" it from gamethread.

I don't remember claiming this issue is bound to the gpu, but point taken. I think it is fair to post it here since it is related to the development of the game, and I prefer stronger exposure. If you wish to delete my posts, feel free to do so. Right now all I can do is sit and watch, I am curious how the situation is going to unfold... I can post some info in proper channels in case it will not break the EULA and put me under a lawsuit. And yes, i know there are places where multithreading cannot be used, but still there are places where it can. But I guess with such statements we could go circles in and out, so I digress.

This is not a question, this is a statement. I have substantial proof from the researched game source that there are infact places which make absolutely no sense (for example drowning buff checks on zombies in the game update loop etc) Now with the respect to the devs, there were already attempts to optimize the performance (TickEntitiesSlice), however, this approach will eventually fail (because you still have to eventually process all the entities on the game thread) You could also try to even lower the workload so you would slice limited number of entities (5 entities frame 1, 5 other frame 2) This will, however, worsen the visual output. Relying on gamethread only is just not feasible. And this is why threading should be used. Buying a new CPU just because it has 2 more GHz just so it catches up to the terribly optimized gamethread is just not a solution, but an excuse. There are also places which are not dependant on the game framerate (for example camera movement is framerate dependant, management of environmental events such as AI perception is NOT) So what I would like to conclude is that the developers/moderators should NOT tell their players to "buzz off and buy better hardware" when you can very easily utilize the already used hardware which supports multithreading.

Yes, the performance is really bad, even on minimum settings, so it has to be the game code at fault (whether it is physics/pathing) but definitely not rendering performance, I highly doubt that, considering i have lowest rendering settings and RTX with 16 gigs

Are there any performance options in Unity Engine for skeletal meshes? Is this bound to physics/rendering? In unreal we use frame slicing for our entities based on their distance, maybe this could be used too? I myself have a fairly beefy pc but the AIs lag so bad even on RTX with 16 gigs (on 64 horde max)... I would say this is more of physics/game logic related rather than the rendering itself? Like... how much of this stuff is routed through tick managers/separate threads? Do AIs share pathing data (I partially think they do, but that is just a quess) Were there any tests done with higher numbers of entities? I would honestly put this as my #1 priority because the gameplay becomes just horribly bad when it comes to massive hordes and it really breaks the immersion for me For example days gone handles this great way, you can have hundreds of them attack you. I mean there is no landscape deformation, the AIs mich have bit simplified collisions/lower freq physics but you have to take into account that the collision cooking in unity is not as bad as it is in unreal engine, so i think with block/landscape changes it should still yield fairly acceptable results.

I mean as long as the game generates enough financial stream to allow developers finish the bandits properly, I'd say it's existence is justified. I am just a bit worried about them steering their focus away and not delivering them at all. But then who knows, right?

So If I understand the bandits are implemented in a correct modular way and not 1 model = 1 bandit like the zombies, right?

Why no tunnels?

This has been issue for a VERY long time. Some animations not reflecting pitch of the player's aim in multiplayer etc etc. Hopefully we will also get proper animal foot IK, moving of entities on steep surfaces is very terrible in this game.