I’ve previously covered fixing Valheim’s dedicated server lag by modifying the dedicated server’s send receive limits. Since I wrote that article not long after launch though the game has been updated that the old method no longer applies. I had theorized in the comments of that article how to address this and today Sam R. confirmed that this method did indeed alleviate most congestion on the server in the places that the send/receive limits are known to bottleneck.
This updated guide will show some updated methods you can use to help reduce lag on your Valheim dedicated server!
Symptoms of lag on Valheim dedicated servers
The symptoms you are experiencing on the server can help narrow down what type of lag you are experiencing and what may be causing it. Lag caused by your CPU being too overloaded for example will have different symptoms than lag that is caused by your server hitting the maximum send/receive limit as an example.
By far the most common type of dedicated server lag seen in the early access Valheim release so far has been mainly due to the low send/receive limit if 64KB/s that is hard coded into the server. This means that when you do something like take your character a heavily populated area on the server it has to send all that information about all the buildings/players through an artificially limited very narrow 64KB/s pipe.
Symptoms of the send/receive limit type of lag include things like chests taking a very long time to open, sometimes 10-30 seconds or never opening while at the same time being able to see players walking around normally. This is because the other people’s X / Y / Z positions is a very small amount of data compared to all the items/names/attributes that are stored in the chest. The other players moving easily fits through the narrow pipe while the chest full of loot’s data chokes since it is much larger.
I’ll specifically lay out how to modify your server and increase this limit in the “Modifying your server’s send/receive limit” section below. Before that though let’s cover a more specific type of lag to watch out for (mostly by being avoided) related to terrain manipulation.
Avoid extensive terrain manipulation (for now)
Another commonly observed source of lag has to do with terrain manipulation. Some players have found that if they take a big chunk out of the ground in Valheim and make extensive terrain modifications that the area gets filled with separate “instances” of terrain for each modification people make. Think of the original ground as one big piece in the game files. Valheim has the very cool feature of letting you modify terrain by raising it/lower it/level it/etc. Each time you do this though the game has to store what you did as a new “instance” or a modification.
The way Valheim seems to work now is it renders that original piece and then the modifications afterward. Early reports suggest having a whole bunch of them in one spot seems to sometimes cause everyone’s in-game FPS on the server to drop as low as 40 when the clients normally are much much higher than that.
The best way to avoid this type of lag at the moment is to limit how much terrain modification you are doing in areas near your base. It is likely this will be addressed/eased in future patches. There should be some things the developer team can do to clean up/merge these instances or at least reduce their effect on the rendering process so it doesn’t drop the in-game FPS so dramatically.
Modifying your server’s send/receive limit
At this time there is no options file for Valheim unfortunately. The only way to change it is to modify the server’s code and recompile the module that controls this.
Fortunately this is a lot easier than it sounds because the module we need to change is in .NET instead of something like C++ which would be much more difficult to do this with. I did not come up with this method, a very clever user on reddit (maximgame) shared it here and I want to give credit where credit is due!
Despite it not being too difficult these modifications are at your own risk. I haven’t experienced any problems so far but technically we are modifying the server’s code with the following procedure so understand that this isn’t an officially supported method and could have side effects or if you make a mistake could cause serious problems. Make sure you have backed up everything (your game world files especially) before you try anything!
Another important note is that it’s very likely you will have to make the changes again each update since the file we are going to modify is going to get replaced by updates. Until they add either a launch option or options file to officially change/control this property that is unfortunately unavoidable.
With all that being said if you understand the above and still feel comfortable let’s proceed!
Get dnSpy utility
We are going to use the utility dnSpy to modify the server code and recompile the module. The utility is free and is available here (download the Win64 build or dnSpy-net-win64.zip): GitHub dnSpy Official Page
Extract the archive and run the program dnSpy.exe from inside the folder you extracted. The dnSpy application will open.
Modifying server with dnSpy
We are going to go to the “File” menu in the top left and choose “Open” like this:
Now you need to navigate to the Valheim dedicated server folder which is located in your “steamapps” folder. If you left all the options default when you installed it’s typically “C:\Program Files (x86)\Steam\steamapps\common\Valheim dedicated server\valheim_server_Data\Managed”.
We are looking for the file “assembly_valheim.dll” in that folder:
Select the file “assembly_valheim.dll” and click “Open” and the server’s assembly will load into dnSpy.
Once it has finished loading we are going to go to the “Edit” menu and click “Search Assemblies” like this:
For the search criteria enter “ZDOMan” like this:
After the search completes you should see a list of results like the one above. Double click on one of these entries on the list and it should place you in the ZDOMan section of the assembly (seen on the left hand side of the screen):
Perfect. We are now in the right place to make the changes. We just need to locate the line that has the send/receive limitation. To find that press Ctrl+F to bring up the find box (or choose “Edit” -> Find from the menu) and search for:
sendQueueSize
which should bring up the following lines:
If you are having trouble finding the lines make sure you’re using Ctrl+F to search this time and not the “Search Assemblies” from earlier at the bottom of the screenshot, that’s a different type of search. Make sure you’ve disabled the case sensitive options (the Aa right below the box) or any other search filters. Your search query box should be in the top right of the screen like the above screenshot that has sendQueueSize in it.
Now right click on this line:
int num = 10240 - sendQueueSize
and click “Edit Class (C#)…”. Another window will open that will let you make changes to the file. We are going to modify ‘10240’ to a variable of our choosing. I made mine 30720 since after doing some conversion math that is the equivalent increase from my previous launch version guide that provided great performance and I kept them the same. If you followed my last guide this will give you the exact same performance as the old one did.
There are two instances of this variable. The second instance is 3 lines above the highlighted line we searched for and is:
if (!flush && sendQueueSize > 10240)
Modify both instances of 10240 to 30720.
Theoretically setting a limit too high could cause the server to swamp your internet connection if you have a large number of players on and there’s essentially no limit but there shouldn’t be any other effects of a very high number.
Once you’ve changed both numbers to the desired value we need to press the “Compile” button in the bottom right corner of this new window. This window will close and take you back to the previous one.
Saving the new assembly
It’s time to save our changes into a new .dll file. Choose “File” -> “Save Module…”:
Change the file name to assembly_valheim_modded.dll. Don’t overwrite the original file just yet as we will want to take a backup and make sure that the server is closed before we do that. Press “OK” to write the new assembly_valheim_modded.dll file.
Backing up original file and replacing with our new one
Now it’s time to back up the original file and replace it with our new modded file. First make sure your dedicated server is closed otherwise the dll file will be in use. It is also a good time to make a backup of your world file just in case (see my Valheim Dedicated Server Backup Location / Guide for instructions)
Navigate in a file explorer window to your Valheim server directory where we saved the new assembly file (usually C:\Program Files (x86)\Steam\steamapps\common\Valheim dedicated server\valheim_server_Data\Managed).
First make a copy of the original assembly_valheim.dll file. You can just select the file and “copy” then paste a copy of it in that same folder and Windows will make a “valheim_assembly Copy(1).dll” file for you or you can back it up to a separate folder. Now remove the original file and rename your “valheim_assembly_modded.dll” file to the original file name of “valheim_assembly.dll”.
That’s it, you’ve now replaced the old assembly with the new one! Go ahead and start your server normally and the changes will have taken effect.
Other Resources
Make sure you are taking constant backups of your Valheim dedicated server: Backup Valheim Dedicated Server – World Folder Paths / Guide
It’s also important to back up your local game’s characters and local worlds if you are using them. I have written a guide for the local game side that is available here!
For historical reasons I’ve left up the post with the old method here as it helped me devise the new method: Fixing Valheim’s dedicated server lag by modifying the dedicated server’s send receive limits
Other Valheim Lag Issues
If you know of other Valheim lag issues that I didn’t cover here or are still having problems let me know in the comments and I will update this guide with other tips/tricks and try to answer any questions. It’s still a very new game and there isn’t very much out there for it yet. Have fun and enjoy!
Greetings and thank you for your great contribution.
I was wondering if this modification needs to be done by everyone or just the one hosting the server (I’m hsoting it on “Start Server” via the ingame menu, not dedicated)
Hey Ysulyan,
Thanks for the kind words and welcome! From a lot of experimentation over time basically the findings are that 90% of the benefits of this modification are basically realized when the person hosting the server does it. The other clients doing the modification outlined in the article doesn’t seem to have a lot of benefit.
There is a way to go further that has been extensively discussed in the comments here that involves changing all of the clients if you find that you need more. This is the “extreme” version of the mod but it is successful for extreme situations and we have several successful confirmations. It involves literally changing the send/receive buffer size for the server and *all* clients.
This isn’t a hard modification to make if you choose to try it but distributing it to everyone makes it a little more annoying for sure. It also has to be done every single update (for every person) no matter how small the update was (even a bugfix will change the main Valheim .dll since the versioning will go up when they build a new copy as well as other changes).
My suggestion would always be to try the change covered in the article first just for the person hosting the server. If you find that you’re still having trouble (and your symptoms match some of the other ones outlined here by others indicating it’s really this issue and not your connection/server hardware) the additional mod is available here as well. That one needs to be done on all clients but is not usually necessary unless you’re running 50+ mods or running full 8 man non-stop boss battles all the time or a few other situations like that.
The extreme version of the mod was posted by (now legendary) patk here in this comment (which I’ll link to here since I expect it will continue to get buried over time).
It’s slightly trickier than the original mod (you end up adding a couple of lines) but if you were able to do the first one then you should be able to do this one as well. Just remember they all need to match (client and server, patk covers this in a followup reply to the post I linked to so read all of it if you try it). Everyone else has been able to follow in his footsteps so far that wanted to try it.
Hopefully that helps!
a follow up question there, will this only work if i run a dedicated server through steam library or do these changes also work if i host the game for a friend and me via the in game (inside valheim) option to launch a server. i wonder if there is a different file/folder for this, as i just make my single player world a “server” via the ingame option.
Hey Teds,
Welcome back! They will also work but you need to change assembly_valheim.dll for the client and not the server for it to be effective. You probably don’t even have the dedicated server installed if you’ve been hosting in game so you may not have much to worry about with this piece but I wanted to mention it just in case.
Otherwise yes it will work!
hey, so far this pushed our limit up to 150 kb/s and it works fine, we play with epic loot and even with 2 of us the desync started to kick in after 60 odd hours. i will test this in the comming days a bit more and give you further feedback. thank you for this!
Hey Teds,
Excellent work, I’m glad to hear it! Definitely stop by and let us know how things shake out but that sounds like a great start!
I’m just dropping by in case someone has the same issues like me. I couldn’t compile after entering the new values. Someone else in the comments already said that the issue was, that the file needed to be in the “home” folder, and not isolated somewhere else. Since i have a nitrado server, i can’t just go in there with dnSpy, so i downloaded all the files out of the “managed” folder via ftp. I was able to edit the file and then reuploaded it. The server still runs, i can’t test the fix tho until weekend. So if you got a rented server and can’t directly use dnSpy on it, this seems to be working. Cheers and thx for the fix!
Hey max,
Thanks for leaving this! I do recall this happening to some others who had a slightly different situation (which it sounds like you saw some of those comments too). Those comments have to be getting buried deeper down there though at this point and none of them had your exact situation.
This is absolutely the secret. There are platform specific differences between the files. If you download the files from the original platform over FTP *before* changing them you will avoid this issue. If you try to use the ones on your local system (let’s say Windows, at least historically it has been) and then upload them to a different platform (often Linux for servers) it won’t work basically because the files aren’t the same.
Definitely let us know if you can confirm it this weekend, but I think you did it and bet this comment will help some others as well!
I was wondering if someone could show a way to increase the rarity of items in epicloot? The items are WAY to common. If someone has a solution, that’d be awesome.
look for the file “loottables.json”, you will then need to modify the drop chances for each tier of mob.
The syntax is a bit tricky, for example:
[0, 90], [1. 5], [2, 5]
Means:
90% chance of no drops
5% chance of 1 drop
5% chance of 2 drops
I have been playing around with the config myself because I don’t like how common the drops are either, I am trying to make the overall drop rate quiet rare and having a fixed chance of quality if you do manage to get a drop. The original settings have the higher tier items have a greater chance of being better quality which is a bit lopsided given they are better base items.
Just dropping my two cents here – tried the change above and the one from Patk88 that people have mentioned worked for them, and all that resulted for everyone were constant disconnects with an “Assertion Failed: Message size XXXXXX is too big. Max is 524588.” It was usually within ~5k, but I couldn’t find any way to prevent those spam disconnects (I tried adjusting the parameters several ways – higher or lower values on both client and server, and differing the client vs. server values, and all lead to the same path).
Curiously, I also had one disconnect with that error after I reverted back to the original .dll, though the next four attempts worked totally fine. I’m a bit stumped and surprised at how well it’s going for others, relatively speaking.
Did you modify the assembly_valheim.dll on both the server AND all clients? What, specifically, did you change?
I modified the file on both the dedicated server and the clients (I gave everyone the updated library, but it also happened when I was logged in solo).
I adjusted both the SendZDOs function as outlined in the original article (I had done this before on its own when this article first showed up and it hadn’t resolved our issues – at the time I didn’t realize Epic Loot was pushing obnoxious amounts of traffic and was essentially the culprit for our issues) and the RegisterGlobalCallbacks function as discussed here in the comments. I changed the values to those described as working, and then experimented with different permutations.
Ultimately we’re playing H&H vanilla w/ a handful of mods and have had no issues with ten people in the same area, so as long as I don’t throw Epic Loot back in while that issue persists, we’ll probably be fine.
Hi Keirsti,
I have performed these modifications again for H&H running epic loot and other mods and it is working as it was before the update.
So a couple of things may have happened which you may need to check:
1:) Before you opened each of the assembly_valheim.dll files did you make sure select ‘close all’, I mention this because if you don’t you could be searching in the same dll file when you move to the next one which means you may have only modified one of the files.
2:) The server and client dlls are slightly different, you can’t use them interchangeably so make sure this isn’t something you have accidentally done.
3:) There are two ZSteamSocket classes that contain ‘RegisterGlobalCallbacks’ make sure you are editing the correct one.
Hi patk88,
1) The client and server are located on two different PCs and I was running dnSpy locally on each device, so no concerns there.
2) See 1.
3) I can only see one ZSteamSocket class, unless I’m losing my mind. There’s also a ZSteamSocketOLD, but that’s not ZSteamSocket. 😉
We’re now hosting the server on another provider, so I can try it on my server again at some point and see what’s happening I suppose.
Hmmm, I’ve done this as well as Patk88’s suggestions and it seems to have helped with the desync, but we’re noticing an odd issue where certain assets aren’t loading in for everyone, specifically we’ve noticed the Portals and the Spawn Stones. Once everyone leaves the area except the person that can’t see the stuff, those things will pop into view for them. Then we can come back and it remains visible for everyone. For example, I was at the spawn stones and a friend loaded in. He could not see the spawn stones and on my screen, he seemed to be clipping through the ground. However, once I logged out, everything appeared and when I logged back in, I couldn’t see the stones. That being said, once whoever could see the assets left the area, it would pop into existence for the person that couldn’t see it, and if that person returned, it remained visible for everyone. We’re also having problems with the Anyportal mod that we weren’t having before. It almost seems like isn’t remembering our portal locations correctly. If someone goes to the portal and uses it, it will pop up, but eventuslly it’s like it ‘forgets’. I’m not sure if it’s a mod conflict or because of the changes. It’s the darndest thing.
Have you done this for both the server and the client dlls? Make sure before you close dnspy you choose File Menu -> Close all, as you may have only modified one of the files.
What is the receive rate from the server when this is happening, it sounds to me like the server send rate is still capped.
I do sometimes have issues with some portals not connected and can be fixed by clearing the portal tag and entering it again…. I don’t believe this is related to these changes however.
AnyPortals bug reports and the posts on NexusMods seem to indicate this might be a problem with AnyPortals on a dedicated server. I’ve used Dnspy to check the valheim_assembly.dll files and it appears they’re both changed, with sendQueueSize at 30720 and the gchandle3 at 524288. We’re having no lag issues itself and our data received can and has gone above 150k on the server. That being said, I didn’t clsoe all windows after modifying the files. I went to the file, right click open with DNspy, then I made the changes, compiled, and saved the module. I may try doing it again from scratch.
Further edit: Removing AnyPortals also seems to have fixed the disappearing portals as well.
Before I modded the valheim_assembly.dll file I did see an issue with the AnyPortals mod with failure to connect. I am not sure where this data for the dropdown is stored but it acted like it lost the info. After completely removing and adding it back in on the server and all the clients it started again like nothing ever happened. It was the oddest bug. Also just FYI, Anyportals allows portals with longer names and they fail without anyportals in if you have portals with longer than standard names. This seems to be an issue with anyportals and not linked to these changes with the valheim_assembly.dll file.
We’ve changed the .dll files and fixed alot of the lag, we got so far into the game with mods now installed and now we’ve come into another problem. For some reason whenever we go into the plains biome it won’t load for the second player has anyone experienced this as well? Thanks!
I tried James and Patch88’s method, they work well when my server has 8-10 people in one area and my server has 55 Mods used. It is a great solution.
But it causes two other disadvantages of losing equipment and weapons when put in IronGate’s iron chest. My solution is to use Mod BuilIT which will have other chests that are more useful than this one.
And the second damage is to affect the terrain of Midgard, causing them to bulge or lose trees and houses. But they can be overcome by you have to go to another area and come back there to let it load slowly and ask that the area has no weak network users in it. It also only affects 1 area as above.
Excellent results, thank you for leaving this! I hadn’t heard a lot of feedback about this mod since the initial report and had almost written it off but now we have several accounts saying that this did indeed have a positive impact. Thanks again!