Value.Changed not working

Help and Feedback Scripting Support
#41

You just copied my script and merged it together.

#42

Exactly, try it out. Let me know if it worked.

Edit: Realised you’re not the one who asked for help lol

#43

It already worked separated but ok.

#44

OP. Show us where your script is located, and try to post the full source. What type of Script is it? How are you changing value?

#45

Here it is. 36th post on this topic.

#46

I haven’t been following the whole discussion, but why would you want to listen for property changes from the same script that also changes that value?

EDIT notice: I corrected this post, because it contained some false information about properties.

As far as actual changing goes, @leogodgg is right. One script should change the value and the other should listen to changes using

 NumberValue.Changed

NumberValue:GetPropertyChangedSignal("Value")

Important factor is also the type of script you are listening for changes from. If you are changing the value from a local script, server script definitely won’t see any changes as long as filtering is enabled. Everything works fine vice versa.

#47

As far as actual changing goes, @leogodgg is right. One script should change the value and the other should listen to changes using

That’s not true. You can have the check on the same script and it’ll still work.
The problem here is something else: he had a LocalScript in workspace (localscripts don’t run!), either that or he had a script in workspace and tried to change the value from a LocalScript (server won’t see client changes)

local ValueObject = Instance.new('IntValue', workspace);
ValueObject:GetPropertyChangedSignal'Value':Connect(function()
print('Changed Value!')
end);

ValueObject.Value = 1 --// will print, same script
#48

Actually, what I said is true, but you took that sentence out of context. Didn’t say it isn’t possible. It’s pointless to have one unnecessary connection inside the same script listening for property changes made by that very script. Other than that, yes, local scripts don’t run in workspace, and changes done by client don’t replicate (with certain exceptions).

#49

I don’t know where did you pull that 2 properties number from when there is exactly 10 properties (or 7 if you don’t count the deprecated ones) on a numbervalue which you can change 5 of them (or 4 if again, you don’t count the deprecrated ones).

1 Like
#50

No it’s not, and there are many cases where it’s useful, for example a countdown script.

#51

You are right, my bad, thank you for correcting me.

#52

Thing
Thing386×542 53 KB

The script named PartSpawner is the script with the Value.Changed inside it. The unnamed script is the script changing the value. The Value named Plastic is our Value
Here is the script in PartSpawner:

--Variables--
local DropPart = script.Parent
local Plastic = DropPart.Parent.Plastic
local Valuables = DropPart.Parent.Parent.Parent.Valuables
print(Plastic.Name)
--Plastic Dropper Script--
local function OnDrop(PlasticDeposited)
	if PlasticDeposited > 1 then
		print("Sucess!")
		local Part = Instance.new("Part",Valuables)
		Part.Name = "Plastic"
		Part.Size = Vector3.new(1.5, 1, 1.625)
		Part.CFrame = DropPart.CFrame
		Part.Material = Enum.Material.Plastic
		Part.BrickColor = BrickColor.new("Shamrock")
		local Value = Instance.new("NumberValue",Part)
		Value.Value = 1
		Value.Name = "Price"
		wait(1)
		Plastic.Value = Plastic.Value-1
	end
end
Plastic.Changed:Connect(function()
	print("Changed")
end)
print("Hi")
while wait() do
	Plastic.Value += 1
	print(Plastic.Value)
end

The script inside the unnamed script:

local Value = workspace.Tycoons.Tycoon1.Buildings.Dropper.Plastic
wait(10)
Value.Value = 5
#53

I beg to differ, because you can use variables for that. Listening for property changes in that case is unnecessary and connections take up more memory.

#55

Actually that code works, believe it or not:
image

1 Like
#56

Well when I added this the value would go up 1 every print

1 Like
#58

This post is not related to the actual issue, about which I’m currently not sure whether it was resolved or not, but is intended to mention and address some bad practices I spotted.

1) Instance creation

-- Good and efficient
local newInstance = Instance.new("NumberValue")
-- properties here
newInstance.Parent = workspace

-- Inefficient and to be avoided
local newInstance = Instance.new("NumberValue", workspace)
-- properties here

Why is that? Because when the value is created, it is not yet part of the game environment. It is, however, stored in memory and ready to be used. Ideally, we define parent last, because as soon as the parent is set, multiple processes start listening for changes of the property, so it’s not very performance beneficial if we change properties that would otherwise stay constant later.

2) wait()

-- Not good -----------
while wait() do
	Plastic.Value += 1
	print(Plastic.Value)
end

-- Better -------------
while (true) do
	Plastic.Value += 1
	game:GetService("RunService").Heartbeat:Wait()
end
-- or -----------------
while (true) do
	Plastic.Value += 1
	wait(0.1)
end

wait() is part of Roblox 30Hz pipeline and there is a possibility that it won’t reliably run every time. There are multiple comprehensive articles around the devforum addressing this practice.

3) Property changes

Again, Value.Changed and Value:GetPropertyChangedSignal() are indented to listen for changes. Using them inside the same script doesn’t really make sense, because we can simply call a function each time change happens. That saves us one connection and some memory.

In case we are listening for property changes from other scripts, @leogodgg particularly and others have already given examples. Generally speaking, that’s when those two methods are used.

1 Like