Tooltips for roll expansion

Thoughts, Help, Feature Requests, Bug Reports, Developing code for...

Moderators: dorpond, trevor, Azhrei

Forum rules
PLEASE don't post images of your entire desktop, attach entire campaign files when only a single file is needed, or generally act in some other anti-social behavior. :)
User avatar
Mr. Pokeylope
Giant
Posts: 118
Joined: Mon Aug 11, 2008 9:24 pm
Contact:

Post by 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. :P

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

User avatar
UntoldGlory
Great Wyrm
Posts: 1649
Joined: Sun Mar 16, 2008 8:12 pm

Post by UntoldGlory »

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

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


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

User avatar
syntruth
Giant
Posts: 241
Joined: Mon Aug 18, 2008 7:15 pm
Location: Michigan, USA

Post by 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.

User avatar
Naryt
Dragon
Posts: 517
Joined: Fri Oct 26, 2007 8:55 am
Location: Near a tree, in a cave, under a rock.

Post by Naryt »

Aria wrote:; 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.
A wandering lost soul

User avatar
Full Bleed
Demigod
Posts: 4558
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Post by Full Bleed »

Naryt wrote: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.

User avatar
Mrugnak
Dragon
Posts: 745
Joined: Mon Jul 21, 2008 7:38 pm

Post by Mrugnak »

Full Bleed wrote:
Naryt wrote: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."

Full Bleed wrote: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.

User avatar
Mr. Pokeylope
Giant
Posts: 118
Joined: Mon Aug 11, 2008 9:24 pm
Contact:

Post by 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 :P ). 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.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Post by jfrazierjr »

Mrugnak wrote:
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??? :roll: :roll:
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
Orchard
Great Wyrm
Posts: 1852
Joined: Fri May 09, 2008 10:45 am
Location: Doylestown PA
Contact:

Post by 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.
0+0=1, for very unstable CPUs.

User avatar
TK
Giant
Posts: 162
Joined: Fri Jun 27, 2008 12:02 am

Post by 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
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Post by Craig »

TK wrote: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.

User avatar
Naryt
Dragon
Posts: 517
Joined: Fri Oct 26, 2007 8:55 am
Location: Near a tree, in a cave, under a rock.

Post by Naryt »

Mrugnak wrote:
Full Bleed wrote:
Naryt wrote: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.
A wandering lost soul

User avatar
Mr. Pokeylope
Giant
Posts: 118
Joined: Mon Aug 11, 2008 9:24 pm
Contact:

Post by 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
Last edited by Mr. Pokeylope on Sun Aug 24, 2008 6:02 am, edited 1 time in total.

User avatar
Naryt
Dragon
Posts: 517
Joined: Fri Oct 26, 2007 8:55 am
Location: Near a tree, in a cave, under a rock.

Post by Naryt »

Mr. Pokeylope wrote: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?

Mr. Pokeylope wrote:[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.
A wandering lost soul

User avatar
kat2cute
Dragon
Posts: 297
Joined: Wed Jan 30, 2008 3:46 pm

Post by 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.
Quote from an underwater D&D fight:
Alright fighter, it's your turn. What do you do?
Fighter: What do you think I do? I FAIL MY F**KING SWIM CHECK

Post Reply

Return to “MapTool”