Tooltips for roll expansion

[Mr. Pokeylope]

Lots of people have said how they consider semicolon end-of-line (which is understandable from a programmer perspective). However, remember that it's not only used in programming languages; it's also used to seperate two complete, related sentences.

Although I think using a colon after the options would probably be fine.

[UntoldGlory]

However, remember that it's not only used in programming languages; it's also used to seperate two complete, related sentences.

Although I think using a colon after the options would probably be fine.

What? You mean like in the english language. Weirdo.

[syntruth]

Maybe kinda silly this far into the thread, but has anyone considered the rolldice syntax?

http://pwet.fr/man/linux/jeux/rolldice

I've reimplemented this in Ruby for an IRC bot, plus in a java lib for testing, 'cept that I used !# in place of the s# syntax. Basically, you get dice strings like this:

6x 4d6 s3 -- 4d6, keep the best 3, roll 6 times. No clue how that would impact the MT dice-parsing as it stands, but thought I'd toss it out there.

[Naryt]

; is used by many scripting languages as EOL. It wold be a bade idea to use it.

I'll agree whole heartedly with Aria on this one.

My real question though, is a delimiter besides a space actually needed?

[Q 3d6]
[Q:3d6]

Is the second one really superior to the first? It's just as easy to check for [Q as it is for [Q: and still be able to use [Question = whatever].

I am fine either way, this is just something to consider.

[Full Bleed]

My real question though, is a delimiter besides a space actually needed?

If it's not needed, then my vote easily swings to not having one. But I also don't mind the colon.

Someone also mentioned longhand versions (i.e. "quiet" versus "q".) I'd like to see that be valid as well so that macros can be made pretty for the macro-challenged.

[Mrugnak]

My real question though, is a delimiter besides a space actually needed?

If it's not needed, then my vote easily swings to not having one. But I also don't mind the colon.

Something in my programmers brain is sending off alarm signals but I can't tell you what, specifically.

Hm.

No wait, yes, yes I can.

I work daily with a proprietary nasty donkey programming language where whitespace is vitally important. The difference between a single space and a double space, for example, can blow everything to hell.

So there's my first alarm bell. Using whitespace as the separator is going to cause unexpected headaches once you do anything more than "One modifier per macro box".

So if the eventual idea to "Stack" modifiers ever takes off, ESPECIALLY if we go with the optional full-word modifiers (please, do), making whitespace be a serious separator means that

[Quiet Explode 10d10]

or whatever will cause a program error, and instead we'll need to come up with another separator to stack modifiers together.

Well, that doesn't sound so bad, right? What about a comma? Oh, no, wait, English-language (and french, and a lot of other Roman alphabet languages) train you to put a space after each comma. Users are going to make that typo a LOT.

[Quiet, Explode 10d10]

will still throw errors. [Quiet,Explode 10d10] looks ugly, and [Q,E 10d10] looks even worse.

Basically, promoting Whitespace to special meaning doesn't seem bad in really simple cases, but if we plan on making the basic structure here extensible (and it appears we do have that as a longterm plan) it's going to confuse a LOT of people. As it stands, whitespace is optional at "word" boundaries (between variables and operators, for instance). Don't make that have a big exception "Except at the beginning near a modifier, where suddenly whitespace becomes critical."

Someone also mentioned longhand versions (i.e. "quiet" versus "q".) I'd like to see that be valid as well so that macros can be made pretty for the macro-challenged.

I vote heavily for "longhand" versions, and making them all case insensitive. I work in the aforementioned bad language, and also perl relying heavily on regular expressions. I love regexes, but they're NOT exactly easily accessible, even by programmers. Don't end up in a situation where Q and q and Quiet could all be different commands.

[Mr. Pokeylope]

Yes, a delimiter is needed. Okay, maybe that's a lie, but a delimiter certainly makes parsing it easier, both for the program and for human readers.

I agree that case insensitivity is the way to go (for roll options; let's not drag the other case thread into this one ). As for longhand version of the options, that can be done, although that would eliminate the possibility of dropping the delimiter between options (you couldn't say [SDC(3): ] instead of [S,D,C(3): ]). Which is perfectly fine with me, and no one else has thus far expressed a preference for the commaless version.

[jfrazierjr]

I vote heavily for "longhand" versions, and making them all case insensitive. I work in the aforementioned bad language, and also perl relying heavily on regular expressions. I love regexes, but they're NOT exactly easily accessible, even by programmers. Don't end up in a situation where Q and q and Quiet could all be different commands.

