Color3.fromRGB() not working correctly with RemoteEvent?

Help and Feedback Scripting Support
,
#1

I’m making a Lantern that displays a GUI upon the User equipping it. I want the user to be able to type in their own R, G, and B values so they can fully customize the color of the lanterns light. To do this, I referenced the values that the GUI had, and cast it over to the server side so it can change the color. What ends up happening, is when the player types in their R, G, and B values, it sets the color and the brick color to black, which is not supposed to be happening.

Example of GUI:
image

GUI is closable, but that only sets the Visible values of the GUI elements so it shouldn’t matter, just throwing it out there in case I’m wrong.

Here is my Script (not a LocalScript)

-- RemoteEvent Portal --
local Portal = game.ReplicatedStorage.Bridge.ChangeAesthetics
-- Core Script --

local function onAestheticChangeReceived(Player, RValue, GValue, BValue)
	Player.Character:WaitForChild("Mayonaka Lantern").LightPart.Color = Color3.fromRGB(RValue, GValue, BValue)
	wait()
	Player.Character:WaitForChild("Mayonaka Lantern").LightPart.PointLight.Color = Color3.fromRGB(RValue, GValue, BValue)
end

Portal.OnServerEvent:Connect(onAestheticChangeReceived)

Very basic, and not that long surprisingly.

Here is my LocalScript also if there is something wrong with that:

-- RemoteEvent Portal --
local Portal = game.ReplicatedStorage.Bridge.ChangeAesthetics
-- Extra Information --
local Player = game.Players.LocalPlayer
local LanternGUI = Player.PlayerGui:WaitForChild("LanternGUI")
local RValue = LanternGUI.OptionsFrame.R.Text
local GValue = LanternGUI.OptionsFrame.G.Text
local BValue = LanternGUI.OptionsFrame.B.Text
local SubmitButton = LanternGUI.OptionsFrame.ChangeColorButton
-- Animations -- (might add, not sure.)

-- Core Script --

script.Parent.Equipped:Connect(function()
	LanternGUI.Enabled = true
end)

script.Parent.Unequipped:Connect(function()
	LanternGUI.Enabled = false
end)

SubmitButton.MouseButton1Click:Connect(function(Player)
	Portal:FireServer(Player, RValue, GValue, BValue)
end)

Little more complicated, but still fairly short.

I know this might be something super easy I’m missing, I just have a feeling the RGB values I made with the variables might be wonky, or are not supported by Color3.fromRBG(). Same happened with Color3.new() btw.

2 Likes
#2

You’re sending the player variable on the client. The server automatically recieves it. So just remove that and it should work.

1 Like
#3

On the server event you only provided one argument even though you provided 4 when you fired it. Also try using tonumber() to verify if it’s a number.

SubmitButton.MouseButton1Click:Connect(function(Player)
    local R = tonumber(RValue)
    local G = tonumber(GValue)
    local B = tonumber(BValue)
    if R and B and G then
	    Portal:FireServer(R,B,G)
    end
end)

Unsure if this next part will work, but try it out:

Portal.OnServerEvent:Connect(function(Player,R,B,G)
    onAestheticChangeReceived(Player,R,B,G)
end)
1 Like
#4

Oh yeah I missed that, I got confused for a moment deciding if it goes on the Server one, or the local one, so I kept it in, forgot to remove it. Thanks for the catch.

#5

I don’t think you have to convert it to number though:
image

1 Like
#6

Thanks a lot, I’ll be sure to check to see if these changes work, and keep them noted for the future when working with number values. :sweat_smile:

#7

The input from the text could potentially not be a number, so using tonumber can check if it is or isn’t. If it isn’t, it won’t fire the event

1 Like
#8

Speaking of which, it doesn’t do anything now with the changes. I guess since tonumber() finds a literal number, and the TextBox is technically a string, it says it’s false.

#9

I’m going to do some more looking into this later, and see if I can find anything else that could be the issue. Thanks for the help so far, please, if you find something, lemme know!

#10

You need to define the RGB values on click and not when the script loads. Adding on to @lluckvy’s changes this should work.

local OptionsFrame = LanternGUI.OptionsFrame
local R_TextBox = OptionsFrame.R
local G_TextBox = OptionsFrame.G
local B_TextBox = OptionsFrame.B
SubmitButton.MouseButton1Click:Connect(function()
    local R = tonumber(R_TextBox.Text)
    local G = tonumber(G_TextBox.Text)
    local B = tonumber(B_TextBox.Text)
    if R and G and B then
	    Portal:FireServer(R, G, B)
    end
end)

I also defined the textboxes since your code would index them each time the player clicked changed color instead of doing that once.

1 Like
#11

Thank you for catching that, I didn’t even think about the whole “inside the click function” thing. I remember making this type of mistake in the past, and posting about it. Thank you for the help, I’ll let you know if it works later.

1 Like
#12

Thank you @lluckvy, and @Kabutey for the help. I wish I could mark you both as Solution, but this issue has been solved with Kabutey’s revised script of all the help together. This now works like it should, and it’s fully customizable just like intended!

quick edit: I had this issue where if you set the light above the value of 255 on each, it would emit a really bright light which could be abused, so I added a counter-measure which is this:

if R and G and B > 255 then
    print("no.")
else
    Portal:FireServer(R, G, B)
end

Which I added right under the first if R and G and B then.

Again, thank you.

1 Like
#13

Note that if R and G and B > 255 then

Should be if not R or not G or not B or R > 255 or G > 255 or B > 255 then

As in,

if not R or not G or not B or R > 255 or G > 255 or B > 255 then
    print("no.")
else
    Portal:FireServer(R, G, B)
end

That way, you make sure all numbers are defined and less than or equal to 255.

Or, you could simplify with

if R and G and B and R <= 255 and G <= 255 and B <= 255 then
    Portal:FireServer(R, G, B)
end
#14

It doesn’t actually have an issue as of right now, it seems to work just the way I want it to. It doesn’t matter if only 1 box goes over, it works just fine. Thanks tho

#15

If it works fine then great. Just know your current implementation could be shortened to B>255, and that it will error if R, G, or B aren’t numbers.

1 Like