Motherboard: ASUS Maximus VIII Hero (Skylake)
CPU: i5-6600K
GPU: GTX 970
RAM: 16 GB (G Skill, 3200)
SSD: 1 Samsung 850 Pro (256 GB), 1 Samsung 850 EVO (500 GB)
HDD: 2 WD Raptor (1000 GB, 500 GB), 1 Seagate (2000 GB)
Affected features
This bug affect not only the fabricators, it affect several features. Here the complete list of all slowed down features i found:
Fabricator
Medi Kit Fabricator
Modification Station
Trashcans
Day/Night cycle
Growbeds
Plant pots
Grow rate in Alien Containment
Moon movement
In this situation the game is not really playable.
Tries to solve the problem
Removed all external power and left only one Solar Panel: no difference
Used the fabricator in Life Pod 5: no difference
Built the fabricators on several positions inside the main base: no difference
Removed all secondary bases: no difference
Used "daynightspeed" with values greater than 1: this works if the value is high enough, but the scalar will not increase at correct speed of course.
Observations
It have to do with the Day/Night scalar. I am a programmer too, but no UWE-dev so i don't know is this only a symptom or the cause. If the bug is present in the game-save, then this scalar will not increase constantly. It increase only a bit by some actions:
Press F1/F3
Make screenshots
Walk around and do other things
Sometimes it helps to only go away a bit
Open/Close inventory (PDA)
More observations and hints
If i set the SN executable CPU affinity to only one core, the scalar will immediately start normal operation. If i set back the affinity to 2 or more (all) cores the scalar stops immediately normal operation. It is 100% reproducable and with all my "defected" game-saves. reference
I can bring back the normal operation of the day/night cycle and all dependent features by changing a few bytes (3-4 depending to the game-save) in scene-objects.bin. This produce a few smaller problems, but the day/night cycle works again and the game is playable again. This workaround is not permanent and must be repeated after some time. reference
Test if the bug is present
Press F1. Look at the Day/Night scalar, if this is increase constantly then all is fine. If this is not increase constantly or is frozen then the bug is present.
Assumptions
It seems it has nothing to do with the game-save complexity. That was my very first assumption but after lot of tests and because of other players reports i have rejected this presumption.
It seems it has nothing to do with the story progress because some players get this bug sooner and other later. reference
It seems it have to do with multi-threading.
It seems there is a bug in the save function. Especially with the file scene-objects.bin.
Something I noticed the other night when I encountered a slow fabricator is if you back off and turn away the item completes its cycle almost immediately.
That's what i meant with "Sometimes it helps to only go away a bit". Ok, then you have this bug also. Press F1 and look at the day/night scalar. It will not increasing at a constant rate, but it should.
That's what i meant with "Sometimes it helps to only go away a bit". Ok, then you have this bug also. Press F1 and look at the day/night scalar. It will not increasing at a constant rate, but it should.
I'll double check. I'm also playing the same save on two different computers and have only noticed it on one of them. Ironically it's the one with an i7 and not the i3 with the underpowered GPU.
Try limiting the threads to 4? (and try to make sure it's the actual CPU cores, not the HT thread). I've heard something about this reducing lag issues before, but only sometimes? (Was never resolved completely to my knowledge).
My scalar is messed up again Can you advice me on a quick fix ?
Hey Nononsch, any news? On my modified game save i played now several weeks without the day/night bug. I had manipulate the game save 2 times at all. And i have still the sleep-bug, but with that i can live.
I have this bug as well. The day/night scalar does update but not constantly and setting the affinity to one core restores normal behaviour. I also tried with varying number of cores just like and Nononsch and got same results.
In my case the problem started when I built a second seabase and got even worse when I built a PRAWN suit and a Cyclops. The fabricator in the second base always was a bit slower than the one in the first base but I just ignored it because it was bearable. After building the PRAWN and Cyclops, all fabricators, including the one in lifepod 5, slowed down.
I was getting so excited about exploring the inactive lava zone in my new PRAWN suit but I guess that wont be happening any time soon now.
I suspect the bug in this thread is just the time precision bug and the 'fix' that was being done earlier in this thread was rolling the game clock back in the save game. That will have a lot of undesirable side-effects as time is used in several locations in the save, like to time when you last slept to prevent people from just repeatedly sleeping. And it sounds like it did break people's ability to sleep.
Sadly I've not heard back either here or on reddit about if the debugging of this I did actually made it to anyone on the team. Anyway, here's a patched version of Assembly-CSharp.dll made per the instructions in that thread which fixes that problem. It replaces the one in C:\Program Files (x86)\Steam\steamapps\common\Subnautica\Subnautica_Data\Managed (back up the original). This is only for the Jun-2017 50032 version of the game, do not use it with the experimental version, it will not be compatible.
Btw, fiddling with cores is unnecessary, it's a crude way of increasing the time between frames which is what's really involved in the bug. If you want to go that route, I'd recommend using rivatuner to lower your FPS instead as it will be much smoother. The reason why you end up with fabricators in different locations running at different speeds is that your FPS differs in those two areas.
A quick test suggests that this fix works. So I guess it really is the time precision bug. Thank you a lot.
I certainly hope that the devs are fixing this bug. They should be. This is a systematic bug that will hit everyone sooner or later. I'm actually quite surprised this has not caused a bigger issue already. I would think that there are lots of people who have played long enough to run into this bug. It can't be that everyone has low FPS.
I suspect the bug in this thread is just the time precision bug and the 'fix' that was being done earlier in this thread was rolling the game clock back in the save game. That will have a lot of undesirable side-effects as time is used in several locations in the save, like to time when you last slept to prevent people from just repeatedly sleeping. And it sounds like it did break people's ability to sleep.
Yes, i found 2 side-effects: 1. The bed can't used after my workaround. 2. Prior rotten food has exorbitant high values for food and water.
The first is no problem for me, i don't need the bed really. But i need a functional Fabricator, Medi Kit Fabricator, Modification Station, Trashcan, Alien Containment etc. etc.
The second is also no problem for me, and the values decrease by time to normal values.
Sadly I've not heard back either here or on reddit about if the debugging of this I did actually made it to anyone on the team. Anyway, here's a patched version of Assembly-CSharp.dll made per the instructions in that thread which fixes that problem. It replaces the one in C:\Program Files (x86)\Steam\steamapps\common\Subnautica\Subnautica_Data\Managed (back up the original). This is only for the Jun-2017 50032 version of the game, do not use it with the experimental version, it will not be compatible.
This sounds interessting, i will test it with my current game (6th). Since yesterday it have also the slow-down-bug and i used also my workaround. But i will undo my workaround so i can test your workaround.
Btw, fiddling with cores is unnecessary, it's a crude way of increasing the time between frames which is what's really involved in the bug. If you want to go that route, I'd recommend using rivatuner to lower your FPS instead as it will be much smoother. The reason why you end up with fabricators in different locations running at different speeds is that your FPS differs in those two areas.
This is a misunderstanding. I never introduced this as workaround, it was simply one of several observations i made, to give the devs much as possible informations.
And seriously, i don't understand why this bug is still not fixed, because it is a real game killer! And this bug is really old. I have this bug since i play SN (summer 2016).
I sent several bug reports via F8 since last year, then via eMail, and then here in forum. I got never any single feedback, so what can i do? Really? Because of this i gave up to send bug reports.
I think with both threads, mine and Belgarel's one, the devs should have enough informations now to fix this bug.
This is a misunderstanding. I never introduced this as workaround, it was simply one of several observations i made, to give the devs much as possible informations.
I meant re Wylfen's reply where he had been trying changing core affinity. It technically is a workaround for some people, but the same effect of dropping the frame rate is better obtained through rivatuner. It's an option for people who don't want to use a patched DLL (or for when they release a new version and break my fix), at least until the bug catches up with whatever minimum FPS can be tolerated.
And seriously, i don't understand why this bug is still not fixed, because it is a real game killer! And this bug is really old. I have this bug since i play SN (summer 2016).
Ditto. When I looked around I found people complaining about it killing their save years ago - it's likely been in since day 1. Communication seems almost non-existent between the players and the devs with this game, it's very different from how Factorio runs its early access. It's more like a traditional development model here rather than an early access one where experience-ruiners need to be prioritized to keep the community in anticipation rather than feeling crushed as that drives word of mouth.
Ditto. When I looked around I found people complaining about it killing their save years ago - it's likely been in since day 1. Communication seems almost non-existent between the players and the devs with this game, it's very different from how Factorio runs its early access. It's more like a traditional development model here rather than an early access one where experience-ruiners need to be prioritized to keep the community in anticipation rather than feeling crushed as that drives word of mouth.
Historically, that hasn't been the case. I don't know why this issue seems to have slipped through the cracks. Normally you'd at least have had an acknowledgement long, long ago. ¯\_(ツ)_/¯
I mean, you've got multiple dev responses on the multi mod. I'm assuming this one was probably an instance where everyone thinks someone else has responded to it?
Excellent, hope it makes it for the feature-complete build. Did you also get the screenshot bug in that thread added to trello? The game continuously scans the screenshot folder (seems to be something to do with thumbnailing but I didn't bother trying to fix it) and the number of screenshots you have in there can wreck FPS.
Did you also get the screenshot bug in that thread added to trello? The game continuously scans the screenshot folder (seems to be something to do with thumbnailing but I didn't bother trying to fix it) and the number of screenshots you have in there can wreck FPS.
Ok this is gonna sound really weird but I've tried it multiple times now and it seems to have the same result at each try :
The bug occurs when I'm standing in front of the fabricator
If I access it from the right side, or move to the right, it gets even slower...
But it seems to work just fine when I access it from the left side.
I have no idea why, I doubt it's gonna help solve the bug but it might work for some players experiencing this problem. Maybe.
The bug occurs when I'm standing in front of the fabricator
If I access it from the right side, or move to the right, it gets even slower...
But it seems to work just fine when I access it from the left side.
Your FPS is likely significantly different when looking in those two different directions. Try my patched Assembly-CSharp.dll (for the stable build) to see if this bug was causing your issue.
I answer you here. Because of your topic title i would never click your topic to search for a solution for the slow-down-bug. So thank you for your answer here in my topic.
The last days i tested your patched DLL very well. First i removed my own workaround, then i installed your DLL. I have played my 6th game like with my own workaround, so i done all things i would normally do. I found no single problem with the modified DLL. Now i can play SN normal and all devices (Fabricator, Grow Beds, Trashcan etc.) works as intended. And also the day/night cycle and the moon animation is back to normal operation. The effect is the same like with my workaround (patched game save) but without side-effects.
You have done a damn good work!
If i understand this correct, a simple wrong variable type is the cause of so much problems? I mean, i write programs since more than 30 years in several languages, but in this case i would never had the assumption that the variable precision was too low.
If i understand this correct, a simple wrong variable type is the cause of so much problems?
Yeah, a float is just way too small for what they're doing with it. Within the first hour of gameplay the error in the game speed is already beyond 10% for most people and eventually it will get so bad that time stutters depending on FPS and later will stop.
The bug occurs when I'm standing in front of the fabricator
If I access it from the right side, or move to the right, it gets even slower...
But it seems to work just fine when I access it from the left side.
Your FPS is likely significantly different when looking in those two different directions.
Oh, that actually make sense now. Less weird than I thought.
@jonasgrohmann The problem here is that DayNightSpeed's timePassed variable is a float, and once that float gets to a certain size, precision is lost and adding small deltaTimes literally has no effect.
I implemented a cheap solution in 51772. I added a double to track time passed, and use OnProtoDeserialize to maintain backwards compatability. The fix is "cheap" because DayNightSpeed casts this double to a float when returning it to callers. This works - in the sense that timePassed will continue to go up - but there are still potential precision problems when casting from a large double to a float. Only actually a problem when the play session day gets into the hundreds, but still potentially a problem.
I'm currently working on the more complete fix, where DayNightSpeed returns a double and calling code adjusts accordingly. Unfortunately there are quite a few systems that lean on this field, so I have to fix them up accordingly. (And sometimes they are in turn serializing floats and I have to figure out if it's worth the hassle to add serialized doubles to replace the floats).
@jonasgrohmann The problem here is that DayNightSpeed's timePassed variable is a float, and once that float gets to a certain size, precision is lost and adding small deltaTimes literally has no effect.
I implemented a cheap solution in 51772. I added a double to track time passed, and use OnProtoDeserialize to maintain backwards compatability. The fix is "cheap" because DayNightSpeed casts this double to a float when returning it to callers. This works - in the sense that timePassed will continue to go up - but there are still potential precision problems when casting from a large double to a float. Only actually a problem when the play session day gets into the hundreds, but still potentially a problem.
I'm currently working on the more complete fix, where DayNightSpeed returns a double and calling code adjusts accordingly. Unfortunately there are quite a few systems that lean on this field, so I have to fix them up accordingly. (And sometimes they are in turn serializing floats and I have to figure out if it's worth the hassle to add serialized doubles to replace the floats).
I implemented a cheap solution in 51772. I added a double to track time passed, and use OnProtoDeserialize to maintain backwards compatability. The fix is "cheap" because DayNightSpeed casts this double to a float when returning it to callers. This works - in the sense that timePassed will continue to go up - but there are still potential precision problems when casting from a large double to a float. Only actually a problem when the play session day gets into the hundreds, but still potentially a problem.
I marked this passage to bring up a point: Why do the game days run so fast on 4546B anyways? Not only is it immersion breaking, but apparently after 100+ days of play the performance of the game is crippled. Now, I know the problem is being worked on, but why not just make the time pass by more slowly instead? The performance is then saved even after many hours of play (due to time passing much slower) and the aesthetics of the game are preserved, since you don't feel like you're playing flashlight tag with nature.
Take for example, Square-Enix's first MMORPG, "Final Fantasy XI". The game runs at an accelerated timeframe as well, where one game day (24 game hours) is only 57 minutes and 36 seconds long real time. This is in account to 25 game days passing by over the course of 24 real hours (60 x 24 / 25 = 57.6). The benefit of this is that for certain time-related events (be it missions, quests or fighting certain Notorious Monsters) that require certain objectives to be completed on specific game days to achieve your goals. This way you can plan ahead and see if you're available for a specific game day to meet your needs, and the slightly-shorter ratio means that specific game days appear at different times of the day in real life.
Now, does Subnautica need its days to run that slowly? No, it certainly doesn't. I'd be perfectly happy if a full day cycle on 4546B took say only thirty minutes to run. Having a longer day means you can forage for items and store solar power for longer, especially in the early game when supplies are light, support is limited and you have meager survival options. Likewise, having a longer night means more time without solar energy, having to brave the wilds for food and items, and needing to rely more on flashlights and flares in order to explore.
While I'm on the subject, let's talk about the science of Subnautica. People might say "Bruh! It's an alien planet, anything goes here!" Well, let's compare it to other known celestial bodies. Jupiter has the shortest day/night cycle of any planet in our solar system, but it's just a mere 9 hours and 55 minutes - their days last far longer than that of 4546B's. Jupiter is also the largest planet in our solar system; 4546B is much smaller in size comparatively speaking. Now it's not a completely fair comparison, as due to game engine limitations we obviously can't have a landmass to explore as large as an actual planet. But for the available landmass that's explorable, it's safe to say 4546B is closer in size to possibly Mercury, the smallest planet in our solar system. (Sorry, Pluto...) How long is Mercury's day/night cycle then? 58 days, 15 hours and 30 minutes.
Now! I'm not going into all of this to make fun of the game or point fingers at any of the developers, that's not my intention at all! I love and appreciate all of the hard work you guys are putting into Subnautica! I just... really feel that having a longer day/night cycle in the game would be more beneficial overall, and make the game feel more lifelike and realistic. It might also help improve the overall performance of the game too - if the floating point calculations cause problems after many days passing, then surely this would help issues even after other corrections are made. All I ask, is that this idea be considered - be it an actual change or a custom game selection. Thank you all for your hard work and your time on this game!
I implemented a cheap solution in 51772. I added a double to track time passed, and use OnProtoDeserialize to maintain backwards compatability. The fix is "cheap" because DayNightSpeed casts this double to a float when returning it to callers.
Great, that's exactly the same as the temp fix I have in the patched DLL. So it won't need updated when they release the next stable version.
So it won't need updated when they release the next stable version.
Yeah, it seems that they are on the way to fix this old bug finally. And i mean, several hundred ingame days is not really much. ^^ If the player wants to play this game really a long time, this should be technically possible. So the "final" fix would be really welcome.
I marked this passage to bring up a point: Why do the game days run so fast on 4546B anyways? Not only is it immersion breaking, but apparently after 100+ days of play the performance of the game is crippled. Now, I know the problem is being worked on, but why not just make the time pass by more slowly instead? The performance is then saved even after many hours of play (due to time passing much slower) and the aesthetics of the game are preserved, since you don't feel like you're playing flashlight tag with nature.
The game time scale is almost entirely unrelated to this issue. Internally, the game is tracking time in wall-clock seconds since epoch regardless of how fast a game day passes (epoch being the beginning of the day you wake up in the pod, which happens on
Saturday May 07, 2287 at 09:36am
). So tracking starts with 480 wall-clock seconds already elapsed to get you up to that point in the game day (480 * 1200 game seconds), and from there out it's all just wall-clock seconds regardless of how fast game days pass other than when you use a bed. The unscaled wall-clock seconds are where this precision problem occurs. But it's an easy fix.
The rate a game day passes is likely chosen for what they found fun (it's the same as Minecraft's, and I personally like it) and also for immersion reasons - you'll probably spend about a 'year' on the planet rather than having built all your vehicles and bases overnight. That'd be one hell of an all-nighter on decaf.
I marked this passage to bring up a point: Why do the game days run so fast on 4546B anyways? Not only is it immersion breaking, but apparently after 100+ days of play the performance of the game is crippled. Now, I know the problem is being worked on, but why not just make the time pass by more slowly instead? The performance is then saved even after many hours of play (due to time passing much slower) and the aesthetics of the game are preserved, since you don't feel like you're playing flashlight tag with nature.
I had a similar feeling about the day length. But, when I used the console commands to stretch the scalar, I found out much to my chagrin that it also stretched fabricator times and anything else time-related. So...I just decided to put up with the strobe light day cycle.
Ideally, though, I would like the time to stretch a bit. Maybe...25% or so.
Comments
My computer
Motherboard: ASUS Maximus VIII Hero (Skylake)
CPU: i5-6600K
GPU: GTX 970
RAM: 16 GB (G Skill, 3200)
SSD: 1 Samsung 850 Pro (256 GB), 1 Samsung 850 EVO (500 GB)
HDD: 2 WD Raptor (1000 GB, 500 GB), 1 Seagate (2000 GB)
Affected features
This bug affect not only the fabricators, it affect several features. Here the complete list of all slowed down features i found:
In this situation the game is not really playable.
Tries to solve the problem
Observations
It have to do with the Day/Night scalar. I am a programmer too, but no UWE-dev so i don't know is this only a symptom or the cause. If the bug is present in the game-save, then this scalar will not increase constantly. It increase only a bit by some actions:
More observations and hints
Test if the bug is present
Press F1. Look at the Day/Night scalar, if this is increase constantly then all is fine. If this is not increase constantly or is frozen then the bug is present.
Assumptions
Need to be confirmed
Divers, please post here if you can reproduce it.
I'll double check. I'm also playing the same save on two different computers and have only noticed it on one of them. Ironically it's the one with an i7 and not the i3 with the underpowered GPU.
Hey Nononsch, any news? On my modified game save i played now several weeks without the day/night bug. I had manipulate the game save 2 times at all. And i have still the sleep-bug, but with that i can live.
In my case the problem started when I built a second seabase and got even worse when I built a PRAWN suit and a Cyclops. The fabricator in the second base always was a bit slower than the one in the first base but I just ignored it because it was bearable. After building the PRAWN and Cyclops, all fabricators, including the one in lifepod 5, slowed down.
I was getting so excited about exploring the inactive lava zone in my new PRAWN suit but I guess that wont be happening any time soon now.
Sadly I've not heard back either here or on reddit about if the debugging of this I did actually made it to anyone on the team. Anyway, here's a patched version of Assembly-CSharp.dll made per the instructions in that thread which fixes that problem. It replaces the one in C:\Program Files (x86)\Steam\steamapps\common\Subnautica\Subnautica_Data\Managed (back up the original). This is only for the Jun-2017 50032 version of the game, do not use it with the experimental version, it will not be compatible.
Btw, fiddling with cores is unnecessary, it's a crude way of increasing the time between frames which is what's really involved in the bug. If you want to go that route, I'd recommend using rivatuner to lower your FPS instead as it will be much smoother. The reason why you end up with fabricators in different locations running at different speeds is that your FPS differs in those two areas.
I certainly hope that the devs are fixing this bug. They should be. This is a systematic bug that will hit everyone sooner or later. I'm actually quite surprised this has not caused a bigger issue already. I would think that there are lots of people who have played long enough to run into this bug. It can't be that everyone has low FPS.
Yes, i found 2 side-effects: 1. The bed can't used after my workaround. 2. Prior rotten food has exorbitant high values for food and water.
The first is no problem for me, i don't need the bed really. But i need a functional Fabricator, Medi Kit Fabricator, Modification Station, Trashcan, Alien Containment etc. etc.
The second is also no problem for me, and the values decrease by time to normal values.
This sounds interessting, i will test it with my current game (6th). Since yesterday it have also the slow-down-bug and i used also my workaround. But i will undo my workaround so i can test your workaround.
This is a misunderstanding. I never introduced this as workaround, it was simply one of several observations i made, to give the devs much as possible informations.
And seriously, i don't understand why this bug is still not fixed, because it is a real game killer! And this bug is really old. I have this bug since i play SN (summer 2016).
Just wanted to be sure the info was delivered where it's needed.
Fix thread:
https://forums.unknownworlds.com/discussion/152299/the-cause-of-two-fps-killers-day-number-framerate-and-screenshots
I sent several bug reports via F8 since last year, then via eMail, and then here in forum. I got never any single feedback, so what can i do? Really? Because of this i gave up to send bug reports.
I think with both threads, mine and Belgarel's one, the devs should have enough informations now to fix this bug.
I meant re Wylfen's reply where he had been trying changing core affinity. It technically is a workaround for some people, but the same effect of dropping the frame rate is better obtained through rivatuner. It's an option for people who don't want to use a patched DLL (or for when they release a new version and break my fix), at least until the bug catches up with whatever minimum FPS can be tolerated.
Ditto. When I looked around I found people complaining about it killing their save years ago - it's likely been in since day 1. Communication seems almost non-existent between the players and the devs with this game, it's very different from how Factorio runs its early access. It's more like a traditional development model here rather than an early access one where experience-ruiners need to be prioritized to keep the community in anticipation rather than feeling crushed as that drives word of mouth.
Historically, that hasn't been the case. I don't know why this issue seems to have slipped through the cracks. Normally you'd at least have had an acknowledgement long, long ago. ¯\_(ツ)_/¯
I mean, you've got multiple dev responses on the multi mod. I'm assuming this one was probably an instance where everyone thinks someone else has responded to it?
Excellent, hope it makes it for the feature-complete build. Did you also get the screenshot bug in that thread added to trello? The game continuously scans the screenshot folder (seems to be something to do with thumbnailing but I didn't bother trying to fix it) and the number of screenshots you have in there can wreck FPS.
https://trello.com/c/HyZ45dFS/6543-fix-screenshot-manager-performance
The bug occurs when I'm standing in front of the fabricator
If I access it from the right side, or move to the right, it gets even slower...
But it seems to work just fine when I access it from the left side.
I have no idea why, I doubt it's gonna help solve the bug but it might work for some players experiencing this problem. Maybe.
Your FPS is likely significantly different when looking in those two different directions. Try my patched Assembly-CSharp.dll (for the stable build) to see if this bug was causing your issue.
I answer you here. Because of your topic title i would never click your topic to search for a solution for the slow-down-bug. So thank you for your answer here in my topic.
The last days i tested your patched DLL very well. First i removed my own workaround, then i installed your DLL. I have played my 6th game like with my own workaround, so i done all things i would normally do. I found no single problem with the modified DLL. Now i can play SN normal and all devices (Fabricator, Grow Beds, Trashcan etc.) works as intended. And also the day/night cycle and the moon animation is back to normal operation. The effect is the same like with my workaround (patched game save) but without side-effects.
You have done a damn good work!
If i understand this correct, a simple wrong variable type is the cause of so much problems? I mean, i write programs since more than 30 years in several languages, but in this case i would never had the assumption that the variable precision was too low.
@Obraxis
Okay, thx for feedback. This is the only real tech problem i have with SN. All other problems are easy to handle or circumvent.
Yeah, a float is just way too small for what they're doing with it. Within the first hour of gameplay the error in the game speed is already beyond 10% for most people and eventually it will get so bad that time stutters depending on FPS and later will stop.
I marked this passage to bring up a point: Why do the game days run so fast on 4546B anyways? Not only is it immersion breaking, but apparently after 100+ days of play the performance of the game is crippled. Now, I know the problem is being worked on, but why not just make the time pass by more slowly instead? The performance is then saved even after many hours of play (due to time passing much slower) and the aesthetics of the game are preserved, since you don't feel like you're playing flashlight tag with nature.
Take for example, Square-Enix's first MMORPG, "Final Fantasy XI". The game runs at an accelerated timeframe as well, where one game day (24 game hours) is only 57 minutes and 36 seconds long real time. This is in account to 25 game days passing by over the course of 24 real hours (60 x 24 / 25 = 57.6). The benefit of this is that for certain time-related events (be it missions, quests or fighting certain Notorious Monsters) that require certain objectives to be completed on specific game days to achieve your goals. This way you can plan ahead and see if you're available for a specific game day to meet your needs, and the slightly-shorter ratio means that specific game days appear at different times of the day in real life.
Now, does Subnautica need its days to run that slowly? No, it certainly doesn't. I'd be perfectly happy if a full day cycle on 4546B took say only thirty minutes to run. Having a longer day means you can forage for items and store solar power for longer, especially in the early game when supplies are light, support is limited and you have meager survival options. Likewise, having a longer night means more time without solar energy, having to brave the wilds for food and items, and needing to rely more on flashlights and flares in order to explore.
While I'm on the subject, let's talk about the science of Subnautica. People might say "Bruh! It's an alien planet, anything goes here!" Well, let's compare it to other known celestial bodies. Jupiter has the shortest day/night cycle of any planet in our solar system, but it's just a mere 9 hours and 55 minutes - their days last far longer than that of 4546B's. Jupiter is also the largest planet in our solar system; 4546B is much smaller in size comparatively speaking. Now it's not a completely fair comparison, as due to game engine limitations we obviously can't have a landmass to explore as large as an actual planet. But for the available landmass that's explorable, it's safe to say 4546B is closer in size to possibly Mercury, the smallest planet in our solar system. (Sorry, Pluto...) How long is Mercury's day/night cycle then? 58 days, 15 hours and 30 minutes.
Now! I'm not going into all of this to make fun of the game or point fingers at any of the developers, that's not my intention at all! I love and appreciate all of the hard work you guys are putting into Subnautica!
Great, that's exactly the same as the temp fix I have in the patched DLL. So it won't need updated when they release the next stable version.
Yeah, it seems that they are on the way to fix this old bug finally. And i mean, several hundred ingame days is not really much. ^^ If the player wants to play this game really a long time, this should be technically possible. So the "final" fix would be really welcome.
The game time scale is almost entirely unrelated to this issue. Internally, the game is tracking time in wall-clock seconds since epoch regardless of how fast a game day passes (epoch being the beginning of the day you wake up in the pod, which happens on
The rate a game day passes is likely chosen for what they found fun (it's the same as Minecraft's, and I personally like it) and also for immersion reasons - you'll probably spend about a 'year' on the planet rather than having built all your vehicles and bases overnight. That'd be one hell of an all-nighter on decaf.
I had a similar feeling about the day length. But, when I used the console commands to stretch the scalar, I found out much to my chagrin that it also stretched fabricator times and anything else time-related. So...I just decided to put up with the strobe light day cycle.
Ideally, though, I would like the time to stretch a bit. Maybe...25% or so.