that’s what you suggested right?
the problem I had with that idea tho is that the humanoid could die first before the weld finishes detaching.
But isn’t the weld almost instant at detaching
so is humanoid death.
say for example I setup a humanoid.died event.
when the humanoid dies, this will do something.
I could detach the weld using this method, but because the humanoid died first to fire that event, the weld will still be attached, leading to both humanoids attached to die.
I could check for the hp and see if it is 0, but again, when the humanoid hp is at 0, will the humanoid dying be faster than the if statement checking its hp?
this is why I was asking for something that could prevent this altogether. maybe a way to disable joint breaking completely.
Maybe try to disable the joint rather than destroy it?
wouldnt that be the same speed as destroying?
Try it Im pretty sure not same as destroying
didnt work, the methods used to find out if the humanoid is dead is too slow
What is the hierarchy of your rigs? When I spawn in two animation rigs, hook them together with a WeldConstraint, then kill one, it doesn’t impact the other. Perhaps there are other factors at play?
after doing some checking I noticed some interesting behavior.
the rigs are for custom characters and a player can load one up as their character.
when I connected two rigs that are not a player, they wont die when connected by weldconstraint.
however, if I connect the player with any other rig, both humanoids die.
initially when I looked at the rigs, the custom ones had to be connected with weldconstraints because normal welds wouldnt form.( I think this might be because a humanoid was inside the rig while I was modeling it). but after testing with a normal default rig from the rig spawning plugin, the same results happened regardless.
it has to do with the player somehow and Idk why.
heres the custom character change script:
script
local respawntime = 3
game.Players.CharacterAutoLoads = false
local newcharmod = require(game.ReplicatedStorage.Mods.Util.NewCharacter)
game.Players.PlayerAdded:Connect(function(plr)
--if player dies reload custom char----------------------------
plr.CharacterAdded:Connect(function(char)
if char and char:FindFirstChild("Humanoid") then
char.Humanoid.Died:Connect(function()
local folder = game.ServerScriptService.PlrData:FindFirstChild(char.Name)
if folder then
folder.BeginCreatureRun.Value = nil
folder.Hunger.Value = 100
end
wait(respawntime)
newcharmod.CreateNew(plr,game.ServerStorage.BaseRig,Vector3.new(0,5,0))
end)
end
end)
---------------------------------------------------------------
--setting the model without humanoid death--
newcharmod.CreateNew(plr,game.ServerStorage.BaseRig,Vector3.new(0,5,0))
-----------------------------------------
end)
character spawning module
local module = {}
module.CreateNew = function(plr,newmodel,newpos)
if plr and newmodel then
plr:LoadCharacter()
local bod = newmodel:Clone()
wait()
bod.Parent = game.Workspace
bod.Name = plr.Name
wait()
repeat
wait()
until
bod.Parent == game.Workspace
plr.Character = bod
bod:SetPrimaryPartCFrame(CFrame.new(newpos))
wait()
plr.PlayerGui.UpdateCam:FireClient(plr,bod.Humanoid)
end
end
return module
Not sure if this works, but checkout Humanoid.BreakJointsOnDeath
If that doesn’t work, a workaround would be to use a fake health value. It’s annoying, but it works.
ive tried breakjointsondeath both true and false but it doesnt make a difference.
is there maybe a way to recreate the behavior of a weldconstraint without acually connecting two humanoids?
Can either of the players move while linked? If not, anchoring them should work. I’ve been messing around since you brought up that it’s only a player-related issue, and even using a part as proxy doesn’t help.
Alternatively, you might be able to accomplish the task with a precisely-oriented PrismaticConstraint with length set to the distance between the two parts.
so you were able to reproduce the issue?
Yeah, and nothing seemed to work.
a note to whether the players can move or not, I made a module that will measure the mass of both humanoids. the lighter humanoid has their platform stand enabled while the heavier one keeps its movement during a grab.
if I leave this out the humanoids will fight over who gets to stand and move.
In that regard, you may be able to use a combination of AlignPosition and AlignOrientation to accomplish your goal, although it won’t be as responsive.
As for the PrismaticConstraint approach I had mentioned, initial tests at least don’t kill the player, but I’m too unfamiliar with physics constraints to provide to much help on how to implement this. Some combination of ensuring the attachments are correctly oriented, the constraint has a limit on its slider set to the distance between the two parts, and probably making the immobilized party Massless during the grab.
It seems like the AlignPosition and AlignOrientation may actually be your best option. I had not realized, but both elements offer rigidity options that keep them pretty responsive, and they shouldn’t kill your player.
were you able to test and confirm if it solves the problem? ill check it out myself and see but I was just curious if you already know or not.
Yes, the player stays alive. You will need to add an Attachment to both parties, but the Attachment for the controlling party needs to be at the controlled’s WorldPosition. Both Attachments need to be angled relative to the initial latch angle (that is, the forward orientation of the controlled relative to the controller). Both constraints need to have as much rigidity enabled as possible.
2 Likes
I was able to put together an example model that has both align positon and orientaion:
GameCap.wmv (1.1 MB)
its pretty responsive but I havent tested it with heavier models with more parts. I assume with rigidity enabed it should be as powerful and responsive as it can get.
to keep both parts relative to each other I put the attachments between both parts which can be scripted via magnitude and cframe. but what you said also would work having the attachments all at one position.