My goal is to have a models of stacks of coins placed around the map. Once a player gets close enough to a model, all coins in the model are unanchored and given an alignPosition to move towards the player’s HRP. Each client can pick up the same coin, even if it’s already been picked up. So, align position should take place on the client, as wells as the unanchoring of a coin (coins are anchored until the player is close enough to trigger the pick up). I’ve got most of the process working, the only thing that’s causing an issue is the unanchoring, which only needs to be done so that the alignPosition can act on the coin.
What I did first: Unanchor the coin, then create two attachments for the alignPosition (one on HRP, one on coin), and then create an alignPosition in the coin and make att1 the HRPAtt and att0 the coinAtt.
This fails because the coin does not get simulated on the client, for some reason. If I change the coins cancollide property to true, the simulation does work on the client, but the issue now is the lag, the fact that the coins are pushing the player, the coins get stuck on objects, and if the player gets too far away from the coins, the simulation stops, causing the coins to act as if they are anchored (though they are not).
So second I tried setting network owner ship to everyone and scrapping the CanCollide resolution, but this fails obviously because the simulation only works for the last person that got ownership.
It seems as though all of the limits placed on the specific objects I’ve chosen to use have come together to make this very hard to do, but maybe there is a simple solution, like building the HRP attachments on the server, or something else. I have not provided code because it really is not important. Thank you.
I used a combination of utilising PhysicsService and it’s CollisionGroups, Unanchoring the part and setting the attachments to an AlignPosition.
Overall, it works pretty well so here’s the code if you’d like an example:
--// Dependencies
local Players = game:GetService("Players")
local PhysicsService = game:GetService("PhysicsService")
local RunService = game:GetService("RunService")
--// Variables
local PartsCollisionGroupName = "Part"
local Range = 10
--// Functions
local function setupPartsCollisionGroup()
PhysicsService:CreateCollisionGroup(PartsCollisionGroupName)
PhysicsService:SetPartCollisionGroup(workspace.Part, PartsCollisionGroupName)
end
local function playerAdded(player)
PhysicsService:CreateCollisionGroup(player.UserId)
PhysicsService:CollisionGroupSetCollidable(player.UserId, PartsCollisionGroupName, false)
player.CharacterAppearanceLoaded:Connect(function(character)
for _, basePart in ipairs(character:GetDescendants()) do
if basePart:IsA("BasePart") then
PhysicsService:SetPartCollisionGroup(basePart, player.UserId)
end
end
local alignPosition = Instance.new("AlignPosition")
alignPosition.ApplyAtCenterOfMass = true
alignPosition.Responsiveness = 50
alignPosition.Parent = workspace.Part
local rootPartAttachment = Instance.new("Attachment")
rootPartAttachment.Parent = character.HumanoidRootPart
local partAttachment = Instance.new("Attachment")
partAttachment.Parent = workspace.Part
local connection
connection = RunService.Heartbeat:Connect(function()
if character and character:FindFirstChild("HumanoidRootPart") then
if (character.HumanoidRootPart.Position - workspace.Part.Position).Magnitude <= Range then
workspace.Part.Anchored = false
wait(0.5)
alignPosition.Attachment0 = partAttachment
alignPosition.Attachment1 = rootPartAttachment
alignPosition.Enabled = true
else
alignPosition.Attachment0 = nil
alignPosition.Attachment1 = nil
workspace.Part.Anchored = true
alignPosition.Enabled = false
end
else
connection:Disconnect()
end
end)
end)
end
--// Setup
setupPartsCollisionGroup()
--// Connection
Players.PlayerAdded:Connect(playerAdded)
You might have missed the key reasons why this is challenging.
The server must see nothing, this is a purely graphical effect.
Ontop of 1, each client gets their own experience. If One player collects a coin, Player two does not see that happen, and can still collect the coin because of that.
As you can see from this.
There should be no collisions at all for the coins. That includes collisions with other coins, the player, and the workspace in general.
once the AlignPosition has been triggered, it is supposed to be enabled no matter how far the player gets.
The following quote was not a wish, but an undesired issue:
When I say “Simulation” I do not mean collisions. I mean the AlignPosition.
I’m not 100% sure, but i am… 99% sure.
This. Is. The. Issue.
Lets clear one thing up, when I say, “simulate physics,” I mean simulate physics. Why? Because the only way that AlignPosition works is if physics are being simulated. So, there is no issue with the properties of AlignPosition. Ontop of that, I do NOT mean that there has to be CanCollide, the ONLY reason that CanCollide was brought up is because the simulated physics dont work without it on.
Now, the actual issue. When a player gets to far from a block, the blocks networkOwner gets set to the server. Meaning that to the client, the block will appear frozen in space, this is because the AlignPosition does not exist on the server. “So just set NetWork owner to the player” This doesn’t work because only one player (the one with network ownership over the block) will see the correct physics. And, chances are there will be many players trying to pick up the same coin.
I will try to work with the CanCollide and Collision Groups, but please understand this is not an issue with something as simple as MaxVelocity.
Edit: and there will still be the issue of NetWorkOwnerShip switching to server once the player is too far away.
This entire issue could be resolved by creating the coin Parts on each client, so they have full ownership. Since it has no need to replicate anyway, this should be fine, yes?
A lot of these posts are good responses too. At least they made the effort to help. Saying this is slightly inappropriate because it comes off as if you’re calling everyone else’s methods bad. They aren’t bad, they are simply not applicable to your case or you can’t salvage the concepts they put forth to fit your situation.
I feel it worthwhile to let you know that Returned’s solution is just as viable because collision filtering can be utilised on the client as well. That being said though, it all depends on the implementation details being sought.
The server would only really need to be here for security purposes or whatever. If that’s not desired, then creating them on the client is the best option for sure. Anything visual should typically always be handled by the client.
