With StreamingEnabled toggled on, when you delete a part under a PersistentPerPlayer model on the client, with the client set as a persistent player, it’ll revert to an Atomic-like behavior when it’s out of max streaming radius with Opportunistic enabled, or when it streams out with LowMemory streaming behavior.
This makes the behavior of PersistentPerPlayer more inconsistent - even if I delete the entire model, I don’t want it replacing the model with a server-copy, because I may want to make changes on the client-side. I can explain my use case more in depth, but I felt that this was worthy of a bug report in general, as the behavior isn’t documented.
If it somehow is intentional, I hope that more documentation could be provided on PersistentPerPlayer, as well as streaming out behavior, as the current section is lackluster and doesn’t get deep into the specifics of streaming out, and how we need to code our experiences on the client-side to react to the same content streaming in and out.
Expected behavior
PersistentPerPlayer should act like an Atomic model until a player is added as a persistent player through Model/AddPersistentPlayer. It should stay as a persistent model for that player (forced streamed in, can’t be streamed out) until you call Model/RemovePersistentPlayer.
By removing any parts under the Model, it should not cause it to revert to an Atomic model, but instead stay under Workspace without replacing it with a server copy. If I deleted the model, I’d expect it to stay gone forever, just as if StreamingEnabled was toggled off - since that’s how I think most of us think Persistent works.
A private message is associated with this bug report