Revisiting Fixing Valheim Lag – Modifying Send/Receive Limits
Published: June 15, 2021 / Last Modified: December 3, 2023 / Gaming / 252 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!
252 thoughts on “Revisiting Fixing Valheim Lag – Modifying Send/Receive Limits”
tolagarf
Hi again.
Does anyone know if the linux distro for Valheim uses .dll files? I’m wondering if this bandwidth fix actually works in a Docker container, now that I switched my server from Windows to Unraid.
It does, yes. But you need to get *all* the files when you do the edit. If you just download the one valheim dll we are editing it will crash when you upload the DLL back to the server. That is because yes even though the Linux version still uses DLL files they are *not* the same as Windows. You need to download *all* the server files from Linux before you edit and then it will work without crashing.
Hey James,
I have also started a new run with my girlfriend.
I’m still secretly reading along here.
Just wanted to let you know that since the Ashlands update the game has been running a lot worse. Also in the previous biomes, but especially in our base and in the Ashlands. You were absolutely right and spot on with what you said back then and that the game is getting more and more problematic with every new content. I was able to play the game with your fix without bigger issues till Ashlands.
1. In Ashlands itself, we both have heavy desync – especially when a storm hits – which is due to the additional huge fps drops I get in Ashlands. Your fix still helps to counteract this a bit, but the overall performance of the game is subterranean compared to before. Even Mistlands runs smooth as butter in comparison – the drop to Ashlands is extremely noticeable. Even I now have super FPS drops and micro-stutters in my base and Ashlands with my “~decent” system (i9 9900k/2070 RTX Super), which certainly has an additional negative effect on the desync problem.
Ashlands seems to load a lot of “instances” by default, as a lot of the environment is destroyable and there is also a lot of loot on the ground the whole time. Walking in Ashlands is/feels like constantly playing in a really large base (and I mean really large with lots of instances) with additionally lots of tamed animals around it and so on plus the possibility of performance-hungry storms that often occur. And the whole thing is a permanent thing in Ashlands.
I’m afraid I’m now at a point where I have to upgrade to a more modern system or wait for a fix from the Devs. Your fix still helps a bit, but at the moment and in this state Ashlands is not really that much fun for us.
2. There’s another problem that I didn’t have before and is really spoiling my fun: player base structures seems to load worse or differently than before the Ashlands update. From ~7000 instances around upwards, when you come back from a portal or, more precisely, your base structures have to reload, enemy spawns seems to be rendered before the player base and it often happens that deer or greydwarves/shamans or fulings run around in our base and possibly kill our animals or structures. It’s simply no fun building a base for a long time, ensure to make it spawnproof and feel safe, if you can never be sure that something will spawn in it. We never had this problem before and it’s definitely Ashland-related. It’s only when you re-enter the base so player base structures has to be reloaded. It occurs even more frequently in co-op, probably also when the weaker system has to load the base first. I dunno, but we never had this issues after many hundreds hours of playing before the Ashlands update. I can 100% guarantee that the base is spawnproof. I don’t know if this is a “lag problem” overall or if they changed something about load orders since the Ashlands update, but I just wanted to mention this, because this can be very gamebreaking at least for us.
This problem is also misunderstood in every official forum. It’s almost frustrating to discuss this officially.
All in all, thanks for the hard work as before. Cool that you’re still keeping an eye on Valheim.
If you have any tips for me, please feel free to write.
The posts here are generally worth a lot more than anything you can read anywhere else especially from official side.
The FPS drops really were my problem, graphics card throttled under maximum load – solved after I replaced the thermal paste.
FPS are now constant again and the fix here is helping like before.
Because of my drops and fluctuations, it has obviously made the whole actual problem much worse – but was another origin in the chain of events, so to speak.
It’s fascinating how much this can affect the desync in this game.
I also saw for the first time the hardware impact of just one machine and the desync it causes on another and how it completely destroys the other player’s gaming experience.
In Valheim, every client has to be perfect and double checked – that’s really blatant.
In general, Ashlands is overloaded with instances. You play permanently in a really huge base and its send/receive data accordingly. It used to be no different in a large base, but Ashlands is one.
Maybe I should give “Better Networking” a try. As far as I’ve read here, it seems to work well with the fix.
The load bug is a mystery to me. Maybe it’s always been like this and I’m just building “denser” now and have recently slipped over a certain number of instances that I never used to exceed.
I am now a little more cautious about jumping to conclusions.
I can only say that I didn’t have it before. I’ll be watching.
I’m sorry I didn’t see this right away but I totally agree and sympathize. I’ve felt like the developers themselves never really understood the issues creating the lag. I suppose if they had though they would not have used a multiplayer design like this. I just kept hoping they would figure it out somewhere along the way and potentially revamp it.
I’m glad the FPS drops got fixed by some thermal paste. I was going to say that usually FPS drops are different from the typical Valheim lag issues we’re used to dealing with. You’re quite right though that when it was happening it drags the whole server down with you as the performance can’t keep up. That in contrast is absolutely right in line with what we’ve been seeing over the past few years.
I wanted to ask if you’ve tried the latest patch. There were some *serious* Ashlands bugs that got fixed. One that caught my eye was “Fixed a performance issue related to grausten building pieces”. There are a lot more other small tweaks / fixes and who knows how many of them don’t make it into the patch notes. Did any of their bug fixes help at all?
Better Networking should absolutely be worth a try as well. If you give that a try let us know if you noticed any difference from that specifically.
As far as the building loading in this patch I did notice some differences in my upgraded world from how it loaded before. Upgrading your map to the newer versions seems like it may impact this. This might be too much effort for a test but I wonder if you picked the same seed and started a new map and tried building those structures fresh if they would load the same way as before. It is also possible they changed the way the code works in this patch but I was suspicious of my map upgrade process (especially since I saw some errors while it was going).
The engine Valheim uses is, as I understood, just terrible at multicore workloads. I’ve seen a couple of times in the patch notes where the devs tried to mitigate this issue, but certainly not fix it. The best solution I found, however which requires you to invest in new hardware, is buying a Ryzen X3D CPU. Graphics card doesn’t really matter in the big scheme of things, as my RTX 4090 runs the same FPS, as my RTX 3080 (4K resolution).
The switch to a Ryzen X3D CPU can be huge, sometimes double FPS in some areas. In one of my old maps I was getting 40 FPS in my base at a specific spot, so I used it as a benchmark. Back then I was running a 3840x1600p monitor and it jumped to nearly 100 FPS.
Yeah the engine or what the devs did with it isn’t a performance flagship. That was known, and I’m not mean about that because it’s EA.
It’s been okay for me the last few years. But even my mum’s beast with a 13700k/4080 has worse performance than I did back then. I made a special comparison and I’m pretty sure now. Something must have changed in the code or I’ve become oversensitive over time or I’m very much mistaken.
The funny thing is, the higher your overall FPS, the bigger the drop in a micro stutter. It’s as if the game freezes for a fraction of a second sometimes very often in a row. There’s a video in my post above. I made exactly the same observation on 4 machines with the same result.
And if I’m not completely mistaken by observation, this is the point in time when delays are created in the multiplayer transmission. Because sometimes the game freezes for up to 0.5 seconds, I don’t know if data is being sent or what is being lost or in queue and how it then leads to lags, all the fixes don’t help if no data is sent even for a short time period. Of course, the fixes make a huge difference between the micro freezes that you only have when you’re not idling in a zone.
Don’t know what is happening with the game code atm., since I’m barely reading about it anywhere, I’m starting to think I’m going completely nuts and it’s a “me” problem.
I know that I had discussions with james earlier here and that I looked closely at the performance of the game especially in multiplayer and I could swear that I had lag issues but the game overall was relatively – as i said “relatively” – stable in general and had no micro freezes to this extend. However there has always been zone stuttering since I play Valheim. But now I’m either completely oversensitive or something has happened to the game code since last time I played which was more than a year ago.
hey, i patched the dlls and seems the server doesnt want to start, it crashes on loading ZDO’s it seems, we are using V+ mod perhaps it is related, are you using vanilla valheim? or have you tried the trick with various mods?
I have not tried it with mods and was definitely using vanilla. Did you get the same behavior when you tried without the mods running? The other common reason for crashing is people only copying over a single DLL file from something like a Linux machine instead of the whole dependency chain.
I am trying to compile the code, but I am doing so on a different computer than the server itself. I run the server via Nitrado, and downloaded the DLL locally to my PC.
I am getting errors like this when compiling:
Severity Code Description File Line
Error CS0246 The type or namespace name ‘UnityEngine’ could not be found (are you missing a using directive or an assembly reference?) main.cs 6
Severity Code Description File Line
Error CS0246 The type or namespace name ‘Vector3’ could not be found (are you missing a using directive or an assembly reference?) main.cs 294
I am going to try to install the Valheim server on my local machine so I can compile. I hope this works, but if not, is there any other things I can do?
Yes, that should definitely do it. You can’t just take the .dll file you need to edit. You need all of the other files that go with it.
We’ve seen people have this problem trying to mix Linux and Windows server dll files for example. You can actually edit the Linux files but you need to copy over *all* of them for the dependencies to resolve. Once you finish editing you only need to copy the updated .dll back but you will need all of them to edit.
In your case yes installing the full server on your own computer will give you the dependencies. It’s okay to delete it after you are done. It should make life easier though in the mean time!
Dude this made a tremendous improvement to my game!! I paired it with BetterNetworking_valheim mod. I did have the compile error also where I had to rename Debug.Log to UnityEngine.Debug.Log. Perhaps this is because I used a .net 6 SDK for another game that I installed at one point.
Hi again.
Does anyone know if the linux distro for Valheim uses .dll files? I’m wondering if this bandwidth fix actually works in a Docker container, now that I switched my server from Windows to Unraid.
Hey tolagarf,
It does, yes. But you need to get *all* the files when you do the edit. If you just download the one valheim dll we are editing it will crash when you upload the DLL back to the server. That is because yes even though the Linux version still uses DLL files they are *not* the same as Windows. You need to download *all* the server files from Linux before you edit and then it will work without crashing.
Hopefully that helps!
Hey James,
I have also started a new run with my girlfriend.
I’m still secretly reading along here.
Just wanted to let you know that since the Ashlands update the game has been running a lot worse. Also in the previous biomes, but especially in our base and in the Ashlands. You were absolutely right and spot on with what you said back then and that the game is getting more and more problematic with every new content. I was able to play the game with your fix without bigger issues till Ashlands.
1. In Ashlands itself, we both have heavy desync – especially when a storm hits – which is due to the additional huge fps drops I get in Ashlands. Your fix still helps to counteract this a bit, but the overall performance of the game is subterranean compared to before. Even Mistlands runs smooth as butter in comparison – the drop to Ashlands is extremely noticeable. Even I now have super FPS drops and micro-stutters in my base and Ashlands with my “~decent” system (i9 9900k/2070 RTX Super), which certainly has an additional negative effect on the desync problem.
Ashlands seems to load a lot of “instances” by default, as a lot of the environment is destroyable and there is also a lot of loot on the ground the whole time. Walking in Ashlands is/feels like constantly playing in a really large base (and I mean really large with lots of instances) with additionally lots of tamed animals around it and so on plus the possibility of performance-hungry storms that often occur. And the whole thing is a permanent thing in Ashlands.
I’m afraid I’m now at a point where I have to upgrade to a more modern system or wait for a fix from the Devs. Your fix still helps a bit, but at the moment and in this state Ashlands is not really that much fun for us.
2. There’s another problem that I didn’t have before and is really spoiling my fun: player base structures seems to load worse or differently than before the Ashlands update. From ~7000 instances around upwards, when you come back from a portal or, more precisely, your base structures have to reload, enemy spawns seems to be rendered before the player base and it often happens that deer or greydwarves/shamans or fulings run around in our base and possibly kill our animals or structures. It’s simply no fun building a base for a long time, ensure to make it spawnproof and feel safe, if you can never be sure that something will spawn in it. We never had this problem before and it’s definitely Ashland-related. It’s only when you re-enter the base so player base structures has to be reloaded. It occurs even more frequently in co-op, probably also when the weaker system has to load the base first. I dunno, but we never had this issues after many hundreds hours of playing before the Ashlands update. I can 100% guarantee that the base is spawnproof. I don’t know if this is a “lag problem” overall or if they changed something about load orders since the Ashlands update, but I just wanted to mention this, because this can be very gamebreaking at least for us.
This problem is also misunderstood in every official forum. It’s almost frustrating to discuss this officially.
All in all, thanks for the hard work as before. Cool that you’re still keeping an eye on Valheim.
If you have any tips for me, please feel free to write.
The posts here are generally worth a lot more than anything you can read anywhere else especially from official side.
Best regards/
The FPS drops really were my problem, graphics card throttled under maximum load – solved after I replaced the thermal paste.
FPS are now constant again and the fix here is helping like before.
Because of my drops and fluctuations, it has obviously made the whole actual problem much worse – but was another origin in the chain of events, so to speak.
It’s fascinating how much this can affect the desync in this game.
I also saw for the first time the hardware impact of just one machine and the desync it causes on another and how it completely destroys the other player’s gaming experience.
In Valheim, every client has to be perfect and double checked – that’s really blatant.
In general, Ashlands is overloaded with instances. You play permanently in a really huge base and its send/receive data accordingly. It used to be no different in a large base, but Ashlands is one.
Maybe I should give “Better Networking” a try. As far as I’ve read here, it seems to work well with the fix.
The load bug is a mystery to me. Maybe it’s always been like this and I’m just building “denser” now and have recently slipped over a certain number of instances that I never used to exceed.
I am now a little more cautious about jumping to conclusions.
I can only say that I didn’t have it before. I’ll be watching.
Hello Gesper,
I’m sorry I didn’t see this right away but I totally agree and sympathize. I’ve felt like the developers themselves never really understood the issues creating the lag. I suppose if they had though they would not have used a multiplayer design like this. I just kept hoping they would figure it out somewhere along the way and potentially revamp it.
I’m glad the FPS drops got fixed by some thermal paste. I was going to say that usually FPS drops are different from the typical Valheim lag issues we’re used to dealing with. You’re quite right though that when it was happening it drags the whole server down with you as the performance can’t keep up. That in contrast is absolutely right in line with what we’ve been seeing over the past few years.
I wanted to ask if you’ve tried the latest patch. There were some *serious* Ashlands bugs that got fixed. One that caught my eye was “Fixed a performance issue related to grausten building pieces”. There are a lot more other small tweaks / fixes and who knows how many of them don’t make it into the patch notes. Did any of their bug fixes help at all?
Better Networking should absolutely be worth a try as well. If you give that a try let us know if you noticed any difference from that specifically.
As far as the building loading in this patch I did notice some differences in my upgraded world from how it loaded before. Upgrading your map to the newer versions seems like it may impact this. This might be too much effort for a test but I wonder if you picked the same seed and started a new map and tried building those structures fresh if they would load the same way as before. It is also possible they changed the way the code works in this patch but I was suspicious of my map upgrade process (especially since I saw some errors while it was going).
Hopefully that helps!
The engine Valheim uses is, as I understood, just terrible at multicore workloads. I’ve seen a couple of times in the patch notes where the devs tried to mitigate this issue, but certainly not fix it. The best solution I found, however which requires you to invest in new hardware, is buying a Ryzen X3D CPU. Graphics card doesn’t really matter in the big scheme of things, as my RTX 4090 runs the same FPS, as my RTX 3080 (4K resolution).
The switch to a Ryzen X3D CPU can be huge, sometimes double FPS in some areas. In one of my old maps I was getting 40 FPS in my base at a specific spot, so I used it as a benchmark. Back then I was running a 3840x1600p monitor and it jumped to nearly 100 FPS.
Hello tolagarf and thank you for your reply,
Yeah the engine or what the devs did with it isn’t a performance flagship. That was known, and I’m not mean about that because it’s EA.
It’s been okay for me the last few years. But even my mum’s beast with a 13700k/4080 has worse performance than I did back then. I made a special comparison and I’m pretty sure now. Something must have changed in the code or I’ve become oversensitive over time or I’m very much mistaken.
The funny thing is, the higher your overall FPS, the bigger the drop in a micro stutter. It’s as if the game freezes for a fraction of a second sometimes very often in a row. There’s a video in my post above. I made exactly the same observation on 4 machines with the same result.
And if I’m not completely mistaken by observation, this is the point in time when delays are created in the multiplayer transmission. Because sometimes the game freezes for up to 0.5 seconds, I don’t know if data is being sent or what is being lost or in queue and how it then leads to lags, all the fixes don’t help if no data is sent even for a short time period. Of course, the fixes make a huge difference between the micro freezes that you only have when you’re not idling in a zone.
Don’t know what is happening with the game code atm., since I’m barely reading about it anywhere, I’m starting to think I’m going completely nuts and it’s a “me” problem.
I know that I had discussions with james earlier here and that I looked closely at the performance of the game especially in multiplayer and I could swear that I had lag issues but the game overall was relatively – as i said “relatively” – stable in general and had no micro freezes to this extend. However there has always been zone stuttering since I play Valheim. But now I’m either completely oversensitive or something has happened to the game code since last time I played which was more than a year ago.
Best regards/
hey, i patched the dlls and seems the server doesnt want to start, it crashes on loading ZDO’s it seems, we are using V+ mod perhaps it is related, are you using vanilla valheim? or have you tried the trick with various mods?
Hey ppapysh,
I have not tried it with mods and was definitely using vanilla. Did you get the same behavior when you tried without the mods running? The other common reason for crashing is people only copying over a single DLL file from something like a Linux machine instead of the whole dependency chain.
Hey James, thanks for all your hard work on this.
I am trying to compile the code, but I am doing so on a different computer than the server itself. I run the server via Nitrado, and downloaded the DLL locally to my PC.
I am getting errors like this when compiling:
Severity Code Description File Line
Error CS0246 The type or namespace name ‘UnityEngine’ could not be found (are you missing a using directive or an assembly reference?) main.cs 6
Severity Code Description File Line
Error CS0246 The type or namespace name ‘Vector3’ could not be found (are you missing a using directive or an assembly reference?) main.cs 294
I am going to try to install the Valheim server on my local machine so I can compile. I hope this works, but if not, is there any other things I can do?
Hello K O,
Yes, that should definitely do it. You can’t just take the .dll file you need to edit. You need all of the other files that go with it.
We’ve seen people have this problem trying to mix Linux and Windows server dll files for example. You can actually edit the Linux files but you need to copy over *all* of them for the dependencies to resolve. Once you finish editing you only need to copy the updated .dll back but you will need all of them to edit.
In your case yes installing the full server on your own computer will give you the dependencies. It’s okay to delete it after you are done. It should make life easier though in the mean time!
Dude this made a tremendous improvement to my game!! I paired it with BetterNetworking_valheim mod. I did have the compile error also where I had to rename Debug.Log to UnityEngine.Debug.Log. Perhaps this is because I used a .net 6 SDK for another game that I installed at one point.
Beautiful, glad to hear it, take care!
you just need to add that one to the top
using Debug = UnityEngine.Debug;
dunno how it works though ^^