If you’re open to this option, you can store terrain as different regions and then load them in with the rest of the individual maps for each round.
1 Like
This just isn’t true anymore and I’m annoyed that this is still being parroted around.
If your game properly accounts for streaming, you will have very few, if any, issues due to things being streamed in and out.
You should not need to rely on controlling it because you will almost always be fighting against it. If you want something to always be visible, make it clientside. You probably shouldn’t be doing this with anything other than large static meshes, but you can make it work with moving things as well.
The loading and unloading is far faster than you can implement using the Lua API. If you can use it, you should be using it. My game has a smooth terrain map around 4096x4096 studs and it’s playable on many phones. In fact, the main performance bottleneck in my game is in my own Lua code.
It’s important to remember good practices when developing a game. Streaming changes the requirements, but they’re certainly not impossible to follow. You should be writing code that’s tolerant of the reality of the data model even if you’re not using streaming.
The important thing to remember is that only parts are currently streamed. The model structure is replicated upfront completely normally. Therefore, you should be setting a PrimaryPart on your models and making sure the property has been set before you try to do anything with that model. If you follow that paradigm, you will have no problem.
4 Likes
Streaming is a very powerful feature, yes, but many developers will argue that it could be better implemented. I strongly disagree with the point of you not being able to control what gets streamed in and out, because you should be allowed to.