Creator Value in a Humanoid

I’m not quite sure what is the ‘creator’ value. All I know it is used for KO’s and WO’s. I’ve tried googling it but the answers doesn’t really explain in detail what the ‘creator’ value is.

Can someone explain in detail how the creator value works?

Thanks!

14 Likes

Alright so, I shall give an explanation :thinking: (And I’m on mobile so dear everything forgive me if the stuff I say isn’t formatted correctly)

A creator “value” is basically in simple terms, a Kill Check (Or detecting if there is a CreatorTag, then we can add a Kill stat to the player who defeated the target)

The way how the creator “value” is implemented, is that it’s basically a way of checking if a player’s Character (Aka the Humanoid) has been damaged or not

Take a look at this GIF here:

tenor (4)

There are a couple things to note:

  • When the Sword touches a Character’s Model (Excluding the Player who welded it itself), it creates the “CreatorTag”, which is actually an ObjectValue

  • Upon a Character’s death (If a CreatorTag is in the target while he is dead in other words), that’s when the “CreatorTag” checks if the Character got tagged or not. If it is, then we can add a Kill to the Player who dealt the damage!

So how about we write just a simple code here, we’ll start with the tool that will deal damage:

local Tool = script.Parent
local Handle = Tool.Handle
local Damage = 10

Handle.Touched:Connect(function(Hit)
    local Player = game.Players:GetPlayerFromCharacter(Hit.Parent)
    if Player then
        
    end
end)

If you don’t know how Tool functions work, I highly advise that you look at this here :wink:

Anyways, so what the first thing we’re doing here is defining our variables, then creating our Touched event, so that it fires whenever the tool hits a certain object (Or in this case, the Model of a Character)

local Player = game.Players:GetPlayerFromCharacter(Hit.Parent)

The next thing we’re doing here, is we’re actually getting the Player’s Instance from the Character’s Model itself (As Hit.Parent will refer to of course, the Hit’s Parent)

Adding onto our code here:

local Tool = script.Parent
local Handle = Tool.Handle
local Damage = 10

Handle.Touched:Connect(function(Hit)
    local Player = game.Players:GetPlayerFromCharacter(Hit.Parent)
    if Player then
        Hit.Parent.Humanoid:TakeDamage(Damage)
        local Tagged = Instance.new("ObjectValue")
        Tagged.Name = "creator"
        Tagged.Value = Player
        Tagged.Parent = Hit.Parent.Humanoid
        game.Debris:AddItem(Tagged, 2)
    end
end)

Now we added some more things, but it shouldn’t be too hard to explain here:

Hit.Parent.Humanoid:TakeDamage(Damage)

This is referring to the Target’s Humanoid that will recieve the damage (OUCH)

local Tagged = Instance.new("ObjectValue")
Tagged.Name = "creator"
Tagged.Value = Player
Tagged.Parent = Hit.Parent.Humanoid

I’ll try to break this the best I can here:

  • Tagged.Name is equal to the creator, it’s optional to change it but it’s good practice to learn
  • Tagged.Value will actually refer to the Player, or in this case we’re getting the Player’s leaderstats upon triggered
  • Tagged.Parent will head to the Target’s Humanoid, so that the Server Script (Will explain soon) will detect for any CreatorTags

So, now we have our weapon ready! But what’s next? Well, the last step is creating the Kill Check from the Server Side! This is to check for any potential CreatorTags lying around the Humanoid :thinking:

We’ll start with making the script inside ServerScriptService, and we’ll mainly need to use the CharacterAdded event to fire every time a Character joins

game.Players.PlayerAdded:Connect(function(Player)
 
   Player.CharacterAdded:Connect(function(Character)
        Character.Humanoid.Died:Connect(function()
            if Character.Humanoid:FindFirstChild("creator") then
                local Player = Character.Humanoid.creator.Value
                local Leaderstats = Player.leaderstats
                Leaderstats.Kills.Value += 1
            end
        end)
    end)
end)

Last stretch! Breaking down time (The majority of these will be events):

  • PlayerAdded will fire whenever a Player joins the game, and CharacterAdded will fire whenever a Character gets created into the Workspace

  • Character.Humanoid.Died fires when the uhh, yes Character’s Humanoid reaches 0

(Inside that event, we’re also checking if we have a CreatorTag inside the Character’s Humanoid)

  • local Player is actually referring to the Player Object we referenced back in our other Tool script, which was Tagged.Value = Player

  • local Leaderstats refers to the Player’s local leaderstats held in a Folder

  • Leaderstats.Kills.Value += 1 is just simply, increasing the Player’s Kills by 1

Aaaaaand if you managed to reach the end, then congrats! You now have a basic understanding on what CreatorTags are hopefully

If you do have any more questions though, feel free to ask! :sweat_smile: (AND SOMEONE PLEASE CORRECT ME IF I FORGOT SOMETHING CAUSE THIS TOOK WAY TOO LONG TO WRITE)

58 Likes

