Tables issue

[digimatt]

In the tables panel, the "add table by size" seems to have developed a flaw with the "step" feature. For example, if you create a d100 table with step=2, you'd expect a d100 table with steps of 2 (1-2, 3-4, 5-6 ... 99-100). Now you get a d200 table with steps of 2 (1-2, 3-4, 5-6 ... 199-200).

[Moon Wizard]

This is expected behavior; and the way it has worked since the feature was added (first in extension; and then in CoreRPG).

As the tooltip suggests, you are making a table with #x rows with a step value of #. So, a 100 rows of step x2 is actually a 1-200 range table.

Regards,
JPG

[digimatt]

I was positive it used to be more useful, but I'll take your word for it. Doesn't it seem a bit odd though? Like there's far more cases for a (standard table size) with steps than a (weird table size) with steps.

[damned]

Im guessing the size is not the size of the dice but the size of the table - eg the number if entries.
Tables can support combinations of dice eg 3d6 or 1d8+1d12 so that probably makes sense.
In your case its size 50 (50 entries) with step 2

[ddavison]

Damned is correct. You are asked for the table size, not the die type for the table. You can get exactly what you want by just feeding it the expected inputs. The table doesn't actually have to map to a die size. You could have a table with 14 rows and a step size of 1 and it would just randomly generate a 1 through 14 result.

[digimatt]

But the "add table by size" only lets you choose standard die numbers. 2, 4, 6, 8, 10, 20, %.

(I'm not saying I don't know how to make the tables otherwise, it's just this feature implies it's going to build a standard die size table, but adding steps breaks it. You can't make a d100 table with step 2 using this feature, as you can't choose d50 in the first step)

[ddavison]

Good point. For your purposes, it would be nice to have a 50x option as well. I will run that by John to see what he thinks. If we did 50x, I could see a benefit of a 25x as well.

[digimatt]

That was just a specific example - it's going to affect all combinations, and would be resolved by making the steps just do steps and not be a multiplier. Admittedly there may be cases when the current method is preferred, but honeslty I can't think of one. I asked in Discord what other people were doing but apparently I'm the only one using this feature :)

[ddavison]

What do you mean by making the steps just do steps? Can you give me a few examples of what you would want to accomplish?

[digimatt]

Sure!

Example 1
Requirement: d6 table, with 1-2, 3-4, and 5-6.
Expectation: choose d6, and step 2.
Actual result: d12 table with 1-2 through 9-12
Workaround: build manually (there's no d3 to choose from)

Example 2:
Requirement: d20 table with 1-4, 5-8, 9-12, 13-16, 17-20
Expectation: choose d20, step 4
Actual result: d80 table with 1-4 through 76-80
Workaround: create a d6 table with step 4, then remove the last row (works, but unintuitive)

[LordEntrails]

Remember, the only reason to have specific dice used for table rolls is tradition and when converting table top resources (which is not an insignificant reason) because with a computer doing the rolls their is no reason a table needs a regular polygon to determine random results. i.e. a table of 1-3 is the same a 1-6 were each entry has 2 valid numbers.

[digimatt]

For sure. Doing conversions I like to stick to what the author specified. And keep in mind that this specific tool doesn't let you choose non-standard dice so in this case there's not a lot of choice to go with a non-standard polygon. My comments are very specifically for the "Add table by size" feature - the rest of the table methods work well, and the newer text import feature is fantastic.