RPTools.net

Hey, I'm currently working on a study project and came across RPTools.

The idea is to combine the physical elements of tabletop RPGs with digital ones
I thought to roll a real die, get the rolled value programmatically (undecided yet how I best do that) and use it as value for ingame dice-rolls.
For that I need to be able to communicate with the program from the outside via a script or something similar
Best case is that I click a button which gets the last rolled value and accepts it as a rolled die ingame

Do you know if something like that is possible with RPTools??

PS: I'm not sure if this is the wrong part of the forum for such kind of questions, forgive me if I posted this in the wrong place

So, roll a real die and then enter it via an Wiki: input() and calculate the results with a formula?

I don't really want to manually enter the value i rolled
Let's say I get the value from a source outside of RPTools (as a method parameter if you will) and want to use it directly in RPTools

aliasmask wrote:So, roll a real die and then enter it via an Wiki: input() and calculate the results with a formula?

No, I believe he means an external source would enter dice values directly into MapTool. (yes, this is possible with some code changes. @pirklbauer31, you make the dice and I'll help you with the code! )

Fyi, it has been done, see https://youtu.be/I1f30R42gfY?t=55 or https://www.youtube.com/watch?v=8po3SY3bBOU

JamzTheMan wrote:

aliasmask wrote:So, roll a real die and then enter it via an Wiki: input() and calculate the results with a formula?

No, I believe he means an external source would enter dice values directly into MapTool. (yes, this is possible with some code changes. @pirklbauer31, you make the dice and I'll help you with the code! )

Fyi, it has been done, see https://youtu.be/I1f30R42gfY?t=55 or https://www.youtube.com/watch?v=8po3SY3bBOU

Yeah something like that is exactly what I want to do

Since I have to do this for a study project, can you give me some hints/reference documentation how I can get the values into RPTools?

How do you want to record the physical dice rolls? Once you get those rolls in to a digital format, you can cut/paste all the data for MapTool to calculate your results.

JamzTheMan wrote:you make the dice and I'll help you with the code!

Interesting videos... but it doesn't look like the developers could find a market for them.

Not to mention how oversized they are.

Honestly, that appears to be the hard way to do this. A video camera framed on a dice tray with bumpers and image recognition software would probably be the "easiest" and most practical method (seeing as how any video camera and most dice could be used with such a setup).

I was thinking the same thing...and then thought of the d4...its not *that* simple. However still worth looking if someone actually tried this.

How I get the values of the dice rolls is something I'm currently not sure of

The more important question for me currently is, how/if I can get these values to use in RPTools

wolph42 wrote:I was thinking the same thing...and then thought of the d4...its not *that* simple. However still worth looking if someone actually tried this.

If I go for the image recognition approach the d4 is indeed a problem
I could decide to use a d8 instead and divide the values by 2 or something like that

pirklbauer31 wrote:

wolph42 wrote:I was thinking the same thing...and then thought of the d4...its not *that* simple. However still worth looking if someone actually tried this.

If I go for the image recognition approach the d4 is indeed a problem
I could decide to use a d8 instead and divide the values by 2 or something like that

Since you're comparing physical vs digital, wouldn't that skew the results? For a sophisticated enough algorithm, the d4 wouldn't be a problem. The digits would be hard to read from above but the patterns would be the same.

I recall seeing something similar to what you're proposing. I think the guy was a teacher and he had a bunch of his students record die results. Also, dice are proven to have a bias based on manufacturing process and design. Funny thing is many of the d20 dice have a 20 bias, although very small.

aliasmask wrote:

pirklbauer31 wrote:

wolph42 wrote:I was thinking the same thing...and then thought of the d4...its not *that* simple. However still worth looking if someone actually tried this.

If I go for the image recognition approach the d4 is indeed a problem
I could decide to use a d8 instead and divide the values by 2 or something like that

Since you're comparing physical vs digital, wouldn't that skew the results? For a sophisticated enough algorithm, the d4 wouldn't be a problem. The digits would be hard to read from above but the patterns would be the same.

I recall seeing something similar to what you're proposing. I think the guy was a teacher and he had a bunch of his students record die results. Also, dice are proven to have a bias based on manufacturing process and design. Funny thing is many of the d20 dice have a 20 bias, although very small.

The idea is to keep the physical/tabletop aspect of Dungeons & Dragons but combined with a digital approach like in RPTools. Not really to use real dice because i think them to be "more random" than dice-roll generators or something

Here's an interesting thread on the random number generator MapTool uses from a few experts. RNGs are pretty random and it's our cognitive bias that give you the impression it's not. We tend to remember the good/bad more than the mundane.

http://forums.rptools.net/viewtopic.php?f=20&t=17423

There's another thread which actually records every roll made for a d20 and gives a report. Across a big enough sample you can see all the values average out. As for physical dice, as mentioned before, they can and often do have a bias where across a large sample you can see which numbers are favored for a particular die.

aliasmask wrote:Here's an interesting thread on the random number generator MapTool uses from a few experts. RNGs are pretty random and it's our cognitive bias that give you the impression it's not. We tend to remember the good/bad more than the mundane.

http://forums.rptools.net/viewtopic.php?f=20&t=17423

There's another thread which actually records every roll made for a d20 and gives a report. Across a big enough sample you can see all the values average out. As for physical dice, as mentioned before, they can and often do have a bias where across a large sample you can see which numbers are favored for a particular die.

Not trying to be rude or anything, but are you actually reading what I'm writing in my posts?

I have to use real dice, since it is a part of my project for this semester.
That's why I asked if it was possible to combine using real dice with RPTools

pirklbauer31 wrote:That's why I asked if it was possible to combine using real dice with RPTools

Your question is really pretty non-specific leading people to jump to conclusions and conjecture. But, in short: No. No VTT does what you're asking. If they could they'd be waving their arms and crowing about it. More specifically, no VTT will just accept random/mysterious/non-specific outside input for its dice rolls. That would be a pretty basic security design flaw. Which is not to say that it couldn't... it would just need input from a "trusted" and supported source.

So before you can expect a Maptool developer to take this too seriously, you need to have a proven input method/source. That is, take the video recognition method I mentioned above: If you can develop the software/hardware combo image recognition then you might have something a MT developer could look into supporting. Jamz has shown an inkling of interest (given his "you build the dice" comment)... so you could talk to him about what platform and data you'd need to produce that MT could, potentially, use.

Oh, and the d4 issue isn't an issue. If you look down a d4 it's pretty easy to see the output. Not to mention that, to be practical, the image recognition would have to work with a moderate degree of angle (determined by the scale of the rolling "tray"). And that's if you wanted to use a more top-down method. You could also consider going with a camera beneath the rolling tray looking up through a glass bottom. That would probably be the path of least resistance.

You're really in the wrong place to pursue this as deeply as necessary, though. Once you have a developer that thinks they could provide the input path you'd need... you really need to be going down the image-recognition rabbit hole.