Jump to content

Obsessive Compulsive

Members
  • Posts

    85
  • Joined

  • Days Won

    2

Obsessive Compulsive last won the day on December 5 2023

Obsessive Compulsive had the most liked content!

2 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Obsessive Compulsive's Achievements

Survivor

Survivor (3/15)

46

Reputation

  1. 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!
  2. 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.
  3. 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
  4. 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
  5. 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
  6. 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
  7. Hiya. Not sure why the optimizer I am producing keeps getting discussed. I have requested the testers be quiet about it and remove all links. That should never have been distributed. Sorry for any confusion on the subject. This forum should remain for discussion of a21. A new topic will be created for the optimizer when it is ready for public distro. Hope you are all enjoying the awesome new alpha
  8. The average cup size in america is a C. This is clearly modeled to match that. The average in Britain is C to a D so it is larger than this. There is an old saying that anything more than a wine glass is a waste. Those are wine glass ta ta. They match her hand size which if you study art development and modelling, is spot on to the average female. Your breast size often develops in line with your hand size. If you are tiny or dont eat any proper fats while you develop, then the body has nothing to put towards breast tissue. This is why highly athletic women do not develop the same. Their body fat is too low and we have women obsessed with looking like boys now, not eating. Its beyond weird. What people are missing is that is a sports bra. The character model actually exemplifies her bust simply by wearing that cut of shirt. Cover up the cleavage and people would not notice. If it upsets you this much, why not stop reading it? Is someone forcing you with tooth picks keeping your eyes open? You can also check the post is a mod or admin and skip through to those, OR, do something else since it is a forum and people are allowed to speak their mind in forums. Strange to demand rules to how people speak. They are still discussing a21 and this is an over flow forum. Pretty sure the point is for people to talk about a21 WITH devs included, not just them speaking to us. They already do that
  9. Thanks for the details. That definitely makes more sense. The 0.01 is the unity update tick rate? Unless I am mistaken. The tick rate of the update phase coming out of the engine is 0.01. Oh you update physics at a different pace. Interesting. Maybe this changed for a21 or a later version? That is great to hear. Fixed update and update phase should definitely be utilized just as you mentioned. I must have misread the code. Currently I am updating it all at one time as that seemed to be how entities were handled. I do not run updates on entities every frame though, I do however run the gmUpdate method every frame and a faster rate. I will have to take another look. It looked like the positions, physics, animations and stats were updating every tick for entities and triggered from the 0.01 unity update phase tick. This update tick triggers the gmUpdate method. Something else may have paced that down to 0.05 as you said. It was a little confusing how it was approached. Some sort of split list approach with entity in particular threw me off. I took over gmUpdate using harmony and isolated the entity update section that triggers from it. I do not run the entity slice and split entity update the way you had it since I was able to utilize that 0.01 unity tick rate more efficiently and it looked like it was more or less to catch up on missed entities due to running too long during the update process. Since I am aiming to keep the tick runtime under 0.01, I can run multiple updates of the entire gmUpdate method within the same time frame of 0.05 that you are currently using. When I allowed the entity to update on every single tick at the 0.01 rate, things were moving around at super sonic speeds. The animations surprisingly keep up until it runs out of ai pathing, then gets stuck running in place. This might be one reason things are getting stuck in game at rare times. High lag and the server failing to keep the path up to date, might get them stuck in place as their animations out pace it. Something out paces the data available for sure, so they run in place at that point. By using a combination of multi thread during certain phases for the player update, I can keep their runtime under 0.01 even with larger player counts. As you stated, you are targeting a 0.05-0.06 time frame window. Since I am aiming for 0.01 as a max runtime per tick, I can split the work across that 0.05 time frame and update specific entities or do specific tasks within each tick, so long as I aim to keep them below that 0.01 runtime which, at least in testing seems to match the update tick from unity that triggers the gmUpdate. In testing, I found I was able to run ten ticks at 0.01 and keep the animation flow to match your current game state, ai was more in tune to player movements and pathing around them, network is updated more frequent so you get less bottlenecking with packet dumps. You have multiple ticks to work with so you can focus on chunk sync to unity which is part of that gmUpdate method and gets a bit heavy with high player counts, but this keeps chunks loading really smooth around players. When I say I run a tick, that means running the gmUpdate method fully, however I am isolating the entity update section of gmUpdate. I run ten ticks at 0.01, total equaling 0.1 time frame approx. Only players update on tick 1 and 6. They update completely, entire list both times. That utilizes multi threading as I phased certain sections like the physics which is mostly in the EntityAlive.OnUpdateLive sections of EntityAlive types. I do this with players to keep a better consistency of the movement that other players see. PvP is dramatically improved but so are the general hitbox responses due to keeping closer in sync. I hope the netcode improvements from a21 will really boost that for us. Exciting! The physics for non alive types are mostly in the Entity.OnUpdate. I update non players single threaded but I divide the work across four ticks so tick 2 3 4 5 are for non players. If there were 100 entity to update, 25 are updated in each tick. Spreading the ai burden. This is why I am thrilled about your updates with AI since the combination with what I am trying out, equals a lot of zombies. I don't see why 400 zombies would not be possible with 100 updated across the four ticks. That should fit inside the runtimes. Tick 7 8 9 10 are for the chunk syncs to unity. When I made it run 12 ticks, I was able to see a momentary stutter in the animation flow of the characters vs the network updates. This was very similar to when high lag and large entity counts will stutter the updates of entity normally. You also start to see a lag in the ai response while moving around the zombies. 10 ticks seems to be the limit which is 0.1 overall so long as I keep my runtimes below 0.01 for each tick. Currently the game runtime is often going well above 0.1 when large player counts or high entity numbers exist, which not only misses your 0.05 runtime rate but starts to bottleneck the netcode with multiple events getting updating at one time on the player side. It starts to look like warping. One other trick I attempted was sector work. Splitting the map to five sectors. Update each sector with a different core handling all the entity of that sector single threaded but simultaneous to each other running their own sectors. Then run the last sector on the main which would be the middle grounds between the sectors. This would avoid physics collisions and overlaps while spreading the work. Only issue there is it does not address bottlenecking within a single sector. It would penalize all of them and so the advantages would be reduced, but typically one core was trying to update all of them, so it has to benefit in some manner. There are two sections if isolated to avoid overlaps, they can be multi threaded. By that I mean running just the Entity.OnUpdate as its own phase and the OnUpdateLive sections as its own phase. It is tricky due to the overrides and how it is coded into the rest of the entity update process, but it can be done. It breaks the OOP pattern though so I know what you mean. You are not going to change the code now and I wouldn't dare suggest you need to. In general, this is not something I would expect you guys to ever do from the whims of some random forum post guy haha. This is your baby, I am just letting you know what I have found in testing so far. If you multi thread these as phases you just need to be cautious of anything spawning, despawning, unloading chunks which in turn unload the entity. Of course double check for race conditions from static lists or anything you might modify while another thread is using the data. You do not want to be running your physics/collision checks and have something change position or despawn. It will crash the engine as I have experienced a lot of. To avoid this while I am updating multi threaded, I make sure the UnloadEntities method from the World class is run inside of the main thread task queue from your thread manager class. I am also running the main thread tasks twice inside of the gmUpdate method that I took over. Once in the original spot you have it placed but another right after the entity update section so that anything I toss at the main thread queue will stay inside the frame time. You guys have a ton of awesome tools and systems that work really well together. A+. Would love to see the job system in action. I am still learning how it functions. Sorry for the long post. I thought it would be best to give better explanations this time
  10. While it is possible, it is another layer of headache. The local player aka local host when self hosting or client while only single player must be updated on the main thread. This is due to some rules in Unity such as mesh changes, chunk syncs, ui alterations and a few other things must be done strictly inside the Unity engine. The main thread is the only thread capable of passing data in and out of the Unity engine. However that means the other players can still be multi thread and get all of the advantages. They should be able to handle a lot more than 8 players if the work load is spread and multi threaded using some phasing techniques. Non players are another beast I am still working on. Some of it can be safely isolated and multi threaded. In particular the entities that are considered alive such as zombies, animals, vehicles, traders. These can all get isolated and multi thread for their physics sections among some other tricks. Non live entity, not so much. The way the game is coded would be very difficult to do that. I really want to avoid anything that alters their form and pattern too much while still getting significant multi thread boosts. I would need to code a version for single player users in particular but I don't see why it could not work. That is something I can look at if people are interested. I am sure you want to see some results first with the dedicated optimizer. It is a little hard to believe it is possible or that the results are as good as stated. All I can say is they are real. You might not see the same level of improvements seen on a dedicated but you will definitely see a dramatic stability increase. Here I am self hosting a dedicated and running a client on the same hardware. This impacts the total potential since the server starts to lose fps when the client is having trouble with hundreds of zombies all at once. Still managed over 200 zombies and a super high fps. This is before client side optimizations and just zombie and players using multi threading. I could not get the zombie stable enough on multi thread yet but this gives an idea of the potential. It is very much plausible to do. I can only get player multi thread stable so far. Once all the hiccups are sorted out I will push it further and see what is possible psst, its a secret. You know me. It is not ready for public release yet. I want to squash some more bugs before making it public. It has run on a few of the biggest american and euro servers on and off the last few months. I had to do some work on ServerTools first but I am back to work on the Optimizer. If you don't remember me, you called me an arm chair developer a few years ago
  11. I think they are doing a great job and have taken on a behemoth task. Probably not a huge consideration early on in the dev cycle but this late, I imagine not using multi thread is hampering the game potential. I would be stripping out things and 'streamlining' as a way to get the fps higher at this point just to fit in content. In reality, its a combination of things. They started this game when Unity was single thread and had no support for multi threading. Unity stopped supporting proper netcode for years and mid development of the game so the Pimps have done a really good job. Bravo Pimps. I hope this can help out in some manner, maybe a small change in the approach of application from the strict OOP. They can keep the pattern but try to adjust it towards phases which would allow multi threading those particular phases as OOP processes. Each core gets a split of the entity list to update and handle on its own for each phase. Differ the work when possible. Utilize the runtime ticks to spread out updates. Not everything needs to be updated every single tick so simple pacers forcing it to only trigger every second or third tick is already 50% less work and retains their current pattern. If it keeps the game flow in tact, then they are really blowing their load a bit as they reprocess things over and over with no real purpose. That is the nature of OOP, so it is not their fault. What I am doing breaks the rules of OOP. It is really hard to use the modern unity features of the engine like the job system since that really should be coded using ECS patterns, not OOP. They have also missed using pooling in some cases. Whenever they can be used, they really should be. What can you do at this stage though? You cant rewrite it all without breaking everything. I know optimization is not their focus but I feel they have missed the boat a little bit. Some of this is not really optimization so much as engineering and coding patterns. Although I am calling this an optimizer since that is what it achieves and does indeed have optimizations for ram reduction, in reality it is borderline an engineerizer lol and using harmony injections to achieve it makes it 10x more difficult. It will be made public once I can sort out some interesting bugs that happen due to multi threading. This post is already too long. Maybe I will write up an entire process of how I did it and the complications along the way. A programmers journey to hell
  12. Ohhh? What I noticed was your animation rate versus physics updates and transforms are all done OOP. This can be spread out to help the runtime load. Making this multi thread is very difficult with the way it is coded however I was able to separate phases for players in specific so far. I took over the gmupdate from the unity update tick and separated some of the work. Specifically the entity update tick. Your thread pool is set too high. Way too high. If most of the game is single threaded, then having a thread pool do that will toss the threads into the pool waiting for work that almost never shows up. This can cause IO handling problems. This is my own opinion but the pool should be slightly larger than the work orientation within the code. If the game is only coded to use 2 cores in general, then 1200 threads in a pool will be an issue. I also like to run work simultaneous along side the main, rather than isolated to only threads. This keeps a better work flow and the data has a better potential to be closer in the data stack when passed off to the other threads by the main which then runs part of the operation. I am isolating the Entity.OnUpdate from the EnityAlive.OnUpdateLive which contains the heaviest calculations. Both can be multi threaded by dividing the work evenly with the players being split among them. If the Entity.OnUpdate runs at the same time as EnityAlive.OnUpdateLive, then the overlaps can cause issues. Isolating them into phases prevent this and I highly recommend it for all of the entity. I run the Entity.OnUpdate phase multi threaded, then the live section multi threaded. There are a few things you have to pull out of this process and run isolated to avoid overlaps with multiple players updated simultaneous. updateCurrentBlockPosAndValue and checkForTeleportOutOfTraderArea. Ideally these would be inside the position update phase. The buffs, inventory, bag, stealth and updateprefab sections need to be isolated, plus those must be done single thread. If some of these can be written for thread safety, it can all go multi thread while keeping your OOP process. This would avoid a total rewrite of the game while getting a giant advantage out of the multi thread. Here is how I mapped the isolation phases Positions > Chunks > Buffs-Inventory-Bag-Stealth-Prefab > Entity.OnUpdate > EntityAlive.OnUpdateLive > One offs that must avoid overlaps like CheckSleeperTriggers 4x 1x 1x 4x 4x 1x 1x = single thread 4x = four threads Not sure if I measured this improper but your runtime with a single player in game on the dedicated servers was around 0.05-0.06 which is honestly atrocious. The unity update tick rate is 0.01. 5 runtimes missed from a single player. I hope I measured it wrong. After taking over the gmupdate and doing some tweaks for dedicated and taking over the entity update phase entirely, I have it down to below 0.01 with one player in game. Actually it was closer to 0.001. I can go into a bunch of other things if you are interested. Due to the runtime you are averaging and how much faster I can run the update, I can run multi runtime ticks in the same time frame, so I split the work across them. It actually was running so fast at first when I left it running every tick, everything was moving around like the flash. Chickens were red blurs. Breaking the chicken sound barrier. Beak neck speeds. Now I am updating across ten ticks. Zombies are in very nice animation flow while keeping their tracking more accurate. I also split them across four ticks. I update the players twice to keep them in better animation, network and update state with others around them. You can reduce the updates across multiple ticks while keeping your OOP but splitting it to phases to allow multi threading too You can also use flat buffers for the entity update phase which helps avoid some of the garbage collection. I did some work on block collapse to make it rapid and look like it crumbles. Chunk sync to unity has four ticks which dramatically helps in with loading large volumes and high player counts. I run the entire gmupdate every tick like normal, it is just the entities update and chunk sync to unity that can be spread out across the ticks/frames Tick 1 and 6 update players. Tick 2 3 4 5 is for non players and single thread for now(Yes it can be multi threaded but more difficult) Tick 7 8 9 10 is for chunk sync to unity. Keep in mind, I do that in 0.1 where the normal game right now is updating one player in 0.05-0.06. I do what I can to keep the runtimes under 0.01 to match the unity tick rate. The closer to that you can keep it, the better the overall fps. We were able to achieve 300 zombies and 70 fps on a high end server with multi threading. There are huge race conditions and overlaps that make non players extremely hard to multi thread. You have a few sections using static lists inside of the class which is the only thing stopping multi thread. To avoid the garbage you need more lists allocated upfront or allocate them at runtime if not worried about the gc. The AI is, well I will be honest its a bit ugly. It must be done single thread currently. I can achieve multi if I alter those static lists, however it hits a duplicate path id error and then spams the console. I suspect it is an issue in the library you guys are using for the pathing algo but I could be wrong. The good thing is its fast. Spreading the work load across more runtime ticks allows the ai to keep up despite being single thread and the changes you guys have made for a21 is a big deal. That single path check instead of eight will help a lot too. I am avoiding touching ai since you guys are updating it but I will let you know if I find anything
  13. Summary: (a short description of the bug) Triggering the twitch event DropHeldItem will spawn a copy of the held item but will not remove the item from the targets inventory Game Version: (A18 b155 / A18.1 bxxx / etc) A20.6(b9) Platform: (Steam / XBL) Steam OS/Version: (Windows / Linux / Mac) Windows CPU Model: (Intel i5 9600K / AMD Ryzen 7 1800x / etc) Ryzen 5 3600 System Memory: (4 GB / 8 GB / 16 GB / etc) 32 GB GPU Model and VRAM: (nVidia GTX 1060 4 GB / AMD RX 580 8 GB / etc) AMD 5500XT Screen Resolution: (width and height) 1920x1080 Video Settings: (Low / Medium / High / Ultra / Custom (Custom has many combinations, so just list the settings you think are relevant to the bug if any)) Custom, mostly medium Game mode: (MP host / MP client / SP / Client on dedi, RWG or NAV) Client on dedi Did you wipe old saves? (Yes/No) No Did you start a new game? (Yes/No) Yes Did you validate your files? (Yes/No) Yes Are you using any mods? (Yes/No) Yes EAC on or off? On Status: NEW Bug Description: I am running the twitch event Drop Held Item on myself which leads to the held item being spawn in front of the character but the held item remains in hand. Detailed steps to reproduce the bug: 1) Run twitch event Drop Held Item on a player 2) Observe the held item being spawned in front of the target but the item remains in the inventory Actual result: (description of what is occurring): I have access to the assembly code and can see that it is coded for a server, not the local client. This is good in the case of spawning the item in to the world but fails to remove the item from client inventory due to calling on EntityAlive instead of the LocalPlayer. Expected result: (what you expect to occur): Running Drop Held Item on a target should spawn the item in to the world as it currently does but also remove the item from their inventory
  14. Worlds will now consist of 80% more water. They needed a niche for the future so they went with water world zombies
×
×
  • Create New...