MoveTo and PivotTo incorrectly allow the Workspace to be moved. These methods are intended to move BaseParts and Models, not Services.
Here is a example script u can run:
workspace:MoveTo(Vector3.new(9e9,9e9,9e9))
workspace:PivotTo(CFrame.new(9e9,9e9,9e9))
Youâd be better off making a feature request for this. Definitely not a bug, and also something you.. shouldnât use..?
I would argue its incorrectly classified and is a bug, Workspace is a service, its not a âobject in the physical locationâ Same with MoveTo
u can see in your screenshot that workspace inherits from worldroot, does that big, long word sound like an individual physical object to you?
I donât think this is necessarily a bug.
Workspace isnât a regular instance or a service in the same sense as something like Players or ReplicatedStorage. WorldModel inherits from WorldRoot for the same reason that it inherits from PVInstance, Position-Velocity instance. Since PVInstance exposes those functions, Workspace inheriting those methods is consistent with the class hierarchy. The fact that calling them on Workspace doesnât have an especially intuitive use case doesnât necessarily mean the methods should be removed or hidden.
Also, you shouldnât go based off that everything that is a âserviceâ must be parented under game directly and be its own thing. Things like UserGameSettings and similar are services aswell, but are not accessible from the regular GetService():
workspace.Position property actually move all models within it, which aligns with the term of âModelâ. This is useful for the future possibility of adding multiple workspaces per game. It being a service is just convention, but I wouldnât be surprised if this tag were to be removed along with the hypothetical update mentioned above.
Iâd like to find out what your question actually means and whether you think all classes can be inserted in the hierarchy or are just for organization. Superclass.
i dont understand your logic whats the point of having multiple workspaces one is just enough to make super realistic game on roblox nobody needs more than one workspace service
Why would you have more than 1 workspace thats literally useless canât you achieve the same with WorldModels
Iâll also posit that this is more of a feature request rather than a bug. You run into the same problem with BasePart properties on Terrain, but in this case, attempting to set properties like Terrain.Anchored or Terrain.Transparency is just silently ignored, which is convenient from a programmatic sense because you can operate on a list of BaseParts without needing to filter out the Terrain. But in this case, this is more of a matter of these properties not being supported on Terrain and less of âthe engine is stopping you from doing something you probably donât want to do.â
Itâs not as clear for the Workspace whether or not these methods should be ignored, as they do have a use case. You can move the entire hierarchy (minus Terrain again, lol) at once without needing to manually move all descendants, which includes player characters. Whether or not this is something youâd want to do comes down to context, but Iâm not sure we should be breaking class inheritance just to prevent mistakes.
Do a bit of research into why Unity, Unreal and even Godot have âscenesâ. Essentially the same thing.
guys.
itâs literally a class that derives from pvinstance and is a model by extension
warn(workspace:IsA(âPVInstanceâ)) â true
Thereâs not really much point in arguing this, because the behavior canât be changed whether you would consider it a bug fix or a refinement. There are some live games that move and/or rotate the whole Workspace, and this would be a breaking change for those games. Breaking changes generally need some strong case for why they should be made, i.e. benefits that outweigh the consequences to affected developers. Roblox isnât going to change this based solely on some developer having the opinion that it shouldnât be possible.