I’ll preface this by saying I’m uncertain as to whether this would be classified as a documentation bug because the behavior is intended but not documented or if it is indeed an engine but because the behavior is unintended.
When attempting to pass a table with boolean keys through any Remote...
or UnreliableRemote...
object, the call will raise an error with the following error message: “Invalid table key type used”
This can be demonstrated by pasting the following code into a server-side script on an empty baseplate and stepping on the button it generates:
--!strict
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
-- This will be sent to the client.
local Payload = {
[true] = "Hello";
}
-- -- --
local Active = false
local Color_ByActive = {
[true] = BrickColor.new("Bright red");
[false] = BrickColor.new("Bright green")
}
-- -- --
local Remote = Instance.new("RemoteEvent", ReplicatedStorage)
local Button = Instance.new("Part")
Button.Anchored = true
Button.BrickColor = Color_ByActive[Active]
Button.CFrame = CFrame.Angles(0, 0, 0.5 * math.pi) + Vector3.new(0, 0.2, -16)
Button.Shape = Enum.PartType.Cylinder
Button.Size = Vector3.new(0.4, 4, 4)
Button.Parent = workspace
Button.Touched:Connect(function(Hit)
if Active then
return
end
local Character = Hit:FindFirstAncestorWhichIsA("Model")
local Player = Character and Players:GetPlayerFromCharacter(Character)
if Player then
Active = true
Button.BrickColor = Color_ByActive[Active]
local Success, Reason: any = pcall(
Remote.FireClient,
Remote,
Player,
Payload)
if Success then
print(string.format("Successfully messaged player %s!",
Player.Name))
else
warn(string.format("Failed to message player %s for reason: %*",
Player.Name,
Reason))
end
task.wait(2)
Active = false
Button.BrickColor = Color_ByActive[Active]
end
end)
While it likely goes without saying, the workaround for this problem is to simply not use boolean keys in networked tables.
Expected behavior
Ideally, boolean keys would be valid table keys when performing remote calls, as there is no indication in the documentation that they wouldn’t be, although this might be more of a feature request. Even if they are not supported outright, Remote Limitations documentation suggests that they would at least be stringified. Outside of cyclical tables or legitimate argument mismatches, I do not expect my remote calls to throw errors prior to actually making the call.