The 255 bug bites again! - Page 5

RMc · 06-02-2006, 06:54 AM

For those of you who came in late:

Users: "Hey, they said the 255 bug would be fixed, and it isn't!"

LGO: "It's not a bug!! And besides only geeks and losers care about such things, so shut up!"

Users: "But..."

LGO: "But nothing! I'm obviously way too smart and important to bother with idiots who actually buy a computer game when it comes out! Don't you know you're supposed to wait for the 2006.999 patch, coming out sometime in mid-century? Dorks!"

And so it goes...

Eumel · 06-02-2006, 07:46 AM

It probably would have been smarter to stay on the safe side and sacrifice that extra byte per RBI number, IMO. Now, I'm not interested in leagues with inflated hitting, so this won't be an issue for me. However, I can't imagine the impact on database size and sim speed should be that big. For most situational stats, one byte for RBIs is enough -- maybe even for all of them. In that case, the whole thing amounts to one byte per player per season and league -- way less than a megabyte, even for large universes. Sim speed effect should not be that large either -- you need to update one RBI season total per player and game, alongside with countless other stats.

Of course the isssue when changing this would probably be something like savegame incompatibility....

canadiancreed · 06-02-2006, 07:59 AM

Quote:

Originally Posted by RMc

For those of you who came in late:

Users: "Hey, they said the 255 bug would be fixed, and it isn't!"

LGO: "It's not a bug!! And besides only geeks and losers care about such things, so shut up!"

Users: "But..."

LGO: "But nothing! I'm obviously way too smart and important to bother with idiots who actually buy a computer game when it comes out! Don't you know you're supposed to wait for the 2006.999 patch, coming out sometime in mid-century? Dorks!"

And so it goes...

So LGO=MD now?

Seriously while you may have a difference of opinion that in-accurate parody is a bit uncalled for. Also I've also been trying to explain the same thing as he has, should I also be labeled in your scathing screenplay segment?

The fact that a civil explanation of the potential reasoning for why the game was made in a certain fashion earning such a reaction is one reason why others may find that their questions unasnwered or answred by less forgiving posters (which there are some out there). I knwo if I saw such a response I'd think twice before bothering to offer suggestions or advice in the future and leave folks looking for help at the mercy of the "RMPL n00b!" crowd.

Just a thought before slamming hands that try to help out, even if it's just with possible explanations or what not.

battists · 06-02-2006, 08:10 AM

In a vain attempt to turn this thread a little more productive...

1. Please drop the "us" vs "them" thing. That means you pro 255+ RBI folks stop beating on LGO, and vice versa. Please?

Take a deep breath and resist the urge to reply to something above that aggravated, and let's start over.

