VDice - Dice Rolling for Proboards v5

[Virgil Sovereign]

Entris: There is some protection against these exploits in VDice. For example, if you edit a post, all rolls will retain their values. If you edit to delete rolls, the remaining N rolls will assume the values of the first N rolls coming in. Hence there's no way to pick 'specific' dice. And currently the dice don't show their values in the Visual mode of the editor, so there's no way to preview their values (this is want Dan wants to add in ).

Making dice truly exploit proof is an extremely complicated matter. My original implementation of VDice used postkeys and a complex lookup system to prevent two additional exploits:

Exploit C:

1) posting N rolls
2) editing to delete all rolls if unfavourable; committing edit
3) editing again to insert N new rolls; committing edit
4) rinse, lather, repeat

Exploit D:

1) posting rolls
2) deleting post if rolls are unfavourable
3) rinse, lather, repeat


I abandoned this 'fully' exploit-proof approach for two reasons, however. Firstly, it could potentially require a litany of AJAX calls to determine correct dice values in cases where rolls were quoted, double-quoted, etc., which is against the Proboards plugin rules. And secondly, because it still wouldn't protect against...

Exploit E:

1) posting rolls
2) if roll is unfavourable, posting the same thing again; no deletes or edits
3) rinse, lather, repeat until a post shows up with a favourable roll
2) deleting all posts besides the one with the favourable roll

And here we hit a brick wall, because short of preventing members from deleting their own posts (which you cannot do per the Proboards CoC), or dropping the requirement that dice values must always stay the same once posted, there is no reasonable way to protect against Exploit E in an unsupervised environment. And if this exploit is possible, it didn't make sense to put in 5 KB of useless additional sophistication to protect against Exploit C and Exploit D.

As I see it, the only way to prevent Exploit E is to include some sort of supervisory component in rolls, where rolls don't actually have outcomes until an admin or privileged member clicks on them (or in some way acknowledges their existence) to 'activate' them. But of course this has its own obvious set of problems. Most notably the delays involved with the human intervention.


Dan:

I took a look at your Spoiler alternative, and it looks quite good. However, when I tried to upload it for some reason it was giving me an older version of Todge's plugin? Perhaps I'm missing something.

No, that would be because I uploaded the wrong file.

Try it now.

Also, since I'm already writing a response here, is there a functionality for creating our own spoiler titles? That was a big reason for our use of Todge's, and I didn't see any mention of it in the thread.

There isn't. In Todge's plugin, the title is just a differently-formatted block of text that precedes the spoiler. Why not simply type in the title yourself in front of the spoiler block?

Another reason I omitted it is because it forces you to use a dialog. Personally, I know I would appreciate the ability to just select text, click the button, and have the spoiler. If we force spoilers to have titles (which is essentially what this is doing), a dialog is required in all situations.

Why do you need the title?

[Virgil Sovereign]

arek, I have added the advanced graphics configuration to version 1.0.3 per the specs in my post from Feb 8, 2013 at 4:34pm.

Dan, I have added the shortened [roll=·] syntax per point 4 of your RFE. Points 1 and 2 are addressed above. I will look at point 3, time permitting.

[Dan]

Virgil Sovereign, with regards to the updated Dice code, thanks for the shortened syntax. Furthermore, I have spoken to some of my members, and they seem to be happy with your proposed modification to the code for previewing (a secondary tag like [rollnow] that would allow for previewing before posting.) I did like the idea you mentioned of some sort of notification for members/admins on the dice that had been previewed, as well. Looking forward to seeing that in action whenever you can find some spare time.

