Page 1 of 1

integration

Posted: Wed Jan 17, 2007 10:01 am
by dLANbandit
Are there plans to integrate the output of this tool into the MapTool chat?

Posted: Wed Jan 17, 2007 10:07 am
by trevor
Plans yes, but the timeframe is indeterminate.

There are issues related to integration, the foremost being verification of rolls. If you just send chat, how do you prove that you didn't just type it in.

In the short term the dicetool rolling engine will be integrated into MT so that you can have the same power but be verifiable.

Posted: Wed Jan 17, 2007 10:13 am
by dLANbandit
Ultimately I guess even if you created an interface that the tools shared, I could still write another program to send those same communications. SO it could be hacked if there are separate tools.

Perhaps the only way to do this, is to put the other tools into MapTool, and have the ability to turn off the other tools if you don't want them. But then you also will want to maintain the tools separate for those few that don't want MapTools.

I guess I have known there are hopes, but I don't know of any plans. it seems to me every time someone brings up the issue it is never discussed to completion (A tracker for the next version).

Can I help in any way? What is missing that needs doing? Are there people in the background somewhere talking that have the answer that we don't get to see?

Posted: Wed Jan 17, 2007 10:27 am
by Big_Mac
trevor wrote:Plans yes, but the timeframe is indeterminate.

There are issues related to integration, the foremost being verification of rolls. If you just send chat, how do you prove that you didn't just type it in.

In the short term the dicetool rolling engine will be integrated into MT so that you can have the same power but be verifiable.
I had a thought on the verifiable issue. That when ever a roll is executed it comes up in a different "chat like" window that is only for dice rolls. But it could also still come up in the chat window.

Posted: Wed Jan 17, 2007 10:45 am
by dLANbandit
Yes big, that should be doable , but it won't fix trevor's problem of verifiability.

In the end underneath the 2 programs will need a communication layer. That will allow anyone with another program to communicate to the 2 tools not just the tools to each other. So if you have MapTool put DiceTool messages in a special place, or special designation with an icon in the chat next to the results. You could still cause the same behavior in MapTool, with another program that isn't DiceTools. Thus anyone who has programming skills could create a completely transparent die rolling cheat.

Other programs solve this by forcing the DM's software to be the only roller. Thus a player sends a request to the dm to roll the die, behind the scenes. To the player it looks like he rolled. But if you were to do that with RPtools, it would mean your dice tool talked to maptools, talked to the DM's dicetool, that rolled, and talked to map tool Just to see one die result.

Posted: Wed Jan 17, 2007 11:06 am
by Phergus
dLANbandit wrote:Other programs solve this by forcing the DM's software to be the only roller. Thus a player sends a request to the dm to roll the die, behind the scenes. To the player it looks like he rolled.
Any reason that wouldn't work just fine here?
dLANbandit wrote:But if you were to do that with RPtools, it would mean your dice tool talked to maptools, talked to the DM's dicetool, that rolled, and talked to map tool Just to see one die result.
An insignificant amount of overhead in the scheme of things. Nobody is rolling dice even once per second let alone enough for it to actually impact the system or connection.

Posted: Wed Jan 17, 2007 11:12 am
by trevor
We have thought about making the server contain the definitive die roller. That would definitely make it verifiable. But the server may or may not be running dicetool, so we can't depend on that.

Which means die rolling has to be stand alone first, with dt being gravy on top.

I've got a plan for roll verifiability which should work fine (assuming your players don't hack and run a custom version of MT that modifies the roller). Basically the messages that are being passed around are not just text, I can assign any additional information to them. One of which will be the original roll type (nDm+c for example) along with the result. The rolls will then have a hover over or something that shows what the original roll was. So inline you'll see the result, but that result can be checked by the GM.

Another problem of making the GM dicetool the one and only instance is that you then have to have the GMs dt set up for all characters, and they have to maintain that instead of the players updating their own.

It may be possible to use a similar mechanism described above to validate DT rolls, but some research will need to be done.

Posted: Wed Jan 17, 2007 11:24 am
by dLANbandit
trevor could you expound on the original roll type?


The only way I can think of this working, is MT having the die roller built in, but DT, being like you said gravy. Thus DT would keep all the modifiers to the rolls and pass them to the GM MT die roller to generate the result and put it in the chat box and pass it as a message back to all other tools.

That method would let triggers be added down the road in all the tools based on results.

Posted: Wed Jan 17, 2007 11:31 am
by trevor
dLANbandit wrote: trevor could you expound on the original roll type?
such as 2d6+2
dLANbandit wrote:The only way I can think of this working, is MT having the die roller built in, but DT, being like you said gravy.
Which is the plan. Giliath has a new rolling engine that he is integrating directly into MT, so MT will have all the power, just not the user setup-ability of DT.

Posted: Wed Jan 17, 2007 11:34 am
by dLANbandit
Ah so I should be poking giliath not trevor. :twisted: thank you very much :)


ooohhhh giliath.... you there? :?:

Posted: Wed Jan 17, 2007 11:34 am
by Dalna
If you look at openRPG and the way it is handled with a symbol before and after it, it verifies its self because you cant simulate the symbols without causing the dice roller to work and out its output. Ofcoase a simple checksum of the program could comfirm the server and clients are using the same version of the program. Verifying the code has not been changed. I am hoping we don't need to have to write anti-cheating code.

Posted: Wed Jan 17, 2007 11:57 am
by trevor
Dalna wrote:If you look at openRPG and the way it is handled with a symbol before and after it, it verifies its self because you cant simulate the symbols without causing the dice roller to work and out its output.
That works too :)
Dalna wrote:Ofcoase a simple checksum of the program could comfirm the server and clients are using the same version of the program. Verifying the code has not been changed. I am hoping we don't need to have to write anti-cheating code.
Unfortunately you can't trust anything coming form the client (specifically their checksum). The cheater could easily trap what the expected checksum is, and when the server requests their checksum they just return the expected instead of the actual. The only real solution to cheaters is to play with people you know are not cheaters. Putting in verifiability just removes the temptation for some people to fudge their rolls :)

Posted: Wed Jan 17, 2007 12:02 pm
by dLANbandit
Yes I don't think anyone would cheat, in my group, but everyone likes the idea of reasonable security. And the only way to do that is to trust the DM client to distribute role results. Unfortunately this means we are forced to put the dice engine into MapTools, since it has become the communication tool.

by only way I mean the only way I can think of.

Posted: Wed Jan 17, 2007 12:12 pm
by Dalna
Well we are lucky for the time being that this program gets changed so often, atleast the development version is...so the checksum could be changing weekly...making it a pain to keep up with the new checksum...hehe