64-bit and DST in Windows: Discussion and Ideas

[Mr.Mulk]

Preface:
For starters? What is this post about? Well, it's a more technically focused discussion about the viability of a 64-bit structure to DST and why that it would potentially be a good idea for Klei to implement in the Windows version of the game. As well in the process I'll attempt to address some potential issues and concerns to the best of my ability, however I am not an expert on this issue nor do I claim to be one. If you see anything that is factually incorrect in this post please leave a comment to correct me. It will not be intentional, as I've tried my best to do research and discussion with more technically minded friends and several very "important" people who've explained why 64 bit on Windows would be a good but challenging thing.

Why would 64-bit be a good thing for the Windows version of DST?

• It's important to understand the fundamental difference between a 32-bit structure (the one DST is currently using) and that of a 64-bit structure (the proposed improvement). 32-bit programs are limited to a maximum processing power of 4 gigabytes, which while more than enough to merely run the game, presents a significant limitation if one wishes to apply a large quantity of mods or host long-term servers* (which slow down relatively soon after launch). Having DST in a 64-bit structure would, in effect, remove this cap. This means servers would run better even in the long-term, and users could apply significantly more mods with a far less risk of the game lagging or running into issues. 
  • It is important to note that CPUs in this situation do matter, however I've found that the difference is marginal between a decent rig with 16 gigabytes of ram using a relatively nice CPU versus a laptop with a much worse CPU and only 8 gbs of ram (when one should obviously be much better).
    *I am aware that using dedicated servers helps "double" the ram usage as the dedicated server is being run off of a separate exe, but even that starts lagging rather quick and is fairly limited in mod capabilities
• It would also increase what mod creators are capable of doing with their work. Especially in mods which plan on utilizing more than two shards eventually, such as Island Adventures. No longer being limited to a maximum processing power of 4 gigabytes would allow more creative freedom.
  • In a similar vein I have also heard a 64-bit version would fix the rather constrictive workshop upload limitations. This however I have not confirmed and should be taken with a grain of salt (If someone knows the answer please comment below).
• To my understanding, 64-bit would allow for all the assets in-game to be essentially turned high definition. Because of the way assets are currently loaded to save space they're compressed into a small size before usage leading to that blurry distortion on multiple items. This however is also unconfirmed but I've heard it from several of the people I've talked to in discussions while researching for this post.

What are some of the issues?

• I think it's important to address by far the largest issue in the room, which is the cost of such an update. To my understanding, and from personal discussions with several key folks it is to my knowledge upgrading DST to 64-bit would be an expensive process, and in order to justify the effort required, Klei would need to receive some form of compensation (which is completely understandable).
  • One solution which was offered to me was the potential of releasing an "HD" edition of DST on Steam, specifically structured in 64-bit. While this is a rather on-the-nose upfront cost I believe a majority of the active community would be fine with this decision, as long as the Steam Inventory is shared and some compatibility with 32-bit players and servers is maintained.
  • Granted, it has recently been brought up that Klei is making a 64 bit version of DST, however it is solely for a version of Mac unfortunately. This does bring up questions of whether or not funding for such an improvement would be as necessary as previously assumed however. This would, however, based on the most recent information available to me be a confirmed issue.
• .Another potential issue would be cross-compatibility. Now on this subject I'd personally like to hear more, because I've heard that having two versions of the game, where the only difference is the structure, would both wildly split the community and also not be an issue at all. And since I'm not technically knowledgeable on this subject, I don't know which is true, if either. So if someone with more knowledge on that would like to inform me and the forums on that specific issue it'd be much appreciated. What I can say is that splitting the community, specifically in a game like this, would be an understandably bad idea, and should be avoided at all costs.
   

So what's the takeaway?

In my opinion, upgrading the current 32-bit Windows version of DST to 64-bit would be an excellent idea to improve user experience greatly. While there are a few concerns I think overall the benefits here would outweigh the costs assuming the only real issue that comes to fruition is the necessity of marketing an "HD" version of DST to the playerbase, something I think the vast majority of players would have no issue with assuming a shared Steam Inventory and compatibility with the 32-bit players.

Apologies if this post would be more appropriate in suggestions/feedback however the purpose is more to see people's thoughts and potentially start discussion on the subject, which I think would be better suited for that goal in general discussion.
Again if there are any edits I need to make to this post please comment below informing me, and feel free to discuss why this is a good/bad idea!

[Mobbstar]

2 hours ago, Mr.Mulk said:

