Right now, Cameras are not replicated even though they are used for ViewPortFrames. They are also automatically deleted from Explorer wasting time and effort setting them up.
I propose an alternative to avoid breaking anything else. Create a new object type called PointObject which only contains the position and orientation and can be replicated.
Allow these point objects to be used in ViewPortFrame or anything else on the client which uses camera.
This would be easy to add, maintain backwards compatibility, and allow us to set up thumbnail icons to be used in custom inventories without having to make parts of 0.00001 size, no physics, no mass, etc.. and then convert those into cameras on the client, then apply those to the ViewPortFrames.
Thanks, I didn’t see that. That is helpful, but we still have to translate that into a camera instead of being able to plug it directly into a ViewPortFrame
Attachments are meant to be “Point” instances! They can’t be used where a camera is because the places that need a camera also need the data of the near plane, far plane, focus, camera type, etc. The real solution here is for us to figure out how we can make cameras replicate in the scenarios they need to while maintaining backwards compatibility, whether that means carefully changing things or making a new type of camera entirely.
New viewport camera that has the essentials would be nice, can use both it and the camera instance since some viewport stuff depends on the currentcamera
Is it still possible to support a multi camera system sometime?
Like I do not mean a ViewportFrame, specifically like a 2nd camera for things like rear view mirrors. Obviously the 2nd camera will have a very high cost, so if such a camera instance was supported you could maybe specify things like, how far this camera renders and so on.
