Disable unstable join-point live cache

[MhaWay]

Summary

• stop rearming join-point live render/world caches in SaveLoad
• keep explicit Clear() and null resets instead of commenting out the copyFrom holders so stale static state cannot survive
• remove the dead SaveAndReload cache flag and update the remaining join-point callsite to the parameterless method
• document that the live-cache path was unstable and the measured gain of about half a second did not justify keeping it

Testing

• dotnet build .\Source\Client\Multiplayer.csproj -c Release
• dotnet build .\Source\Server\Server.csproj -c Release

[Copilot]

Pull request overview

This PR disables the previously optional “live cache” rearming path during join-point creation by removing the SaveAndReload cache flag and always clearing/nulling the static cache holders after save, keeping reload behavior deterministic and avoiding unstable reuse of render/world objects.

Changes:

• Remove the cache parameter from SaveLoad.SaveAndReload and delete the associated cache-rearm branch.
• Always clear/null join-point cache holder statics after saving, with an explanatory comment about instability vs. small perf gain.
• Update the join-point creation callsite to use the new parameterless SaveAndReload() API.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
Source/Client/Saving/SaveLoad.cs	Removes cache-rearm option from SaveAndReload and always clears/nulls static cache holders after save.
Source/Client/AsyncTime/AsyncWorldTimeComp.cs	Updates join-point snapshot creation to call the new parameterless SaveAndReload().

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[notfood]

A revert? What happened?

[MhaWay]

A revert? What happened?

Render issue still happening, really depends about alive objects that corrupt everything, ao i tried to cache only static or reusable stuff more deeply but it still are risks of corruption and the difference between non cached and cached are like 2.300 ms(cached) and 2800 ms (no cache) and i think that unless we can't handle the reload(the heaviest part) in a different way, then there is no reason to risk it for 500ms

[MhaWay]

And tbh at this point i found more useful and efficient to find a way to implement map streaming (load and unload other players map) so this could improve the tps for those who play with lower end pc or similar

[notfood]

Related: #926

It shouldn't affect TPS. Did it impact things negatively for multifaction? I didn't notice anything for coop.

[MhaWay]

If someone plays with a friend with a slower pc, everyone slow down

[MhaWay]

But this is not related to caching

[notfood]

I'm very hesitant to disable the cache permanently. Can you explain more about your rationale? What is it doing that is causing render burn? Can I reproduce it?

[MhaWay]

Is not related to multifaction, but in general when a joinpoint is armed

[MhaWay]

Safest way to handle the save and reload

[notfood]

If you're permanently disabling the cache, you need to remove everything under CacheForReloading.cs because it's not used anywhere else, then rework the logic.