I applaud you for managing to write this all on mobile! Additionally, I haven’t seen many explanations for the Creator object before – this is something that would’ve helped me a lot back when I was trying to wrap my head around how it works.


There’s only a few things I’d like to point out – the first of which is in the second to last codeblock when the ObjectValue is created. I noticed that the value property of the ObjectValue is being set to:

local Player = game.Players:GetPlayerFromCharacter(Hit.Parent)

Instead of referencing the Player who inflicted the damage, this will refer to whoever owns the Character that was hit, which would inevitably cause the leaderstats of the incorrect player to be increased.

In order to resolve this, you could reference the Parent of the Tool to access the Character model of the Player that’s wielding the tool, and similarly, call :GetPlayerFromCharacter() on that Character to before updating the value:

local Players = game:GetService("Players")
local Debris = game:GetService("Debris")

local Tool = script.Parent
local Handle = Tool.Handle

local playerWithTool
local Character

Tool.Equipped:Connect(function()

--[[
This function is used to update the "playerWithTool" and "Character" variables
to ensure that the tool is being wielded by a player's Character

(I'm not sure if this much is really necessary but just in case!)
--]]

    local characterCheck = Tool.Parent and Tool.Parent:IsA("Model")

    if characterCheck then

        local playerCheck = Players:GetPlayerFromCharacter(Tool.Parent)

        if playerCheck then
            playerWithTool = playerCheck
            Character = Tool.Parent
        end
    end
end)


Tool.Unequipped:Connect(function()
-- This resets the values of the variables whenever the tool is unequipped
    playerWithTool = nil
    Character = nil
end)



local Damage = 10

Handle.Touched:Connect(function(Hit)

    local otherCharacter = Hit.Parent

    if otherCharacter then

        local otherPlayer = Players:GetPlayerFromCharacter(otherCharacter)
        -- otherPlayer references the player that was hit by the tool

        if otherPlayer and otherPlayer ~= playerWithTool then
    --[[
        If what was hit ended up being a player's Character and it wasn't
        the Character of the player who's wielding the tool, then...
    --]]
            local Humanoid = otherCharacter:FindFirstChildOfClass("Humanoid")

            if Humanoid then

                Humanoid:TakeDamage(Damage)

                local Tagged = Instance.new("ObjectValue")
                Tagged.Name = "creator"
                Tagged.Value = playerWithTool
    --[[
        The value is then updated to be the player that inflicted damage
        so the other script will know whose leaderstats need to be updated
    --]]
                Tagged.Parent = Humanoid
                Debris:AddItem(Tagged, 2)
            end
        end
    end
end)

The other thing I’d like to point out is in the final codeblock. Some fail safes could be implemented just in case there doesn’t happen to be a value stored in the ObjectValue, if the value isn’t referring to Player, if the Player doesn’t have those specific Leaderstats, etc.

(It should already be there most of the time but it’s good to check just in case)

And just for fun, I created a function that handled updating leaderstats which allows for it to be more dynamic in case any other leaderstats needed to be modified (which would probably be better suited for use in a ModuleScript):

Note: I haven’t tested these, so if I’ve made any typos/if any errors occur, let me know and I’ll correct my post!

local Players = game:GetService("Players")

local function updateLeaderstats(player, leaderstatName, incrementAmount)
	
	local playerCheck = player:IsA("Player")
	local leaderstatCheck = type(leaderstatName) == "string"
	local incrementCheck = type(incrementAmount) == "number"
	
	if
		playerCheck
		and leaderstatCheck
		and incrementCheck
		
	then
		
		local leaderstats = player:FindFirstChild("leaderstats")

		if leaderstats then
			local leaderstatToUpdate = leaderstats:FindFirstChild(leaderstatName)

			if leaderstatToUpdate then
				leaderstatToUpdate.Value += incrementAmount
			end
		end
	end
end


Players.PlayerAdded:Connect(function(player)

    -- Create leaderstats here

    player.CharacterAdded:Connect(function(Character)

        local Humanoid = Character:WaitForChild("Humanoid")

        Humanoid.Died:Connect(function()
            local Creator = Humanoid:FindFirstChild("creator")

            if 
                Creator
                and Creator:IsA("ObjectValue") 
                and Creator.Value 
            then
                updateLeaderstats(Creator.Value, "Kills", 1)
--[[
This will activate the function called "updateLeaderstats", sending through the
player who inflicted damage, the name of the leaderstat that will be updated, and
the increment that the leaderstat will change (in this case, +1 will be added)
--]]
            end
        end)
    end)
end)
15 Likes

Hey man I have a question, is it only for handles or it can be used with a part?

1 Like

Any part within the Tool could be referenced – a part with the name of “Handle” was referenced in the solution of the post because Tools that have the Tool.RequiresHandle property enabled are supposed to have a part called “Handle” in order for it to function as intended.

Because that property is set to true by default, the vast majority of Tools will have a centralized part called “Handle” (and for many of those tools, the “Handle” will be its only part, meaning that it’s the only Instance inside of the tool that would be able to detect collisions when using the BasePart.Touched event).

2 Likes