Search the Community
Showing results for tags 'optimization'.
Found 4 results
Recently been encountering the Out Of Memory issue more often server-side, as many have before; as the modding community gets more creative and expansive, this problem gets more common. The game just can't handle what the community is coming up with. It's been stated by a dev in the past that a full 64-bit game client upgrade isn't in the cards due to not wanting to raise minimum specs. But, would a separate 64-bit server be considered? It would help alleviate some of the growing issues, at least.
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!
So, I have been playing this game for quite a while, so I have a decent idea about what impacts the game lag... But... Than I realized that I never actually tested some of my assumptions... If you are not interested in the experiments, feel free to skip to the end of the thread - the "takeaway section" For the start of the chain of the experiments... I prepared an almost empty map for myself. Than, for the first set of experiments. I made sure to turn this into a box with insulation tiles as the walls and filled the entire box with equally spread oxygen... My hope is that it will minimize any calculation for gas movement and heat exchange, so they do not interfere with the actual experiments. Experiment 1.0: Test: filling the entire map with ladders to maximize the possible amount of routes. But do not give duplicants access to those ladders. Expected result: game will work without lag, because the game does not actually get to calculate those paths. Result: No lags were observed. Experiment 1.1: make dupes mine something, but do not allow the access to ladders yet. Expected result: game will work without lag. Result: no lag observed. Experiment 1.2: Make a mining task that will give access to the ladders. Expected result: game will explode. Result: game almost explodes as soon as they mine a path to the ladders. There is major lag and even moving camera around in pause mode is hard. Experiment 1.3: have an access to the ladders through a closed door. Expected result: lag will be gone. Result: lag was gone as soon as I hit lock button on the doors. You can only imagine what kind of relief it was when you can move your camera again. * actually, I did not even hit the lock button in quick build mode. Most of lag was gone before the doors were actually locked by a dupes which is unexpected. Though, the game staggered quite a bit while the dupe was walking to the door to lock it, but way less than when the door was on other mode. Opening the door introduces lags as expected. **not giving a way out through the auto door works the same as just locking it... Clicking allow button on the permission to move right makes game lag harder and harder with each dupe allowed and less when a dupe is removed from permissions. Experiment 1.4: Lock dupes inside the minibox and add a few flying critters into the open space. Expected result: game will lag. Result: Suprisingly, the game only froze for a few second when unpaused, but did not lag afterwards. * adding many times more critters. I managed to achieve very minor lag of the game... Though. I observed another thing. At the start of the cycle and sometimes in the middle of it, the game would freeze... The number of critters would make the freeze longer. Thats 400 pufts in the open and it just causes period freezes for 5-10 seconds once or twice during a cycle. Getting rid from all the pufts, gets rid from any freezes. ** putting 400 pufts inside the confined space makes the game run smooth, though, I there was still a loading freeze at the start of the cycle. Closing and opening the door does not seem to have an impact on the game. I find it very interesting that the game calculates something for critters at the start of the cycle, but putting critters inside a closed room does not seem to ease those calculations. Accidental Experiment 1.5 Trying to save and restart this map. Result: game took quite a long time to load and when it loaded, you could not play for about a minute as it kept on loading. -------------------------------- ---------Takeaway---------- -------------------------------- Mostly, with this experiment, I have confirmed what I already knew. To cause less lag in your game: 1. Give your duplicants as little options in their paths as possible. Here is what will cause you lag more: If your base ever looks like that, make sure to fix it. Just having access to more options causes more lag. Also, on the side note. Every single time I added fire pole to my base, my base would start lagging, I do not even need to test for it. Here is what should cause less lag: 2. As a continuation of point 1, block your duplicants access to areas that they have no business visiting. 3. As continuations of point 2, confine your duplicants to their personal workspace. Only let miners have access outside your base. Make farmers sleep next to farms and make them never be able to leave the farms. Make ranchers sleep with the critters... Etc. 4. Use automation to lock down areas which duplicant will not visit during the specific time of day... For example: They have no business inside their bedrooms, mess halls, toilets, rec rooms, washrooms, etc during the time of day that is not a break time. So, use automatic to lock those away and open at specific time of day... This design uses 2 doors, one is open/closed by automation, the other is an one way door, to make sure that dupes do not consider going out after they went in and vice versa... (also, this a reason why narcoleptic sucks, they can easily fall asleep during the time you close/open the doors and be stuck where you do not want them to be.) I plan to do more lag tests, but I would like to hear what other people know and tried.
This is my next set of tests for how things impact the game. For this set of experiments, pipes will be the suspect... I dearly hope that there is no difference between water and gas pipes, because conducting same experiments for both types would be time consuming. Same as before, I will place "takeaway" section in the end. I was not sure when ever to post it within same topic and make it hard for people to find as they dig through comments or to create a new topic. Previous part Already during the building, I have experienced several issues. In fact, I managed to kill my game on the first attempt to build it. Which is surprising because there was no such issue with setting up ladders map. First of all, building large segments would become harder the larger the segment became, I would give up at segments with length of 1000. Secondly, building next segment starting at the end of previous one would become painfully slower and slower, this is how I killed the game on first attempt... Game handles placing segments of pipes and than connecting them much better than trying to continue building same pipe network. Also, I got a few glitched out areas during my building process: Also, the game experiences no issues in normal mode. Switching to pipes overview mode causes several major problems. First of all, moving camera becomes painfully slow and it depends on how close you are zoomed in which suggests that there is a major problem in game with the rendering of the pipe network. Also, I tried moving my camera in pipe mode in an area without pipes and it was smooth, but when I moved back to the pipes area, game crashed: Luckily, I made sure to save my game. The game took quite a while to load, but loaded without issues. Before attempting to run any tests with that piping network, I let the game run for a few cycles... It seems like having those pipes does not impact game performance. Though, for some weird reason, it did increase loading freeze during the new cycle start more than having 400 pufts did. Experiment 2: Run water through the entire pipe one way. Expected result: with how many setbacks I experienced during the construction of that machine, I can only expect game crashing. Result: Game Crashed within a few seconds of running after connecting the pipe network to the pump. So, to continue the experiment, I first attempted to load the same game (in hope that I do not need to build a smaller map with same setup) and disconnected about half of the pipes from the network, but did not delete them. Experiment 2. Attempt 2: Result:Game still crashed. For next attempt, still using same map, disconnected 3/4 of the pipes from the network. Experiment 2 Attempt 3: Result: Game crashed before I even started things running lol. I am led to believe that I have to setup a smaller experiment map D: While Setting up way smaller map, I got it to crash again >_> F6 overlay kills your games. I am going to attempt making the pipes on the smaller map for second time. Getting crashes one after another is discouraging me from doing any experiments (I crashed it again). My experiments might lose their validity after something that causes game to crash gets fixed. I am going to attempt with 2 times less pipes than I planned on smaller map. Well, at the very least, moving in F6 mode does not crash the game, but its painfully slow. I am surprised about how lucky I got with the bigger map when moving camera in pipe overlay. Before starting the experiment, I will let it run for a few cycles. There is a minor cycle start loading freeze. Experiment 2 Revised version: Expected result: hopefully it will work this time. Result:it did not crash... As long as I avoid F6 overview mode, the game seems to run smooth, but as soon as I enter it, the game lags really hard, hovering map over the pipe makes game lag even harder. It might be too small of a pipe to properly stress test for the lag, so I will still advice to build shorter pipes, but thinking logically about it, single input, single output should not be demanding to calculate. Also, I did not realize how many cycles would it take for the water to reach its destination Experiment 2.1: Now, lets make a "questionable" piping system and see how it runs... Questionable is the best way to describe it. Expected result: this is where the game will start to lag. Result:Well, first of all, even trying to build questionable network makes the game freeze, the more connection I added, the more it would take to load. In screenshot, it handle fine the first big segment than it took a bit to load after second segment... Third segment was small, but it took like 2 minutes to load... I gave up trying to wait for last segment as the game stayed frozen even after 20 minutes... So... I settled for less connection as shown in second screenshot. Still there were no lags. So, the game calculates the route for pipes at the moment of the construction and actually calculating the piping of liquids does not take much. To test this, I tried another setup on screenshot 3... I stopped adding more connections when it started giving small delay. Surprisingly, it caused no lag, but the game failed to make proper routes for the water as it ended up getting stack at random places Experiment 3: setup a system with multiple inlets and outputs separately. Expected result: perhaps the game will lag now? Result: the game did not lag, maybe, the map size is too small to stress test how much lag it caused... On the other hand, going to the pipe overview crashed the game --------------------------------------- -----------Takeaway--------------- --------------------------------------- 1. Do not go into pipe overview mode when you do not have to and if you have to, make sure to zoom in first and do not zoom out in pipe overview. 2. Build your pipes systems as short as possible. 3. Try to not build systems that use pipes close to one another. 4. When building a network of pipes, build segments of pipes first and than connect them together. Do not try to just extend pipe system that you already have, instead, build the extension first and than connect it. With how much the game actually crashes, it feels impossible to setup a proper stress test pipes for lag. But, common sense tells me that you should not build mazes with your pipes and try to use bridges to simplify the flow of gasses and liquids. Also, having a lot of pipes might be even worse than having a lot of critters.