Lastly, I uploaded your spoiler plugin and I think it works great! I appreciate that it looks good in all skins and is easily noticeable as a spoiler. In response to your question about the spoiler titles, for one thing our v4.5 code has spoiler titles with the tag [spoiler title=Title Here]Body Here[/spoiler] , so as with the old dice rolls there would be many broken spoiler titles post-conversion, and I think the members of my forum have grown accustomed to being able to mark spoilers within the title itself what the box contains, in order to protect those who wish to go unspoiled on whatever is inside the box, etc. And I noticed when testing the plugin that if you use the Insert Spoiler button in the editors without highlighting any text, there is a dialogue anyways to enter spoiler body text, so I don't see a problem myself with forcing a dialogue every time to include the spoiler title above the body text. Perhaps it could be an option? Anyways, those are just my two cents.

Thanks again for all your assistance (and putting up with my requests! XD)

[Virgil Sovereign]

Dan: Since quite a few people were using the 'Dice Rolls In Posts v1.1' hack, I've updated to VDice v1.0.4 and added an optional extension called 'VDice Compatibility'. You can find a link to it in the OP.

Updating to VDice v1.0.4 and installing VDice Compatibility should add support for displaying the existing [dice] tags used by that hack. Editing old posts that contain them may still prove... interesting.

I had a limited ability to test it, hence you'll be the first guinea pig.

As for the spoilers, I suppose I can add in a title. The problem is that I don't think Proboards supports the title="" attribute in [spoîler] tags natively, which makes the code messier. Basically, the plugin has to add in all kinds of bits and bobs into the editors, etc. to allow them to handle the conversion from editor html to UBBC to display HTML back to UBBC back to editor HTML to display HTML back to editor HTML, etc., etc.

Was there a popular v4.5 spoiler hack that used the [spoîler title=blah][/spoîler] syntax?

Regarding the ability to preview, I'll add it in sometime in the coming week in the form of the 'reasonable option' I mention in point #2 of this post. Specifically, I'll add the ability to specify a 'previewtag=X' tweak for previewable rolls. The dialog will also include a checkbox to specify 'previewable' if the tweak is included. In the Visual mode of the editor, rolls inserted using the preview tag or flagged as 'previewable' in the dialog will appear with a tooltip-style box in their top right corner that shows what their value will be.

Previewable rolls will have different classes applied so that they can be distinguished from non-previewable rolls if an admin so desires.

[Dan]

Virgil Sovereign, The extension works perfectly! That's a huge relief, thanks very much. I'll let you know if I come across any glitches, but I checked three pages of dice rolls and they all match perfectly with their 4.5 counterpart. That'd indicate success to me, I think. XD I did notice that editing the old rolls to add in the correct format of the syntax does change the rolls, but that's a small price to pay for bringing the old rolls back at all, so thanks again.



As for spoilers, I can't seem to remember which particular code we used, but this seems to be similar, and I believe it uses that syntax.

Anyways, that preview option for the dice sounds excellent. Looking forward to it!

[Todge]

Just to let everyone know, in case they want to use my Spoiler Plugin, the current version IS compatible with Virgil's Dice plugins.

[Entris]

Awesome tyvm Virgil Sovereign and good to know Todge ty 

[arek]

Virgil Sovereign Thanks again for implementing Advanced Graphics. I haven't tested it extensively yet, but clearing the (basic) images settings and using Advanced Graphics to set up the dice1-dice6 resources worked perfectly, once I finally remembered to change 1-6 to 1d6* in the range (chased my tail for an hour before remembering that).

