VDice - Dice Rolling for Proboards v5

[havelock]

Update:  Copying over all the same input into VDice Advanced 1.1.1 (from 1.1.0) isn't showing images for me anymore.  (I did not add any range aliases to my board as we don't need them yet.) 

Same board! I've left a Dice Rolls Thread in one of the guest viewable forums if that helps while you have a look.  Thanks, Virgil!  lighthouse.boards.net/

[waysoftheearth]

Virgil Sovereign great plugin, thanks!

There are a couple of simple things I'd like to do with it. Some of these I may be able to do already, but I don't know how.


1. I'd like to be able to reduce the size of the default result and result box so that it better fits inline with the text of the post. I can see the templates, and that divs have CSS classes. I just can't see where I can edit the definition of those classes.

2. Instead of inserting a graphic for the outcome, It would be great to be able to insert ALT text instead.
E.g., the output would be some text like "1-20=17" neatly wrapped in a configurable font tag so you can say render this in blue, make it bigger, make it italic, or whatever.

Maybe it's already possible to do these things?

Thanks again

[arek]

waysoftheearth, #1 may be possible with just VDice: On the tweaks tab, there's a textbox. In that textbox, enter "width=50", save the changes, and see what that looks like. If that doesn't work (or isn't the size you want), try reducing or increasing the number. If it doesn't work at all, then you'll have to grab VDice Advanced.

As for #2, if you know how to do that in HTML, it can be done with VDice Advanced. Have a look at Advanced Templates there, in particular at the Die Templates.

Hope this helps.

--Arek

[Virgil Sovereign]

havelock: you'll need to give me the address of the dice rolls thread and approve my pending user account on your board (or create one specifically my use). I need to be able to access the "Reply" form to debug.

---

waysoftheearth: Arek is correct on both counts. You can use VDice Advanced to exactly specify how dice will appear in posts. Changing the default templates is a simple matter of going into ADVANCED TEMPLATES and changing the HTML in the default templates there (four of each kind) to reflect the HTML you want. Or if you want all rolls displayed the same way regardless of syntax, you can specify a single .+ (capture everything) pattern in ADVANCED GRAPHICS and tell it to use a single roll template and die template of your making.

Making it so that users can specify a huge range of colours, font sizes, etc. as part of the [roll] tag is also possible, but trickier. For example, if you wanted users to be able to specify both a font size and a font colour as part of the roll, you could include an ADVANCED GRAPHICS rule such as

Pattern: (\d{1,2})\s*,\s*(\w{3,18}).+)
Roll Template: custom1

And define a roll template custom1:

<font style="font-size: %TOK1px; color:%TOK2;">%TOK3 = %TOT</font>

Then a roll tag of the form (e.g.) [roll=16,red:1-20] would be displayed as the text "1-20 = 14" in 16px red font to represent the roll, etc.

---

