Tooltips for roll expansion

[Craig]

You would only need to change macros that use { } for things other than rolls if using the braces puts these: «  » around the result.

You strike the {token.name} for {damage}.
You strike the ogre for 9 damage.

Why does it matter if you get "token.name" and "damage" when you mouseover the ogre and 9 damage in the chat box? You get the best of both worlds, as long as { } does not put « » around the result.

Now if it showed up as:

You strike the {token.name} for {damage}.
You strike the « ogre » for « 9 damage ».

I can see where it would be an issue. I say leave the formatting to the macro itself, since roll verification would be done in the tooltip.

No this is not true. Creating a tool tip requires that the output be put into a <span>.
So this means no more using {} with the new table image, token image, token halo color functions, or the health bar example, or any conditional formating that it is used for.
Oh and if you forget to modify your macro you can easily confuse the HTML parser enough that you dont get output again.

[Brigand]

Health bars don't belong in the chat window in the first place, imo. It just creates massive amounts of clutter. The chat window should be for dice rolls and roleplaying. With tooltips, we can even minimize the impact of rolling dice while roleplaying.

The health bars were an awesome example of just how far you could push the chat window with macros, but they're obsolete now. Custom states with health bars are much cleaner, more visually appealing and even if you don't use the map to draw things, you can put your tokens on a blank map to see the party members and their health.

[Craig]

Health bars don't belong in the chat window in the first place, imo. It just creates massive amounts of clutter. The chat window should be for dice rolls and roleplaying. With tooltips, we can even minimize the impact of rolling dice while roleplaying.

The health bars were an awesome example of just how far you could push the chat window with macros, but they're obsolete now. Custom states with health bars are much cleaner, more visually appealing and even if you don't use the map to draw things, you can put your tokens on a blank map to see the party members and their health.

It was just an example, even if health bars are not valid (I never thought they were I just posted them to show the kind of things that could be done) it doesn't mean that the techniques it uses are no longer valid.

[Naryt]

Health bars don't belong in the chat window in the first place, imo. It just creates massive amounts of clutter. The chat window should be for dice rolls and roleplaying. With tooltips, we can even minimize the impact of rolling dice while roleplaying.

The health bars were an awesome example of just how far you could push the chat window with macros, but they're obsolete now. Custom states with health bars are much cleaner, more visually appealing and even if you don't use the map to draw things, you can put your tokens on a blank map to see the party members and their health.

It was just an example, even if health bars are not valid (I never thought they were I just posted them to show the kind of things that could be done) it doesn't mean that the techniques it uses are no longer valid.

Would just wrapping <span title="roll details"></span> hurt such a display in any way (as I suggested back a couple of posts.

[Brigand]

I can't think of any reason to use anything like that in the first place. Especially in the chat window. The chat is for roleplaying and communication. Spam and clutter makes it harder to roleplay. Handouts, graphics, and the like need to remain out of the chat window.

[Naryt]

I can't think of any reason to use anything like that in the first place. Especially in the chat window. The chat is for roleplaying and communication. Spam and clutter makes it harder to roleplay. Handouts, graphics, and the like need to remain out of the chat window.

That's a personal preference. I find that whispering images to players is very useful.

[Craig]

I can't think of any reason to use anything like that in the first place. Especially in the chat window. The chat is for roleplaying and communication. Spam and clutter makes it harder to roleplay. Handouts, graphics, and the like need to remain out of the chat window.

We use smaller images of certain states after damage macros, so its clear to everyone when a player dies or is bloodied (or drunk ). Its not for everyone but it doesn't mean that those that do use it should not be able to.
Since we use a voice chat program we make other uses of the chat window than just dice rolls.
Some of my 4e macros use conditional formatting for things like critical damage.

Just because some don't use them doesn't mean they are not valid.

[Brigand]

I don't see how the tooltips would break conditional formatting.

[the_meek]

I was on the "make {} do that" side of this discussion until one of Craig's last posts. If what he's saying is accurate, it makes things like:

Code: Select all

<!-- [Roll = d20][Crit = floor(Roll / 20)] -->
Attack: <span style="color:rgb({255 * Crit},0,0)">{Roll + Stuff}</span>
<td>Damage: <span style="color:rgb({255 * Crit},0,0)">{max(1d8 * abs(Crit - 1), 8 * Crit)}</span>

...which makes crits show up in red font no longer function. Conditional formatting is also huge for D&D 4e AoE macros like:

Code: Select all

<table>
<tr><td colspan=2 nowrap><b>Dragon Breath (STR+2 vs Reflex)</b> <i>Minor action, Close blast 3<i></td>
<!-- [Bonus = HalfLevel + STRMod +  2][Total = NumberOfAttacks] -->
<tr><td>Attacks: <span title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(1 <= Total, 12, 0)}">{Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(2 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(3 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(4 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(5 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(6 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(7 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(8 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(9 <= Total, 12, 0)}">, {Roll + Bonus}</span></td>
<td>Damage: {1d6+CONMod}, <font color=red>{6 + CONMod}</font> <i>cold</i></td>
</table>

...which rolls 9 attacks but hides the ones you don't need by setting their font size to 0.

If Craig is right on this, we'd be losing a whole lot of functionality by changing {}.

[Naryt]

I was on the "make {} do that" side of this discussion until one of Craig's last posts. If what he's saying is accurate, it makes things like:

