How do I make a script read BackgroundTransparency float?

My code works in this way

I press a button, and if another button has a BackgroundTransparency of 0.3, another frame appears.

However, the frame doesn’t appear. In fact, the script straight up can’t read BackgroundTransparency. When I made it so if the other button with the 0.3 BackgroundTransparency is to be seen through if __ .visible == true, the other frame does appear, so the issue was luckily narrowed down to just BackgroundTransparency. However I still don’t know how to make the script to get what I need it. What’s wrong with the method?

Can you post the script here?

@BloxaBrick
local Transparency = math.floor((YourFrame.BackgroundTransparency * 100) + 0.5) / 100;
Change 100 to get more or less decimal places.

That doesn’t seem like what he’s asking, I think his issue is just checking the transparency.

Yes. It’s because he’s doing if it is == 0.3 and it is actually a float with a bunch more decimal places. That code I gave him will give the transparency in something he can compare it to, which is 0.3

You are probably looking to do:

Button1.MouseButton1Click:Connect(function()

if button2.BackgroundTransparency == 0.3 then

end
end)

Doesn’t work. It gives like 0.30000009 something. He already said this is the problem.

He said it can’t even read it. Probably isn’t float error.

Well it’s hard to solve a problem without the questioner providing any context.

local Transparency = math.floor((script.Parent.BackgroundTransparency * 100) + 0.5) / 100;

if Transparency == 0.3 then

print'a'

end

This works just fine.

How do I post in code format on the dev forum? Copy pasting the script doesn’t seem to cut it, but I’ll put it here like this anyway.

armamentmenu.SlotTypeChooserLinebacker_Armament.A_SlotTypePrimaries.SlotButton.MouseButton1Down:connect(function()

if pressed == true then

elseif pressed == false then

if linebackerarmament.A_TopListPrimary.RifleSlot.BackgroundTransparency == 0.3 then
linebackerarmamentcatalog.Listings.PrimaryRifleList.Visible = true

elseif linebackerarmament.A_TopListPrimary.SMGSlot.BackgroundTransparency == 0.3 then
linebackerarmamentcatalog.Listings.PrimarySMGList.Visible = true

elseif linebackerarmament.A_TopListPrimary.SMGSlot.BackgroundTransparency == 0.3 then
linebackerarmamentcatalog.Listings.PrimaryMachineGunList.Visible = true

end
end
pressed = false
end)

For example if I do

if linebackerarmament.A_TopListPrimary.RifleSlot.Visible == true then
linebackerarmamentcatalog.Listings.PrimaryRifleList.Visible = true

That works, but it’s not the solution I’m working towards.

Look at what I posted above.

armamentmenu.SlotTypeChooserLinebacker_Armament.A_SlotTypePrimaries.SlotButton.MouseButton1Down:connect(function()

if pressed == true then

elseif pressed == false then

local Transparency = math.floor((linebackerarmament.A_TopListPrimary.RifleSlot.BackgroundTransparency * 100) + 0.5) / 100;

if Transparency == 0.3 then

linebackerarmamentcatalog.Listings.PrimaryRifleList.Visible = true

elseif Transparency == 0.3 then

linebackerarmamentcatalog.Listings.PrimarySMGList.Visible = true

elseif Transparency == 0.3 then

linebackerarmamentcatalog.Listings.PrimaryMachineGunList.Visible = true

end

end

pressed = false

end)

Oops, just realized that there are different comparisons, haha. But, I’m sure you can fix that.

That works perfect. I guess we really had to carpet bomb the number line looking for that 0.3.

Awesome! Glad to have helped.

As you have noticed, non-integer numbers are not entirely accurate, and do not lend themselves well to comparison. In order to figure out why this might be the case, consider the means by which computers represent data. They use bits, or binary digits. That is, computers basically have lots and lots of on/off switches which stand for 1 and 0. Using these bits, how might we accurately represent non-integers?

As it turns out, this is actually really difficult to do, and to completely precisely represent a non-integer with a finite amount of switches is (almost always) impossible. Let’s explore why.

First, let’s look at how a computer might represent integers. Representing integers with binary is easy. Trivially, 0 is just 0 and 1 is just 1. Okay, so what about 2, 3, 4, 5, etc.? Well, let’s look at what happens in the decimal system which we use everyday! If we count from 0 to 9, how do we get the next number? We reset the digit to 0, and we add a number in front. So the next number up from 9 becomes 10! In binary, what would be the next number after 0 and 1? It would be 10 as well! And of course, after 10 comes 11. But what about after that? Well, we just reset all of the numbers to 0 and add a 1 in front. So after 11 is 100, just like 99 becomes 100 in decimal!

Because we can count with integers in this way, they are considered countable. This property means that integers can be fairly easily enumerated, or defined one after another. So let’s enumerate decimals in binary:

0 → 0
1 → 1
2 → 10
3 → 11
4 → 100
5 → 101
6 → 110
7 → 111
8 → 1000
9 → 1001
10 → 1010
11 → 1011
etc.

So, if we can represent integers so cleanly, why is it so hard to represent the numbers between the integers? For starters, we can’t enumerate all of the numbers between 0 and 1. We can have 0.1, 0.01, 0.001, 0.0001, but as you can see, there is no end in sight. This might be hard to believe, but there are actually an infinite amount of numbers between every other number, and that fact alone dooms non-integers into a realm of hopeless imprecision. But still, we have found a way to store non-integers using 1s and 0s. So how do computers do it?

The standard way of representing non-integral values is with floating points. Floating points are so named because the format allows for the movement of the decimal point. Essentially, what floating points do is store a significand and an exponent, such as what would be used in scientific notation:

1.254 * 10^6

In the number above, 1.254 is the significand, 10 is the base and 6 is the exponent. Representing a number like 0.3 is easy with a base of 10: 3 * 10^-1. But what about binary? With a base of 2, it is actually pretty hard to represent that number with a limited about of space. In order to see why, consider how many digits it takes to represent the number 1/3 in base 10. If you were to write this out, it would look like 0.3333… That’s an infinite amount of 3s! The same thing happens in binary. The only non-integral numbers that can be stored with a finite amount of space in binary are numbers that can be expressed as fractions with an integer in the numerator and a power of 2 in the denominator. Things like 1/4, 5/8, 3/16, 11/32 are all easy to represent. Things like 1/7, 4/5, 7/13, 3/10 are not. Because the absolute binary content might change depending on the format used to store the number (and because the computer can’t read your mind), directly comparing numbers which need an infinite amount of space to store might fail. That’s what happened here.


This was a long a reply, and probably not well-formatted either, but this concept is crucial to understand. I hope that this post helps you understand why your comparison might have failed where you expected it to succeed. In the future, avoid comparing decimals unless it is absolutely necessary. And if you absolutely, positively cannot avoid comparing decimals, do not compare them using the double-equals operator. Instead, subtract them and test the value against a sufficiently small “epsilon” value, like so:

function decimalEquals(a, b, epsilon)
    if epsilon == nil then
        epsilon = 0.00001;
    end
    return math.abs(a - b) < epsilon;
end

tl;dr: use the code above to compare decimals instead of ==

1 Like

Just a little tip, you can do epsilon = epsilon or 0.00001 :slight_smile:

I know, I just decided to forgo the short-circuit syntax for purposes of readability, but yeah you could shorten the code with that if you wanted to. You could even just write return math.abs(a-b) < (epsilon or 0.00001).