Motor6D Killing Issue with FE

Bug Reports Engine Bugs
#1

So I’m using Motor6Ds to weld players’ HRP to a small anchored part to keep them in place (when batting/pitching) for a baseball game of mine. However, if a player resets while welded to the anchored part, it like breaks that anchored part, so that if I try to weld the same character or any other character to that same part it will kill them.

Video of problem:

Place File: WeldIssue.rbxl (34.7 KB)

Repro Steps:

  1. Start a Server with 1 Player (bug does not occur in Play Solo or non FE games)
  2. Simply walk up to the grey block and touch it to be welded to it with a Motor6D
  3. Reset your character using the Core GUI.
  4. Walk up to the grey block again and touch it.
  5. This will kill your character.

Happens with both R15 and R6.

If it helps, I noticed that when you reset your character, the Motor6D is immediately destroyed on the Client, however, it is not destroyed until the character is removed on the Server. When you touch the block the second time the Motor6D is created on the server, but seems to not be made on the client, could be since the character dies immediately.

3 Likes
If a player dies whilst welded to a part, attempting to re-weld to it after respawning kills them
Problem with passing an object to another player
#2

I can confirm that this happens without FE too. It was an issue when I was building some on-rails trains even before FE was created.

1 Like
#3

Well the repro place I have linked with FE turned off doesn’t reproduce the bug. I couldn’t figure out why the bug wasn’t happening on my simple repro place, but then I remeber new places default to FE = false. Which why does new places still default to FE = false?

3 Likes
#4

I can confirm I still experience this issue.

5 Likes
#5

This is still happening and it is considerably hindering gameplay for my players.
If any engineer could acknowledge this, please do so. We’d like to know the proper team is aware of the issue.

5 Likes
#6

Okay, so it’s been 4 years, and this bug still occurs. The repro place is super simple I would think it would be quite easy to diagnose the issue and fix it. Currently running into this issue again on a new game I am working on.

Also an update, this occurs in Play Solo now.

2 Likes
#7

Have you tried deleting them and doing the whole thing again?

1 Like
#8

Parent the Motor6D’s to the part, not the character. The client is able to delete any non-BasePart Instance parented to the character.

1 Like
#9

Deleting the part and re adding it works, but it is a hassle to deal with, especially when the thing you want to weld the player to is moving.

Also the motor6d is parented to the part and not the character.

1 Like
#10

This just seems like a case of BreakJoints doing its thing.
When you reset, its the equivalent of doing Character:BreakJoints() which deletes all welds, which would include Motor6D whether the attachment is under Part0 or Part1.

If they did want to help make it more friendlier, they could possibly check if it is assigned to Part1 and nil rather than destroy, but that could break existing games

1 Like
#11

The issue isnt the weld breaking when you reset. The issue is when you weld any player to the part a second time, after a player had already died while welded to the part, the second player immediately dies, without having to reset or do anything.

1 Like
#12

I am stuck with this issue as well. Is there any solution you found?

1 Like
#13

There is no real solution for this; I had the same problem year ago when was making carrying system for downed players, although i managed to find the solution but it was really buggy.

So I suggest you start using bodyposition, or monitor the Motor6D and reset it by replacing with a new one if any changes being made regarding Part0 and Part1 properties

1 Like
#14

I just used AlignPosition and AlignOrientation instead of Motor 6D.

1 Like
#15

You could also use RigidConstraints, which behave similarly to Motor6Ds but use attachments

1 Like
#16

Thank you so much. It helped a lot. Align Position & Orientation seemed a little bit slow from the other clients’ perspectives. However, it seems like RigidConstraints works well without any delay. :+1: