New roll options - request for feedback

[Mr. Pokeylope]

I've been working on a few more frequently-requested roll options. Here's what I've got:

[s: ] (self) - only displays result to yourself
[p("playername"): ] (player) - displays result to the selected player
[g: ] (gm) - only displays result to GMs

You can combine these options, and you can specify p more than once. For example:

[s,g: d20] would display the result to yourself and GMs.
[p("Bob"),p("Joe"): d20] would display the result to the two named players.

(One thing to note: if you send a message consisting only of rolls a given player can't see, that player will still see an empty message from you. Unfortunately, I think this would be somewhat non-trivial to change.)

That's what I have implemented so far. I'm thinking a few more options might be useful; they would behave the same as the above, but instead of filtering the entire roll, the result would be visible to everyone but the tooltip would only be visible to the specified players. I imagine these options would be called something like: st/selftooltip, pt/playertooltip, gmt/gmtooltip.

And a few more random thoughts:
A function that returned a list of all the players connected to the server could be useful, if you wanted to use input() to select a player to send a roll to.
In addition to being able to use the p option more than once to specify multiple players, maybe it should also accept a comma-separated list to accomplish the same thing?

Questions, comments, concerns, requests for additional functionality?

As a side note, in the interest of full disclosure: due to the way things are currently implemented, the filtering is done client-side; that is, even if a player can't see a given roll, it's still sent over the wire to them. A sufficiently motivated player could use a customized client or a packet sniffer to see results they normally wouldn't be able to. Don't use this if you're really paranoid or need an unusually high level of security; but then, if you need that much security, you shouldn't be using MapTool anyway.

[knizia.fan]

Cool, Mr. P!

We have enough options (especially if the macro options that Craig and I are working on get added) that I think we should stop using single-letter names for most things.

After all, we don't have single letter names for all the chat commands like /gm, /rollsecret (aka /rsec), /emote (aka /me), and so on. No one has been demanding that they get shortened to one letter, and they get used more often than these roll options would.

I suggest that the single-letter option names be used mainly for the formatting options (t, r, h, e). Especially if more options get added later, it would be good to keep the single-letter names in reserve.

Should your new option names be the same as the chat command names?

/self
/gm
/w or /whisper

[self: 1d20]
[gm: 1d20]
[w("Bob"): 1d20] or [whisper("Bob"): 1d20]

There are /rollgm, /rollme, etc., but I think the "roll" part is already implied here, so the normal command names /gm, /self, etc. are a better choice.

Would it be useful for w to take a list of names? The comma might not be a good choice for separator, since some names might include a comma. how about a semicolon?
[w("Bob ; Joe"): 1d20]

[Craig]

Given the size of macros and hopefully some new ways to use them coming in a future build I think another good option is [none: ] If there is a lot of set up happening it would be useful to do that in a [none: ] which runs the macros but throws away all the output (appends "" if you like). I know this would be visually similar to [h: ] but result in a lot less hidden text being copied to the output.

[Mr. Pokeylope]

We have enough options (especially if the macro options that Craig and I are working on get added) that I think we should stop using single-letter names for most things.

After all, we don't have single letter names for all the chat commands like /gm, /rollsecret (aka /rsec), /emote (aka /me), and so on. No one has been demanding that they get shortened to one letter, and they get used more often than these roll options would.

I suggest that the single-letter option names be used mainly for the formatting options (t, r, h, e). Especially if more options get added later, it would be good to keep the single-letter names in reserve.

Hmm, perhaps. I'm fine with it either way, so I can do it whichever way people prefer.

Would it be useful for w to take a list of names? The comma might not be a good choice for separator, since some names might include a comma. how about a semicolon?
[w("Bob ; Joe"): 1d20]

Sure. I said comma since that's the default separator for your list functions, but semicolon would work too.

Given the size of macros and hopefully some new ways to use them coming in a future build I think another good option is [none: ] If there is a lot of set up happening it would be useful to do that in a [none: ] which runs the macros but throws away all the output (appends "" if you like). I know this would be visually similar to [h: ] but result in a lot less hidden text being copied to the output.

Unless I'm misunderstanding what you're requesting, this is how [h: ] currently works. It doesn't produce any output (it doesn't wrap the output in a comment, it discards it completely).

