Well, there is 4 now… which is the new native one.
Back over to when door got underlined and the motors, was the way I did it right or is there a better way instead of using a table?
No, there are only 3 flags for type checking, the --!native flag -that was added recently- isn’t the same, it doesn’t have anything to do with type checking, that’s why I didn’t include it.
Ohhh, ok. Thanks. What exactly does native mean or do? I was reading it and it was confusing.
The only flaw you have in your approach with Door is that you’ll have to cast at your call site to any type if it isn’t already, since there’s not natural way to make an Instance & table type. Any time you cast to any, you lose a little bit of type safety.
I would probably replace the Door argument with a table containing all the things you care about.
type DoorAssembly = {Root: Model, Motor1: Motor6D, Motor2: Motor6D}
Then when you call, you’ll have to do some type checking.
local m1 = myDoor:FindFirstChild("Motor1")
local m2 = myDoor:FindFirstChild("Motor2")
if m1 and m1:IsA("Motor6D") and m2 and m2:IsA("Motor6D") then
AnimateDoor("Open", {Door=myDoor, Motor1=m1, Motor2=m2})
else
error("Door is missing components") --handle this as you will
end
Alternately, you can do that same type checking in your function.
function AnimateDoor(Direction: "Open"|"Close", Door: Instance)
local m1 = myDoor:FindFirstChild("Motor1")
local m2 = myDoor:FindFirstChild("Motor2")
if m1 and m1:IsA("Motor6D") and m2 and m2:IsA("Motor6D") then
--rest of the function
else
--error handling
end
end
Where you perform the type checking is up to you. If you have a universal way to “fix” the problem (e.g., instantiate new Motor6D objects & link them up), then I’d do the type checking in the AnimateDoor function.
Natively compiled Roblox code is way more performant, if you run the same code on native mode and on normal mode, you will see that native mode is more performant. That isn’t something you can control. It’s still being added so don’t worry about it, it’s still in beta now.