Obsessive Compulsive

Little side note to the devs about the current fps loss. Some of it is due to chunk loading/saving. I noticed your WorldChunkCache class is using resource locks to prevent race conditions but the game itself is not written in a manner to take advantage of multi threading for the most part. Putting locks when accessing the generic data container will not prevent race conditions on the chunks themselves, only the data storage container access. If you are trying to avoid race conditions with the container, then I highly recommend using Concurrent Collections such as ConcurrentDictionary. This avoids the need for locks. It has some limitations but can be used in place of almost all the data collections within the WorldChunkCache class. Things like LinkedList would have to be rewritten to utilize the ToArray method built into the Concurrent Collections. Might be worth checking out because currently you are only locking the data storage to avoid race conditions, not the chunks themselves. The lock is disabled before the chunk is utilized. If a mod or event takes place that alters a chunk, there is still potential for a race condition

Whos yelling? How about I yell since nobody has been prior. LOUD NOISES!!! Its in the Unity instruction manual telling you NOT TO APPLY VELOCITY TO KINEMATIC OBJECTS! For some unknown, brain melted reason, your dev team is not fixing this and have yet to convert to the proper form of movement control. I gave this report to an official tester who already put it in the system for you weeks ago before you went to stable. That was during experimental. Its almost three weeks later, multiple patches and hotfixes came and went without a fix and yet you are acting like its benign or caused by mods. You want a report of how you are doing the opposite of something listed in the Unity instruction manual? Seriously? That error comes from the Unity engine. Spamming the Unity engine with physics errors. I have personally seen it spamming on vanilla servers. It can get stuck triggering dozens of times a second which locks the mainthread in a loop state. Eventually crashing the server. When its not stuck spamming, it fires off every single time you get out of a vehicle. Multiple times depending which vehicle due to multiple rigidbody and having linear based velocities on them, then getting their bool flipped to a kinematic object for absolutely no reason. You are switching a moving entity with a rigidbody to a kinematic object. That is a huge no no in Unity physics engine since 2019. They stopped supporting that and specifically said DONT DO IT around 2022 if my memory recalls correctly. Its on their website. I gave it to you in your bug reports section as well. They gave you an alternative and yet you aren't using it. I am reading your assembly.dll right now. I am really tired of this no mods allowed idea. YOU provided harmony injections as a basis of the game but dont want mods. We are currently reading your programming and telling you its faulty. I can give you sections that dont make any sense in YOUR programming and you want a log showing you a crash without mods? Mods have nothing to do with the base game utilizing the Unity engine improperly. Again.... you are going against the basis of the Unity physics engine. It will not allow linear velocities on kinematic objects. Linear means it doesnt stop immediately. If you switch the object to kinematic and it still has a velocity on it, you will hit physics engine errors. AGAIN... this is in the instruction manual of Unity and how to program a game in the Unity engine. Something you are not following and then asking us for reports on how you are not following the basic instructions of the Unity engine as its spitting an error out telling you what is wrong. I can load unity and cause this fault right now if I wanted to. Spawn a gameobject with a rigidbody and then set kinematic true. Then set a velocity on it. The engine will tell you it cant and guess what error it shows... It has options to move manually while kinematic but it makes no sense to be applied on a vehicle in the first place. Do you really need another report showing you a log with the Unity engine telling you to stop applying velocity to kinematic objects? AGAIN, unity gave you the exact way to run this. Why was this not fixed when you switched your Unity version? You are acting like the mods are changing the kinematic state on the rigidbody of vehicles. Something that should never be done in the first place. I am staring at the EntityVehicle class right now as your programmers are for some bizarre reason, switching the kinematic state over and over. Maybe this isnt clear enough. A turret, something that animates but doesnt change its position can be a kinematic object on the rigidbody. A moving entity/vehicle is not kinematic due to it changing position. If you still wish to achieve movement while kinematic, use the alternative Unity devs instructed us to use which is a manual form of movement control. That is the problem here. You programmed this in a manner Unity told you not to do anymore. How many reports do we need on this? Do we need more links to the Unity developers instructions on this issue? Im being serious. This is getting ridiculous. You spent weeks making us download POIs and bear models over and over and yet you arent even using the physics engine of Unity properly and this is stable now?

If this is still an issue pimps, I highly recommend a follow up check to an inventory change upon placement. Should likely be done for dropped items too. By this I mean, the server receives a netpacket from the client upon dropping an item or placing a vehicle. The server can queue the spawn until it receives the inventory change confirming they dropped the item. If they never receive the inventory net packet, then it doesnt spawn the item or vehicle. This helps prevent duping for both and prevents that annoying dupe players use at server shutdown/restart

