Closed L3tum closed 2 weeks ago
I just noticed that I think from the change to the worksetTemperature there's now an issue with essentially "infinite energy" being pulled, since the calculation takes temperatures
rather than worksetTemperatures
into account. I need to think a second on how it could be mitigated without impacting the multithreading too much, so I converted it into a draft. My first instinct would be to, instead of having a worksetTemperature, save the temperatureChange and then cumulatively applying it. It would reduce performance a bit but not by much. I'm not all that well versed in energy simulation. If you have any input or any sources I could read I'd appreciate it. Most of what I can find is highly scientific and less about the nitty gritty of performantly simulating it.
The few things I've found, i.e. 1 and 2 seem to simply accept the error as is from what I could tell. That feels a bit weird although is probably acceptable for a game.
lol, disregard the above. I thought of it as a discrete energy transfer rather than simultanously solving the same function on multiple inputs. I got spooked by the temperature on a testmap steadily rising, but it reached an equilibirum after ~2 ingame hours. I'm gonna add another comment to the code to explain this as well just to make sure. At least this also means we could get another significant speed-up with some SIMD acceleration, especially around the terrain code I guess.
That mentioned, I did also try to have the different components (terrain, cell, ambient) in different functions so that they could be throttled individually as well, but I found it made the code a whole lot more unreadable. At least the melting code could be separated, but I'll let you look over this first to see what you think of it.
Hey, this is a great effort, and something I wanted but never had the heart to do. I have almost no experience with multi-thread programming. All I know about it is that it may be a hell to debug. But if the code works well, it's a huge improvement.
Don't forget to mark the PR as ready when it is, so that I could test it and see how best to integrate it.
Hey @GarwelGarwel , thank you! I had a few issues with a borked Rimworld installation, but after reinstalling I could test the ice/snow melting and it works for both terrain and cell and replaces an ice sheet with water. That was the major thing that I didn't know if it would work accurately in multithreading, but it does, so the PR for me is gtg and I'll undraft it in a sec. Regarding SIMD I noticed Unity is still using Mono, which doesn't support the newer SIMD stuff that .NET Core 3 and later put out. Honestly thought it had already moved over at least for desktop, since they published plans for that a few years ago. So that's unfortunately a no-go for now, afaik
Hallo!
I like to build base and have big map. I noticed a while back that Celsius didn't seem to scale all that well with larger map sizes and got curious how it did its thing. From that this change was created, which I've been using successfully in both "standalone" and a larger (~200 mods) modpack.
Changes
#if DEBUG
conditional compilation was removed to be able to actually activate debug logging at runtime without recompilingParallel.ForEach
)Results
Questions
I'm new to Rimworld modding and know Rimworld and its creators don't really like Multithreading. I tested these changes extensively though, but:
Further work
float.MinValue
)I'm happy to discuss this change with you and I'd be fine if you would want to make it a setting or fork or something like that. I haven't published it to the Workshop, just forked for the code commit.