It’d just make retrieving the parts slower. There’s a reason RAM exists.
StreamX will not help at all for a game with 150k parts, because according to your reply, the server will apparently crash before it can upload it to StreamX. What kind of example is this?
And, actually, with StreamingEnabled and a game with 150k parts, I got decent FPS.
And the server was using ~950 MB of memory;
That is comfortably below what I think is a Roblox server’s maximum memory limit (4 GB).
As they need to be. The majority of the client’s performance will not be lost by something simply existing in memory, that’s the reason LevelOfDetail or LoD exists basically everywhere. The tradeoff is better performance because the client will render a more basic model from farther away, but for the cost of more memory usage, which will barely even matter most of the time.
Not storing something leads to problems like getting stuck in a tree;
Horrendous 150+ KB network spikes;
And of course, very visible pop-in!
There’s actually two modes, “LowMemory” and “Opportunistic”. LowMemory makes streaming enabled unload stuff only when it thinks there’s not much memory left, whilst Opportunistic will unload stuff the moment it thinks it isn’t in use.
This makes no sense. Performance is dictated by the weakest link in the chain. Just because you have StreamingEnabled does not mean your module will function any better.
I am not trying to discredit all of the work you’ve done on this, but the way you’ve gone about implementing this is incredibly flawed and broken. Just because you store assets on an external server does not negate the cost of the server having to redownload parts every 15 seconds, not to mention that that is a ludicrously long time for games.