Very good. Nobody was complaining. Not even once. I asked whats the deal with the size of hotfixes and curious if they could be reduced, which they answered, vaguely but then you chimed in with this why? What does this have to do with anything? I am a game developer outside of 7 days and have been making mods for it for years. You are talking like this is entirely a new concept. Weird

Loving the patches. Thanks for all your work pimps. One question. What is with the size of the patches? We have downloaded 7 days to die approximately 2 to 3 times this month with just patches alone. I assume more is on their way. You are tagging in hotfixes to the prior patch struct or something weird with steam? We had the original experimental patch at just over 10 gigs, a 'hotfix' around 8 gigs. Then a normal patch around 8 again and now this 6 gig patch which is marked as 'hotfix' again. The base game is 20 gigs so at this rate of patching, we will be downloading 7 days to die 3-5 times in a single month. Any way to ease up on the size of the 'hotfix'. Hard to comprehend a 6 gig hotfix. That is 30% of your entire game

For any pimps reading this... https://docs.unity3d.com/ScriptReference/Rigidbody.MovePosition.html A kinematic body can not have a velocity applied to it. The vehicles are kinematic objects when the player exits them. They can not have a velocity on their body when the clients exit them. You also can not set the velocity manually on the object while in that state. There is an alternative for this provided under Unity as seen at the link. Every time the vehicle manager updates it likely spams the console and log for each vehicle with a velocity stuck on them or being attempted.

That is why I had to switch my mod to the main dir/Mods. Odd since they told us the user data folder would be forced eventually.

Generally speaking a TOS is telling people that the pimps don't endorse you or anyone using their IP for anything they don't give specific permissions to. Does not mean they will act on it or even really care. It is a protection for you and from you as they can't really tell what you intend to use it for. Once they know your intension, well its up to them to enforce what they feel is worth it. Normally with cease and desist letters, then lawsuits. Another tricky part of this TOS is where they state you are allowed to accept donations but the reasons are specific to hosting a server. For the modders that dont host servers, instead they program mods, well this TOS might shut them down since donations had a defined purpose in the TOS. Awkward

This does get a little messy when you get into the realm of custom programming. Using an 'asset' as a library for development of another product, is NOT under copyright of redistribution provided the original product is not what is being sold or distributed and they have provided it without restriction. In this case they provided the tools to modify the original using harmony injections. Injections are normally seen as forced manipulations but in this case, they have provided it. Derivative works is often opinion based. Taking an existing model and changing it slightly is still under copyright unless changing enough. What is enough? Depends where you live. Reusing a base model they provide for you as an example and give you the tools to do it, does not become theirs. That is like saying works made in photoshop are theirs because it uses the core program of photoshop to develop it. In this case, 7 days and the assets are being used like photoshop to create a separate project or work. The assets created by the programmer are not copyrighted through extension. That is a goofy thing for the Pimps to try. They own the original works, not products made using tools they provided. That would be considered entrapment in many countries. Stealing mods under IP grabs will normally get you lawsuits and a third party development that avoids things like official steam workshop. Not really sure why they specified items cant be sold for in game currency either. That means their own traders need to removed from the IP. Whomever wrote this was on drugs

No I wanted to get the optimizer ready as a bit of a portfolio piece before bugging them. I know they took on junior developers and it did not work out too well. My hope is that the work speaks for itself, motioning them to reach out at least or be more accepting if I were to apply. Last I was told when asked is they were not hiring and not interested. I did not go through official channels at the time. I asked one of the devs during a stream if they were hiring. It was a clear no. Timing might have been a bad idea and they didn't want rando viewers applying in droves. They would only want applications with particular skill sets at this stage. They are busy and my project is the last thing on their mind right now. If it becomes quite popular in the community, I am sure they would take more notice but I am not here to impress them in the end. I want to see the game do well and I will use this as a portfolio point regardless wherever I end up applying. I might just start my own game project with some of the passionate devs I have worked with in this community. Lots of talent here if someone were to rustle the right feathers. I think this game has insane capacity if done right. Its the next sandbox minecraft. That would be very different as a long term goal for them but worth it if you were to ask me. To get the most of this engine, they need to use the job system. Recoding this to use the unity job system would require a full overhaul in many cases and more time which I am doubtful they want to spend. Sections can be isolated and improved dramatically with it though. If they focus on some standard runtime profiling, they could orient those particular sections into the unity job system to run it in parallel with all available cores. Unity does most of the hard lifting for them. In honesty, I can see some of the code is oriented to utilize it. Someone had the intent to multi thread various portions. They also have access to the unity math lib and the burst compiler. Both of these in combination with the job system cranks the runtime potential up 3x - 10x faster. I could go on about various things but truly I am still wandering around the code, experimenting, learning. That can be a bit of a problem for lead programmers on projects of this size. They dont want to watch over junior devs at this stage and they dont need me contending with their engineering application. Ten years is very late in a cycle. Maybe I could help them? Maybe I would cause more problems and they can't afford it this late. I imagine they would want to hit a gold state and exit early access before even considering looking at what I am up to. Unfortunately, that is too late to alter the engineering of the game and nobody takes the random comments of some dude on a forum as reason to consider altering their game pattern runtimes. Likely the optimizer will stay as a mod. Kind of the nature of programming games these days. Either way, I am grateful for the opportunity to work on it. Bravo pimps, keep at it!

