Problem with how tool local scripts work

Help and Feedback Scripting Support
#33

A CharacterAdded event in the local script would most-likely not work.

#34

However keep in mind, not really sure if this applies to LocalScript’s in tools, when I used CharacterAdded in StarterPlayerScripts locally, it wouldn’t fire the event for the first time the player joined.

#35

It does work, I tried this with my old gun system version when I did use CharacterAdded.

The only problem was when the player first joined it didn’t fire sometimes, I know how to fix that though.

#36

What? That makes no sense, it works, just has issues on the first time around.

#37

Also you could just grab the character model each time you need to use it.

#38

It’s not the most efficient for local scripts.

#39

By that I mean, workspace:FindFirstChild(LocalPlayer.Name).

#40

I can’t really do that I have a lot of setup needed in the script. When the script starts running first I need to change their camera to my shouldercamera module.

#41

Ah okay, I see. Let me know if CharacterAdded resolves your issues.

1 Like
#42

I ran into a similar issue while trying to do some stuff with forces and GetMass(). Trying to immediately calculate mass for a character right when it loads can lead to unexpected problems. Seems the CharAdded event triggers before the ACTUAL character is loaded. Functions can end up returning values for the default avatar instead of for parts that are supposed to be equipped. I was able to fix my problem by adding a short delay. Bummer that didn’t work here… maybe try different placements for the delay (closer to the top).

Might also try running the script when the tool is actually equipped. Backpack is supposed to destroy the tools and reload them when the player respawns, so it shouldn’t be that it’s holding on to the old character. Possibly it’s grabbing something new when the script restarts before the character is actually loaded, similar to what I was seeing. Seems there may be a problem with trying to call code on the character from the CharacterAdded callback, which is unfortunate since that would seem a good place to do that. Don’t know. Interested to see what you all come up with.

#43

Oh so the delay actually does work when you put it above setting the variable to the characterreference, I know this by expirementing when I did, the delay doesn’t work after you set the character reference since that references the old character.

Wait(2)

local Character = Player.Character or Player.CharacterAdded:Wait()

The reason I don’t do this is because I honestly think it’s a hack, that’s why i’m trying the CharacterAdded solution right now.

Yah I think character loading is a weird thing

#44

Yah it does. However I still think roblox should change the thing to make the Character Reference nil when the character is dead ect.

local Player = game.Players.LocalPlayer

local Character = Player.Character

if Player.Character == nil or Player.Character.Parent ~= workspace then

Character = Player.CharacterAdded:Wait()

else

Character = Player.Character

end

local Root = Character:WaitForChild('HumanoidRootPart')

Root.Anchored = true

The reason I need to do the Parent Check is to see if the character is the Old character, the old character reference would be parented to nil.

2 Likes
#45

I don’t think CharacterAdded will ever pass the old character. So I don’t entirely see a need for a parent check, however if you continuously wanted to update the character in a loop just have a while char.Parent ~= workspace do -- end

#46

Oh wait let me explain that, i’ll type the message hn

This isn’t really using the characteradded event, it;s just waiting for the character using it but it doesn’t wait if it;s there. But it does way if the Character’s parent is nil (that means it was the old reference).

The reason im not using Player.CharacterAdded:Connect() is this way is much cleaner IMO then this.

Player.CharacterAdded:Connect(function(Character)

local Root = Character:WaitForChild('HumanoidRootPart')

Root.Anchored = true

end)

I don’t really want to type all my code inside an CharacterAdded event listener. That’s why I use CharacterAdded:Wait(). If the Character is parented to nil it means it’s the old reference. If the Character Property itself is nil then it means the player just joined and his character isnt loaded yet

#47

Yeah but there might be other needs for the character before it is entirely destroyed.

#48

Prob don’t need the else part since you set Character = Player.Character prior to the if statement. Is that doing something extra?

#49

Oh yah you are right, I didn’t actually see that lol. Yah i’ll remove that.

#50

I guess that’s true this is why I think we need an event which fires just before the character is destoryed.

Wait doesn’t CharacterRemoved do this, doesn’t it fire before the character is destoryed.

#51

CharacterRemoving does fire before the character despawns, yes.

#52

It worked with my TP tool! Thanks, it’s really helpful! Anyways, here’s the code of my work:

local Player = game:GetService("Players").LocalPlayer
local Character = Player.Character
if Player.Character == nil or Player.Character.Parent ~= game:GetService("Workspace") then
	Character = Player.CharacterAdded:Wait()
end
local Mouse = Player:GetMouse()

script.Parent.Activated:Connect(function()
	if Mouse.Target then
		Character:MoveTo(Mouse.Hit.p)
	end
end)
3 Likes