imnota10
|
  |
| Joined: 25 Dec 2010 |
| Total Posts: 2594 |
|
|
| 01 Feb 2015 07:24 PM |
Whenever a value in a leaderboard stat goes above the maximum value allowed for a 32-bit signed integer, the value becomes negated. This is a bug that is Roblox's fault, and has existed since the dawn of Roblox, and it shouldn't be up to the developers of the games within Roblox to fix bugs having to do with Roblox itself.
It's not even that hard to fix, a simple conditional check during the increment of a value on the leaderboard would fix this. Roblox has already been updating GUI code, they might as well fix that stupid leaderboard problem.
|
|
|
| Report Abuse |
|
|
Manchenzo
|
  |
| Joined: 27 Jan 2010 |
| Total Posts: 3209 |
|
| |
|
|
| 01 Feb 2015 08:24 PM |
is that the reason why my data store script doesn't work? Support either way. |
|
|
| Report Abuse |
|
|
imnota10
|
  |
| Joined: 25 Dec 2010 |
| Total Posts: 2594 |
|
|
| 01 Feb 2015 09:27 PM |
| Just gonna... bump this now. |
|
|
| Report Abuse |
|
|
0nesh0t
|
  |
| Joined: 24 Mar 2012 |
| Total Posts: 15845 |
|
| |
|
| |
|
|
| 01 Feb 2015 10:54 PM |
| May I ask why you are setting a value on the leaderboard stats that high? |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 01 Feb 2015 10:56 PM |
*facepalm* This has nothing to do with the leaderboard.
And if that's a problem, use a NumberValue... An integer is (by default) 32 bits (31 bits if signed), meaning the max number for a signed integer is 2^31 - 1. It's your fault for not knowing this, not Roblox's fault for displaying the integer. |
|
|
| Report Abuse |
|
|
|
| 01 Feb 2015 10:57 PM |
happens in SFT and some popular games, I hate making leaderboards SUPPORT |
|
|
| Report Abuse |
|
|
imnota10
|
  |
| Joined: 25 Dec 2010 |
| Total Posts: 2594 |
|
|
| 02 Feb 2015 04:52 PM |
"*facepalm* This has nothing to do with the leaderboard.
And if that's a problem, use a NumberValue... An integer is (by default) 32 bits (31 bits if signed), meaning the max number for a signed integer is 2^31 - 1. It's your fault for not knowing this, not Roblox's fault for displaying the integer."
You're absolutely wrong.
a integer's maximum value it totally dependent on the machines architecture. However, you're right if you're assuming the hardware that most PC's have, as far as I'm aware.
For most computers, a normal unsigned integer will be 32-bits and have a maximum value of 2^32 - 1
The maximum value for a signed integer that is 32-bits will be (2^32 - 1) / 2.
This IS a leaderboard problem. When the program increments the value, and the value reaches above the maximum value that can be represented as a 32-bit integer, it brings it back to the LOWEST value that can be represented by such, that being -((2^32 - 1) / 2)
This is a common bug in coding, and can easily be fixed on Roblox's part.
|
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 02 Feb 2015 05:31 PM |
Notice my "by default" you mongaloid. And you're wrong. You probably mean (2 ^ 32 / 2) -1 WHICH IS THE SAME THING -.- Do you not know 2 * 2 * 2 /2 is the same thing as 2 * 2.
This is NOT a leaderboard problem, it's the IntValue "problem". You're fault for using an IntValue. You obviously don't know why it goes negative, it's a YOU problem. You overflow by adding 1 to the max SIGNED int giving a 1 in the SIGN bit giving you the smallest. God damn you're dumb |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 02 Feb 2015 05:33 PM |
| Roblox shouldn't handle IntValue overflows for us because the programmer can do it themselves you lazy ODer |
|
|
| Report Abuse |
|
|
imnota10
|
  |
| Joined: 25 Dec 2010 |
| Total Posts: 2594 |
|
|
| 04 Feb 2015 10:37 PM |
"Notice my "by default" you mongaloid."
Once again, you're wrong. "Default" assumes a standard, while the size of an int is not standardized because hardware varies. One piece of hardware will NOT use the same form of memory manipulation as another. They'll probably even have entirely different forms of assembly language.
Also, did you even look at the definition of the word before using the word "Mongaloid"? If so, you would realize that it doesn't make ANY sense in the context you used it in.
"And you're wrong. You probably mean (2 ^ 32 / 2) -1 WHICH IS THE SAME THING -.- Do you not know 2 * 2 * 2 /2 is the same thing as 2 * 2."
((2^32)/2) -1 is the same as (2 ^ 32 / 2) I put the parentheses to emphasize the important parts of the expression. I'm not "wrong" for choosing to write the expression differently.
"This is NOT a leaderboard problem, it's the IntValue "problem". You're fault for using an IntValue."
It IS a leaderboard problem. Health also uses an integer value to represent health, but setting it above ((2^32)/2) - 1 does not set your health to negative and kill your character. This is because they decided that it was a bug worth fixing. There's no such thing as a "problem with an int value", because that's claiming that the language itself is bugged, which it is not. They simply aren't using conditional statements to correctly check the value before incrementing it.
"You obviously don't know why it goes negative, it's a YOU problem."
I'm a programmer, I know why it negates after reaching its max value. This is not a problem with the base type once again, because blaming a language for your inability to properly control the flow of your code is the coders problem, not the language.
"You overflow by adding 1 to the max SIGNED int giving a 1 in the SIGN bit giving you the smallest."
This does not explain the process at all. At max value, the value for all bits will already be 1. More specifically, the value of a 32-bit integer would be: 11111111111111111111111111111111. You can not "give" it a 1, because all the bits are already set to one. I forget the exact process of converting it to a negative value. I'd have to read up on it again.
|
|
|
| Report Abuse |
|
|
imnota10
|
  |
