Grandpa Minion
-
Posts
189 -
Joined
-
Last visited
Content Type
Profiles
Forums
Store
Articles
A20 Bugs
A21 Bugs
Events
Posts posted by Grandpa Minion
-
-
1 hour ago, Roland said:
I just went on North America West and did get several chinese servers intermixed with others but nothing like this.
Looks like a frined of mine is having the same issue over on North American East..
Darksim — 08/10/2023 9:29 PM
"WTF's up with all these Chinese servers???"
Its not hard to see.. go to any region in the server list chinese servers everywhere
1 -
Hello, i was wanting to share some information about a21 and for the life of me do not understand why so many Chinese servers show up in my region list. Is there ANYONE out there who knows why this is? I play on N
orth America West and all i ever see is chinese servers to play on when i try to join.
2 -
2 hours ago, SylenThunder said:
PvP has been disabled on the server for now. It only takes a few @%$#s to ruin it for everyone else.
I dont see how you claim it ruins it for everyone else? That definately doesn't include me or the 100+ people i personally know who was planning on joining to help identify some issues. If anything turning pvp off gave players a reason not to join now. However- I am glad that server is a 32 man server for sure because once you reach 25+ players that is when your going start seeing the zombie freeze, zombie falling in ground and such.
This is not a topic to debate PVP, let's keep it out of here, please.
0 -
1 hour ago, SisterDiscord said:
Respectfully, I gave it a shot. I'm out. Took a few minutes to explore and get to the trader, and before completing the newbie quest to the trader I got murdered by griefers camping the trader to kill people. This is why I don't PVP, or I only PVP where there's low level character protection from it.
I am HAPPY to test anything with PVP off. Love the game. I despise griefer gamers.
hello, just because you where killed at the trader doesn't mean you was camped. There is only a limited amount of traders on a map shared by everyone else... im assuming you went there to do a quest (the same as who ever killed you went there for) First rule of any pvp allowed server is check your back before entering the trader.. gl
0 -
-
A22 i recommend that early release be giving NOT JUST TO STREAMERS but to SERVER MANAGERS and HIGH POPULATION servers. This really does need to go in effect because here we are again...... all the server owners and server managers for the multiplayer scene scrambling on release day to get our servers ready to open.
SERVER MANAGERS WHO SHOULD BE GIVEN PRE RELEASE TO GET THINGS READY
SERVER TOOLS
CSMM
CPM
BOTMAN
RAT
4 -
1 hour ago, Jost Amman said:
And all this, independently of IF the streamer weekend will start on June 9 or June 16.
I really don't believe June 9th is even on the table since diablo 4 is being released on the 6th. From a business stand point wouldnt make much sense to compete against it- especially since alot streamers are going be doing diablo reviews. I agree with you on the 16th for streamer weekend followed by the 19th for release. If what faatal said a bit earlier about them being down to the last of the bug list than yeah my money is on that middle of June for release.
0 -
-
1 hour ago, Stranded_Napkin said:
In the end we all want the same thing: Bandits.....lol. We want more of the game. More enemies.
That is what pvp has been. No way in the world i would have stuck around 20000+ hours if all i did was play pve only. The pve side of it is to easy and gets boring way to fast with no end game or story line to continue on. Pvp players have to worry about everything the pve side has plus the extra threat of others players raiding and killing them. So yes i could definately see the average pve player wanting bandits to give that xtra unknown element.
0 -
1 hour ago, SylenThunder said:
I'm still under 7000 hours though.
7000 in game and 3000 forums hours get you there😀
1 -
8 hours ago, warmer said:
I miss a few things a great deal and I feel that the games environment/mood really suffer from a few key changes.
Thats a definate.. one of the biggest mistakes i believe the pimps ever made was taking calipers out of the game. Back than calipers forced players to travel around the map to search for them. The way it is now players can pretty much stay put in any region to get everything they need. Calipers where great for pvp because players traveled the map alot more creating more chances for pvp.
0 -
17 minutes ago, Maharin said:
And for what it's worth I have 6700+ hours so I guess my opinion isn't quite worth the time I put into this thread.
6700+ is a good enough amount to have seen the good and bad of this game. Going into the future what would you like to see? alot of people talk about bandits and such but from your experience what is the game lacking?
0 -
Hello,
over the years and thousands of hours i have playd this game.. i have personally seen alot of changes good and bad throughout the alphas. Most of which is nearly impossible to explain to new players "nublets" who are joining it for the first time or especially for those who can't understand "why has this game been in alpha so long?" "why this or that?"
I'm starting this post in hopes of players who have actually playd the game for extended time can post meaningfull ideas of how they would like to see this game moving forward instead of the same continous rhetoric. Please feel free if you have playd this game for 10000+ to leave a meaningfull comment on how you would like to see 7d2d progress in the future. For me its all about pvp.. i would like to see the game give more love to pvp players when fixn bugs and exploits- also the optimization to allow bigger servers again.
thanks
0 -
On 4/20/2023 at 2:39 PM, Obsessive Compulsive said:
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 timeThe newest version of the optimizer is running fantastic! I recommend holding off untill at least a21 before you release it to the public. With your optimizer and what the pimps have tweaked im hoping sometime a21 to have a 100 man server on a 10-12k map. Honestly, i never thought it would be possible that anyone would ever be able to figure out how to optimize multicore for this game but you sure have done it. The great thing is that your mod doesn't effect EAC so server
s can still leave that on. I also think once the public gets their hands on it they are going feel the same way.. GREAT JOB!! CHEERS
0 -
5 hours ago, Jetset said:
I really hope the Bandits will come one day. It would be more varied because there are hardly any players left on the open public servers.
A20 almost killed the multiplayer public servers due to horrible optimization it brought - no need to worry about A21 though the good news is a coder has made an optimaztion mod to help multiplayer servers out in every way. Player count is the #1 thing to have on a public server and without the optimaztion mod "hardly any players left on the open public servers" is a phrase i have heard way to often from people in a20.
1 -
On 4/20/2023 at 2:39 PM, Obsessive Compulsive said:
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 timeThank you so much for working on the optimizer... A20 nearly killed multiplayer servers due to the lack of optimazations: while making NAIWAZI alot of money by servers paying for his NON EAC FRIENDLY OPTIMIZER. Your optimizer is EAC friendly and without it there would have been no way our server could have achieved 50+ players on with a respectable fps and cpu usage. I sure hope people and the pimps give you the credit that you deserve.
0 -
3 hours ago, Gamida said:
Any chance to get the discord?
ill message his invite link to you
0 -
39 minutes ago, Gamida said:
Can I ask? If it seems to be working as well as you say, is there any idea when it will be available to the public?
Am sure many out there would love to see how it works and to test it out.
He announced in his discord apr 14th "next project you will see is the stand alone optimizer" so w/e he was working on before that is completed- he can focus mainly on the optimizer now. I'm assuming it wouldnt be long but dont know- Please keep in mind this forum post i started he probably doesn't even know it exists- i initially started the post to bring good news for players going into a21, His discord is public anyone can join it.
0 -
2 hours ago, meganoth said:
Just an idea: One way he could achieve this would be moving calculations to the clients. For example **IF** zombie pathing currently is all done on the server, in his mod each client might do the pathing for the zombies summoned by that clients player.
He tells me daily how it works but im not a coder or modder so everything he says goes in one ear - out the other.. surprised he doesn't get frustrated telling me about it-
simply because i dont understand anything he is doing but what i can tell you is i have been an admin in this game a very long time over the years- w/e he is doing its increasing server FPS, lowering cpu usage, less lag, better overall player experiences for everyone who plays. Using the optimizer the games runs super better than without it. Also with the optimizer we can achieve high player count on the server with EAC on. You probably know as well as i do in a20 multiplayer servers took a big hit for population capability, so for big servers like ours its a blessing for sure.
0 -
1 hour ago, Roland said:
I look forward to the day it goes public. I'll definitely share the info with Alloc once there is a link to be shared. You can send one right now to @Crater Creator by PM and he'll pass it along privately if you can get permission from the creator of the mod. Alloc is the developer that would look at this sort of thing and evaluate its usefulness.
your going love it once you get your hands on it, right now we have 47 players on cpu is only using 16.8%
0 -
On 4/12/2023 at 3:51 AM, Pernicious said:
I wouldn't hold your breath.... I'm not a software dev, but have some knowledge of computer systems architecture and why parallel programming is so difficult and inefficient. There are limited ways you can modify precompiled code to make it more efficient. Some have been tried already - e.g. disabling features or modding out blocks that are computationally expensive.
I'm reading his post in a sing song "I know something you don't know!" Tone, and if such a mod exists, I am expecting it to be just a compilation of those aforementioned techniques.
I have been proven to be too cynical in the past before though, so I may be pleasantly surprised.
here is an example of the optimizer working today apr 15th today our server with 42 players on, 57 zombies and 50 animals the server fps is 42.5- our server is lucky the coder allows us to use it during its creation. 100% works and with it being updated all the time its only going get better going in a21
0 -
-
On 4/12/2023 at 6:57 AM, Gamida said:
Hypothetically speaking, if a mod like this did exist would it work on SP games also.
I have only seen it mentioned having to do with multiplayer servers.
hello, i can assure you the mod does exist. It also will work on SP since it makes the game run on multiple cores doesnt matter if your on single player or multiplayer. Also im currently running the mod on [NAPVP] NORTH AMERICA PVP server if you want to see it in action just join. The mod has allowed us to have 100+ max zombies with over 50+ player online with high fps and no issues. As i said earlier the mod is still being worked on by the coder once its done he has told me he plans to release it to public AND YES ITS EAC COMPATIBLE people wont have t
o turn eac off for it to work.
0 -
Thank you pimps! its really nice to know MY BLESSING was accetpted!
god bless!
1
s can still leave that on. I also think once the public gets their hands on it they are going feel the same way.. GREAT JOB!! CHEERS
Alpha 21 Dev Diary
in News & Announcements
Posted
During the time 7d2d has been in alpha i have personally known players, modders who have past away... Odds are alot of people have known someone who playd this game over the last 10 years who isn't with us now. I think your question is very acceptable and brings up another question how much longer is this going delay the game going gold? Odds say we all well know more people who pass before this game goes gold.