pototo
Terrarian
- Steam or GOG
- Steam
- Single Player/Multiplayer
- Both
- Operating System
- Windows 10
- Terraria Version
- 1.4.4.9
- Controls Used
- Keyboard/Mouse
stream footage: Twitch
additional footage: https://media.discordapp.net/attach...0939a1f149c9eebc810f707a8256cd67d60da9e2e8a1&
so basically, when generating a new world, the game takes the position of the moon to be the current time. here is an explaination by RHgeKZ on the speedruner discord.
-When in a world, time is advanced using the main thread (in Main.UpdateTime())
-When loading a world, the call to SetOngoingToTemps(), which sets Main.time to the world's saved time, is on some worker thread
-Putting a breakpoint on each of them, it seems that SetOngoingToTemps() normally occurs slightly before the first time UpdateTime() is called (which makes sense). But if you artificially lag the worker thread with Thread.Sleep(5000) directly before the SetOngoingToTemps() call, they can happen in the opposite order, showing that they're technically in a race condition even though SetOngoingToTemps() is almost always first.
If in normal gameplay, by some miracle, the worker thread is so laggy that SetOngoingToTemps() is called at the exact same time as the first time the world time is advanced, it could end up running like this:
1. It's night in the menu but day in the world you're loading, so Main.time is night and _tempTime is day.
2. UpdateTime() reads Main.time to be night and begins computing its new value, but is interrupted by the worker thread before it can write back to Main.time.
3. SetOngoingToTemps() runs and sets Main.time to _tempTime, so day.
4. UpdateTime() finishes computing and sets Main.Time with its outdated result, bringing it back to night.
5. The next time UpdateTime() is called, it's still night, so it progresses as if it were a normal night.
TLDR; if this theory is correct, it's a multithreading issue. It's also hardware-dependent and impossible to manipulate.
i guess its not really a big deal if not changed, but still would be nice to see it fixed
additional footage: https://media.discordapp.net/attach...0939a1f149c9eebc810f707a8256cd67d60da9e2e8a1&
so basically, when generating a new world, the game takes the position of the moon to be the current time. here is an explaination by RHgeKZ on the speedruner discord.
-When in a world, time is advanced using the main thread (in Main.UpdateTime())
-When loading a world, the call to SetOngoingToTemps(), which sets Main.time to the world's saved time, is on some worker thread
-Putting a breakpoint on each of them, it seems that SetOngoingToTemps() normally occurs slightly before the first time UpdateTime() is called (which makes sense). But if you artificially lag the worker thread with Thread.Sleep(5000) directly before the SetOngoingToTemps() call, they can happen in the opposite order, showing that they're technically in a race condition even though SetOngoingToTemps() is almost always first.
If in normal gameplay, by some miracle, the worker thread is so laggy that SetOngoingToTemps() is called at the exact same time as the first time the world time is advanced, it could end up running like this:
1. It's night in the menu but day in the world you're loading, so Main.time is night and _tempTime is day.
2. UpdateTime() reads Main.time to be night and begins computing its new value, but is interrupted by the worker thread before it can write back to Main.time.
3. SetOngoingToTemps() runs and sets Main.time to _tempTime, so day.
4. UpdateTime() finishes computing and sets Main.Time with its outdated result, bringing it back to night.
5. The next time UpdateTime() is called, it's still night, so it progresses as if it were a normal night.
TLDR; if this theory is correct, it's a multithreading issue. It's also hardware-dependent and impossible to manipulate.
i guess its not really a big deal if not changed, but still would be nice to see it fixed
Last edited:
