FloorMaterial not changing for a part / mesh

  1. I’ve been making this game, and it requires FloorMaterial. I used this because it was the easiest to detect (and script lol), but the FloorMaterial is not changing. I am not using a player, I am using a mesh → Humanoid → Script. The FloorMaterial doesn’t change. I am quite sure it’s not the script. Also note, the mesh is cloned.

local hum = script.Parent

if hum.FloorMaterial == Enum.Material.Air then
	print("In the air")

else
	print("Touching the ground")
end
  1. No solutions quite yet…

If you would like any code or pictures / videos, please feel free to ask!

1 Like

Nothing in the code is changing the Material property of the part; it’s only checking what the current value is for the FloorMaterial property *of the Humanoid.


If the issue is that the print statements are not appearing when the value of the FloorMaterial property is updated, then that’s occurring because the code is only being run when the script starts for the first time (it’s not being run in a loop / function / etc. where the condition can be checked for multiple times).

If you want it to check the current value of Humanoid.FloorMaterial every time it changes for the Humanoid, you can use the Instance:GetPropertyChangedSignal() method on that property:

Example

local Humanoid = script.Parent

Humanoid:GetPropertyChangedSignal("FloorMaterial"):Connect(function()
    if Humanoid.FloorMaterial == Enum.Material.Air then
        print("In the air")
    else
        print("Touching the ground")
    end
end)
2 Likes

It’s not printing anything. Also to note, the Humanoid FloorMaterial, is not changing, it only stays as “air”.

2 Likes

By chance, is the code included in a server script, which would be the following:

or a client-sided script, which would be the following:

  • A LocalScript or a Script with its RunContext property set to Client

If the code from the original post happens to be in a LocalScript, the code will not run in the Workspace unless it’s a descendant of a player’s Character model. The Roblox Creator Documentation site provides of list of all the containers where LocalScripts can run.

As a result, the code would need to be placed into one of the other options for it to run (either one of the server-sided script options or a Script with its RunContext set to Client).


Ah, in that case, the :GetPropertyChangedSignal() method would not be necessary here since that would only fire and run the function when the value of the FloorMaterial property changes.

Stil, changed it to a local script and a client script…
image

OP, I believe its better to just use raycasting instead.

local bomb = script.Parent.Parent
local rp = RaycastParams.new()
rp.FilterDescendantsInstances = {bomb}
rp.FilterType = Enum.RaycastFilterType.Exclude

local floorMaterial = Enum.Material.Air

local down = -Vector3.yAxis
local offset = (bomb.Size.Y / 2) + 0.1

local materialConnection = game:GetService("RunService").Heartbeat:Connect(function()
    local ray = workspace:Raycast(bomb.Position, down * offset, rp)
    floorMaterial = ray and ray.Material or Enum.Material.Air
end)
2 Likes

If it’s not printing anything upon moving it into the Workspace, then I currently don’t know what would be causing that to happen.

I have not been able to replicate that issue whether or not the Part and its descendants start in the Workspace or start in the ReplicatedStorage and are moved into the Workspace during runtime:

-- Script1 Code
-- In a script with "RunContext" set to Legacy
local Humanoid = script.Parent
local currentFloorMaterial = Humanoid.FloorMaterial

print("Part1's FloorMaterial is: "..tostring(currentFloorMaterial))
-- Script2 Code
-- In a script with "RunContext" set to Server
local Humanoid = script.Parent
local Part2 = Humanoid.Parent -- Part2 is currently in the ReplicatedStorage

task.wait(3)
-- Example wait (simulating if it's moved later on during the game's lifecycle)

Part2.Parent = workspace

local currentFloorMaterial = Humanoid.FloorMaterial
print("Part2's FloorMaterial is: "..tostring(currentFloorMaterial))

Regardless, I would recommend the raycasting option that @anirudh851 mentioned, instead, (so long as it still matches your use case)

especially because it might not be particularly performant on a large-scale to utilize Humanoids for objects that aren’t meant to be Character models. *Raycasting would also be more versatile for adding other features, such as special effects when it detects that the part is about to impact something.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.