AlignPosition and AlignOrientation Freezing Part


I have a client-sided grabbing system.

I can completely assure you that this is NOT a replication issue.

My grabbing system works by making a small spheres CFrame each frame to head.CFrame+Mouse.hit.lookvector*distance


image

In that image, the object should be at the sphere. Instead the object is in a frozen state- I can not interact with it in any way, I can’t push it or move it with the alignment object.

I have tested:
Disabled alignOreintation - same behavior
Disabled alignPosition - same behavior
Disabling both - obviously, the part does not follow the mouse anymore, but it stops freezing.


I’m really sure this is an engine bug and I have to do some workaround that shouldn’t be necessary to fix it. Both alignment objects are causing the problem, and this BUG has been posted about before.

Other information:
Model I am using is welded.
The alignment objects are parented to both the selected part and the attachments aswell.
Attachment1 for alignposition is the player’s mouse sphere.
This bug does not occur for singular objects.

WHAT I’M LOOKING FOR:
a workaround I can use, or this bug being fixed.

MOVE CODE:

RunService.RenderStepped:Connect(function()
	if not Player.Character then
		return
	end
-- Variable Magnitude is a distance offset from the players head. Depends on how close the object was when the player clicked on it
	local Target = Mouse.Target
	Mouse.TargetFilter = Player.Character

	GrabSphere.CFrame = Player.Character.HumanoidRootPart.CFrame+Mouse.Hit.LookVector*Magnitude+Vector3.new(0,1.5,0)
	
end)

When a player clicks their mouse, it selects the part they clicked and adds the alignment stuff and other stuff. When a player lets go of their mouse, it removes the alignment stuff.

1 Like

This has been an issue since I made my grabbing system, too.

1 Like

Two things I would recommend checking, is 1) are any parts anchored (I know you would’ve checked but it doesn’t hurt to mention it) and 2) is ReactionForceEnbled set to true? If so the lighter object moves towards the heavier, possibly causing your issue.

2 Likes

Yes, But I forgot to mention I already tried with it disabled. Same behavior.

No parts are welded to the selected part. Anything that’s grabbable has to be unanchored.

1 Like

Hmm… That is strange, I would highly suggest you keep it off as it would case the grab object to move towards the grabbable object sometimes, which I assume is unwanted behaviour.

As for the issue, I would recommend two other steps:

  1. Up the max force on the AlignPosition or set Rigidity to true.
  2. Set the grabbable objects parts “Massless” property to true and see if the issue continues.
1 Like

Still persists, and besides I need mass anyway so this wouldn’t be a good workaround for me.

I also tried this before, too, and the object was still completely frozen.

1 Like

Just to get some more info, is the “GrabSphere” CanCollide off?

1 Like

Yes, The sphere has cancollide off.

1 Like

I think I may see what the issue is. You may need to create a RemoteEvent or RemoteFunction from client to server, so that when an object is grabbed / dropped, it changes the network owner using :SetNetworkOwner(). Pass the grabbed object through the remote and call that on it, passing in the player that called the remote.

I personally believe it is this that has caused this as in my own grabbable object system I had a freezing issue when the Server took control of my object and was locking it in place to stop client forces from applying to it!

2 Likes

It isn’t a replication issue, I already have remote events in store for the situation you described. I even printed the network ownership and it printed the player when the object froze. I believe this is a bug considering the object literally acts as if it’s anchored, but it’s not and I’ve checked ingame and in studio.

1 Like

I’m going to go ahead and check my implementation for similar issues to confirm if maybe a bug was introduced recently, if it still works ill get back to you with insight

1 Like

I’ve gone and tested it, and it does seem to work. Below is a code snippet from my setup of the AlignPosition, and a video showing the effects:

                local Align = Instance.new("AlignPosition")
                Align.Enabled = false
                Align.Mode = Enum.PositionAlignmentMode.OneAttachment
                Align.Attachment0 = CurrentGripAttachment

                Align.Responsiveness = 40 - (Cast.Instance.Mass*7)
                Align.Parent = Cast.Instance
                CurrentGripMover = Align

To add, have you made the GrabSphere visible and seen where it goes when the issue is ongoing?

I can also mention, it is significantly less error-prone if you use “OneAttachment” mode on the AlignPosition, then set the AlignPosition.Position variable to the position you want it to go to, with the one attachment it is connected to being inside the part you are grabbing!

2 Likes

I might just want to recode my grabbing system, how did you manage to create this one? (In the terms of did you clone the align position ever like I did for the selected, nothing involving the effects like highlight or stuff, but also include how you used the current grip part)

The core differences between mine and yours at the moment is:

  1. I used One-Attachment mode to simplify the AlignPosition. Setting this means that you can simply define a “Position” inside the AlignPosition instance that it will pull the object to. I also used the math you saw here:

to calculate a realistic responsiveness based on the weight of the object being grabbed.

  1. I used UserInputService combined with my own raycasts based off the camera instead of the mouse as the use of the mouse object is rather limiting and I personally preferred it.

  2. I set the Position variable of the AlignPosition within a renderstep loop like you did, but i personally used :BindToRenderStep() with the priority of Camera.Value + 1

And in terms of this:

I created a new AlignPosition each time a grab was initiated and parented it, and destroyed the current one whenever the grab was dropped (InputBegan and InputEnded respectively). I also set Enabled to false initially, then inside the Render Stepped loop, set it to true if it wasn’t already. I believe this was to fix an issue I was having but I’m not certain of its use.

Feel free to ask for specific code snippets if it would help you!

1 Like

I recoded the whole thing in way less time and way less lines than the last time and managed with this output

image

it’s perfect, your method worked

my script: (i don’t care if anybody uses this

local Player = game.Players.LocalPlayer
local Camera = workspace.CurrentCamera
local Mouse = Player:GetMouse()

local CanClick = true

local Magnitude = 10

local PartsToDestroy = {}

local SelectionBox = script.SelectionBox
local CurrentMover = nil

local Align = Instance.new("AlignPosition")

local RunService = game:GetService("RunService")

local function UnGrab()
	for _,v in PartsToDestroy do
		v:Destroy()
	end
end

Mouse.Button1Down:Connect(function()
	local Target = Mouse.Target
	if Target then

		if Target:HasTag("Moveable") and not Target:FindFirstChildWhichIsA("ClickDetector") then
			
			game.ReplicatedStorage.SetOwnership:FireServer(Target)
			
			local a = Instance.new("Attachment")
			a.Parent = Target
			a.WorldPosition = Mouse.Hit.Position
			table.insert(PartsToDestroy,a)
			local c = Align:Clone()
			c.Parent = Target
			c.Attachment0 = a
			CurrentMover = c
			table.insert(PartsToDestroy,c)
		end

	end
end)

Mouse.Button1Up:Connect(function()
	UnGrab()
end)

Align.Enabled = true
Align.Mode = Enum.PositionAlignmentMode.OneAttachment
Align.Responsiveness = 40

RunService.RenderStepped:Connect(function()
	local TargetPosition = Player.Character.HumanoidRootPart.Position+Mouse.Hit.LookVector*Magnitude+Vector3.new(0,1.5,0)
	
	if CurrentMover then
		CurrentMover.Position = TargetPosition
	end
end)

thank you for the time

1 Like

Amazing work!!! Glad to see you sorted it out, hope to see your game out there one day :slight_smile:

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.