Thank you for the response Faatal. I made my own pool for testing as well. Not a huge fan of what Unity has. I noticed you had a few pools for things but one in specific stood out as missing so I did some trial and error. Indeed, I prefer to directly change the vectors. I wondered why you sometimes do that and sometimes dont. Makes a lot of sense. Appreciate the info. I did some experiments with transform pooling. You are instantiating them off the entity class when you spawn an entity. I could not get it stable with all of the entity types but falling trees and players were easy to achieve. At the point it instantiates, I had the main thread check for a pooled one, if none exist it ran it like normal but then started a job in the unity job system to pool an extra 25. This cut down the runtime and improved performance when spawning entity. I was able to pool them by their entity class name but ran in to very random crashing, particularly when trying to pool entity like zombies. Some things could not be stored at all such as the transform for falling blocks or snakes and animals. I know the typical thing is to store game objects but in this case, you are instantiating a transform which is slow. Honestly I am not sure on the limits of multi thread safety and unity api calls, even if run through the job system. I tried to store the transform of entity after use instead of destroy the game object/transform. This does work but there are a lot of components attached to the game object within the transform. If you try to reuse the transform, the components will get doubled up from the entity spawn process and zombies with dismemberment become an issue. As a side note I noticed you mentioned wanting to improve game performance to someone else on the forum. I have been working on an optimizer for the game. I have managed to get the players and non players in a dedicated server to update multi threaded for various portions of the game code. Offloaded work from the main thread to improve stability. Improved chunk sync for players. Increased the rate and stability of block collapse. Removed some bloat that was not needed since clients already send certain things to the dedi server. Vehicle response and general movement is smoother. It appears to improve the single player client side performance as well. Tests are just starting on that. Player capacity and zombie capacity are dramatically increased in dedicated servers. Rough numbers so far show 40-60 players and up to 300 zombies at a 60 fps target depending on hardware. If all goes well, I will try and get it out to the public before christmas. Would you have any interest in what I am doing? I dont want to step over my bounds or on any bodies feet.

If I had a few suggestion for the code monkeys on the team, would posting it here take any notice? Is there a better place to mention some stuff about Unity. Not trying to tell you guys what to do, that is your call. Just some suggestions if someone wants to look at it. I will post it anyways and if there is a better home for the post, maybe a mod can shift it or direct me to whom I should speak with? I have been looking through the Assembly-CSharp.dll file for the game and noticed someone has written FindObjectsOfType() in various classes This is known to be very slow for Unity to run. There is an alternative that is faster. GameObject.FindGameObjectsWithTag() My suggestion would be to only use this during game initialization. Avoid it at all costs or use the alternative if you have to. An entity object pool can be setup for the Transforms to handle the spawn and unloading of players, falling trees, falling blocks, items and all other world based entity such as the zombies. I setup one in tests for an optimizer I am working on. You can set limits on the pool size and unity has a built in pool system. UnityEngine.Pools can be referenced inside a class for use. I made my own with a queue and use the entity type as a way to sort the game objects. The one stage of the entity spawn with instantiation went from 0.04 down to 0.004 with the use of the pool so the impact on bloodmoon spawns, sleepers and players joining a server should all benefit tremendously. Falling blocks, falling trees also benefit from it. Even if you dont implement it for all of them, a transform object pool for falling blocks or zombies would make a big difference. It is already done for chunk allocations. This also has the benefit of reduced garbage collection. The last one is a little bit weird. Order of operations. If you have to multiply a few things such as a vector and some floats, placing the floats first in the equation is almost twice as fast. Unity recommends this. Happy Halloween

haha true, I dont know if that is a good or bad thing that Im not making that much. I would never expect to make money from something I distribute for free but that comes full circle to unity. They released this as a free engine. To do this now and to devs in mid production. Plus the wording being some what vague as to whom and why this applies. Its very shady. Like they were just testing the waters to gauge the reaction seeing as they are already changing the approach after a single day While I was just using myself as a vague example of the absurdity to it, I have friends that have produced very popular mods that have made them close to 200k a year so far. Not for 7 days, but rather in another game produced in unity. It doesnt last forever since game popularity dwindles quick. Its amazing the money in gaming if you get lucky. Between the sponsors, advertisers and direct sales, there are insane funds which is why we see these goofy schemes creep up from unity. I hope your project goes well