| Joined: 25 Dec 2010 |
| Total Posts: 2594 |
|
|
| 04 Feb 2015 10:39 PM |
"Roblox shouldn't handle IntValue overflows for us because the programmer can do it themselves"
Roblox should fix their own code problems. They aren't expected to add things at the whim of players, but they most certainly are expected to fix the bugs that they have due to over-looking certain aspects of their code. |
|
|
| Report Abuse |
|
|
|
| 04 Feb 2015 10:45 PM |
No support.
This isn't a ROBLOX bug, it's how integers work with computers. Game developers can get around this if they want, but it's not a bug.
I think ROBLOX should make IntValues have a maximum value and be unable to go that high. That would "fix" this easily. |
|
|
| Report Abuse |
|
|
imnota10
|
  |
| Joined: 25 Dec 2010 |
| Total Posts: 2594 |
|
|
| 04 Feb 2015 10:50 PM |
"This isn't a ROBLOX bug, it's how integers work with computers. Game developers can get around this if they want, but it's not a bug."
It is a Roblox bug. A bug is when code does not show behavior that you expected it to show. When you increment a value, you most CERTAINLY aren't expecting it to then become the lowest possible value it can, that is defined as a bug.
"I think ROBLOX should make IntValues have a maximum value and be unable to go that high. That would "fix" this easily."
Yes... That's how everyone deals with this problem. This is a very common problem. |
|
|
| Report Abuse |
|
|
imnota10
|
  |
| Joined: 25 Dec 2010 |
| Total Posts: 2594 |
|
|
| 04 Feb 2015 10:51 PM |
| I also want to point out the saying "No support" than offering a fix is a paradoxical set of statements. |
|
|
| Report Abuse |
|
|
|
| 04 Feb 2015 11:02 PM |
If you understand computers, you know that it is not fully a bug. It may be a bug to us, but it's not a bug to the computer. It's simply how computers deal with integers that are too large.
What do you think should happen instead when numbers get too large? |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 04 Feb 2015 11:07 PM |
'Once again, you're wrong. "Default" assumes a standard, while the size of an int is not standardized because hardware varies. One piece of hardware will NOT use the same form of memory manipulation as another. They'll probably even have entirely different forms of assembly language.' No. Assembly language has nothing to do with the size of an integer, it's hardware specific. And no matter what the size, go look up integer overflow.
'It IS a leaderboard problem. Health also uses an integer value to represent health, but setting it above ((2^32)/2) - 1 does not set your health to negative and kill your character. This is because they decided that it was a bug worth fixing. There's no such thing as a "problem with an int value", because that's claiming that the language itself is bugged, which it is not. They simply aren't using conditional statements to correctly check the value before incrementing it.' Nope, health is a float, not an integer; and it's NOT a leaderboard problem.
'I'm a programmer, I know why it negates after reaching its max value. This is not a problem with the base type once again, because blaming a language for your inability to properly control the flow of your code is the coders problem, not the language.' No, it's a problem because languages shouldn't have to prevent overflow because why take the extra step if you can do it yourself?
'This does not explain the process at all. At max value, the value for all bits will already be 1. More specifically, the value of a 32-bit integer would be: 11111111111111111111111111111111. You can not "give" it a 1, because all the bits are already set to one. I forget the exact process of converting it to a negative value. I'd have to read up on it again. ' It doesn't matter, signed numbers are represented with 31 bits for "storage" and the most significant bit IS the sign bit. For example, my max signed 8-bit number: 011111111 If I add 1, the processor doesn't care if it's signed or unsigned; but Roblox IntValues are signed (otherwise they would overflow to 0, and not have negative numbers) so adding 1 would give you: 10000000 Which would be a negative number.
'Roblox should fix their own code problems. They aren't expected to add things at the whim of players, but they most certainly are expected to fix the bugs that they have due to over-looking certain aspects of their code.' It has nothing to do with that. Read above.
'It is a Roblox bug. A bug is when code does not show behavior that you expected it to show. When you increment a value, you most CERTAINLY aren't expecting it to then become the lowest possible value it can, that is defined as a bug.' Negative numbers are stored as just a 1 in the most significant bit, meaning it's actually a LARGE number; we just represent signed numbers like this.
'"I think ROBLOX should make IntValues have a maximum value and be unable to go that high. That would "fix" this easily."' IntConstraintValues |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 04 Feb 2015 11:11 PM |
| Well then again, some assembly languages have different representations for sizes but in most cases, an "int" will be 32 or 64 bits; regardless the size is not what makes your "max number" go to "min number". |
|
|
| Report Abuse |
|
|
imnota10
|
  |
