Disable unstable join-point live cache rearming

[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]

Simply, open a standalone server, do the configuration process(it will close at the end so you will just reopen), enter, and try to save.

[MhaWay]

This affect the standalone server cause is used only there

[MhaWay]

Is not related to multifaction, but in general

[MhaWay]

You made me realize something.
The issue happen only on standalone server with the CreateJoinPoint who enter in SaveAndReload() that then follow with SendStandaloneMapSnapshots and SendStandaloneWorldSnapshot in AsyncWorldTimeComp.cs.

[MhaWay]

inside hosted game the follow-up is different, no map/world snapshot there, only SendGameData

[MhaWay]

Ill close this PR, i found something to test on, probably i can isolate even more the issue and then understand if the cache must be removed only from standalone case or even fix the issue