Code: Select all

<!-- [Roll = d20][Crit = floor(Roll / 20)] -->
Attack: <span style="color:rgb({255 * Crit},0,0)">{Roll + Stuff}</span>
<td>Damage: <span style="color:rgb({255 * Crit},0,0)">{max(1d8 * abs(Crit - 1), 8 * Crit)}</span>

...no longer function. Conditional formatting is also huge for D&D 4e AoE macros like:

Code: Select all

<table>
<tr><td colspan=2 nowrap><b>Dragon Breath (STR+2 vs Reflex)</b> <i>Minor action, Close blast 3<i></td>
<!-- [Bonus = HalfLevel + STRMod +  2][Total = NumberOfAttacks] -->
<tr><td>Attacks: <span title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(1 <= Total, 12, 0)}">{Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(2 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(3 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(4 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(5 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(6 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(7 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(8 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(9 <= Total, 12, 0)}">, {Roll + Bonus}</span></td>
<td>Damage: {1d6+CONMod}, <font color=red>{6 + CONMod}</font> <i>cold</i></td>
</table>

...which rolls 9 attacks but hides the ones you don't need by setting their font size to 0.

If Craig is right on this, we'd be losing a whole lot of functionality by changing {}.

NOT IF IT JUST ADDS <SPAN TITLE ="SOMETHING"> </SPAN> AROUND THE ENTIRE BLOCK.

Why is everyone trying to make this so hard?

[the_meek]

If I understand how it operates, it would end up outputting:

Code: Select all

<span style="color:rgb(<span title="255 * Crit">255</span>,0,0)">{Roll + Stuff}</span>

which I don't think the parser would be a big fan of.

EDIT: fixed code

[Craig]

I was on the "make {} do that" side of this discussion until one of Craig's last posts. If what he's saying is accurate, it makes things like:

Code: Select all

<!-- [Roll = d20][Crit = floor(Roll / 20)] -->
Attack: <span style="color:rgb({255 * Crit},0,0)">{Roll + Stuff}</span>
<td>Damage: <span style="color:rgb({255 * Crit},0,0)">{max(1d8 * abs(Crit - 1), 8 * Crit)}</span>

...no longer function. Conditional formatting is also huge for D&D 4e AoE macros like:

Code: Select all

<table>
<tr><td colspan=2 nowrap><b>Dragon Breath (STR+2 vs Reflex)</b> <i>Minor action, Close blast 3<i></td>
<!-- [Bonus = HalfLevel + STRMod +  2][Total = NumberOfAttacks] -->
<tr><td>Attacks: <span title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(1 <= Total, 12, 0)}">{Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(2 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(3 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(4 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(5 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(6 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(7 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(8 <= Total, 12, 0)}">, {Roll + Bonus}</span><span
 title="[Roll = d20]" style="color:rgb({255 * floor(Roll/20)},0,0); font-size:{if(9 <= Total, 12, 0)}">, {Roll + Bonus}</span></td>
<td>Damage: {1d6+CONMod}, <font color=red>{6 + CONMod}</font> <i>cold</i></td>
</table>

...which rolls 9 attacks but hides the ones you don't need by setting their font size to 0.

If Craig is right on this, we'd be losing a whole lot of functionality by changing {}.

NOT IF IT JUST ADDS <SPAN TITLE ="SOMETHING"> </SPAN> AROUND THE ENTIRE BLOCK.

Why is everyone trying to make this so hard?

Not trying to make it hard, just trying to make sure everything is covered.

Adding <span title="blah"></span> around the entire block is exactly what causes the break
Take the above example in the style="" and the font-size="' will have embeded <span title="">. This will break what you are trying to display every time. And if you are unlucky enough its enough to make the Java HTML parser/renderer combination chuck a wobbly and refuse to display anything from that point onwards (yeah I wrote buggy enough macros to make this happen before).

Like it or not the {} syntax is being used to do a lot more than just display text and I think a lot wont want to lose that functionality.

[Brigand]

The problem here is that I don't know HOW the tooltips are being added... so I have no idea about how it's working.

[Naryt]

Adding <span></span> around the entire block is exactly what causes the break
Take the above example in the style="" and the font-size="' will have embeded <span>. This will break what you are trying to display every time. And if you are unlucky enough its enough to make the Java HTML parser/renderer combination chuck a wobbly and refuse to display anything from that point onwards (yeah I wrote buggy enough macros to make this happen before).

Like it or not the {} syntax is being used to do a lot more than just display text and I think a lot wont want to lose that functionality.

Gah, color me blind. I didn't even notice that title attributes were being used in the macro. Consider my previous "protests" redacted.

[Craig]

The problem here is that I don't know HOW the tooltips are being added... so I have no idea about how it's working.

Usually a html render like web browsers display anything in the title property of a tag in a tool tip
e.g.
<span title="this is my tool tip>Something here</span>
The java html component does not do this, but it is some what easy to make
it do so (for one type of tag at least) with a little bit of code. Which is what has been changed.

So to display tooltips in a roll you need to enclose it in a span.
Something like this
<span title="1d6 = 3 = 3">3</span>
With more colors and things though

So any place you wanted used {} you wouldnt just get the text anymore you would get the whole thing enclosed in a <span> like above.

Hopefully my explanation makes sense. I have the horrible curse of being able to understand things easily but badly explaining them