PDA

View Full Version : d100 does not work correctly.



Griogre
May 3rd, 2007, 21:26
FG2 v2.0.8. When you roll the percent dice (1d100) the number is wrong when you drag and drop the roll if the d10 number is 10.

IE If the d100 roll is 40 + 10 with the two percentile dice - the drag and drop value will be 50. The only time the drag and drop number is correct is when the d10 is 10 is when the ten tens dice is 00 (ie 00 + 10 = 10).

Cantstanzya
May 3rd, 2007, 22:04
I believe it has always been like this. It isn't a bug, it is just another way to interpret the die. It has been debated to death on this message board in the past. It is still a random number between 1 and 100

kalmarjan
May 3rd, 2007, 23:02
Actually, if the dice read 00+10, should that not be 100?

I use the old school dice myself... LOL

Sandeman

Sir Bayard
May 3rd, 2007, 23:57
Yeah, it is supposed to add up that way in actually (40, and the 10, being 50). to get a 1 would be 00 and 1, being 1, and it should be 90 and 10 to equal 100. That's how it was programmed into FG, even in the FG I days. Either way, you still get anywhere from 1 -100, just takes awhile to get used to the format FG uses (but once you get used to it, it makes sense. Just totally different from how we read the dice in real life)

Tokuriku
May 4th, 2007, 00:22
Yeah...
Cuz for me too 00 + 10 meant 100.
It actually reads 0 (00) + 0 = 100.

The sequence would be:
0 (00) + 0 = 100 (because 0 does not exist)
0 (00) + 1 = 1
0 (00) + 2 = 2
0 (00) + 3 = 3
..
..
1 (10) + 0 = 10
1 (10) + 1 = 11
1 (10) + 2 = 12
...
...
8 (10) + 0 = 80
8 (80) + 1 = 81
..
..
9 (90) + 8 = 98
9 (90) + 9 = 99
0 (00) + 0 = 100
The first and last line are the same.

FG simply uses the 00 as what it is.... 0
So the 0 from the digits die has to always be carried as a 10.
Much easier to program has Sir Bayard said.

