Can you try printing on line 22 to see if/when the Mine.OnServerEvent is triggering.
Yeah, I did. It seems to be printing after the event.
It must be a problem with the “if CS:HasTag(Hit, “Ores”) then” block. You should add an “else” and then print something to see if it’s returning as false.
if CS:HasTag(Hit, "Ores") then
print("Ores")
local HP = Hit.Parent:GetAttribute("HP").Value
print("StillWorking")
Health = HP
print("Possibly still working")
Hit.Parent:SetAttribute("HP", Health-1)
print("Might be broken here")
print(HP)
if HP <= 0 then
print("RockBroken")
else
print("No tag, LOL")
end
end
No print. It’s very odd.
You placed it wrong. Put the else somewhere else.
if CS:HasTag(Hit, "Ores") then
print("Ores")
local HP = Hit.Parent:GetAttribute("HP").Value
print("StillWorking")
Health = HP
print("Possibly still working")
Hit.Parent:SetAttribute("HP", Health-1)
print("Might be broken here")
print(HP)
if HP <= 0 then
print("RockBroken")
end
else
print("No tag, LOL")
end
So the event prints, the touch prints, but everything after does not print? Weird…
That’s what I have been saying. I would put this in bugs, but I want to see if it is a bug, or it’s just me being an incompetent scripter.
For some reason, once I do it on the client, the script seems to work? I’m going to attempt to move the script to the actual tool. The whole thing does work, once I place it within a local script. So, what does that mean?
I just read an article and it said to use a LocalScript to listen for the tag. I didn’t read the whole thing though, I just typed in “LocalScript” in Cmd + F and that was the thing that popped up.
So try checking for the tag in a local script and use an event to fire everything else.
I managed to fix it though seeing another script, and trying another solution. It wasn’t seeing the things in SP, so I had to fix it a little.
So is everything working as intended now?
1 Like
I don’t know what your Pickaxe’s LocalScript looks like, but you ideally want to be detecting touches on the client for this, while also detecting user input. When both debounces align, you can fire a remote to let the server know it’s okay to damage the ore. You’d need sanity checks with this of course.
Logpoints would make debugging this easier so you don’t need to add a print everywhere, just a tip.
Few things I see that could be the culprit -
- Touched is created whenever
Mineremote is fired; this will cause a memory leak when fired multiple times and you might not be receiving a response from the client to initiate the Touched event. - Touched passes the part that made contact with the part as its only argument. Health is unlikely to ever exist. Make sure to not pass this through the client/server boundary.
- You can’t get
.Valueout of an attribute. Attributes do not support Instances either. I assume you’re trying to do this on a number.
Yeah, the attribute issue is now the problem. It would’ve been nice to do so, but I guess not. What is the alternative method I can do?
You can always use a NumberValue for your “HP”.
Doesn’t that add to the memory?
Probably, but it’s the only alternative I can think of.
Aw man. Guess I’ll be moving back to the IntValues.
Oh no, attributes are definitely fine and likely preferrable, I was just saying you can’t use Value on it as it’s a number, and numbers can’t have a value ‘property’ associated with it since it’s already the number.
And value objects are totally fine as well, both would take up memory. It’s really just up to preference I assume. I use attributes for Health & MaxHealth of my enemies due to lack of precision with Humanoids.
So, how would I do something that I was trying to achieve within the previous version of the script? Back to the IntValues, or there is an alt. to fix that property value.