[ElCucuy]

I've been working on a few more frequently-requested roll options.

Good stuff, Pokelope.

That's what I have implemented so far. I'm thinking a few more options might be useful; they would behave the same as the above, but instead of filtering the entire roll, the result would be visible to everyone but the tooltip would only be visible to the specified players. I imagine these options would be called something like: st/selftooltip, pt/playertooltip, gmt/gmtooltip.

This is great stuff! I'll be making extensive use of this. I love to have the die rolls displayed, but for many enemies I do not want the players to be able to explode their results to figure out what kind of stats they have. I mean technically right now they can examine my tooltips and figure out "Hey, the bad guy has a +3 sword". So it'd be just lovely to be able to hide stuff like that.

Plus, just to toss in my own (non-programmer) point-of-view on the single-letter naming vs. the multi-letter naming, I would *much* prefer the full word name, but not for the same reasons as above. As it is now, whenever I want to use any of those / commands, I've got to look it up to figure out what that one letter is. But when the command is a full word, I find it's far easier to commit to memory.

El Cucuy

[Mr. Pokeylope]

For what it's worth, all the existing single-letter options have a corresponding long name, so you can use whichever you prefer.

[palmer]

This is great stuff! I'll be making extensive use of this. I love to have the die rolls displayed, but for many enemies I do not want the players to be able to explode their results to figure out what kind of stats they have. I mean technically right now they can examine my tooltips and figure out "Hey, the bad guy has a +3 sword". So it'd be just lovely to be able to hide stuff like that.

The immediate solution to that is

[h:AtkRoll = 1d20 + Bonus + OtherBonus]
[h:DmgRoll = 1d8+StrBonus+OtherBonus]

The guard swings his sword!
Attack: [AtkRoll]
Damage: [DmgRoll]

This will only explode to <<AtkRoll>>
No actual breakdown.

[ElCucuy]

Yes, thanks, but I want to see it. Right now my desire to see the breakdown of those results is greater than my desire to keep the data from the players, so I just go ahead and display it.

If it's something really critical, then I go ahead and hide it. But having that optional ability to hide it from only certain eyes would be pretty sweet. Then people like me wouldn't have to worry about making the choice between all or nothing.

El Cucuy

[lmarkus001]

Did these get submitted for build? They don't appear to be live in b46/7 and I was anxiously awaiting them!

[lmarkus001]

Well these are not in B48 either so I guess they have faded from sight...

[lmarkus001]

Well I was hopeful that the Library macros could provide a work around so these roll options would not be needed, but it is not so.

If I use "/self" in a macro that is called, it merely sends the text "/self" to the chat (it appears the very first characters must be "/self" or it is ignored).

So I will keep bumping this thread as these would definitely be useful!

[RPTroll]

Yet another contributor that went poof!

[Orchard]

Yet another contributor that went poof!

Yeah, that seems to happen. Not really a big deal, all things considered. But hopefully someone will notice and pick up the slack.

[jfrazierjr]

Yea... I really, really, really, really want the option to put my macro code into a span tag, ie, the whole darn thing... all the calculations expanded...

[Mr. Pokeylope]

/me casts Thread Necromancy

So, uh... hi again!

I guess I kinda disappeared there for a while, and so the parser changed rather drastically. (Nice job k.fan, by the way; it definitely needed to be cleaned up, and it looks a lot nicer now.) So, after getting things figured out, I redid and finished the implementation for these options. I'm not completely happy with some things, but that's primarily due to how the chat system is currently implemented (I am very much looking forward to 1.4 and potentially rewriting the whole chat framework from scratch, but that is perhaps a discussion for another day).

So, what I have currently functional are the three options s(elf), g(m), and w(hisper). w takes either a string or a JSON array of names. I'm not sure if it's worth implementing the tooltip options I had mentioned, although at least the one to display the tooltip only for yourself would be useful. I'm not sure when Trevor's planning on releasing b57, but hopefully I'll have a patch ready soon so this can make it in by then.

And, as always, let me know if you have any feedback. Thanks!