blondejohn
May 4th, 2007, 01:22
Actually, that is not the case: no d10 die roll results in zero. Normally, any d10 roll will generate in 1-10. The developers keep to this format and attempted to minimized the code necessary for d%. They could have written code they would yield the results we've usually expect but that would have entailed an enormous amout of effort and troubleshooting to just generate a number between 1 and 100.
Humans are used to the (0) on a d10 to be read as 10, except in the case of d% when (0) is actually zero.
In FG, multiple die that are rolled are added together. The devs don't change the value of a d10 or exclude the two dice rolls for d% from these rules. It is simpler to take one die roll, multiple it by 10, and add the results together. For any sum over 100, subtract that amount from the result. Very minimal code necessary to generate a number between 1-100. However, this does violate our expecations of the results:
[all numbers in () are the actual # read on the die]
Thus (10) + (1) is 11 but (10) + (0) is actually 20. (90) + (0) is 100. Furthermore, (00) + <any number> would total to 100+ but since you can't get that result, subtract 100. So (00) + (1) = [101 - 100] = 1. But, (00) + (0) is 10. [110 - 100].

The High Druid
May 4th, 2007, 01:56
Would just like to add my preference to this as well for 00=100, or at least an option for it to work that way so we have the choice. It's the way we work with real dice and it's a bit of a pain to have to switch modes for working with FG.

blondejohn
May 4th, 2007, 02:58
I suppose the easiest way would be to have an option to not display the sum of d%. Just show the two die rolls and list the modifiers, if any. Most of the time, this is what my DM wants anyway to ensure all modifiers have been included in the total.

Sir Bayard
May 4th, 2007, 03:47
I guess to me, it doesn't really matter. In an electronic format, as long as I know when I roll the dice the number is random between 1-100, and it's doing the math correctgly (based upon how we described FG doing it, not based upon our expectations), I can adjust to the way FG does it. a 90 and a 0 works easily for me to equal 100, since I know that a 0 on a d10 roll is equal to a 10 in NORMAL circumstances. Just like a 00 and a 0 works fine for me to be a roll of 10, since I know that the 0 on a d10 reprsents a 10 in reality. All I know is I'm shooting for a 90 and a 0 instead of triple 000's now. I don't find it all that difficult to make the switch, even after 10+ years of reading it the "normal" way.

Now, if they were to change it, I'd be happy as well, but hey, whatever makes the dev's life easier. It's not so huge an issue to me.

Griogre
May 4th, 2007, 04:03
I would agree with you except for one thing: Smiteworks whole philosophy is to mimic the tabletop experience. I don’t know anyone in a face to face game that reads the d100 the way FG is generating it now. Frankly, when I DM I just roll 2d10 for percents and read them left to right because it is faster than selecting a d100.

Cantstanzya
May 4th, 2007, 22:21
I would agree with you except for one thing: Smiteworks whole philosophy is to mimic the tabletop experience. I don’t know anyone in a face to face game that reads the d100 the way FG is generating it now.That doesn't mean your way isn't the only way people read the d100 (although I calculate it the same way you do). Maybe that is the way they calculate it in Europe, I don't know. But I don't really think it is a big deal, don't think just drag and it will show you the result between 1 and 100. Them changing the way the d100 is calculated ranks right up there (or down there) with adding sound to FG. It would be nice to have, but there is so much more they could be working on.

Griogre
May 4th, 2007, 22:40
Cantstanzya, I agree with you on sound and that this "bug" is very minor. However, we are talking editing some existing code rather than creating a new feature. All that is wrong here is the two dice are being added in an expession something like
dieValue = (tenTen * 10) + d10 instead of something like:

dieValue = (tenTen * 10) + (d10 % 10);
if(dieValue == 0) dieValue = 100;

Cantstanzya
May 5th, 2007, 05:26
Cantstanzya, I agree with you on sound and that this "bug" is very minor. However, we are talking editing some existing code rather than creating a new feature. All that is wrong here is the two dice are being added in an expession something like
dieValue = (tenTen * 10) + d10 instead of something like:

dieValue = (tenTen * 10) + (d10 % 10);
if(dieValue == 0) dieValue = 100;But, you have yet to accept that this may be the way it was designed to work based on how things are done over in Europe. As much as we Americans want to think that the world revolves around us, it possibly was programmed the way it was for a reason. I'm just guessing that it was programmed this way on purpose and not by accident. I could be wrong though. Besides, if it were not supposed to be like this I think they would have changed it several years ago when this was brought up. Am I way off base here, could someone from Europe tell us if this is how it is done over there?

Griogre
May 5th, 2007, 08:36
I don't feel I have to accept anything. ;) I just write it up and let Smiteworks decide. If they don't fix it then they must be happy. If the do fix it they aren't. *shrug* I'm not going to try to second or triple guess them, that's too much like work. :D

The High Druid
May 5th, 2007, 13:11
Am I way off base here, could someone from Europe tell us if this is how it is done over there?
Certainly not in any gaming group I've ever encountered in the UK, and I was at the and I was at the Student Nationals for 4 years in a row.

kalmarjan
May 5th, 2007, 13:18
In the above example, about the 0+00=100:

Call me an old timer, but this is how I am used to reading the dice in RL games. Consider that before the invention of the "10's" die, this is how you would roll d100:

First roll indicates the 10's, second roll indicates the ones. Or, if you prefer, you could roll two different colored dice and designate one color as the 10's.

It was in the 1990's that Chessex invented the 10's die, to "make things easier". Looks like it just causes confusion. LOL

So, SW is actually incorrect in the way they represent the dice, in my old skool gamer frame of mind.

So, to sum it up, it is like this:

You do NOT add the two dice together. That was never the intention. The 10's die represents what the 10's number is. For example, you may roll 90 and 1, so you get 91. If you roll 10 + 0, you get 10. If you roll 90+0, you get 90. so if you roll 00+0, then you get 100.

I think the problem is that the 1's die goes from 1 to 10. I think that this is where the confusion runs here.

From a programming point of view, I can see why SW does this, but something is not right.....

If you look at the logic, we would actually have an 11 sided die for the 10's die. This is because I see that 7+00 = 7, but 40+10 = 50. Also, the convention as to how the die are arranged changes as well.

REAL percentile dice have a 10's die ranging from 00 - 90, and the 1's die ranging from 0 - 9. This eliminates the confusion as to how the dice are read.

Can anyone remember a time BEFORE the d10, when you had to roll a special d20 marked from 1-10 twice to get your percentile roll? LOL

Cheers,

Sandeman

The High Druid
May 5th, 2007, 13:34
For example, you may roll 90 and 1, so you get 91. If you roll 10 + 0, you get 10. If you roll 90+0, you get 90. so if you roll 00+0, then you get 100.

The d100 in FG doesn't work like this though. You don't get 10+0, you get 10+10. Your "90+0" would actually give the 100 result as the dice roller reads it as 90+10 and your final one there would be a 20 (10+10).

The problem stems from *most* real 10-sided dice showing 0-9 not 1-10 so the manufacturers only have to put one figure on each face of the dice. It's perfectly logical to read 20+10 as 30, it's just not how we work when we're playing with real dice.

Edit: Hmmm I think your edit changed the entire tone of your post there.

The High Druid
May 5th, 2007, 13:39
In the above example, about the 0+00=100:

Call me an old timer, but this is how I am used to reading the dice in RL games. Consider that before the invention of the "10's" die, this is how you would roll d100:

First roll indicates the 10's, second roll indicates the ones. Or, if you prefer, you could roll two different colored dice and designate one color as the 10's.

It was in the 1990's that Chessex invented the 10's die, to "make things easier". Looks like it just causes confusion. LOL

So, SW is actually correct in the way they represent the dice, in my old skool gamer frame of mind.

So, to sum it up, it is like this:

You do NOT add the two dice together. That was never the intention. The 10's die represents what the 10's number is. For example, you may roll 90 and 1, so you get 91. If you roll 10 + 0, you get 10. If you roll 90+0, you get 90. so if you roll 00+0, then you get 100.

I think that this is where the confusion runs here.

From a programming point of view, SW has this bang on.

Cheers,

Sandeman



That's what I was replying to.

Sir Bayard
May 5th, 2007, 18:52
Now, I fully agree on how I read the dice, and long before I have had a "tens" die I always had 1 color was the tens, and the other color was the 1's (as mentioned above) with two 0's equaling a 100, etc tec. Exactly as was described by many many people on the boards here.

My question is, does it really matter how SW does it? How big an issue is it?

Logically, from a SW standpoint, it makes sense how they did it. Logically, for a gamer's standpoint, it's TOTALLY out of whack with what we're used to. Reality wise = Hit the sums button and there's no need to really care. Maybe we, as gamers, just totally screwed the pooch on how we read dice in a massive way and SW has it the correct way... even if the minority way ;). Either way, I don't see it as such a big deal, except for the fact that it keeps getting mentioned...