for example:
“slow” way
if Humanoid.Health > 50 then
Humanoid.Health -= 50
“fast” way
local Humanoid_Health = Humanoid.Health
if Humanoid_Health > 50 then
Humanoid_Health -= 50
This actually breaks what you want to do, since it’s not changing the health property if you’re just changing the variable.
You’re changing the variable’s value instead of the Humanoid’s health.
Assigning the value of a property to a variable copies the value to the variable.
Humanoid.Health is equal in value to humanoid_health at the time of reference.
Referencing an object with a variable makes your code readable:
local humanoid = game.Workspace.Player.Humanoid
humanoid.Health -= 10
Though, this is synonymous with:
game.Workspace.Player.Humanoid.Health -= 10
References are not memory-intensive. Objects are. The Humanoid object exists either way. The humanoid variable is a reference to that object - like an address.
Does this clarify?
3 Likes
You always want to find the Instance for the objects. Finding the property will only make the variable equal to the property’s value.
local humanoid = character:FindFirstChild("Humanoid")
-- humanoid equals the Character's Humanoid.
humanoid.Health = 80
local humanoid_health = humanoid.Health
-- humanoid_health equals the value in the Humanoid health,
-- but this is not connected to the value of Humanoid.Health.
-- humanoid.Health = humanoid.Health
-- humanoid_Health = 80 (the value humanoid.Health had initialized)
The reason this is the case is the Properties of Objects are just that, Properties. They are values that apply to how the object works in the Engine. They are storage locations that the game’s and the engine’s code find to determine how the given instance is generated in the Engine.
Think of it like this: the Engine API, the Luau Language is how we understand the code running in the game. But it’s just a computer language that is more convenient for our use. What we write in code isn’t how the computer understands it, so the code has to be compiled and translated for machine understanding. Variables are just storage locations in the code:
local x
-- Storage location x = nil
local y = 50
-- Storage location y = 50
x = y
-- The computer calls storage location y.
-- This returns whatever value is kept in location y, and stores that value in location x
-- Storage location y returns the value 50, so x = 50.
This is how Properties work in roblox. You call their storage location: and they return the value in their storage location. So that means when a property is called, it will return and only return the value it is storing. What’s important is that checking storage locations, manipulating values at storage locations, and preforming actions based on storage location checks are generally all code does. (It’s a lot more complicated, and that’s a real oversimplification over programming and very inaccurate. Don’t take this as an absolute.)
So then you may be wondering how come we are able to save the location of Objects if calling a storage location only returns the value it stores. What we can do is store storage location information at storage locations. This is how Objects work, they storage information on calling other relevant storage location information:
local x = 50
-- storage location x = 50
local y
-- storage location y = nil
y = game.Workspace.Z
-- storage location Z = storage location info Z.Properties
-- returns storage location info Z.Properties
-- storage location y = storage location info Z.Properties
y.Value = x
-- storage location y is called, find the Value location, and sets the Value location equal to x.
-- storage location Value = 50.
y = x
-- 50 is returned
-- storage location y = 50.
And that is an oversimplification of how the engine translates your scripts into computer language, finds the storage location information in their memory, and finds and manipulates their values.
Edit: I should add that Objects and Properties are also saved as storage locations in RAM on the client and server.
1 Like