Aww... come on. Who would not want [q.d20] to be quite and [Q.d20] to be REALLY quite???

[Orchard]

Well, I'm glad that the expanded and short options are gaining steam--and I definitely want to see Quiet and quiet work the same (and Q/q). This makes life much easier.

This is a really cool set of features. Thanks for this.

[TK]

To allow for expanded rolls, could there be a way to add an optional argument to the roll() function that rather than returning a number returns a string of the individual results? or would that mess things up.
I'm envisioning that 3d6 could end up with an output of 12 or "4+3+5" depending on weather expansion is requested or not.

[Craig]

To allow for expanded rolls, could there be a way to add an optional argument to the roll() function that rather than returning a number returns a string of the individual results? or would that mess things up.
I'm envisioning that 3d6 could end up with an output of 12 or "4+3+5" depending on weather expansion is requested or not.

Doing that would require returning a String and not a number so the parser would then not be able to add things up.

[Naryt]

My real question though, is a delimiter besides a space actually needed?

If it's not needed, then my vote easily swings to not having one. But I also don't mind the colon.

So if the eventual idea to "Stack" modifiers ever takes off, ESPECIALLY if we go with the optional full-word modifiers (please, do), making whitespace be a serious separator means that

[Quiet Explode 10d10]

or whatever will cause a program error, and instead we'll need to come up with another separator to stack modifiers together.

Ah, I missed the long hand version suggestion. [QE 10d10] would work fine and be easy just using a space BUT your long hand example would definitely make spaces be worthless.

[Mr. Pokeylope]

Okay, I'm working on the new implementation. For reference, here's the revised summary:

[ ] gets the new tooltip behavior. Just shows the output of the roll, blue text, light grey background. When you mouse over it, you get a tooltip showing the full roll expansion.

{ } keeps its current behavior. Just the output, no additional decoration.

[x,y: ] is used to implement any additional roll behavior. Options are:

[P: ] - plain output. Does the same thing as { }. (long option: "plain")
[E: ] - expanded output. Same as b40 [ ] rolls. ("expanded")
[H: ] - the output is hidden completely. Replaces HTML comments for hiding calculations. ("hide", "hidden")
[T: ] - tooltip output. Default behavior for [ ]. ("tooltip")
[C(n, sep): ] - execute the roll n times and display each result (for AoE attacks, for example). sep is an optional string used as a separator between each roll; defaults to ", ". n and sep can be expressions/variable names. The variable roll.count gives the index of the current roll (1 through n). ("count")

All options are case insensitive.

Thes are options that I'd like to add eventually but that I'm not worrying about for now:
[S: ] - tooltip for the person making the roll, plain output with no tooltip for everyone else. ("self")
[D: ] - display individual die rolls. [D: 3d8 + 4] displays as "3d8 + 4 = (3 + 2 + 5) + 4 = 14" (long option is... uh, something)

---------

The output for [C(n): ] is still a concern. One idea I've had is to specify it instead as [C(n, sep): ], where sep is a string to use as the seperator. For example:

Code: Select all

[C(3, ", "): d20] -> "5, 12, 14"
[C(3, "--"): d20] -> "5--12--14"

If you used C(n) without specifying a seperator it'd default something reasonable like ", ".

This would make the option parsing a bit more difficult, but it'd still be doable. Would people find this syntax acceptable, or is there a better way to do it?

---------

Edit: revised the summary to reflect the actual implementation

[Naryt]

Okay, I'm working on the new implementation. For reference, here's the revised summary:

[ ] gets the new tooltip behavior. Just shows the output of the roll, blue text, light grey background. When you mouse over it, you get a tooltip showing the full roll expansion.

{ } keeps its current behavior. Just the output, no additional decoration.

[x,y: ] is used to implement any additional roll behavior. Options are:

[P: ] - plain output. Does the same thing as { }. (long option: "plain")
[E: ] - expanded output. Same as b40 [ ] rolls. ("expanded")
[H: ] - the output is hidden completely. Replaces HTML comments for hiding calculations. ("hide", "hidden")

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?

[C(n): ] - execute the roll n times and display each result (for AoE attacks, for example). n can be an expression/variable name. ("count")

All options are case insensitive.

Thes are options that I'd like to add eventually but that I'm not worrying about for now:
[S: ] - tooltip for the person making the roll, plain output with no tooltip for everyone else. ("self")
[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.

[kat2cute]

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.