Material Footsteps Tutorial

  • I posted a video like.. 3 weeks ago and i think its useful enough to be here :P
    So my script changes a player's running/walking sound depending on the material he is walking

    Click here for Tutorial :)


    • Can be placed in Non-Player Characters (if Character has Sound Script)
    • Sound Instances with Smooth Terrain Material names are Compatible :P
    • The Script have about 19 lines and still works (lol how)
    • Doesn't need Raycasting (too complex for me)
    • also doesn't need Touched Event


    • Can't Detect Smooth Terrain Water (unless you figure out a way to fix this)

  • @FullMetalEdward45221 Lines are a bad unit to measure your code.

  • @hiimgoodpack said in Material Footsteps Tutorial:

    Lines are a bad unit to measure your code

    you're right, i'm just telling i didn't do this:

    if Humanoid.FloorMaterial == Enum.Material.Grass then
       --Do Stuff
    elseif Humanoid.FloorMaterial == Enum.Material.Concrete then
       --Do Stuff
    elseif Humanoid.FloorMaterial == Enum.Material.Sand then
       --Do Stuff (and so on)

    I just found a different way to make my code shorter :3

  • @hiimgoodpack In general, sure. But in this instance it does the job just fine.

    Lines clearly aren't overly long, and the point is a rough estimate of "it's not too long" rather than "it represents exactly this much effort".

  • @fredfishy All code that works doesn't mean it's good code. I never watched the video so I can't judge but code that "just works" isn't necessarily good code

  • Using the Changed event is genius, I would have thought of something else extremely complicated.

  • @sjr04Alt Good code is really subjective. The universal way of good code is only good code because it is the popular way of writing that way.

    My way of solving any problem is by first just getting it to work. And then only start practicing the "Good Code".

  • @sjr04Alt My point is, you shouldn't just be repeating the mantra "don't measure code progress by lines" without actually understanding WHY you shouldn't be measuring code progress by lines.

    In an informal "look it's only this long" setting, measuring code volume by lines is totally acceptable.

  • Global Moderator

    @Formidable_Beast @FullMetalEdward45221 Actually using the Changed event is bad, because it fires when any property of an object changes.

    Instead you should consider using Instance:GetPropertyChangedSignal(PropertyName), which is a method that returns an event that is fired with only that specific property changes.

    Keep Changed for when you want to listen for any property change. Do note that there are some exceptional properties that never fire any events when changed (such as a part's Position and CFrame properties), for performance reasons.

    There's also one exception to the above rule. ValueBase objects. ValueBase objects only fire their Changed event when their Value property changes.

  • @FullMetalEdward45221 i would also like to point out that ReadVoxels can be an alternative, albeit a more complex alternative that can detect smooth terrain water

Log in to reply

Looks like your connection to Scripting Helpers was lost, please wait while we try to reconnect.