Scripting Helpers is winding down operations and is now read-only. More info→

Not able to access team color? [closed]

Asked by

BSIncorporated 640

9 years ago

When I have it print Color the output says: Bright Blue, but when I ask if Color = "Bright blue" it returns that it's not. Please Help

while wait() do
    Players = game.Players:GetChildren()
    NumPlayers = game.Players.NumPlayers
    for i,v in pairs (Players) do
        Color = (v.TeamColor)
        if Color == "Bright blue" then
        print 'success'
        else
        print (Color)
        end
    end
end

Locked by AmericanStripes, BSIncorporated, SanityMan, Operation_Meme, Redbullusa, and MessorAdmin

This question has been locked to preserve its current state and prevent spam and unwanted comments and answers.

Why was this question closed?

2 answers

Answered by

BlueTaslem 18071

9 years ago

Comparing different types of things in Lua will always result in false:

print( 1 == "1" ) -- false
-- (one is a number, one is a string)

print( Workspace == "Workspace") -- false
-- (one is a ROBLOX instance, one is a string)

In your case, TeamColor is a BrickColor value; so you can't compare it with "Bright blue", a string.

You have to compare BrickColors:

if v.TeamColor == BrickColor.new("Bright blue") then

Equivalently, you could turn the TeamColor into a string (but that would be worse)

if tostring(v.TeamColor) == "Bright blue" then
-- or
if v.TeamColor.Name == "Bright blue" then
-- as chess123mate suggested

"but that would be worse"

In general, you want to deal with the most restricted possible types. Lua makes this a little less pleasant, unfortunately.

Still, it's better to talk about BrickColors, since it's harder to, for instance, make a typo in a name¹. Strings are more free-form and could have a lot more done to them than BrickColors.

The basic problem is that you can have strings which aren't brick colors -- thus there's a lot more room for weirdness and confusion.

Using BrickColors may be marginally slower, because of the cost of creating a new one. That should not be an argument to use strings. 20% savings on something that should only be taking a very small fraction of your program time doesn't justify using messier/worse code.

If you save 0.1 seconds by using v.TeamColor.Name == "Bright blue" instead of v.TeamColor == BrickColor.new("Bright blue"), you're probably calling this hundreds of thousands of times. Why are you doing that? That is the problem you have to solve.

It would make the most sense to have a variable for the team color defined anyway,

oneTeam = BrickColor.new("Bright blue")

.....

if v.TeamColor == oneTeam then

This reads the clearest, and will cut most of the cost of BrickColors; it also helps prevent typos.

Other comments:

You should probably use :GetPlayers() instead of :GetChildren().

Meaning BrickColor.new("Bright bleu") won't make a "valid" BrickColor. Unfortunately, ROBLOX will just give you 'Medium stone grey', but this is probably much easier to catch when you debug. Even better, you could use BrickColor.blue to avoid the possibility altogether (or in general, making your own variables like this for your pallet) ↩

Wow, thank you so much BSIncorporated 640 — 9y

Why do you say "that would be worse", for converting the TeamColor into a string? Considering the first one has to convert a string into a new BrickColor (which means another object will need to be garbage collected). chess123mate 5873 — 9y

It makes more sense to use a more restricted type (BrickColor) than a less restricted type (string), in general. In particular, you don't have to trust that tostring on a BrickColor doesn't make something like "BrickColor(Bright blue)" or anything like that. You don't have to worry about GC. The tostring cost might even be higher, at scale. BlueTaslem 18071 — 9y

I see your point about not needing to trust the results of tostring (though we have an even better method: use the .Name property), but I don't see how the cost of calling tostring (which probably calls a function that returns ".Name") could possibly exceed the cost of converting "Bright blue" into a new BrickColor object. Doing a quick test in Roblox Studio suggests that - ignoring GC... chess123mate 5873 — 9y

View all comments (4 more)

...creating a new BrickColor is about 80% more expensive than calling tostring. (tostring is only ~30% more expensive than just checking the .Name property) chess123mate 5873 — 9y

You should not have to care about how many BrickColor values you create. Algorithmic improvements are better than microoptimizations, always. You should prefer better code over code that's 20% faster when it only does a trivial thing. (If you were to save 0.1 seconds by switching, you're calling `BrickColor.new` hundreds of thousands of times -- which already makes no sense since there's only a ha BlueTaslem 18071 — 9y

[Note: Probably should've said "v.TeamColor.Name" instead of "v.Name"] Why is 'v.TeamColor.Name == "Bright blue"' worse code vs "v.TeamColor == BrickColor.new("Bright blue")'? Are there any articles explaining this principle you're referring to when you say "you want to deal with the most restricted possible types" (so that I might understand the idea)? chess123mate 5873 — 9y

chess123mate: I just remembered the relevant phrase, being "stringly typed" (a pun on "strongly typed"). Whether or not they're convincing arguments (for some things, it does make sense) hopefully you can find material around that. BlueTaslem 18071 — 9y

Answered by

chess123mate 5873

9 years ago

When you say print(Color), the print command automatically converts its arguments to a string. However, when you compare a Color with a string, you will always get false because they are different types. You have a few options:

if tostring(Color) == "Bright blue" then

if Color.Name == "Bright blue" then

if Color == BrickColor.new("Bright blue") then