It is important to note that CPUs in this situation do matter, however I've found that the difference is marginal

Simply put: The CPU does active thinking, while the RAM is short-term memory. DST is pretty good at not over-thinking things, but it has to keep all the entities and playerdata and what not in mind. As worlds get older, there's more things to keep in mind and remember. Or at least I assume so. I am not sure what exactly increases the RAM usage, and just assume it's metadata and world regrowth.

2 hours ago, Mr.Mulk said:

I have also heard a 64-bit version would fix the rather constrictive workshop upload limitations.

I am not aware of any correlation here. To my knowledge, the filesize and filecount limits are set by the Workshop. The file count limit in particular should be entirely unrelated.

2 hours ago, Mr.Mulk said:

64-bit would allow for all the assets in-game to be essentially turned high definition. Because of the way assets are currently loaded to save space they're compressed into a small size before usage leading to that blurry distortion on multiple items.

This is correct (at least theoretically). High-resolution art has higher filesize and also requires more RAM to load. Practically speaking, however, I believe Klei tries using the Dyn file format more because it supposedly loads and unloads data as needed.

2 hours ago, Mr.Mulk said:

"HD" version of DST

Is there any reason it could not be a DLC?

[Canis]

Starbound, for example, allows you the option to run a 32 bit and 64 bit executable on steam startup, and you're able to play multiplayer with people using either executable, so crossplay is definitely possible.

 

Edit: Im aware that Starbound is a completely different game, but I wanted to put it out there that this is very much possible, and has been done before.

[Daniel86268]

8 hours ago, Mr.Mulk said:

a maximum processing power of 4 gigabytes

Processing power is generally counted in teraflops. 4 Gigabytes is a unit of measurement for storage, in that regard: RAM.

Same as saying "My car has a range of 1200 kilograms".

 

Back to topic, I agree that DST should either switch over to 64 bit or have a second 64bit version like starbound. Only "problem" would be that a 64 bit program generally needs a bit more space, since some variables and numbers end up being larger. And ofc, lots of more work for Klei.

As long as you use the same protocols (What you would usually do) there's no communicative difference between a 32 bit DST and a 64 bit, so the server wouldn't even notice without an extra parameter if a client is 32bit or 64 bit.

 

Edit: On the other hand it very rarely happens that someone actually runs over the limit. I've only seen once that someone hit the memory limit with a >70 days map and like literally 86 mods.

[maradyne]

