Tooltips for roll expansion

[Mr. Pokeylope]

Like the looks of the new syntax. Question, about HTML code work in your Separator area for [C(n): ]. I think I'd want my separator to be <br>, and is there any way to get a new line without using HTML? I am also assuming that the 'n' value will pop up if it is an undefined variable for user-input. Looks nice.

Yes, [C(3, "<br>"): d20] would be valid, and [C(num): d20] would prompt for the value of "num".

[Mr. Pokeylope]

How will the hidden roll be hidden? Will it automatically generate HTML comments or will the output be completely suppressed? If completely suppressed, might I suggest adding another option that outputs as [] does now but automatically wraps it in <!-- --> tags?

It's completely suppressed. An option to put the roll in a comment could be added if people want it. (I'm guessing you want it to show up when you save the chat history?)

[D: ] - display individual die rolls. [D: 3d8 + 4] displays as "3d8 + 4 = (3 + 2 + 5) + 4 = 14" (long option is... uh, something)

Mmm that last option is something I miss for some reason. Yes, we really only need the total but it somehow seems more statisfying to know I rolled a 3,7,1 to get that 11.

Yeah, I just want to get the basic framework finished before I go and start hacking at the parser library. Expanded die rolls is going to be a bit more work than most of the other options.

[Naryt]

How will the hidden roll be hidden? Will it automatically generate HTML comments or will the output be completely suppressed? If completely suppressed, might I suggest adding another option that outputs as [] does now but automatically wraps it in <!-- --> tags?

It's completely suppressed. An option to put the roll in a comment could be added if people want it. (I'm guessing you want it to show up when you save the chat history?)

Right, that way if someone wants to dispute the roll after the fact (or even mid game) there's still the possibility of verification. Of course, I can just leave my current <!-- [] -->{} rolls as is and still have that, just not having the <span title="expanded roll data"> in the comments would make it clearer.

[D: ] - display individual die rolls. [D: 3d8 + 4] displays as "3d8 + 4 = (3 + 2 + 5) + 4 = 14" (long option is... uh, something)

Mmm that last option is something I miss for some reason. Yes, we really only need the total but it somehow seems more statisfying to know I rolled a 3,7,1 to get that 11.

Yeah, I just want to get the basic framework finished before I go and start hacking at the parser library. Expanded die rolls is going to be a bit more work than most of the other options.

Oh, I completely understand. I went hunting the parser details early on and, well let's just say I got lost.

[jfrazierjr]

Like the looks of the new syntax. Question, about HTML code work in your Separator area for [C(n): ]. I think I'd want my separator to be <br>, and is there any way to get a new line without using HTML? I am also assuming that the 'n' value will pop up if it is an undefined variable for user-input. Looks nice.

Yes, [C(3, "<br>"): d20] would be valid, and [C(num): d20] would prompt for the value of "num".

So Mr. Pokeylope, will

[C(3, ""): "Attack: " + d20 + "<br>" ]

just work? Also, any chance (in the following release if not this one) of making some type of property to get at the loop counter? I am thinking of something like this:

[C(3, ""): "Attack: " + loopcounter + d20 + "<br>" ] so that it does:

Attack 1: 15
Attack 2: 4
Attack 3: 19

of course, I don't care what the specific variable name is, but perhaps loop.counter would be nice and descriptive.

[Mr. Pokeylope]

So Mr. Pokeylope, will

[C(3, ""): "Attack: " + d20 + "<br>" ]

just work?

Yep.

Also, any chance (in the following release if not this one) of making some type of property to get at the loop counter?

Hmm. That sounds reasonable. How does roll.count sound?

[Lindharin]

So Mr. Pokeylope, will

[C(3, ""): "Attack: " + d20 + "<br>" ]

just work?

Yep.

Do we really need the separator then? If I can just put the separator I want at the end of the expression, what benefit does including a separator in the options area provide?

Also, what tooltip behavior will it have when you use the C option? Are all of the loops put into the tooltip?

Also, any chance (in the following release if not this one) of making some type of property to get at the loop counter?

Hmm. That sounds reasonable. How does roll.count sound?

Works for me...

Another question: What happens if the expression inside a C loop is an assignment? What does [C(3):AttRoll=1d20] actually do?

Is it feasible to have assignments in a C loop automatically apply an incrementing suffix to the variable on the left side of the assignment? For example, something like:

[C(3):AttRoll = 1d20]

would be equivalent to:

[AttRoll1=1d20]
[AttRoll2=1d20]
[AttRoll3=1d20]

Is that possible and desirable? Or maybe instead of it happening automatically, you have to use a flag of some type. Maybe you would need to do [C(3):AttRoll.suffix=1d20] to have it create variables AttRoll1, AttRoll2 and AttRoll3?

Just a random thought...

[Mr. Pokeylope]

Do we really need the separator then? If I can just put the separator I want at the end of the expression, what benefit does including a separator in the options area provide?

Because [c(3): d20 + ", "] would then give "6, 2, 11, ". You don't want the separator included for the last roll.

Also, what tooltip behavior will it have when you use the C option? Are all of the loops put into the tooltip?

Each one has its own tooltop. [c(3): d20] is equivalent to [d20], [d20], [d20].

Another question: What happens if the expression inside a C loop is an assignment? What does [C(3):AttRoll=1d20] actually do?

It does the assignment three times, so AttRoll ends up with whatever the value of the third roll was.

Is it feasible to have assignments in a C loop automatically apply an incrementing suffix to the variable on the left side of the assignment? For example, something like:

[C(3):AttRoll = 1d20]

would be equivalent to:

[AttRoll1=1d20]
[AttRoll2=1d20]
[AttRoll3=1d20]

Is that possible and desirable? Or maybe instead of it happening automatically, you have to use a flag of some type. Maybe you would need to do [C(3):AttRoll.suffix=1d20] to have it create variables AttRoll1, AttRoll2 and AttRoll3?

You can accomplish this with [c(3): eval("AttRoll" + roll.count + " = d20")].

So, it's now working as described here (still no S or D options). Tomorrow (er, well, today after I wake up) I'll test it some more, make sure the code's nice and clean, check for any last-minute suggestions here, then send the patch off to Trevor.

[Mr. Pokeylope]

So Mr. Pokeylope, will

[C(3, ""): "Attack: " + d20 + "<br>" ]

just work?

As a followup to my previous answer, yes, but you'd probably want [C(3, "<br>"): "Attack: " + d20 ] instead. The extra "<br>" that you get doesn't make a difference in this case, but it does keep the tooltips cleaner: you get
"Attack: " + d20 = "Attack: " + 15
instead of
"Attack: " + d20 + "<br>" = "Attack: " + 15 + "<br>"

[knizia.fan]

Hey Trevor! You may want to disable some of the following smilies in the forum management software. Once Mr. Pokeylope's patch goes live, people may get burned when they post code with the new syntax. We know from our experience with HTML tags that people will post without realizing that their text was mangled.

The smilies that could cause problems are

Code: Select all

:(    :D    :x    8)    :o    :-o

The first two are pretty common smiley abbreviations, so we might have to keep them and live with the problems.

Thanks,
--k.fan

Code: Select all

 
[Q:( Strength + Bonus )]
[Q:D + E + F]
[Q:x + y]
[C(8): 3d8]
[Q:o + p]
[Q:-o + p]
 

[Q:( Strength + Bonus )]
[Q:D + E + F]
[Q:x + y]
[C(8): 3d8]
[Q:o + p]
[Q:-o + p]

[jfrazierjr]

So Mr. Pokeylope, will

[C(3, ""): "Attack: " + d20 + "<br>" ]

just work?

Yep.

Also, any chance (in the following release if not this one) of making some type of property to get at the loop counter?

Hmm. That sounds reasonable. How does roll.count sound?

Sure. You could call it fragglebutt for all I care as long as I have access to it, but yea....roll.count sounds just fine and dandy to me.

[BigO]

So Mr. Pokeylope, will

[C(3, ""): "Attack: " + d20 + "<br>" ]

just work?

Yep.

Also, any chance (in the following release if not this one) of making some type of property to get at the loop counter?

Hmm. That sounds reasonable. How does roll.count sound?

I like roll.count.

Will we be able to include IF statements in the [C:] loop? Please?

[Mr. Pokeylope]

Will we be able to include IF statements in the [C:] loop? Please?

Of course. Anything you can do in [ ], you can do in [c(): ].

[Orchard]

Will we be able to include IF statements in the [C:] loop? Please?

Of course. Anything you can do in [ ], you can do in [c(): ].

you rock!

[Mr. Pokeylope]

So, I lied; I haven't actually sent the patch in. I was doing some testing and found I needed some more functionality to make one of my macros do what I wanted. (Namely, I wanted to roll a die and save the value, and have it be verifiable, but not have it appear in the output. So now [t("foo"): ] will output the text "foo" and show the roll as a tooltip.)

Also, is there anyone out there who has an SVN checkout and some free time that I can send the patch to? I wouldn't mind another person or two throwing test cases at my code and just generally making sure it does what people want it to. Since I completely changed the way MapTool parses rolls, I'd like to make sure everything works properly.

[Full Bleed]

Also, is there anyone out there who has an SVN checkout and some free time that I can send the patch to? I wouldn't mind another person or two throwing test cases at my code and just generally making sure it does what people want it to. Since I completely changed the way MapTool parses rolls, I'd like to make sure everything works properly.

I suggest that you contact Giliath directly. Parser stuff seems to go through him.