2. If I'm going to bring this up again with Markus, we need to be constructive about it. Heard you loud and clear about RBI. But let's assume, for the sake of argument, that making every statistical field capable of exceeding 255 will cause problems with size and/or performance. If that is the case (and I certainly don't know if it is), then what are the most important fields, in your opinion, that need to be capable of going over 255?

I mean, so 190 is close to 255, RBI is a logical candidate. What about doubles? Triples?

Let's discuss this in a positive manner so that I can get this presented to Markus.

Eumel · 06-02-2006, 08:31 AM

I don't know which stat categories already have two bytes assigned, but this screen from the reports should help with the priorities:

http://reports.ootpbaseball2006.com/...derboards.html

Double and triples would be overkill, IMO.

battists · 06-02-2006, 09:03 AM

Quote:

Originally Posted by Eumel

I don't know which stat categories already have two bytes assigned, but this screen from the reports should help with the priorities:

http://reports.ootpbaseball2006.com/...derboards.html

Double and triples would be overkill, IMO.

Excellent idea, Eumel.

These single-season ones look like they deserve consideration at least:

Strikeouts (batter)
Walks (batter)
Games
Runs
Singles
HR
Walks (pitcher)

jarmenia · 06-02-2006, 09:16 AM

Quote:

Originally Posted by Le Grande Orange

It probably would be a good idea to mention in the Customization Guide that those running leagues with offences set to be significantly higher than those of real-world leagues may run into this issue.

You could also prevent the roll over. If a player has 255 in a certain stat, stop incrementing it. At least at that point it serves as some kind of reminder and doesn't get mixed in with other weaker players in the same catagory.

battists · 06-02-2006, 09:33 AM

Quote:

Originally Posted by jarmenia

You could also prevent the roll over. If a player has 255 in a certain stat, stop incrementing it. At least at that point it serves as some kind of reminder and doesn't get mixed in with other weaker players in the same catagory.

I'll add that into the discussion as well...

Chappy · 06-02-2006, 10:18 AM

Quote:

Originally Posted by battists

In a vain attempt to turn this thread a little more productive...

1. Please drop the "us" vs "them" thing. That means you pro 255+ RBI folks stop beating on LGO, and vice versa. Please?

Take a deep breath and resist the urge to reply to something above that aggravated, and let's start over.

2. If I'm going to bring this up again with Markus, we need to be constructive about it. Heard you loud and clear about RBI. But let's assume, for the sake of argument, that making every statistical field capable of exceeding 255 will cause problems with size and/or performance. If that is the case (and I certainly don't know if it is), then what are the most important fields, in your opinion, that need to be capable of going over 255?

I mean, so 190 is close to 255, RBI is a logical candidate. What about doubles? Triples?

Let's discuss this in a positive manner so that I can get this presented to Markus.

These single-season ones look like they deserve consideration at least:

Strikeouts (batter)
Walks (batter)
Games
Runs
Singles
HR
Walks (pitcher)

I too am disappointed to see the 255 design flaw again, as I remember Markus saying it would be gone in the new database.

But Steve is right, let's stay positive and constructive here, and maybe something can be worked out down the road.

As a rule of thumb, I'd say any statisitcal categories that routinely reach triple digits should avoid the 255 cap. So, I'd add RBI and possibly remove HR from your list, Steve.

jff1515155 · 06-02-2006, 11:15 AM

I agree only those stats that reach 100 are in jeoprady. Even joe hardy and roy hobbs in my universes never get close to 150 home runs.

Jared · 06-02-2006, 11:42 AM

Quote:

Originally Posted by canadiancreed

I do know that the next step up from 255 is 65536, which is using a new datatype to store the information, and if repeated enough may hae issue with size and even performance (i'm no c++ programmer so the resource hit is beyond me).

Yes, but what if I want to have a player drive in 65537 runs during the year!

canadiancreed · 06-02-2006, 11:44 AM

Quote:

Originally Posted by Jared

Yes, but what if I want to have a player drive in 65537 runs during the year!

hire the rockies pitrching staff

blynch10 · 06-02-2006, 11:47 AM

Quote:

Originally Posted by battists

In a vain attempt to turn this thread a little more productive...

1. Please drop the "us" vs "them" thing. That means you pro 255+ RBI folks stop beating on LGO, and vice versa. Please?

Take a deep breath and resist the urge to reply to something above that aggravated, and let's start over.

2. If I'm going to bring this up again with Markus, we need to be constructive about it. Heard you loud and clear about RBI. But let's assume, for the sake of argument, that making every statistical field capable of exceeding 255 will cause problems with size and/or performance. If that is the case (and I certainly don't know if it is), then what are the most important fields, in your opinion, that need to be capable of going over 255?

I mean, so 190 is close to 255, RBI is a logical candidate. What about doubles? Triples?

Let's discuss this in a positive manner so that I can get this presented to Markus.

Definetly RBI needs to be reconsidered. I don't use extreme hitting leagues but have on one occasions had a player hit the roll over for RBIs and another year come within 2 RBIs of 255. Was quite annoying to have the best player in the league have his history messed up with the rollover. I've not had it happen again (that I have ever noticed) and that makes it even more disappointing since it was such a huge accomplishment.

jff1515155 · 06-08-2006, 10:56 AM

Is there this can be addressed or is it a dead issue???

greenmonster04 · 06-08-2006, 02:09 PM

i hope its not a dead issue, since I feel that it is still a very important one... at least, for the minimum, RBIs (and runs?) need to be 'fixed'.

I have no programing knowledge, but sometimes it helps to think outside the box...

perhaps another 'block/byte/ 256whatever' could be added, and when the RBI byte reaches 255 it stops, and then starts tallying on this new byte.
the game code could then have a small modification that would add these bytes together.

as I said, I know nothing of programing, but it seems logical enough to me, and sounds like it would not add much, if any, overhead to the game.

Raidergoo · 06-08-2006, 02:36 PM

Quote:

Originally Posted by jff1515155

Is there this can be addressed or is it a dead issue???

Battist wrote that he is making a proposal to Markus.

SandMan · 06-08-2006, 02:58 PM

As a programmer I had this same issue in front of me. A field that should not reach past the value of a byte but may if some other factors were involved. I simply add a bit field and if the value exceeded the 255 limit the bit would be set to on indicating that the value is 255 plus the value in the field. This would then assume that the calculated field displayed on the reports is set to 2 bytes but this is done in a calculated field and is not required for saving the value in the file.

Example: Joe Blow has 254 RBI and there is 10 more games in the season and he sure to hit the 255 value. The database would have a bit field that is set to off and the 1 byte field will actually have the 8 bits set as 01111111 to store the value of 254....

Now he hits 10 more RBI, giving him a value of 265. This would change the byte to the on position and the RBI field (the 1 byte) will now read a value of 10 with the bits set as 01010000. Now this is simple when doing the calculations on the report simply adds 255 to the value of the RBI field stored to give you the value over 255. This works great because you are only adding a one bit to the database.

In the apps that I used this with it work great. Again it is just in design and most databases that I have created have unnamed fields set up to use in case of changes. I would then need to change the program and not the data design.....

Just my thoughts on this complex problem....While this is not a bug it really is an annoying error in the design of the database structure....

QuestGAV · 06-08-2006, 03:05 PM

Quote:

Originally Posted by SandMan

Just my thoughts on this complex problem....While this is not a bug it really is an annoying error in the design of the database structure....

It is a bug if incorrect data is stored, displayed, and acted on.

06-02-2006, 06:54 AM	#81
RMc All Star Starter Join Date: Jan 2004 Posts: 1,718	For those of you who came in late: Users: "Hey, they said the 255 bug would be fixed, and it isn't!" LGO: "It's not a bug!! And besides only geeks and losers care about such things, so shut up!" Users: "But..." LGO: "But nothing! I'm obviously way too smart and important to bother with idiots who actually buy a computer game when it comes out! Don't you know you're supposed to wait for the 2006.999 patch, coming out sometime in mid-century? Dorks!" And so it goes... __________________ "We're all behind our baseball team..."

06-02-2006, 08:31 AM	#85
Eumel Major Leagues Join Date: Mar 2003 Location: Germany Posts: 499	I don't know which stat categories already have two bytes assigned, but this screen from the reports should help with the priorities: http://reports.ootpbaseball2006.com/...derboards.html Double and triples would be overkill, IMO. Last edited by Eumel; 06-02-2006 at 08:32 AM.

06-08-2006, 02:58 PM	#97
SandMan Hall Of Famer Join Date: Aug 2003 Posts: 2,946	As a programmer I had this same issue in front of me. A field that should not reach past the value of a byte but may if some other factors were involved. I simply add a bit field and if the value exceeded the 255 limit the bit would be set to on indicating that the value is 255 plus the value in the field. This would then assume that the calculated field displayed on the reports is set to 2 bytes but this is done in a calculated field and is not required for saving the value in the file. Example: Joe Blow has 254 RBI and there is 10 more games in the season and he sure to hit the 255 value. The database would have a bit field that is set to off and the 1 byte field will actually have the 8 bits set as 01111111 to store the value of 254.... Now he hits 10 more RBI, giving him a value of 265. This would change the byte to the on position and the RBI field (the 1 byte) will now read a value of 10 with the bits set as 01010000. Now this is simple when doing the calculations on the report simply adds 255 to the value of the RBI field stored to give you the value over 255. This works great because you are only adding a one bit to the database. In the apps that I used this with it work great. Again it is just in design and most databases that I have created have unnamed fields set up to use in case of changes. I would then need to change the program and not the data design..... Just my thoughts on this complex problem....While this is not a bug it really is an annoying error in the design of the database structure.... Last edited by SandMan; 06-08-2006 at 03:00 PM.

06-02-2006, 07:46 AM	#82
Eumel Major Leagues Join Date: Mar 2003 Location: Germany Posts: 499	It probably would have been smarter to stay on the safe side and sacrifice that extra byte per RBI number, IMO. Now, I'm not interested in leagues with inflated hitting, so this won't be an issue for me. However, I can't imagine the impact on database size and sim speed should be that big. For most situational stats, one byte for RBIs is enough -- maybe even for all of them. In that case, the whole thing amounts to one byte per player per season and league -- way less than a megabyte, even for large universes. Sim speed effect should not be that large either -- you need to update one RBI season total per player and game, alongside with countless other stats. Of course the isssue when changing this would probably be something like savegame incompatibility....

06-02-2006, 08:10 AM	#84
battists Hall Of Famer Join Date: Jul 2004 Posts: 18,506	In a vain attempt to turn this thread a little more productive... 1. Please drop the "us" vs "them" thing. That means you pro 255+ RBI folks stop beating on LGO, and vice versa. Please? Take a deep breath and resist the urge to reply to something above that aggravated, and let's start over. 2. If I'm going to bring this up again with Markus, we need to be constructive about it. Heard you loud and clear about RBI. But let's assume, for the sake of argument, that making every statistical field capable of exceeding 255 will cause problems with size and/or performance. If that is the case (and I certainly don't know if it is), then what are the most important fields, in your opinion, that need to be capable of going over 255? I mean, so 190 is close to 255, RBI is a logical candidate. What about doubles? Triples? Let's discuss this in a positive manner so that I can get this presented to Markus.

06-02-2006, 11:15 AM	#90
jff1515155 Minors (Rookie Ball) Join Date: Mar 2003 Posts: 42	I agree only those stats that reach 100 are in jeoprady. Even joe hardy and roy hobbs in my universes never get close to 150 home runs.

06-08-2006, 10:56 AM	#94
jff1515155 Minors (Rookie Ball) Join Date: Mar 2003 Posts: 42	Is there this can be addressed or is it a dead issue???

06-08-2006, 02:09 PM	#95
greenmonster04 Bat Boy Join Date: Jan 2005 Posts: 14	i hope its not a dead issue, since I feel that it is still a very important one... at least, for the minimum, RBIs (and runs?) need to be 'fixed'. I have no programing knowledge, but sometimes it helps to think outside the box... perhaps another 'block/byte/ 256whatever' could be added, and when the RBI byte reaches 255 it stops, and then starts tallying on this new byte. the game code could then have a small modification that would add these bytes together. as I said, I know nothing of programing, but it seems logical enough to me, and sounds like it would not add much, if any, overhead to the game.