As a Roblox developer, it is currently too hard to have server sided modules and instances which will not ever replicate to clients, and will behave consistently in Team Create servers, and its additionally too hard to create Cameras for use in ViewportFrames without a script.
If Roblox is able to address this issue, it would improve my development experience because it would reduce usage of Camera instances for this behaviour, which is hacky, and leads to very unexpected results, especially in Team Create, and it would generally resolve a lot of issues, such as usage of Cameras in ViewportFrames mentioned in topics linked below.
What this could entail for the replication behaviour of Cameras:
As requested here:
This would allow for Camera instances to start being replicated to clients, and in TC to the server, which would fix usage within ViewportFrames as seen in this bug report (related to ViewportFrames).
This could, however, possibly change behaviour in old (or recent) games using Cameras to block replication to clients if it was not opt in, but, would likely in a majority of cases not cause anything bad to happen.
Here are a list of problems I can think of where a change to Camera replication like this could potentially cause game-breaking behaviour:
- A LocalScript is contained within the Camera and is expected not to run.
- Cameras are recreated on clients by client code where modifications are made to the specificly creaeted camera, and other scripts are not expecting a second Camera. (E.g. in ViewportFrames)
- Instances with special behaviour are contained within the Camera, such as Explosions, and the Camera is in a location where the Instances can activate their behaviour.
I would like for it to be opt-in, but that likely won’t need to be the case. The solution I propose below offers a way for this to occur smoothly. The only other bigger side effects I can think of if legacy behaviour wouldn’t be kept would be that devs wanting to protect server sided ModuleScript source from decompilation would then have them exposed to the client.
A few solutions
Personally, I believe that a few elegant solutions to this problem would be to have a property on instances, or perhaps a single class such as a Folder getting a unique property, or a unique class which carries the above behaviour. This would allow for clauses to exist within Team Create to prevent the sorts of desync issues Cameras currently cause (as mentioned in my bug report above)
I would propose that the best solution would be that all
Instances get a
CanReplicate property which is by default enabled. If disabled, the instance in live servers, not TC servers would simply not replicate to clients at any time, and, if it already had replicated, it would be immediately removed. In the case of services and Terrain, this property shouldn’t take effect and I’d expect it to be hidden/inactive. Instances within services such as ServerStorage and ServerScriptService I’d expect to keep the property available as well since instances could move out of these locations.
In the aforementioned changes to Camera behaviour, an elegant way to take advantage of a property like this for legacy purposes would be to in the case of old Cameras, make the property
false by default. Newly inserted Cameras would then, like other instances get a
true value. Additionally, this would allow for the game to make the
CurrentCamera of the workspace non replicable which keeps existing behaviour.
This would be extremely useful for developers who wish to protect their ModuleScripts that are only used on the server from being decompiled because it would allow a supported way to do this that works in Team Create. This is currently one of the primary use cases of how Cameras currently behave. Additionally, developers who want certain instances to remain server only would be able to do so without being restricted to ServerScriptService or ServerStorage.
Lastly, this would allow for Camera usage in ViewportFrames to work within live servers and Team Create, and would allow for ThumbnailCameras and other Cameras to properly replicate in Team Create and live servers.
Mockups of what I think this could look like
Here is a mockup of what I think my feature request could look like in both cases (Using some mockup code from my own projects):
On the client, these would then appear as the following:
List of relevant bug reports & feature requests: