PhysicsService is causing trouble when deleting a drop in a Tycoon locally

I was scripting a Tycoon when I found a bug:

So I have a conveyor which has its own collision group, players have their own collision group and drops have their own collision group, the player can’t collide with these but the drops can collide with the conveyor.

I’m using PhysicsService to set every drops collision group after spawning them.
When I tried to hide drops from Non-tycoon owners by just destroying every part that gets added into a specific folder on the client I noticed that when I use a proximityprompt to spawn a drop as a non-tycoon owner (everything is serversided besides the script that destroys the drops locally) the part would freeze on its position for the tycoon owner. How is that possible?

I am using the Folder.ChildAdded function and after a wait() I destroy the drop.

If I don’t set the collision group for the drop it works just fine, but thats not a solution.

Collision group script (this one works fine) --ServerSide

PhysicsService:CollisionGroupSetCollidable("NoCollideDrops", "NoCollideDrops", false)
PhysicsService:CollisionGroupSetCollidable("PlayerCollision", "NoCollideDrops", false)
PhysicsService:CollisionGroupSetCollidable("PlayerCollision", "NoCollideConveyor", false)
PhysicsService:CollisionGroupSetCollidable("PlayerCollision", "Players", true)
PhysicsService:CollisionGroupSetCollidable("NoCollideConveyor", "NoCollideDrops", true)
PhysicsService:CollisionGroupSetCollidable("Players", "NoCollideDrops", false)

Dropperscript (works fine if i dont destroy the drops locally) --ServerSide

local function drop()
	local p ="Part")
	p.Name = "Drop"
	p.Size = config.Default.DropSize
	p.Position = purchase.Drop.Position + config.Default.DropOffset
	p.Orientation = config.Default.DropOrientation
	p.CastShadow = config.Default.DropShadow
	p.Transparency = config.Default.DropTransparency
	p.BrickColor = self.Tycoon.Instance:GetAttribute("DropColor")
	p.Material = Enum.Material[self.Tycoon.Instance:GetAttribute("DropMaterial")]
	p.FormFactor = Enum.FormFactor.Custom
	p.TopSurface = Enum.SurfaceType.Smooth
	p.BottomSurface = Enum.SurfaceType.Smooth
	p.Parent = self.Tycoon.DropsFolder

	if config.MeshDrop.Enabled then
		local m ="SpecialMesh")
		m.TextureId = config.MeshDrop.TextureId
		m.MeshId = config.MeshDrop.MeshId
		m.Scale = config.MeshDrop.MeshScale
		m.Parent = p

	--this line here causes the trouble
	PhysicsService:SetPartCollisionGroup(p, "NoCollideDrops")

	Debris:AddItem(p, config.Default.DropExpiration)

I’ve tried just setting the collision of the drop to false locally, but the drop would fall through the conveyor even for other players (and yes, everything is serverside)

Any Help is really appreciated!

this might be a stupid idea but maybe you could try just spawning the drops locally instead?

Local part | Roblox Wiki | Fandom.

I mean this would just take away the problem of having to even remove them in the first place (although it might not work)

just an idea

I need to somehow collect them on the server though

you could try to set the network owner of the part to the tycoon owner. use SetNetworkOwner()

I already did but that caused imense lag

weird, do u constantly set network owner or just once. Personally I haven’t experienced lag using network owner

just once on creation before the physicsservice line

1 Like

so I did that now, I haven’t put it in a complete tycoon to check if it lags yet, but now when the player who doesn’t own the tycoon drops, the drop freezes for everyone:

Also, I’m deleting drops like that: (on the client)

if Configuration.Collecting.LocalDrops then
	for _, tycoon in pairs(kit.Tycoons:GetChildren()) do
			if not (Players.LocalPlayer.Tycoon.Value == tycoon) then

does the part get deleted for the owner if it does im guessing that’s the problem, you could try set the network owner to whoever activated the proximity prompt, otherwise idk sorry.

1 Like

That’s it, I feel so stupid rn cause I accedently set the network owner not to the tycoon owner, but to the player activating, thats why it glitched in the air, thanks for your help!

1 Like