| Joined: 25 Dec 2010 |
| Total Posts: 2594 |
|
|
| 04 Feb 2015 11:11 PM |
You completely ignored what I said. " A bug is when code does not show behavior that you expected it to show."
"A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways." - Wikipedia
"A software bug is a problem causing a program to crash or produce invalid output. The problem is caused by insufficient or erroneous logic. A bug can be an error, mistake, defect or fault, which may cause failure or deviation from expected results." - Techopedia
By the very definition of a bug, the value going from positive to negative when you're trying to increment it is indeed a bug. Yes, there is a reason it happens, but that doesn't matter. There's ALWAYS a reason something happens, that doesn't change the fact that what happens is not what is intended, and henceforth a bug. |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 04 Feb 2015 11:13 PM |
| But this is not a bug/flaw, it's just your misunderstanding (no offense) of signed numbers vs unsigned numbers and overflow. I mean SURE you can implement something for Lua to prevent this but this might cause more harm then good. And if it were a "bug" (which it is not) then why would this "bug" appear in all REAL programming languages (C, Asm, etc.) |
|
|
| Report Abuse |
|
|
|
| 04 Feb 2015 11:30 PM |
cntkillme.
This. is. a. bug.
When a program GIVES an unexpected result to anyone, even people under nine years old. Do you expect them to go like, "Oh of course, the computer has a limit on int values.".. No, they will say 'BUG!!!'.
Thanks for your responce, Mr. Internet Explorer. (psst. When you have that logo, you will know many people hate you) |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 04 Feb 2015 11:33 PM |
It's not unexpected, people who don't understand how integers were are just oblivious to it. In fact, if Lua didn't allow you to overflow then it would make less sense.
0111 + 0001 should not be 1000? It's just logic, read up how signed integers work and you'll realize why it's not a bug. |
|
|
| Report Abuse |
|
|
imnota10
|
  |
| Joined: 25 Dec 2010 |
| Total Posts: 2594 |
|
|
| 04 Feb 2015 11:40 PM |
"No. Assembly language has nothing to do with the size of an integer, it's hardware specific. And no matter what the size, go look up integer overflow."
I never said the assembly has anything to do with the size. My exact words were: "They'll probably even have entirely different forms of assembly language."
In no way did I mention that this dictates how much memory a data type represents. But the form of assembly DOES affect the method of memory manipulation.
'It IS a leaderboard problem. Health also uses an integer value to represent health, but setting it above ((2^32)/2) - 1 does not set your health to negative and kill your character. This is because they decided that it was a bug worth fixing. There's no such thing as a "problem with an int value", because that's claiming that the language itself is bugged, which it is not. They simply aren't using conditional statements to correctly check the value before incrementing it.'
"Nope, health is a float, not an integer; and it's NOT a leaderboard problem."
Okay, very well, it's a float. Doesn't change the fact that they had to code it in to check if the value is above the maximum excepted value. I'm not going to argue about grouping UI sections and functionality. The problem is stated, and a solution is known. There's no reason for a fix.
"No, it's a problem because languages shouldn't have to prevent overflow because why take the extra step if you can do it yourself?"
What are you talking about? Was this sarcasm to try to claim that languages SHOULD manage this? In which case you're wrong. It's in no way a languages job to prevent the conversion from positive to negative. A good language wouldn't do that honestly. A good language will do only what is HAS to do, and leaves the programmer to decide what behavior they wish to change.
"It doesn't matter, signed numbers are represented with 31 bits for "storage" and the most significant bit IS the sign bit. For example, my max signed 8-bit number: 011111111 If I add 1, the processor doesn't care if it's signed or unsigned; but Roblox IntValues are signed (otherwise they would overflow to 0, and not have negative numbers) so adding 1 would give you: 10000000 Which would be a negative number."
That's not "adding 1" though. That's a complete misrepresentation of what is happening. I'm not explaining this well at all. You're right though, but that's not the point I've been trying to make.
"It has nothing to do with that. Read above."
It IS a problem with there code. if I had C++ code that did a for look, incrementing a value indefinitely just for the sake of it, say...
long signed int = 0; while (1 == 1) { x++; }
The EXPECTED result it to achieve a constantly increasing value. When this inevitably DOES NOT HAPPEN, it is referred to as a bug.
"Negative numbers are stored as just a 1 in the most significant bit, meaning it's actually a LARGE number; we just represent signed numbers like this."
No, it's not a "large" number. That's a completely different thing in programming that involves increasing the amount of space being occupied in memory by an object with that specified base type. |
|
|
| Report Abuse |
|
|