Revisiting Fixing Valheim Lag – Modifying Send/Receive Limits
Published: June 15, 2021 / Last Modified: December 3, 2023 / Gaming / 232 Comments
My Valheim Dedicated Server Castle
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.
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:
dnSpy – File -> Open Menu
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:
dnSpy – Selecting Valheim server assembly file
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:
dnSpy – Search Assemblies
For the search criteria enter “ZDOMan” like this:
dnSpy – Searching for ‘ZDOMan’
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):
dnSpy – ‘ZDOMan’ section of assembly
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:
dnSpy – sendQueueSize Variable
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…”:
dnSpy – Save Module as assembly_valheim_modded.dll
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.
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!
The answer to your question is yes. People have tested this. Removing both the rocks and the trees will reduce instance counts.
Whether it’s worth it seems to be subjective. Some people say yes. It sounds like you can easily remove a couple thousand instances at most bases. Whether it’s worth it would depend on how many you start with.
Some of the people in the reddit thread were at 30,000 instances when they started. Yes, if you start with 30K instances and remove 2K that is going to be a negligible impact. That’s only a 6.6% reduction.
However, in your case you have 10,000 instances. If you reduce them by 2,000 or so roughly by removing the trees and rocks that is a 20% reduction in your instances. You might actually “feel” that 20% in your circumstances (especially if it’s close to working well but it just needs a little extra push).
No. I just confirmed it a few weeks ago (shouldn’t even be off the first page of the comments).
If they fixed it this page would drop off the top of Google and never be seen again. Like within weeks. Google is very competitive and the only reason I’m still at the top is because this is still the same issue it has been from day #1.
See this amusing reddit thread here asking how the netcode has improved when Mistlands was released. Yes, people were disappointed when they learned it worked the *exact* same way with CLIENTS (not the server) having control over huge areas of the server and controlling the monsters in them.
That was a year ago already. No, nothing has changed. I’m literally amazed people still think they’re going to fix this issue. It has been a problem since day 1 and there was never any point since release where it hasn’t been a problem.
For a technical explanation of why you briefly saw it break the limit it’s because they moved a few things outside of the single-cored Valheim server loop. I believe it’s things like doors and chests. Those now run outside of the game loop so it makes sense when you go into a portal since it’s loading every building in the area and some of that exists outside of the game loop you’re able to briefly exceed it. That has been in since Hearth and Home and there have been no further changes since then.
It won’t make any difference to your game that they moved a few minor things like opening doors/chests outside of the main loop that everything normally has to wait in line to go through. Everything important (such as combat and movement) still gets backed up / lags the exact same way they always have. The only way to fix that would be to completely change their multiplayer model back to a more traditional client/server model instead of a P2P-hybrid model where literally the first person who goes into a zone starts controlling the monsters for everyone in the game off their local machine.
The only positive impact moving opening doors and chests out of the main loop had is that at release when Valheim started lagging you literally could not open a door or a chest during the lag spikes. Until Hearth and Home if you tried you used to literally be frozen in place until the server stopped unlagging. It felt horrible. Okay, so now you don’t get stuck if you click a chest during a lag spike anymore but the entire server will still be at a standstill. You won’t be able to do anything still. You just won’t get literally frozen in place anymore if you try to open a door or chest when things are lagging. It’s a band-aid (and a pretty small and useless one honestly).
We’ve not even seen an attempt at revisiting the network code since Hearth and Home. I don’t blame them either because as I’ve been saying for years the real problem is their super weird hybrid-P2P model where you are having regular players control the monsters for other players. This is nonsensical when you have a “dedicated server” but it’s not really a dedicated server. It’s just a map storage server. The Valheim clients still run the actual game in a P2P way where PLAYERS are controlling the monsters. I’d imagine the reason they haven’t revisited attempting to fix this is they understand that to actually fix this they have to redo their entire multiplayer code base.
Completely redoing the network code for an existing game is unheard of. I literally don’t think I’ve ever heard of someone shipping a multiplayer game with bad code like this and then go back in and completely redo the entire networking part of the engine. It’s not really practical and it’s far less practical today than it was at release because now we have expansions and new systems built on top of that existing crud making it even harder to go back and tear out the foundation later. It would probably be easier to make a Valheim 2 than to rework Valheim 1.
I actually think it’s far more likely in fact that we will get a Valheim 2 that has a different multiplayer engine. But James you might say, the developers said they’re going to implement all 9 biomes in the existing game with no DLC! Yes, yes they did. In 2021 when they were a studio with a team of 4 people. The game released with 6 biomes in February of 2021. It has been 3 YEARS and we have ONE additional biome (we have 7 now). Okay, so if we are going to be nice and say they can add 1 biome every 2 years then we are looking at 2028 until the game is finished. If you want to get them credit for Ashlands work they claim is well underway then maybe it will be 2027. That is a long time to run a studio with 1 big game that everyone has already bought. Years ago probably for most people.
If you were Iron Gate Studios what is your way out of this situation? You have 4 years left to even finish a game that everyone already bought years ago and there are no DLC packs or additional purchases that are going to bring in any additional revenue. You made technical mistakes in your design/implementation as a young and small team (particularly around multiplayer) that are difficult/impossible to go back and fix this late into the release. The studio is *much* bigger now with more people to pay / more mouths to feed. What do you do?
Easy. Upgrade to the latest version of your game engine, pick a better multiplayer model, improve the graphics and resources slightly and there you go, Valheim 2 which everyone has to buy again! It wouldn’t surprise me if they’ve already started. With how much the cost of everything is going up worldwide constantly I would not be comfortable running a studio that is operating purely off burning cash from the Valheim surprise viral release all the way back in 2021. Especially for 4 MORE YEARS with a growing studio. No matter how big that pile is it never goes as far as you think it will or lasts as long as you think it will. If they aren’t going the route I’m saying they’ll just be acquired by someone else like virtually every other gaming studio that ever has a single hit.
Update… I realized after your specific words in a response to another post. In the “compiler window” search Ctrl +F , then the replace all command was available. Changes were compiled and saved. Launched local dedicated headless server without issue. Loaded the game into the server no issues. Although need to wait for my buddies later to test for their gameplay. I have done the decompiling and editing of the client DLL as well but have not applied it yet to the client files as there is no mention anywhere about the client side aspect or whether the other clients joining the server need the client side dll modification as well ?
However being both locally hosted on the same pc I didn’t expect results of the data transmission edit for myself but was hoping. Just started playing the game on December 22nd via steam. Amazing game and loved it !! High FPS 140-150’s …looked and felt great! However noticing after a while of gameplay with 2 other friends in this dedicated private public server. We started to notice severe lag at our home base that I mostly developed in debug. With that I did severe Terraforming across from our landed base. Built up a huge area of land to create a natural wall, and the ability to dig a deeper basement tunnel system. After a while started to notice that my video card wasn’t even pushing the game anymore (RTX306012GB) thought it was weird and noticed our home base was giving me around 20-30fps.. sometimes less than 20. I tried drivers, video card, load treating … everything ! Now reading about unity engine games and terrain modifications or terraforming is a big NoNo in Valheim or Unity Engine games. However possibly because I am hosting on my pc and joining and playing on the same system. However I tested that by moving the server to another local pc and same results at home base where all the major terraforming was done. I tested the theory further by loading my character into a default dedicated server but in a new world nothing done … my vid card amps up, fans speed up, gets to about 60 degrees c … perfect!! And about 140-150 fps !! Then I load back into our dedicated server with all the terraforming, drops the vid card to nothing and 20-30 fps…. Then in our same server I decide to portal to another area in the world where no terraforming has been done but have a couple buildings , lights, fires etc and get between 80-100fps … average around 90. Just on the load start screen of Valheim is crisp and pushes the video card , looks great and 160-170 fps .
This is also with a gsync 240hz monitor. Older i7 processor and 32Gb ram.
So the result is clear, terraforming is a big no no . Our world file size went from 5-6MB to 19-20MB now. Sure I have around 140 hours of game time , only having purchased it 2 weeks or so ago. Lol Amazing game ! Love it , but the low FPS lag at home base is almost enough to sour me and not feel like playing it. The video lag just bothers me. Made me spend countless hours on hardware and software diagnosing before finding the posts everywhere about terraforming and creating unmanageable instances in the game. I could load my backup world file from Dec 25th lol … pre terraforming craziness! But also lose all world progression since then, however thankfully not character progression! But …I now know to NOT Terraform!! I’m hoping the game gets fixed for this sooner than later. However I understand likely not till full release… if and when?
Hopefully this post makes it through as it could be helpful.
Hi James! I’m getting the same CS0104 error that everyone else is getting. I tried spinning up a fresh windows 10.0.19045 virtual machine and running it through that, but it’s the same error even on a fresh windows installation! Any tips?
Thanks for trying with a blank virtual machine. I’m on Windows 11 and I’m wondering if I have something you guys are missing rather than it being a conflict. It’s definitely not everyone that gets this. I don’t have any machines that get this. I have no idea why my same dnSpy version on the same Valheim version is smarter than yours at figuring out the dependencies.
The reason it doesn’t make a lot of sense is that if you installed the game and it runs on your computer then you have all the dependencies. Did you try just copying the files over to the new VM without actually installing Valheim (which will install the .NET framework along with a bunch of other dependencies)? If you can run the dedicated server / game then you should have all of these.
Nevertheless I have something for you to try. The error you are getting (if you type it in Google) is extremely common. For some reason your system / DNSpy can’t figure out which “Debug” it’s supposed to be using.
What you can try doing is doing a find (Ctrl+F) and then use the “Replace All” button in the compile window like this:
Notice I’m replacing Debug.Log with UnityEngine.Debug.Log to resolve the conflict. I have no idea if this will be enough to let you compile as I don’t have to do this to compile on my system. I did try compiling it after replacing though and it still worked.
Maybe that will let you proceed? If it doesn’t there are a lot of other things to try on Google if you want. You’d just have to go down the Google results line by line and see what works for you.
I’m not sure what is wrong with your system (or the few others that get this) though. I’d suspect it has something to do with the .NET framework installed or other dependencies but it’s hard to fix something that doesn’t happen to me (or most of the people who have tried this over the years).
On most systems it is able to resolve this conflict without needing intervention (at least historically, this is a pretty new phenomenon although we have seen it a few times over the years but it was such a tiny percentage of people it didn’t really register as anything more than an isolated issue until lately).
Thanks so much for leaving a confirmation for me! I’m glad it’s working. Eventually it will probably become clear why this is happening to certain people (now, after all of these years all of the sudden) but I’m just glad there’s a workaround.
Thanks for the reply James, and sorry for the slightly longer wait. Replacing Debug.Log with UnityEngine.Debug.Log did indeed allow it to compile on the VM! The server booted successfully using the new modded .dll. The VM has never had the server installed on it, and neither has my main machine. The only machine the server was installed on was a remote managed server that I was not able to run DNSpy on. This may be the cause? Regardless, I can’t muster enough people to test the server yet, due to Christmas, but I will let you know the results once we have managed to test it. Thanks for the help!
Thanks for stopping by again and letting me know! I’m still not sure why this is necessary for some people but at the moment I’m just relieved that this fairly easy workaround is taking care of it.
It doesn’t sound like the replace is working. When you replace they will change immediately *before* you compile.
If you are talking about after you compile it you are going back in and not seeing the changes that is because you aren’t opening your new file. It’s still looking at the old files. When you compile you have to save the DLL somewhere else. If you opened *that* DLL file with dnSpy you would see the changes in it. The changes will not go into the original DLLs though which is why you have to replace it after you compile (at which point you would also see the changes within dnSpy).
Hi! Thank you for the continued posts and updates. Just attempted a change of send/receive rate for my server and had compile issues after changing the values. Booted up a virtual machine with a fresh install and no luck, same error type and lines of code.
Any way to just edit the text of the file and call it good? I’m pretty sure this is my only bottleneck for my performance and would love to solve it.
anything we can do to help FPS drops in base? i see 10000+ instances being generated when pressing F2.
such as would chopping all nearby trees next to base increase FPS/reduce lag?
thanks
Hello Lex,
The answer to your question is yes. People have tested this. Removing both the rocks and the trees will reduce instance counts.
Whether it’s worth it seems to be subjective. Some people say yes. It sounds like you can easily remove a couple thousand instances at most bases. Whether it’s worth it would depend on how many you start with.
Some of the people in the reddit thread were at 30,000 instances when they started. Yes, if you start with 30K instances and remove 2K that is going to be a negligible impact. That’s only a 6.6% reduction.
However, in your case you have 10,000 instances. If you reduce them by 2,000 or so roughly by removing the trees and rocks that is a 20% reduction in your instances. You might actually “feel” that 20% in your circumstances (especially if it’s close to working well but it just needs a little extra push).
Hopefully that helps!
Has there been an update, because when going into one of my portals I saw, data recv: hit 124kb, I have not modded or done anything to the base game.
No. I just confirmed it a few weeks ago (shouldn’t even be off the first page of the comments).
If they fixed it this page would drop off the top of Google and never be seen again. Like within weeks. Google is very competitive and the only reason I’m still at the top is because this is still the same issue it has been from day #1.
See this amusing reddit thread here asking how the netcode has improved when Mistlands was released. Yes, people were disappointed when they learned it worked the *exact* same way with CLIENTS (not the server) having control over huge areas of the server and controlling the monsters in them.
That was a year ago already. No, nothing has changed. I’m literally amazed people still think they’re going to fix this issue. It has been a problem since day 1 and there was never any point since release where it hasn’t been a problem.
For a technical explanation of why you briefly saw it break the limit it’s because they moved a few things outside of the single-cored Valheim server loop. I believe it’s things like doors and chests. Those now run outside of the game loop so it makes sense when you go into a portal since it’s loading every building in the area and some of that exists outside of the game loop you’re able to briefly exceed it. That has been in since Hearth and Home and there have been no further changes since then.
It won’t make any difference to your game that they moved a few minor things like opening doors/chests outside of the main loop that everything normally has to wait in line to go through. Everything important (such as combat and movement) still gets backed up / lags the exact same way they always have. The only way to fix that would be to completely change their multiplayer model back to a more traditional client/server model instead of a P2P-hybrid model where literally the first person who goes into a zone starts controlling the monsters for everyone in the game off their local machine.
The only positive impact moving opening doors and chests out of the main loop had is that at release when Valheim started lagging you literally could not open a door or a chest during the lag spikes. Until Hearth and Home if you tried you used to literally be frozen in place until the server stopped unlagging. It felt horrible. Okay, so now you don’t get stuck if you click a chest during a lag spike anymore but the entire server will still be at a standstill. You won’t be able to do anything still. You just won’t get literally frozen in place anymore if you try to open a door or chest when things are lagging. It’s a band-aid (and a pretty small and useless one honestly).
We’ve not even seen an attempt at revisiting the network code since Hearth and Home. I don’t blame them either because as I’ve been saying for years the real problem is their super weird hybrid-P2P model where you are having regular players control the monsters for other players. This is nonsensical when you have a “dedicated server” but it’s not really a dedicated server. It’s just a map storage server. The Valheim clients still run the actual game in a P2P way where PLAYERS are controlling the monsters. I’d imagine the reason they haven’t revisited attempting to fix this is they understand that to actually fix this they have to redo their entire multiplayer code base.
Completely redoing the network code for an existing game is unheard of. I literally don’t think I’ve ever heard of someone shipping a multiplayer game with bad code like this and then go back in and completely redo the entire networking part of the engine. It’s not really practical and it’s far less practical today than it was at release because now we have expansions and new systems built on top of that existing crud making it even harder to go back and tear out the foundation later. It would probably be easier to make a Valheim 2 than to rework Valheim 1.
I actually think it’s far more likely in fact that we will get a Valheim 2 that has a different multiplayer engine. But James you might say, the developers said they’re going to implement all 9 biomes in the existing game with no DLC! Yes, yes they did. In 2021 when they were a studio with a team of 4 people. The game released with 6 biomes in February of 2021. It has been 3 YEARS and we have ONE additional biome (we have 7 now). Okay, so if we are going to be nice and say they can add 1 biome every 2 years then we are looking at 2028 until the game is finished. If you want to get them credit for Ashlands work they claim is well underway then maybe it will be 2027. That is a long time to run a studio with 1 big game that everyone has already bought. Years ago probably for most people.
If you were Iron Gate Studios what is your way out of this situation? You have 4 years left to even finish a game that everyone already bought years ago and there are no DLC packs or additional purchases that are going to bring in any additional revenue. You made technical mistakes in your design/implementation as a young and small team (particularly around multiplayer) that are difficult/impossible to go back and fix this late into the release. The studio is *much* bigger now with more people to pay / more mouths to feed. What do you do?
Easy. Upgrade to the latest version of your game engine, pick a better multiplayer model, improve the graphics and resources slightly and there you go, Valheim 2 which everyone has to buy again! It wouldn’t surprise me if they’ve already started. With how much the cost of everything is going up worldwide constantly I would not be comfortable running a studio that is operating purely off burning cash from the Valheim surprise viral release all the way back in 2021. Especially for 4 MORE YEARS with a growing studio. No matter how big that pile is it never goes as far as you think it will or lasts as long as you think it will. If they aren’t going the route I’m saying they’ll just be acquired by someone else like virtually every other gaming studio that ever has a single hit.
Hopefully that helps!
Update… I realized after your specific words in a response to another post. In the “compiler window” search Ctrl +F , then the replace all command was available. Changes were compiled and saved. Launched local dedicated headless server without issue. Loaded the game into the server no issues. Although need to wait for my buddies later to test for their gameplay. I have done the decompiling and editing of the client DLL as well but have not applied it yet to the client files as there is no mention anywhere about the client side aspect or whether the other clients joining the server need the client side dll modification as well ?
However being both locally hosted on the same pc I didn’t expect results of the data transmission edit for myself but was hoping. Just started playing the game on December 22nd via steam. Amazing game and loved it !! High FPS 140-150’s …looked and felt great! However noticing after a while of gameplay with 2 other friends in this dedicated private public server. We started to notice severe lag at our home base that I mostly developed in debug. With that I did severe Terraforming across from our landed base. Built up a huge area of land to create a natural wall, and the ability to dig a deeper basement tunnel system. After a while started to notice that my video card wasn’t even pushing the game anymore (RTX306012GB) thought it was weird and noticed our home base was giving me around 20-30fps.. sometimes less than 20. I tried drivers, video card, load treating … everything ! Now reading about unity engine games and terrain modifications or terraforming is a big NoNo in Valheim or Unity Engine games. However possibly because I am hosting on my pc and joining and playing on the same system. However I tested that by moving the server to another local pc and same results at home base where all the major terraforming was done. I tested the theory further by loading my character into a default dedicated server but in a new world nothing done … my vid card amps up, fans speed up, gets to about 60 degrees c … perfect!! And about 140-150 fps !! Then I load back into our dedicated server with all the terraforming, drops the vid card to nothing and 20-30 fps…. Then in our same server I decide to portal to another area in the world where no terraforming has been done but have a couple buildings , lights, fires etc and get between 80-100fps … average around 90. Just on the load start screen of Valheim is crisp and pushes the video card , looks great and 160-170 fps .
This is also with a gsync 240hz monitor. Older i7 processor and 32Gb ram.
So the result is clear, terraforming is a big no no . Our world file size went from 5-6MB to 19-20MB now. Sure I have around 140 hours of game time , only having purchased it 2 weeks or so ago. Lol Amazing game ! Love it , but the low FPS lag at home base is almost enough to sour me and not feel like playing it. The video lag just bothers me. Made me spend countless hours on hardware and software diagnosing before finding the posts everywhere about terraforming and creating unmanageable instances in the game. I could load my backup world file from Dec 25th lol … pre terraforming craziness! But also lose all world progression since then, however thankfully not character progression! But …I now know to NOT Terraform!! I’m hoping the game gets fixed for this sooner than later. However I understand likely not till full release… if and when?
Hopefully this post makes it through as it could be helpful.
Cheers
Hey MrBungles,
Excellent work and great writeup, I’m glad you got it, this should help anyone else who might get stuck!
Hi James! I’m getting the same CS0104 error that everyone else is getting. I tried spinning up a fresh windows 10.0.19045 virtual machine and running it through that, but it’s the same error even on a fresh windows installation! Any tips?
Hey Kit,
Thanks for trying with a blank virtual machine. I’m on Windows 11 and I’m wondering if I have something you guys are missing rather than it being a conflict. It’s definitely not everyone that gets this. I don’t have any machines that get this. I have no idea why my same dnSpy version on the same Valheim version is smarter than yours at figuring out the dependencies.
The reason it doesn’t make a lot of sense is that if you installed the game and it runs on your computer then you have all the dependencies. Did you try just copying the files over to the new VM without actually installing Valheim (which will install the .NET framework along with a bunch of other dependencies)? If you can run the dedicated server / game then you should have all of these.
Nevertheless I have something for you to try. The error you are getting (if you type it in Google) is extremely common. For some reason your system / DNSpy can’t figure out which “Debug” it’s supposed to be using.
What you can try doing is doing a find (Ctrl+F) and then use the “Replace All” button in the compile window like this:
Notice I’m replacing Debug.Log with UnityEngine.Debug.Log to resolve the conflict. I have no idea if this will be enough to let you compile as I don’t have to do this to compile on my system. I did try compiling it after replacing though and it still worked.
Maybe that will let you proceed? If it doesn’t there are a lot of other things to try on Google if you want. You’d just have to go down the Google results line by line and see what works for you.
I’m not sure what is wrong with your system (or the few others that get this) though. I’d suspect it has something to do with the .NET framework installed or other dependencies but it’s hard to fix something that doesn’t happen to me (or most of the people who have tried this over the years).
On most systems it is able to resolve this conflict without needing intervention (at least historically, this is a pretty new phenomenon although we have seen it a few times over the years but it was such a tiny percentage of people it didn’t really register as anything more than an isolated issue until lately).
Thanks for posting this. I ran into the same thing on a Windows 11 computer too and this seems to compile and work fine after for me.
Hey Ballfart,
Thanks so much for leaving a confirmation for me! I’m glad it’s working. Eventually it will probably become clear why this is happening to certain people (now, after all of these years all of the sudden) but I’m just glad there’s a workaround.
Enjoy and take care!
Thanks for the reply James, and sorry for the slightly longer wait. Replacing Debug.Log with UnityEngine.Debug.Log did indeed allow it to compile on the VM! The server booted successfully using the new modded .dll. The VM has never had the server installed on it, and neither has my main machine. The only machine the server was installed on was a remote managed server that I was not able to run DNSpy on. This may be the cause? Regardless, I can’t muster enough people to test the server yet, due to Christmas, but I will let you know the results once we have managed to test it. Thanks for the help!
Hey Kit,
Thanks for stopping by again and letting me know! I’m still not sure why this is necessary for some people but at the moment I’m just relieved that this fairly easy workaround is taking care of it.
Have a Merry Christmas and take care!
I tried to do this, I replace all but when I press compile it doesn’t actually change any of them. Any ideas?
Hey madnuzz,
It doesn’t sound like the replace is working. When you replace they will change immediately *before* you compile.
If you are talking about after you compile it you are going back in and not seeing the changes that is because you aren’t opening your new file. It’s still looking at the old files. When you compile you have to save the DLL somewhere else. If you opened *that* DLL file with dnSpy you would see the changes in it. The changes will not go into the original DLLs though which is why you have to replace it after you compile (at which point you would also see the changes within dnSpy).
Hopefully that helps!
That worked for me! Thanks a bunch 🙂
Hi! Thank you for the continued posts and updates. Just attempted a change of send/receive rate for my server and had compile issues after changing the values. Booted up a virtual machine with a fresh install and no luck, same error type and lines of code.
Any way to just edit the text of the file and call it good? I’m pretty sure this is my only bottleneck for my performance and would love to solve it.
Thank you in advance for your help.