Another use for the advanced graphics tab is to make simple cheats more obvious: Set up the roll types you want to support, then at the end use .+, no condition, and the "blank" or "unknown" resource, or a "roll not supported" image. Cheating by doing something like [roll=5-6] (or [roll=6-6] if that's not specifically checked for) now becomes painfully obvious.

2 things I noticed in testing: First, using the advanced graphics setup seems to disable the ability to just use a default [roll] without specifying a range. Both [roll=range] and [roll range=range] still work, tho. (this is fine, just making a note of it).
Second, using range=1dS (not sure about just dS, didn't check that one) still prints out a sum unless nosum is specified in tweaks, which looks a bit funny if you're only rolling one die.

Finally, another request: On the Advanced Graphics tab, it would be nice to have a "nosum" option there. In addition to being nice for folks that want to have unsupported rolls not work, it would allow for different rolls to be summed up or not as needed (by using advanced gfx config and prefixes).

Thanks for putting up with my requests, I appreciate it.

--Arek

[Virgil Sovereign]

VDice Advanced v1.1.5

BETA

Author: Virgil Sovereign
Plugin: VDice Advanced v1.1.5 Beta - See OP for Plugin
Permissions: Editable
Keys Used: None
Dependencies: VDice or VDice SDE v1.1.4+


Description:

VDice Advanced (VDA) 'adds' three tabs to the VDice configuration UI in a separate plugin: ADVANCED GRAPHICS, ADVANCED TEMPLATES, and RANGE ALIASES. As of v1.1.3, VDA also allows administrators to specify JavaScript-based rendering functions for highly advanced dice customizations. Specifications are provided later in this document.

Range Aliases Tab:

Range aliases are special codes you can define to represent bulky or complicated ranges. For example, rather than requiring the user to type in the range attack:5d20+6, you might associate this range with the alias atk, which allows users to type atk into the "Range" dialog box (or simply type [roll=atk] into the editor). The RANGE ALIASES tab provides a form-type input with two fields: Alias             Equivalent Range          ... ... Alias is a regular expression that defines (matches) an alias. For example, atk will match only the string "atk", while (\d+)sided will match the strings "20sided", "6sided", etc. Equivalent range is the range syntax that VDice will use when an input range matches the associated alias. The equivalent range field may use any tokens captured by alias in the form of tokens $0, $1, $2, ... (the standard RegExp tokens). The plugin scans down the list, checking each entry until it finds one where the input range matches the alias. For the first match found, the plugin uses its equivalent range as the range for the roll. If none of the aliases match, the plugin uses the input range as-is. Aliases are processed before any of the rules in the ADVANCED GRAPHICS tab are applied, hence equivalent ranges can use custom syntax, etc. that will be captured by one or more rules in ADVANCED GRAPHICS. Also note that to avoid problems with the VDice parser, aliases must not include the characters =, <, >, [, ], or ". Consider an example list of aliases as follows: Alias       Equivalent Range       atk attack:5d20+6 (\d+)sided 1d$1 def defense:1,2,3,3,3,2,1         twodice 2d6 (\d+)\s*crystals?          crystal red:$1d25-$1 Given this, in order, the plugin will: check whether the input range is "atk", and if so, treat it as "attack:5d20+6" if no match has been found, check whether the input range is "nsided", where n is a number (for example, "5sided" or "20sided"). If a match is found, treat it as 1dn (a single n-sided die) if no match has been found, check whether the input range is "def", and if so, treat it as the weighted range "defense:1,2,3,3,3,2,1" if no match has been found, check whether the input range is "twodice", and if so, treat is as "2d6" (rolling two standard dice) if no match has been found, check whether the input range is "n crystals" (or "1 crystal"), where n is a number. If a match is found, treat it as the custom roll syntax "crystal red:nd25-n". For example, a range of "6 crystals" will be treated as "crystal red:6d25-6". if no match is found, simply leave the input range as-is

Advanced Graphics Tab:

The ADVANCED GRAPHICS tab gives the user full control over how VDice selects dice graphics and templates based on the range syntax used for a roll. The tab provides a form-type input with five fields as follows: Pattern       Condition       Resource      Die Template      Roll Template      ... ... ... ... ... Pattern is a regular expression that selects (matches) a particular range syntax. Condition is a set of conditions to check on the tokens captured by pattern, if any. Resource, Die Template and Roll Template are respectively a graphic resource, die template, and roll template to use when both the pattern and the condition match. The plugin scans down the list, checking each entry until it finds one where both the pattern and condition match. For the first match found, the plugin uses the associated resource, die template, and roll template. If none of the entries match, the plugin falls through to the standard templates and graphics specified in the base plugin. Fields condition, resource, die template, and roll template may use any tokens captured by pattern in the form of tokens $0, $1, $2, ... (the standard RegExp tokens). Additionally, any of these fields may use the token $R, which evaluates to the roll outcome, and the token $P, which evaluates to a lowercase p if the roll is previewable, or an empty string otherwise. The resource and die template fields may also use the $D token, which evaluates to the face value of the specific die being rendered. The resource field should evaluate to an image URL or to the name of a graphic resource in the base plugin's 'Images' section. If it is left blank, the entry is treated in the same way as a roll whose outcome lacks a graphic resource, and is rendered using a DIV and the standard style parameters. If die template is used, note that the %URL template token for a roll with no resource will evaluate to an empty string. The die template field, if non-empty, must evaluate to the ID of a die template specified in the ADVANCED TEMPLATES tab. If the field is left empty, the plugin chooses the default template based on the usual rules for the roll parameters. The roll template field, if non-empty, must evaluate to the ID of a roll template specified in the ADVANCED TEMPLATES tab. If the field is left empty, the plugin chooses the default template based on the usual rules for the roll parameters. Consider an example list of rules as follows: Pattern             Condition       Resource      Die Template    Roll Template    (red|blue|green):d6   dotted$1 \d*d2 coinflip$R \d*d(\d+) $1 <= 6 my$1sided$D extrapad \d*d(\d+)     $1 <= 20 my20sided$D (\d+)\-(\d+) $1 >= 100 && $2 <= 200 && $R < 150     someurl/bigdice_blue_$R.png (\d+)\-(\d+) $1 >= 100 && $2 <= 200 someurl/bigdice_red_$R.png .+ defaultdice$R Given this, in order, the plugin will: check for a range of the form red:d6 or blue:d6 or green:d6, and if it finds one, will use the roll template dottedred (for red), dottedblue (for blue), or dottedgreen (for green) if no match is yet found, check for a range of the form Nd2 or simply d2, and if it finds either, will use the graphic resource coinflip1 (for a 1 outcome) and coinflip2 (for a 2 outcome) if no match is yet found, check for a range of the form NdB or dB, where B, the first (and only) captured token is less than or equal to 6, and if these conditions are met, use the resources myBsided1, myBsided2, ..., etc. For example, my5sided1, my5sided2, ..., etc. if B (the maximum roll) is 5, or resources my6sided1, my6sided2, ..., etc. if B is 6, etc. Additionally, if the conditions are met, the plugin will use the die template extrapad when rendering the roll. if no match is yet found, check for a range of the form NdB or dB, where B, the first (and only) captured token is less than or equal to 20 (and is implicitly known to be > 6), and if these conditions are met, use the resources my20sided1, my20sided2, ..., etc. if no match is yet found, check for a range of the form A-B, where A and B are between 100 and 200, and the roll outcome is less than 150; if these conditions are met, use the URL resources someurl/bigdice_blue_100.png, someurl/bigdice_blue_101.png, ..., etc. if no match is yet found, check for a range of the form A-B, where A and B are between 100 and 200 (and the roll outcome is implicitly known to be >= 150); if these conditions are met, use the URL resources someurl/bigdice_red_150.png, someurl/bigdice_red_151.png, ..., etc. if no match is yet found, check for anything, and default to using defaultdice1, defaultdice2, ..., etc.

Custom Roll Syntax:

It is worthwhile to note that when VDice parses a range, it automatically eliminates all characters that are not: a digit a comma a lowercase d either preceded by a digit, followed by a digit, or both a lowercase w either preceded by a digit, followed by a digit, or both the + and - characters Hence, 3WALLAWALLAd6?BING+10BANG is interpreted as 3d6+10 by the plugin. Furthermore, as of v1.1.1, the parser automatically ignores all characters in a range up to and including the last colon ( if one or more colons is present. For example, 123 do re me:3d5+2 is interpreted as 3d5+2 by the plugin. Because of this, it becomes a simple matter to invent your own roll syntax that can be captured by the pattern and condition fields of rules in the ADVANCED GRAPHICS list, but will still be recognized as valid ranged by the VDice parser. For instance, the first rule in the example list above captures ranges of the form red:d6 and blue:d6 and green:d6, and places 'red', 'blue' or 'green' into the $1 token. This token can then be used to select a resource, to select templates, or can be used as a token in the templates themselves. When the parser examines the range, all cases reduce to simply d6, which is one of the many supported range syntaxes (see the list in the OP). You can make range syntax as complex as you desire, passing any amount of additional information to be used as tokens in the various fields and templates. Do note, however, that as protection against XSS attacks and possible malformed markup, ranges are automatically stripped of the characters '<', '>' and '"', hence any custom syntax may not rely on these characters.

Advanced Templates Tab:

The ADVANCED TEMPLATES tab gives the user full control over the HTML templates VDice uses when rendering dice for display in threads. Die templates are the templates used to render individual dice. Roll templates are the templates used to 'wrap' groups of dice and add additional information such as offsets, totals, etc. Each template has an ID, which can be referenced in the die template (for die templates) and roll template (for roll templates) fields of rules in the ADVANCED GRAPHICS tab. The templates themselves are simply HTML markup that the plugin compiles together to represent a roll. Die templates may include tokens that evaluate to useful values: Token Evaluates to... %VAL numeric face value of the die (e.g. 6) %RNG die range in the format low-high (e.g. 1-6) %URL URL of the image associated with the roll outcome, or an empty string if no URL is associated with the roll outcome %POS 1-based position of the die in the roll, increasing from left to right %NUM total number of dice in the roll %PRE evaluates to a lowercase p if the roll is previewable, and to an empty string otherwise Additionally, when a die template is invoked by matching a rule in ADVANCED GRAPHICS, the template will have access to captured tokens $0, $1, $2, ... in the form of %TOK0 for $0, %TOK1 for $1, %TOK2 for $2, etc. Four default die templates are specified in the plugin: box - used when no graphic resource is specified for a die, and the 'showrange' tweak is not present boxrg - used when no graphic resource is specified for a die, and the 'showrange' tweak is present img - used when a graphic resource is specified for a die and the resource can be resolved to a URL txt - used when a dice range is invalid and the placeholder resource cannot be resolved to a URL, most likely because the resource name is invalid These templates may be deleted since 'copies' of them exist in the base plugin JavaScript. However, since these IDs are used for all cases where die template IDs are not explicitly specified, it generally makes sense to edit the existing templates rather than making new ones if you plan on making 'global' changes to dice. Similarly, roll templates may include tokens that evaluate to useful values: Token Evaluates to... %DICE markup for all dice (as generated by the die templates) %DIE1, %DIE2, ... markup for individual dice (as generated by the die templates); one token per die %TOT total sum of all dice values plus offset (if any) %OFF absolute value of the roll offset, or 0 if no offset is specified %PM '-' (minus) character if the roll offset is specified and is strictly negative, and '+' in all other cases %NUM total number of dice in the roll %PRE evaluates to a lowercase p if the roll is previewable, and to an empty string otherwise And like dice templates, roll templates have access to the %TOK0, %TOK1, %TOK2, ... captured tokens when the template is invoked by a match in ADVANCED GRAPHICS. Four default roll templates are specified in the plugin: sum - used for all rolls with a non-zero offset specified, if the 'nosum' tweak IS NOT present sumzo - used for multi-dice rolls with a zero offset specified or no offset specified, if the 'nosum' tweak IS NOT present nosum - used for all multi-dice rolls if the 'nosum' tweak IS present bare - used for all single-die rolls with a zero offset specified or no offset specified Like the default die templates, these may be safely deleted since copies exist in the base plugin JavaScript. As an example of using tokens in templates, consider that rather than specifying 'dotted$1' as a roll template for the first rule in the example list, which requires three separate roll templates, we might instead specify a single roll template, dotted, and define dotted to be <div class="vdice-sum" style="padding:5px; border:2px solid %TOK1;"> <div class="vdice-md">%DICE</div> : <div class="vdice-total">%TOT</div> points </div> This will cause rolls using the red:d6 syntax to be surrounded by a red dotted border, rolls using the blue:d6 syntax to be surrounded by a blue dotted border, etc.

Rendering Functions:

Rendering functions are a type of JavaScript closure that allow administrators to precisely specify how dice are rendered. Rendering functions are used in place of roll templates. When an ADVANCED GRAPHICS rule specifies a roll template, VDice first checks to see if a rendering function is associated with the roll template ID. If no rendering function is defined, the plugin uses the HTML roll template instead. Rendering functions must be defined in the BUILD section of the VDice Advanced plugin rather than in the plugin configuration UI. They should be inserted at the end of the VDA JavaScript component. This component is accessible under the COMPONENTS tab of the BUILD interface. The BUILD interface can be accessed by selecting VDA from the 'Build Plugins' menu, or by clicking on the 'Build Plugin' button at the top of the plugin configuration UI. Scrolling down to the end of the JavaScript component, you will see a comment block beginning with "Custom rendering functions may be placed below." Rendering functions should be inserted immediately after this comment block. To define a rendering function for the roll template with ID my_roll_template_id, insert the code $V.DiceAdv.renderers['my_roll_template_id'] = function( dice, roll, is_previewable, tokens ) {   ...   your code here   ... }; replacing "your code here" with your own code, and using whatever roll template ID you prefer in place of my_roll_template_id. The arguments passed to the function are as follows: dice is an n-element object array of dice, where n is the number of dice in the roll. Each element of dice includes fields: url - the graphic URL for the die, as a string (identical to the %URL token for die templates) value - the face value of the die, as an integer (identical to the %VAL token for die templates) range - the range of the die, as a string (identical to the %RNG token for die templates) roll - the roll outcome, as an integer (identical to the %TOT token for roll templates) is_previewable - boolean true if the roll is previewable, and false otherwise tokens - RegExp tokens captured from the pattern match in ADVANCED GRAPHICS, as an array of strings (identical to tokens %TOK0, %TOK1, ... for both die and roll templates) The rendering function must return the HTML representing the rendered state of the roll. If the function returns anything besides a well-formed HTML string, unexpected behaviour, errors, etc. may result. Be careful that the function is syntactically correct (certain errors may prevent VDA from functioning entirely), and if the function uses RegExp tokens (in tokens) captured from the pattern, be especially careful that these tokens are not inserted into the HTML in a way that could expose your board to a code injection attack by a malicious user. Note that if the roll is previewable, the PREVIEWABLE ROLL WRAPPER specified in the base VDice plugin settings will still be wrapped around any returned HTML. Also note that any elements in the HTML assigned classes of vdice-image or vdice-box will automatically have their width and height overridden by the width=X tweak if this tweak is present in the base VDice plugin settings. As an example, consider the following rendering function, invoked by an ADVANCED GRAPHICS rule with pattern virgil:.*, resource dice$D, and roll template ID virgil1: $V.DiceAdv.renderers['virgil1'] = function( dice, roll, is_previewable, tokens ) { var num_dice = dice.length, HTML = '<table cellspacing="3"><tbody>' + '<tr><td colspan="3" style="text-align:center;">Roll: <b>' + tokens[0] + '</b></td></tr>'; for( var i = 0; i < num_dice; i += 3 ) { HTML += '<tr>'; for( var j = 0; j < 3; j++ ) if( i + j < num_dice ) HTML += '<td><img width="80" src="' + dice[i+j].url + '"></td>'; else HTML += '<td> </td>'; HTML += '</tr>'; } HTML += '</tbody></table>'; return HTML; }; When run in VDice Standard Die Edition (which includes the dice1, dice2, ... image resources), the rendering function renders the dice in rows of three, including a table heading (see Fig. 1). Fig 1. Rendering function output.

---

Update to v1.1.0

- Updated for compatibility with VDice 1.1.0.

Update to v1.1.1

- Added range aliases.

Update to v1.1.2

- Added %DIE_ tokens to roll templates.

Update to v1.1.3

- Added support for rendering functions.

Update to v1.1.4

- Fixed bug where 1dN+O syntax was using the incorrect roll template for non-zero offset.

Update to v1.1.5

- Fixed bug where Advanced Graphics rules without a graphic resource would not default to the default graphic resources.

[Virgil Sovereign]

arek: I bit the bullet and put in a full-fledged templates interface (see above). To avoid bloating the basic plugin, I've 'spun off' the advanced settings into an extension plugin. The other major advantage to this is that you can update VDice without wiping out all your advanced settings, and likewise update VDice Advanced without wiping out your VDice settings.

As part of the move to 1.0.5, I've improved the logic used when selecting roll templates in the base plugin. Hence single dice don't appear with = total after them, and a few other improvements. In short, you may not need to modify HTML templates to get the degree of control you're looking for.

As for the plugin not supporting plain [roll] when dynamic ranges are allowed, that is by design. My reasoning was that if dynamic ranges are allowed, there should be some explicit acknowledgment by the user that he/she knows the range he/she is rolling. It was a tough call, since I admit it would be nice to simply be able to type [roll] into the Quick Reply even with dynamic ranges enabled.

I'll maybe add it in in 1.0.6.

Since you'll probably be the first to try out VDice Advanced, let me know if you run into any problems.

[arek]

It works, mostly. The only problem I've had so far is this: If I set the condition on my templates to $1 < X with a (\d)*dN match template (tested with X=10 and X=6 and N values of 4, 6, 8, 10, 12, 20, and 100), and $1 > 10 VDice acts as if the condition is true (i.e. it doesn't check the condition) and spits out a roll of 10 dice. If the condition is at least tested even when numdice > 10 I could work around this by setting X (whoops, NOT N) to something less than 10, but it's not even tested. Can this be fixed?

Also, would it be possible to add a "passthru" checkbox in the advanced graphics area that tells the plugin to continue checking patterns even if a "passthru" pattern is matched?  In the case of multiple matches, only the last non-blank matching resource and/or templates should be applied (but if a passthru provides a roll template and a non-passthru provides a resource, for example, both should apply).  This would greatly simplify applying templates to rolls.

Thanks in advance, and great work. :-)

--Arek

P.S. Sorry it took me so long to get back to you...this is the first chance I've had to really test out VDice since you split the advanced part into a separate plugin.

[arek]

Another problem: For some reason, VDice (advanced) doesn't work with Internet Explorer. It only shows the roll used without results (e.g. 5d6). Can you fix this as well?

--Arek

[Virgil Sovereign]

Feb 21, 2013 1:44:16 GMT -8 arek said:

Another problem: For some reason, VDice (advanced) doesn't work with Internet Explorer. It only shows the roll used without results (e.g. 5d6). Can you fix this as well?

--Arek

I can look into it this evening.

[arek]

Thanks for looking into it.

--Arek

[arek]

Feb 21, 2013 0:23:04 GMT -8 arek said:

It works, mostly. The only problem I've had so far is this: If I set the condition on my templates to $1 < X with a (\d)*dN match template (tested with X=10 and X=6 and N values of 4, 6, 8, 10, 12, 20, and 100), and $1 > 10 VDice acts as if the condition is true (i.e. it doesn't check the condition) and spits out a roll of 10 dice. If the condition is at least tested even when numdice > 10 I could work around this by setting X (whoops, NOT N) to something less than 10, but it's not even tested. Can this be fixed?

GAH.  I'm stupid.  The regex needed to get this to work is "([1-9]\d*)dN" not "(\d)*dN" and a separate pattern is needed for just "dN" if I want to support that.  That's what I get for coding at 4am.

--Arek

P.S.  I'd still like the ability to tell VDice to test other later patterns after a match via a checkbox.