While the wording of this announcement is directed to developers, it does not state what it will mean for third party developers that also utilize the game engine. Will this extend to those making assets in their shop? Will it affect mod developers? As a modder, I can state we do not package the engine with our work but we still utilize and work within it. We call on the engine to make our code function. This is not only a slippery slope, it feels like an entrapment scheme. They created this out of nothing and nobody was aware they were planning to do it. Who is to say they wont extend this practice to third party developers. When we install and utilize 7 days to die, we agree to a license agreement. This applies to people like myself that develop code with the game, whether that be a mod distributed publicly or something for personal use. I do not charge for my work however the wording of this is based on installation of the game, not the engine itself. While my work is not a game, it extends from the game itself and works within it hence why the user agreement would be binding to this. You can not strip the engine out of the game distribution and start making a new game with it. Just as you can not get unity from my mods. Both of us are backing on to the engine to use functions within in. Will this extend to third party modders and developers at some point? What a can of worms. If they say no now, will they say yes in the future? Would they charge me for each installation of my mod because it utilizes Unity to function? The base game does this too. There is a reason you do not charge for the installation but rather the sale of it. For one, this guarantees there was a monetary transfer of value to someone utilizing the engine to make profits and two, it makes sure that free software and modders are not pushed out of the industry by greedy devs and publishers. Open license agreements will not protect us from things like this, in fact it can implicate us where having no user license agreement becomes our only option and never ever collect donations since that implicates a for profit scheme that Unity wants their cut of for installing it. Imagine every time you have a bug or some missing files and decide to delete and reinstall, I would have to pay Unity as the developer of the mod, not you the user that reinstalled or had a problem from a bad original install. Your power goes out during the install or you hit alt f4 but had the wrong window selected. did a virus corrupt some files making you reinstall? Oops I guess I have to pay Unity for you every time. Gamers can ask for refunds on their games with services like Steam too. That is the logic being done to game devs and possibly third party programmers. Even if they could afford it, I would want to get away from the engine. I legit have no idea if I should produce mods for the engine anymore since this is such a nasty approach they have done. Either they did not think of the total ramifications or they have some very bad intentions for the future. It smells like something EA or activision would do

If I was to guess, little to none. The skill sets required and type of coding used are different. One is c#, the other is c++. I have noticed that some of the team uses c++ since unity allows both to be used from a trick they use at compile time. The designers and art team are used to working with the confines of the unity engine at this point. It would take a lot of work to get all models and assets transferred over and working properly. Months of checking for mesh and model issues along with redoing the animations to work with the unreal animation rig. While it would have some tremendous benefits, they simply dont have the team or skills for it. No offense to the pimps. They are unity devs at this point and the few with skills to work inside unreal cant carry the weight of the team. The good thing is they are working on another title that is rumored to use unreal 5 so they do have some members that could do it, but that would mean pulling them off their new IP to work on converting the game over. Easily a year or two set back. Rust took around a year to convert over if I recall. Maybe they could do it faster but to what end? Unreal charges 5% royalties and how do they know the games interest has not peaked. If they brought something totally new along with the conversion, then maybe but we are coming up to 10 years dev time on this game already. I highly doubt the programmers nor artists want to keep doing this for another three but on a new engine. Unreal forces certain things that Unity does not, meaning entire sections of the game must be recoded to work with the other engine and in doing so, the animations and overall design of the game will likely change. Unreal uses something called blueprints. This is radically different than Unity. Unity in all respects, allows for some of the most advanced design for games IF you know how to take advantage of it by writing your own program to work along side the engine. Unity is great at none shooter things. RPG and open world designs. However it is also limited by forcing you inside of the engine for specific calls and on a main thread OOT game design at least until roughly 2019 when they finally started implementing ECS design. Unity has only added netcode backing back in this year. They stripped it out in 2018 I think. Devs had no proper network code to work with and had to design their own. Some what of a challenging thing and skill in its own right. Things like this are not just alarming, it shows a weird disconnect in unity to what standards need to be offered before charging for installations lol The more I think about it maybe a switch, if at all possible, is actually worth considering. That means they will change the engine to not only spy on you but record your hardware. Outright data harvesting and theft of private information. It would be the only way to implement a hardware based design mixed with some kind of online requirement. Everything about this is bad news. Many users down the road may stop buying unity games just as they hate the smell of Denovo