...something that's been mentioned recently is that Klei wishes to keep the minimum specs for the game the same as they've always been (well, it was implied that they kind of have to due to Steam shenanigans, though I'm not at all sure how that works given how many games grow in drastic ways over time??). There were concerns about how designing the game in the future around 64-bit capabilities would leave users who play the game on old toasters behind.
But, I don't think that that should hold back the game/limit what the community can pull off.
DST doesn't necessarily have to be designed around 64 bit...but it should be able to benefit from its usage.

 

In that vein, there are some ways to trim the fat, per-say, for lower-end systems.
For instance, making lower-res textures the default, and splitting off the recent wave of high-res textures as a free DLC, ala original Steam Skyrim. Set the game to prioritize loading the high-res textures over the low-res ones, if the high res files are detected; similar tech is already in use as of the newish data packaging system for script file alterations (if the game can't find scripts.zip, it tries to load from the old \scripts folder)
Heck, you could even have the game give a little prompt when a user opens it for the first time, letting them know that higher-res textures exist.
...or, don't do DLC, and instead base it all on a launch option chosen by the player when starting the game through Steam; 32 bit automatically loads the lower res textures, 64 bit automatically loads the higher.

I mention the above because newer textures have mostly been high-res...while older textures seem to have just been down-scaled versions of images that were once higher res. Writing instructions to blow up the size of images loaded from the low-res package would be a one-time effort, and the creation of those lower res images in the first place would always be the same, repeated down-scaling setting in an image editing program. A decently sized one-time investment, but with bare-bones upkeep required.

Optimizations for server operation.
This includes Thanosing high-volume low-use items. The two largest offenders that come to mind are rot and stingers. Doing something about items like that which amass as world time increases would...help everyone regardless of specs, really.
The current situation of having to decide whether or not you want to play the game based on what hardware and hosting options are available, and how those options affect what parts of the game you're allowed to play and for how long, kinda sucks.
Server hosting needs optimization.

On the client side, it isn't so bad, but I recall that masses of trees/other constantly animated items in one screen area cause slowdown; more noticeable on lower-end machines of course, but that's the point. This could be something else to tackle. Perhaps syncing of identical stationary prefabs (client-side), rather than individual rendering? Individual states for mass items that aren't being interacted with are the sorts of thing that really only needs to be kept track of server-side.

 

...you know, I've been thinking about this lately due to going back and playing some of them recently, but...
Older games used to have a lot more options for tuning the game to match system specs. Heck, quite a few had hardware detection and automatic graphical tracking adjustment based on the results. That game made back in 2004, that I mentioned in a similar topic, was one of them. Hiding unnecessary elements, lowering quality of individual graphical objects, refresh rates...
If older systems are a concern, then we could use some more of that.

 

 

...finally, back to servers for a second. One of the big reasons why 64-bit would be a boon to the game, given that it would free hosts to just keep running.
Servers hosted in-game typically can't last long with caves and mods enabled (reminder here that most games in the server browser are modded, even after you break it down with filters; the general preference seems to be playing with mods).
This leads to a requirement of running a dedicated server, if you want a world that lasts a bit.
Running a dedicated server in the normal way while managing mod updates and editing text files trying to figure out what each raw-form value corresponds to in those mods setting all with different organizational standards is
7 layers
of actual hell.

...there's a way around it, of course; a hacky way involving some stuff from this post, which works wonderfully.
I've set up a dedi from the ground up myself, I've used external host consoles, and I've used the hacky way, and let me tell you, tricking the game into running your local world as a dedicated server so it inherits everything about that world save is by far the least stress inducing option...
...but how many people are even willing to try that hard to find the right information?
This should be made more user-friendly, for instance having the game automatically launch a separate instance for the server, or at least presenting such as an option upon hosting a game...
But here, a 64 bit version would kill two birds with one stone.

64 bit loading would allow game-run servers to operate more smoothly and with less technical know-how/effort. I believe this would make common users more likely to stay interested in the game.
This would also benefit low-spec users, who would then be able to play on the servers run on other, 64-bit machines owned by other players, and experience more of the popular mod content for themselves.

 

 

 

TL;DR because that was long as heck: a 64 bit version of the game would benefit both low-end and high-end users in different ways, and there are various ways of pulling it off while still supporting our dinosaur friends.

[. . .]

I really hope we get a 64-bit version in the future, it would be sad to see DST always have crappy low quality textures which don't bring out highest quality of the game's unique artstyle.

[Mr.Mulk]

Apologies for the late response, I've been super busy today!
I'm glad to see most people seem to be able to agree on this, which admittedly is a bit surprising but I'm impressed.
 

Spoiler

19 hours ago, Mobbstar said:

Simply put: The CPU does active thinking, while the RAM is short-term memory. DST is pretty good at not over-thinking things, but it has to keep all the entities and playerdata and what not in mind. As worlds get older, there's more things to keep in mind and remember. Or at least I assume so. I am not sure what exactly increases the RAM usage, and just assume it's metadata and world regrowth.

I am not aware of any correlation here. To my knowledge, the filesize and filecount limits are set by the Workshop. The file count limit in particular should be entirely unrelated.

This is correct (at least theoretically). High-resolution art has higher filesize and also requires more RAM to load. Practically speaking, however, I believe Klei tries using the Dyn file format more because it supposedly loads and unloads data as needed.

Is there any reason it could not be a DLC?

 

This was really informative, thank you! Also the idea of it being a DLC I would love! It'd allow Klei to earn a profit yet keep the same storefront page on Steam, and also give users the 64 bit update everyone seems to agree would be good.
 

Spoiler

18 hours ago, Canis said:

Starbound, for example, allows you the option to run a 32 bit and 64 bit executable on steam startup, and you're able to play multiplayer with people using either executable, so crossplay is definitely possible.

 

Edit: Im aware that Starbound is a completely different game, but I wanted to put it out there that this is very much possible, and has been done before.

 

While it's not a 1:1 example this does appear to be solid evidence to me the issue of a 64 bit update splitting the community likely wouldn't come to fruition, thank you for the information!

 

13 hours ago, Daniel86268 said:

Processing power is generally counted in teraflops. 4 Gigabytes is a unit of measurement for storage, in that regard: RAM.

Same as saying "My car has a range of 1200 kilograms".

 

Back to topic, I agree that DST should either switch over to 64 bit or have a second 64bit version like starbound. Only "problem" would be that a 64 bit program generally needs a bit more space, since some variables and numbers end up being larger. And ofc, lots of more work for Klei.

As long as you use the same protocols (What you would usually do) there's no communicative difference between a 32 bit DST and a 64 bit, so the server wouldn't even notice without an extra parameter if a client is 32bit or 64 bit.

 

Edit: On the other hand it very rarely happens that someone actually runs over the limit. I've only seen once that someone hit the memory limit with a >70 days map and like literally 86 mods.

Also good to know, backing up that there likely wouldn't be compatibility issues.


 

Spoiler

10 hours ago, maradyne said:

...something that's been mentioned recently is that Klei wishes to keep the minimum specs for the game the same as they've always been (well, it was implied that they kind of have to due to Steam shenanigans, though I'm not at all sure how that works given how many games grow in drastic ways over time??). There were concerns about how designing the game in the future around 64-bit capabilities would leave users who play the game on old toasters behind.
But, I don't think that that should hold back the game/limit what the community can pull off.
DST doesn't necessarily have to be designed around 64 bit...but it should be able to benefit from its usage.

 

In that vein, there are some ways to trim the fat, per-say, for lower-end systems.
For instance, making lower-res textures the default, and splitting off the recent wave of high-res textures as a free DLC, ala original Steam Skyrim. Set the game to prioritize loading the high-res textures over the low-res ones, if the high res files are detected; similar tech is already in use as of the newish data packaging system for script file alterations (if the game can't find scripts.zip, it tries to load from the old \scripts folder)
Heck, you could even have the game give a little prompt when a user opens it for the first time, letting them know that higher-res textures exist.
...or, don't do DLC, and instead base it all on a launch option chosen by the player when starting the game through Steam; 32 bit automatically loads the lower res textures, 64 bit automatically loads the higher.

I mention the above because newer textures have mostly been high-res...while older textures seem to have just been down-scaled versions of images that were once higher res. Writing instructions to blow up the size of images loaded from the low-res package would be a one-time effort, and the creation of those lower res images in the first place would always be the same, repeated down-scaling setting in an image editing program. A decently sized one-time investment, but with bare-bones upkeep required.

Optimizations for server operation.
This includes Thanosing high-volume low-use items. The two largest offenders that come to mind are rot and stingers. Doing something about items like that which amass as world time increases would...help everyone regardless of specs, really.
The current situation of having to decide whether or not you want to play the game based on what hardware and hosting options are available, and how those options affect what parts of the game you're allowed to play and for how long, kinda sucks.
Server hosting needs optimization.

On the client side, it isn't so bad, but I recall that masses of trees/other constantly animated items in one screen area cause slowdown; more noticeable on lower-end machines of course, but that's the point. This could be something else to tackle. Perhaps syncing of identical stationary prefabs (client-side), rather than individual rendering? Individual states for mass items that aren't being interacted with are the sorts of thing that really only needs to be kept track of server-side.

 

...you know, I've been thinking about this lately due to going back and playing some of them recently, but...
Older games used to have a lot more options for tuning the game to match system specs. Heck, quite a few had hardware detection and automatic graphical tracking adjustment based on the results. That game made back in 2004, that I mentioned in a similar topic, was one of them. Hiding unnecessary elements, lowering quality of individual graphical objects, refresh rates...
If older systems are a concern, then we could use some more of that.

 

 

...finally, back to servers for a second. One of the big reasons why 64-bit would be a boon to the game, given that it would free hosts to just keep running.
Servers hosted in-game typically can't last long with caves and mods enabled (reminder here that most games in the server browser are modded, even after you break it down with filters; the general preference seems to be playing with mods).
This leads to a requirement of running a dedicated server, if you want a world that lasts a bit.
Running a dedicated server in the normal way while managing mod updates and editing text files trying to figure out what each raw-form value corresponds to in those mods setting all with different organizational standards is
7 layers
of actual hell.

...there's a way around it, of course; a hacky way involving some stuff from this post, which works wonderfully.
I've set up a dedi from the ground up myself, I've used external host consoles, and I've used the hacky way, and let me tell you, tricking the game into running your local world as a dedicated server so it inherits everything about that world save is by far the least stress inducing option...
...but how many people are even willing to try that hard to find the right information?
This should be made more user-friendly, for instance having the game automatically launch a separate instance for the server, or at least presenting such as an option upon hosting a game...
But here, a 64 bit version would kill two birds with one stone.

64 bit loading would allow game-run servers to operate more smoothly and with less technical know-how/effort. I believe this would make common users more likely to stay interested in the game.
This would also benefit low-spec users, who would then be able to play on the servers run on other, 64-bit machines owned by other players, and experience more of the popular mod content for themselves.

 

 

 

TL;DR because that was long as heck: a 64 bit version of the game would benefit both low-end and high-end users in different ways, and there are various ways of pulling it off while still supporting our dinosaur friends.

 

That was quite the read but it brings up a lot of really excellent points, while also being reasonable in the fact that Klei is considering not just the high-end rigs when they make decisions, which is an important consideration I admittedly glossed over in my initial post. It's good food for thought, thanks!


Anyways thanks for the updated information on the subject! I'm glad that it appears my research ended up being decently close to the mark, and again I'm impressed that everyone seems to agree 64 bit would be a good option for DST.

[CarlZalph]

On 9/7/2019 at 1:01 AM, Mr.Mulk said:

If you see anything that is factually incorrect in this post please leave a comment to correct me.
 

• 32-bit programs are limited to a maximum processing power[1] of 4 gigabytes, which while more than enough to merely run the game, presents a significant limitation if one wishes to apply a large quantity of mods or host long-term servers* (which slow down relatively soon after launch). Having DST in a 64-bit structure would, in effect, remove this cap. This means servers would run better even in the long-term, and users could apply significantly more mods with a far less risk of the game lagging or running into issues.[2]
   
  • In a similar vein I have also heard a 64-bit version would fix the rather constrictive workshop upload limitations.[3] This however I have not confirmed and should be taken with a grain of salt (If someone knows the answer please comment below).
• To my understanding, 64-bit would allow for all the assets in-game to be essentially turned high definition.[4] Because of the way assets are currently loaded to save space they're compressed into a small size before usage leading to that blurry distortion on multiple items.

 

• .Another potential issue would be cross-compatibility. Now on this subject I'd personally like to hear more, because I've heard that having two versions of the game, where the only difference is the structure, would both wildly split the community and also not be an issue at all. And since I'm not technically knowledgeable on this subject, I don't know which is true[5], if either.

[1] Processing power isn't how much memory the system has.  The CPU itself has its own cache that's effectively RAM on steroids, but that's besides the point- 4GByte of RAM isn't CPU processing power.  The job of the CPU is to fundamentally move data from one part of the system to the other and let other components do work on it.  If you want to make it an umbrella term for how much throughput the entire computer can handle at once, then you may consider using a more general term such as 'computing power' or something.

 

[2] Having more RAM doesn't benefit the engine's entity logic tick rate.  You can have more entities with more RAM, but in the end this game's engine uses LUA in a single-threaded instance and is thus capped by the CPU's single-threaded throughput.  There's also the side effect of a server having the ability to house more entities than the client is able to, where any client joining a server with 128GByte of RAM full of entities would surely run out of RAM on join if the entities were within the client's view.  This effect is lessened when there's a memory cap guaranteeing that both sides are not going to outperform one another on any modern computer.

 

[3] The Steam workshop limits are limited to by currently the old ISteamRemoteStorage set of API, whereas Valve has an updated ISteamUGC set of API that has more freedom.

Current old: https://partner.steamgames.com/doc/api/ISteamRemoteStorage

Unused new: https://partner.steamgames.com/doc/api/ISteamUGC

 

[4] Not necessarily the case.  It would highly depend on the user's GPU's VRAM size and/or system RAM for when the GPU automatically offloads stale textures to the system memory.

You're pretty right in the storage system, it's compressed and has gone through a lossy transition to reduce its memory footprint.

 

[5] It'd mainly be an issue with having too much demand from a 64-bit server to a 32-bit client, either from too many mods populating memory or too many entities that the client can't load all at once.  The rest of it would operate the same, though Klei may need to rework their networking packet generator/serializer/deserializer section to accommodate for the variable bit-lengthed structures and such.  Can't tell from here, this is source-code-only information to know.

 

 

Personally I don't think that the 64-bit version would be warranted, but then again I don't make/use such high memory requirement mods.  If Klei had programmed the engine with 64-bit in mind in case they wanted to make a build for it at the get-go, then this wouldn't be such a big issue.  But hindsight is 20/20, so it is what it is.

Klei's already put on the limitation to themselves to not increase the system minimum requirements, and I don't blame them.  Zenimax Online did this for Elder Scrolls Online and it made quite a few people upset about it- they completely removed dx9 support in favour of dx11.  Activision-Blizzard did this, too, with Heroes of the Storm- dx9 removal.  Again, a same bit of outrage from the people who were able to play the game and then suddenly not because of an update.  I've been there, and it feels almost like a betrayal by the company to have an actively played game taken away due to factors decided by some corporate executive to make their games look shinier.

[Fuffles]

On 07/09/2019 at 7:01 AM, Mr.Mulk said:

• To my understanding, 64-bit would allow for all the assets in-game to be essentially turned high definition. Because of the way assets are currently loaded to save space they're compressed into a small size before usage leading to that blurry distortion on multiple items. This however is also unconfirmed but I've heard it from several of the people I've talked to in discussions while researching for this post.

Yes and No, Peter has informed me about this matter once in a Steam Discussion, the 32-bit limit is not the only thing that holds them back, Atlas Sizes also are a potential holder, if you'd like an example the Pillar objects (Cave Pillars, Hamlet's Large Stalk, etc) are most likely over the Atlas limit which I believe is around 2000px x 2000px. And on a side note .dyns have another function than Protecting Textures, .dyns as their name implies are dynamic, they only are loaded whenever necessary, compared to .zips which are loaded at all times (If I understood that correctly), this is why Skins can be as HQ as they want to be without nuking the game

As to this whole post; Klei has done a Founders Program for the Chester Plush, I dont see any reasons as to why  not make a 64-bit DST Founders Program, People Donate and idk, maybe get the new 64-bit version a month or so early than other people

[Paddlefruit]

By what Mobb said about DLC, he didn't mean something you would buy (I think). For instance, Rainbow Six Siege, Borderlands 2 and a few other games have free HD DLCs, so that it isn't mandatory to download it in the base game. Having to pay for a graphics upgrade would not be a good thing  

[maradyne]

13 hours ago, FuffledBeeQueen said:

And on a side note .dyns have another function than Protecting Textures, .dyns as their name implies are dynamic, they only are loaded whenever necessary, compared to .zips which are loaded at all times (If I understood that correctly)

More or less; zips get loaded by game section (for instance, loading everything for mods that are enabled while not loading disabled mods, or for a more vanilla example, not loading data for a DLC that isn't enabled on a particular save file), whereas dyns are...yea, dynamic. They're kinda on standby; the game can be instructed to be ready to load them, without them actually being loaded.
It's like indexing kinda?

Obvious downside is the same as the upside; you don't want everything loading and unloading as the game is played, because you eventually reach a point where the cost outweighs the benefit.

 

13 hours ago, FuffledBeeQueen said:

As to this whole post; Klei has done a Founders Program for the Chester Plush, I dont see any reasons as to why  not make a 64-bit DST Founders Program, People Donate and idk, maybe get the new 64-bit version a month or so early than other people

Aaah I'd be all for this. Do a little commemorative skin for backers and people would be all over it. Triply so if it looks cute with Wendy.

[Mobbstar]

On 8.9.2019 at 2:03 PM, CarlZalph said:

[2] [...] There's also the side effect of a server having the ability to house more entities than the client is able to, where any client joining a server with 128GByte of RAM full of entities would surely run out of RAM on join if the entities were within the client's view.  This effect is lessened when there's a memory cap guaranteeing that both sides are not going to outperform one another on any modern computer.

You make good points, but I feel the need to stress that this one is only a concern if the client has to load all those entities, which is not the case. As you said, the entities near the client's view are the only ones that matter to the client in this regard. The entity count in the world rises proportional to world size, the entity density does not. At most, I can see some hypothetic crazy mods or equally crazy admins spawn a lot of entities near each other, but there's nothing stopping those from doing that right now.

[Theukon-dos]

Something that should be noted is that coding is an absolute b****.

 

While admittedly I'm not to knowledgable in the field ir the underlying code base, what I do know is that Klei had to do some really hacky stuff to make DST work. And I can only imagine that adding an entirely different bitage (?) Would make that come crumbling down. 

[CarlZalph]

14 hours ago, Mobbstar said:

You make good points, but I feel the need to stress that this one is only a concern if the client has to load all those entities, which is not the case. As you said, the entities near the client's view are the only ones that matter to the client in this regard. The entity count in the world rises proportional to world size, the entity density does not. At most, I can see some hypothetic crazy mods or equally crazy admins spawn a lot of entities near each other, but there's nothing stopping those from doing that right now.

The density around 'mega' bases surely is the worst offender, but from what I've seen people tend to self manage their bases as-is to keep it not so populated.  It may be a nonissue practically, but I tend to look for the edge cases.

I'd hate to see honeypot servers wherein once you join the client crashes from out of memory, either maliciously or from an accidental admin command.