Jump to content

SylenThunder

Moderators
  • Posts

    5,429
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by SylenThunder

  1. The visitmap command crawls the map in this method. However what you describe sounds like a local hardware issue with loading the data visually. Which doesn't have anything to do with how the map is generated. Is the save data on SSD? What graphical settings do you have? That RX 580 8gb is a little bit dated, though it is on-par with the same performance as a GTX1060.
  2. Heh, yeah I've got a few spare drives left as well. Along with a couple of motherboards, and some CPU's. May even have a PSU or two that has more than 500W sitting around too. Also last I checked, the Console version was 14.7 with some features from a15. It is most certainly not a16, though a16 did get a couple of features that spurred from console development.
  3. Yeah, you want as close to direct I/O as you can get. This is why I haven't used VM's in like 10 years. Even with hardware virtualization, they do not get the same performance as bare metal.
  4. 1. Don't use Nitrogen. It hasn't been supported since before a19 launched, and is more likely to cause you trouble than not. If you want to use a custom map generator, then use KingGen. 12k maps would be fine on that system. 16k is not stable long-term yet. 2. You would have to run a dedicated server with a server manager. There is a Pinned thread in this very section regarding those. 3. Allocs Server Fixes has a visitmap command to crawl and populate the webmap. It can be CPU intensive, so you would want to run it without a lot of server activity.
  5. All of this is covered in the Pinned Support FAQ Thread. Both the location of save files, and how to possibly recover a corrupted save. The game launcher also has a tool for cleaning game data.
  6. No it wouldn't. The config will get sent to you from the server. EAC would ban if you were using a hacked DLL or were injecting code into memory to force change values. EAC bans are per-game as far as I am aware.
  7. I did a hardware comparison once between my i7-3930k with different clock settings, and then my R9 3900X. https://steamcommunity.com/app/251570/discussions/4/2247803885925802071/#c2247803885925903682 GPU was a constant across all the tests. Pretty sure that was on Alpha 18.
  8. New video with yet another list of reasons to avoid Dell like the plague. Alienware used to be reasonably good gaming systems. Then Dell bought them out. At least this one actually has a PSU, and not a laptop brick.
  9. Ok, yeah that's a freaking huge log. I'm about 15 seconds into looking at it and holy crap your list of mods. There is about a 95% chance that's your issue right there. Some are even trying to load twice! You have the air drops set to land every 5 game hours. That's quite often already. Honestly though, the core of your issue is most likely a mod. You've got a real rats nest there. Then it starts spamming errors on zombie actions, so at a minimum your entities are corrupted, which is where the supply drop spawns from. Your log is so massive because it's a truckload of errors caused by your mods.
  10. Child zombies has been requested quite often, and the developer is completely against that. This really isn't much of a step past that. I'm not sure there is a good cost/return in the amount of code that would be required to support this suggestion either. Survivor NPC's are already planned though, so who knows.
  11. The issue isn't writing to RAM, it's that when you're storing a lot of data in RAM, and then have to write it to the disk, it's going to be an extremely large operation. Make a copy of the Regions folder, and see how long that takes. Now imagine it has to do that every few minutes instead of just writing to the files live. Also look at the total size of the files. At least that much RAM would be in use by the client. This is a pretty basic representation, and it could be optimized a little bit. However the current method is the most optimal.
  12. If it cached the gigabytes of data instead of writing it live you run into two issues. 1. Massive amounts of RAM being used. 2. Every time it saves the cache, it's going to tank performance. Take Valheim as an example here. Even with as little data as it's processing, and it being written to a very small flat database, having it cache the data causes the game to almost pause every time it does a save. And the server isn't even hosting most the work! You can see this in action on the PS4 and Xbox versions of the game, because they perform a similar operation. Game will freeze once every three minutes because it's performing a save.
  13. Run it from the 2019 instance that your server runs from.
  14. Good to hear you got it sorted. For future reference, migrating saves is covered in the Support FAQ thread.
  15. I still don't know what the actual bandwidth of your 10k drives are. You never said. My 15k drives get about 890MB/s, but to be fair, there are only two of them. You've never provided the full details on your configuration there. I did ask about it in the very first post.
  16. Yes. Especially if you have players spread about. It is actively loading and writing to region files that could literally be gigabytes in size. It's doing it live as changes happen, and as data needs to be loaded when people move around. It's a large reason for the current limitations on vehicle speeds. And you need not just fast storage, but a CPU and RAM that can keep up, and the bandwidth on the motherboard to keep up. Our main Linux array is a little bit overkill, but I set this system up to run several 7 Days servers and a full Ark cluster. For your particular case, I would advise at least 3-4GB/s throughput on the drives.
  17. Absolutely correct. Huge difference between NVMe and the SSD's on our servers. And additionally between NTFS and F2FS. I can hit 5802 MB/sec with our fastest array, but that's pretty much the upper limit. (It can hit 6659 MB/sec in performance tests, but the limit for the RAID controller is 6.5GB/s) You could do that with just a pair of NVMe's in RAID-0. A standard NVMe array could easily hit 26GB/s with a full array of 6-8 drives. The AI server I used to get the 30-player limit on was running a full deck of Intel Optane drives at 45GB/s.
  18. Honestly, don't use anything but Samsung Evo's. 1. They are supported by your RAID controller. 2. They will last for literal years. 3. They are faster than most others. We have multiple R710's with all the drive slots filled. Here is what we've run on them. Our Evo 850's lasted almost ten years. One of which is still in use. I tried Kingston drives. After about a year they were at 80% wear, and speed was reduced by 40%. I tried Crucial drives. They didn't last 6 months. Critical drive failures across the board. Got them RMA'ed, next set did the exact same thing. Tried Inland Professional. Same end result as the Kingston's, except we started seeing the drops in performance at about 6-9 months. I don't recall what the health was on these when I pulled them offhand. I think it was around 90%. I do know that when we pulled them, they were almost as slow as a freaking platter drive. So now our array is almost fully Evo 860's with long term media storage being on Seagate Ironwolf drives. (Note that WD NAS drives are not worth the metal they are printed on.) Our current drive layout. On Miata the Linux OS is on a pair of 15k SAS drives in RAID-0 (650GB). The servers run on a pair of 860's in RAID-0 (500GB). The game save data is on 4 860's in RAID-0 (1TB). And the backups are stored on a pair of Seagate Firecuda SSHD's in RAID-0 (2TB), and mirrored to Challenger. On Challenger the Windows OS is on an Evo 850 (120GB, health is at 93%, and estimated life remaining is about two years. It's only ever been a Windows drive). The servers and save data run on three 860's in RAID-0 (750GB). Media storage and all backups are on a Seagate IronWolF (8TB). One slot is currently reserved for another IronWolf drive that we are saving up for, but prices have been pretty steep for a year now. The next system is planned to have NVMe's, and I am considering testing Sabrient or another brand I cannot for the life of me recall the name of now.
  19. Last time I ran into this, flushing the DNS helped.
  20. You can try locking the client down to only 4 physical cores, and that may improve performance. Usually only needed on older Gen 1/2 Ryzen's that don't support multithreading. Also, make sure your BIOS is up to date. Motherboard manufacturers have been pushing frequent updates that fix bottlenecks and increase performance. Your issue could be something as silly as the RAM not being utilized properly by the system, and it was fixed in a BIOS update.
  21. You have Defender. Ensure it is fully excluded. Even if Defender is disabled.
  22. Ok right at the start, the server FPS is 20. Then it gets up to the 30's. Then after you've had a couple of people connect, you get this error... The server FPS for a while varies from 29-32. Serviceable, but not a lot of room for overhead. It does occasionally pick up to 35 or 36. I'm seeing a number of errors for corrupted map tiles, and the above error appears a couple more times. Sharing violation is most commonly a result of not excluding the client from security software. It could also be a result of some other process accessing the files, the drive not performing well enough to handle requests in a timely fashion, or a simple permission issue.
×
×
  • Create New...