The Rocan: Your site has extremely odd behaviour in the sense that something (and for the life of me I can't determine what) is resetting all options associated with your forms when the page is loaded. It's wiping out the code I use to convert dice from the representations the editor understands to the representation required for display.

Fortunately, I've found a solution. Try the updated v1.1.2 (now downloadable) and let me know if the problem persists. You'll have to post new dice. The old ones that appear as [roll] tags when displayed will always appear that way.

Also, I notice that you have the old "Dice Rolls in Posts" code included as part of a header or footer in one of your plugins. You should remove this code. It doesn't do any harm, but it will cause errors and it isn't doing any good either. VDice Compatibility will handle these rolls.

[havelock]

Virgil Sovereign  Can do!  Please do me a favor and re-apply as a new member again.  I wiped pending memberships back when 1.1.0 VDice Advanced was working fine with 1.1.1 VDice Standard thinking I'd got it all fixed.   URL is:  lighthouse.boards.net

As soon as I see you there I will send you the links!

[Virgil Sovereign]

havelock: You appear to have the "old" VDice v1.1.1. I updated to a "new" v1.1.1 without changing the version number, which I shouldn't have done. If you download VDice or VDice SDE v1.1.2, it should fix the problem. No need to update VDice Advanced.

[havelock]

Excellent - thanks so much for looking! I'm on it!

ETA:  That fixed it up perfectly.  Thanks again for a great dice roll system.

[The Rocan]

Thank you so much, it works great now! You are a god/dess! Not sure what my site code was doing but I thank you for taking the time to mess with it.

I do have one request though, every time you edit the post the dice has a chance of changing in outcome.
And if I don't like the outcome I could go into my post, edit the post, delete the roll, and "re-roll" till I get the outcome I desire.
Is there anyway, as with the old Dice Rolls in Posts v1.1 , to where the dice roll is permanent. That the roll will never be able to be changed even if deleted and re-put in?

"This dice roll will appear the exact same to every member. No member can modify their dice roll, it will always be the same as long as the number of sides do not change and the ubbc code is in the message."

I ask because I would like to add a battle system to my site, using your dice, but members able to edit their rolls after they are done means only staff will be able to roll. Doable but sort of a pain.

I was just wondering if such a tweak is possible?

[arek]

The Rocan, if you read through the thread, you'll find that that was already asked. Unfortunately, making it work would apparently be a ton of trouble and may make it so that VDice requires a post key, if it could even be done while keeping the plugin within the rules.

Your best bet if you require die rolls to be unedited is probably to forbid the editing of posts with dice in them (by forum rules), meaning that if a post is edited any rolls within it may be considered invalid. This, unfortunately, does not stop all forms of cheating, but it does stop the one you're talking about. The only way to stop all forms of cheating would be to forbid members from deleting their own posts, which is against the Proboards CoC.

Edit:  Another option I just thought of would be to require die rolls to be handled by a moderator.  This is cumbersome, but would solve the problem of cheating if your moderators are trustworthy.

I'm sorry if this isn't the answer you were looking for.

--Arek

[Virgil Sovereign]

The Rocan: Dice values shouldn't change when you edit a post. If you post dice, edit the post, delete one or more dice and then replace them, the edited post should have the same values as the original one.

If this isn't happening, it's a bug, and I'll need to look into it.

The exception to this is if you change the roll range. For example, suppose you insert a die with a range of "1-20" and it comes up with an outcome of 10. Then suppose you edit the post and either change the range on the die or delete it and insert a new one (it makes no difference), and you make the new range "1-6". When you save the edit, the die will have a new value (between 1 and 6).

The dice "value" hasn't actually changed. The value is a huge pseudo-random number called a hashcode, and VDice simply converts that big number into a something inside the range 1-10 (or 1-6, etc.) depending on what the die range is. I could have made it so that a die stores its specific face value from its original range, but you can see where this might be a problem as well. If I changed the range from "1-10" above to "1-6", and the die still held the outcome 10, it wouldn't make much sense. Likewise, users could game your system by first putting in a very limited high range (such as "6-6"), rolling a guaranteed 6, then editing the post to change the range to "1-6" to make it look as though the outcome was obtained fairly.

When speaking about dice generally, there are many possible exploits. It is possible for me to detect range tampering in dice. For example, I can detect whether the dice in an edited post have the same ranges as in the original post, and have the plugin append a custom message to the edited post (presumably something along the lines of "Dice ranges have been modified in this post.") if the ranges do not match from before to after.

Arek is correct is that there is one particular exploit that is a nightmare to prevent, which is when a user posts multiple times and then deletes all but the most favourable post. It can be done, but it involves using 'keys' to track users' posts and deletions in multiple threads and is generally a mess to implement. Not only that, but admins must not prevent users from deleting posts (per the Proboards rules), hence the best I could do is append some sort of notice such as "'someuser's last posted dice are displayed here (link). 6 post(s) containing dice by 'someuser' were deleted between that post and this one" to posts. The plugin could be configured to dynamically attach such a message to every post containing dice that had deleted predecessors, regardless of the order in which posts were created or deleted. But to do so would require both a user key and a post key for the plugin. Keys are highly limited. I don't want the basic versions of VDice to rely on keys, and if I decided to go this route it would have to be in another extension plugin.

In short: It's possible, but you have to really want it. And I'll need at least a few votes.

As for detecting range tampering, if you're interested in that, it's simple enough to add.

[arek]

Virgil Sovereign, the edit-exploit I was talking about is the one where someone edits a post containing rolls, deletes the rolls, saves the post, edits it again, re-creates the rolls, and saves the post again. Is this exploit now protected against?

--Arek

Edit:  by "deletes the rolls" I mean "deletes all rolls".

[Virgil Sovereign]

arek: Ah. The old double-edit exploit.

No, that particular exploit isn't prevented. It would be simple enough to protect against it, though.

The next update will include it.

Another option that comes to mind wrt exploit prevention is to prevent users from posting posts containing dice "twice in a row" in any given thread. By "twice in a row" I mean the thread would keep a record of the user that last posted dice in a thread. The user could delete the post or not, and could post as many posts without dice as (s)he wished, but as long as (s)he was the last dice poster, the plugin would prevent him/her from posting new dice. When another member showed up to post dice, this would restore the first poster's ability to post dice.

The nice thing about this particular option is that it would only involve a single thread key. Its faults are that two or more members could still collude to game the dice (although I'm not sure how conspiratorial your members are), and the obvious problem that any activity involving dice would have to include two or more members alternating turns. The only way to legitimately 'add' dice twice in a row would be to edit a post and append new dice to the end of it. This isn't an exploit since those values can't be chosen.

[arek]

The "twice in a row" protection sounds nice, provided that it's both per-thread and optional.

--Arek

[elshlog]

I can't seem to get eh dice roller to work for private messages? Is anyone else having this problem or is it just my work computer?

[The Rocan]

Thank you for explaining it some to me, but again a lot of that goes over my head. lol

Although I have noticed, if you edit the post, the dice do not change but say you have three rolls in one post you are editing. If you delete any of those three, the other two will re-roll and change their results. So for instance I had 3 range 1-6 rolls in a post, (3,5,4), I go in and delete the roll that gave me (5), and the remaining two dice change to (5,2).

I think it would be easiest to just have staff do the rolls for individuals to avoid any cheating, and since I was going to have staff involved in such threads it isn't too much of a pain. Plus it then forces more staff/user interaction.