Library Token: Dice Box

These are tools and utilities that make it easier to run games. This includes Lib: macro tokens dropped into MapTool to manage the game, a conversion file for CharacterTool to allow use in MapTool, or just about anything else you can think of -- except graphics with macros and anything specific to a particular campaign framework. Those are already covered by the Tilesets subforum and the Links and External Resources forum.

Moderators: dorpond, trevor, Azhrei, giliath, Gamerdude, jay, Mr.Ice

DeviantNull
Dragon
Posts: 685
Joined: Wed Sep 03, 2008 12:34 pm
Location: The Junkyard

Re: Library Token: Dice Box

Post by DeviantNull »

Rumble wrote:Actually, simultaneously maintaining the different layouts was why I scrapped them and went with "you can have any layout you like, as long as it's the one I decided on."
Maybe I should take a look at things under the hood. Different layouts shouldn't be posing that much of a problem, should they? Then again, I write some fugly code that I think only works through brute force... which isn't exactly elegant or often speedy.

DeviantNull
Dragon
Posts: 685
Joined: Wed Sep 03, 2008 12:34 pm
Location: The Junkyard

Re: Library Token: Dice Box

Post by DeviantNull »

So it wasn't as hard as I thought... I'd change simply change your json.get for the TN and mod to

Code: Select all

[h:mod=if(json.get(selectedDice,"mod") == "", 0, json.get(selectedDice, "mod"))]
[h:target = if(json.get(selectedDice, "tn") == "", 0, json.get(selectedDice, "tn"))]
that way if a empty value is passed it's converted to a 0 to prevent the math functions from exploding in messy ways. Also, if you construct alternate inputs and they don't pass those 2 values it doesn't crap out. All the alternate frame layouts work just fine for me now since TN is automatically zeroed out. I'll take a look at the exploding thing if I get a chance.

DeviantNull
Dragon
Posts: 685
Joined: Wed Sep 03, 2008 12:34 pm
Location: The Junkyard

Re: Library Token: Dice Box

Post by DeviantNull »

I'll have to finish chasing down the exploding checkbox later. It simply appears to be an issue of it not having a value for it read out and passed forward when you execute SelectDice. But I can't get the macros to output when I change the links to "all" to properly debug it right now. I did notice something else that might help in general though...

I see that you're using <a> anchors for the macrolinks and then laying an image over it (or something like that, my HTML is for crap). You can get the same result without the anchors just by using a regular MacroLink like

Code: Select all

[h: tempTableImage = tableImage("D4", 4)]
[r: macroLink ('<img border="0" height="47" width="50" src="'+tempTableImage+'" align="middle"></img>', "SelectDice@this", "none", json.set(macro.args, "lastSelected", "d4"))]
You could probably even roll it all into one line and get rid of the first function execution but nested quotes makes my head go wobbly and the "D4" has to be inputed like a string... I think.

It's not a huge change, but it makes it more compact as well as easier to read IMHO.

Edited to add:
And like a lightning bolt it came to me what the problem is... it's a checkbox.

HTML inputs (no matter the kind) only gain a value to pass forward when the form itself is submitted using the submit button. The dice selection are macroLinks and thus the checkbox (and modifiers and TN) never have a value to pass forward in the links.

You have 2 options to work around the problem.

One, you turn the Exploding option into a macroLink itself like the show results option and thus have a value you can set and pass around in the other macroLinks and when the form is submitted (using hidden inputs like you currently do). This is the easy to code but ugly UI option.

Two, you make the checkbox into a value that is stored on the lib:token and thus can be retrieved by the macroLink macros. Code wise you'd have a couple different ways you can store the info and still make it player independent (I personally use 1 prop with a JSON in my new sheet stuff to make the page views player independent so it doesn't change on the player while the GM is poking through it). You might have issues with the Lib:Token not updating properly if multiple players try to access it at once. And, of course, it's not going to have a value set till the dice are rolled at least once and it's saved from it's default value. But you'd have the nice UI friendly checkbox... yeah, I'd go with option 1 myself.

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: Library Token: Dice Box

Post by Rumble »

DeviantNull wrote:One, you turn the Exploding option into a macroLink itself like the show results option and thus have a value you can set and pass around in the other macroLinks and when the form is submitted (using hidden inputs like you currently do). This is the easy to code but ugly UI option.

Two, you make the checkbox into a value that is stored on the lib:token and thus can be retrieved by the macroLink macros. Code wise you'd have a couple different ways you can store the info and still make it player independent (I personally use 1 prop with a JSON in my new sheet stuff to make the page views player independent so it doesn't change on the player while the GM is poking through it). You might have issues with the Lib:Token not updating properly if multiple players try to access it at once. And, of course, it's not going to have a value set till the dice are rolled at least once and it's saved from it's default value. But you'd have the nice UI friendly checkbox... yeah, I'd go with option 1 myself.
I'd rather not do a link - that's how it used to work, and I prefer the checkbox option (aesthetics, mostly). As for option 2 - that's how it's done in the latest revision (all the values are stored in Library properties).

The issue is that if you select your dice, set TN and Modifier and all the remaining options, it will remember them on the next roll. HOWEVER, if you set it all up, and then go "oh crap, I need to roll one more dX", and hit a button to increase the number of dice, it loses the checkbox and radio buttons. And I cannot for the life of me figure out why. Probably something stupid.

In any case, feel free to play with it. As I mentioned, I'm not going with the multi-layout option anymore; but it's still certainly viable.

DeviantNull
Dragon
Posts: 685
Joined: Wed Sep 03, 2008 12:34 pm
Location: The Junkyard

Re: Library Token: Dice Box

Post by DeviantNull »

Rumble wrote:I'd rather not do a link - that's how it used to work, and I prefer the checkbox option (aesthetics, mostly). As for option 2 - that's how it's done in the latest revision (all the values are stored in Library properties).
I guess I explained it badly. Really short answer is that it blanks because it is not a stored value and when you execute the macroLinks for dice addition you end up reloading the Dice Box frame and thus HTML input values revert to their default values.

There's actually a 3rd work around but I had to tear apart the die roller to figure out how it works. I forgot that Frames hold their values on screen until reloaded. I always reload my input frames after execution due to the fact mine have to reflect updated changes so I just forgot that. You don't reload the frame after executing the RollDice code so that's why it would 'remember'.

The solution is to just store the Mod, TN, and Explode in temporary properties that keep getting passed around. However, they're not set until an initial die roll is made, since there's no other way to get a value into the variable otherwise. I'm in the process of updating it right now...
In any case, feel free to play with it. As I mentioned, I'm not going with the multi-layout option anymore; but it's still certainly viable.
Real shame... I'll fix that for you! The HTML layout code looks pretty modular once I started smushing parts into nested tables. Shouldn't take too long to copy and paste things around. Just not sure if I want to do all of them, but i'd like a horizontal and vertical option and then the original box.

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: Library Token: Dice Box

Post by Rumble »

DeviantNull wrote:I guess I explained it badly. Really short answer is that it blanks because it is not a stored value and when you execute the macroLinks for dice addition you end up reloading the Dice Box frame and thus HTML input values revert to their default values.
My point was that those values were being stored as properties (unless I missed a setProperty() somewhere - always possible!) when the frame action was executed, but were still not being repopulated when the dice buttons are being pressed. I lost hair about it, and then gave up.

DeviantNull
Dragon
Posts: 685
Joined: Wed Sep 03, 2008 12:34 pm
Location: The Junkyard

Re: Library Token: Dice Box

Post by DeviantNull »

Rumble wrote:My point was that those values were being stored as properties (unless I missed a setProperty() somewhere - always possible!) when the frame action was executed, but were still not being repopulated when the dice buttons are being pressed. I lost hair about it, and then gave up.
Wow, I just looked at the 2.8 version... huge difference from the 2.7 (I think) that I was looking at.

Okay, I'm behind the curve apparently. You can safely ignore me. Though from looking at it, you may be making it more complex then it needs to be and you seem to still have the same problem of the values resetting when the dice are changed.

I'll send you a token of what I came up with based on the previous version.

EDITED:
Yeah, I just confirmed it by connecting to myself... since you're storing all your dice rolls in a single lib:property all connected players share the same saved dice values unless it's cleared before they roll.

basically, if I as the GM roll 1d20 and then a player clicks 3d6 and rolls it rolls 1d20+3d6.

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: Library Token: Dice Box

Post by Rumble »

DeviantNull wrote:Wow, I just looked at the 2.8 version... huge difference from the 2.7 (I think) that I was looking at.

Okay, I'm behind the curve apparently. You can safely ignore me. Though from looking at it, you may be making it more complex then it needs to be and you seem to still have the same problem of the values resetting when the dice are changed.

I'll send you a token of what I came up with based on the previous version.

EDITED:
Yeah, I just confirmed it by connecting to myself... since you're storing all your dice rolls in a single lib:property all connected players share the same saved dice values unless it's cleared before they roll.

basically, if I as the GM roll 1d20 and then a player clicks 3d6 and rolls it rolls 1d20+3d6.

No kidding. I didn't see that behavior - it seemed to clear out the roll every time, but then, I didn't test it as a player, just as GM. It makes sense - conflicting writes are "last-one-wins" and I didn't even consider that. That will need to be fixed.

Fortunately, it's not that tough to do - just switch from token properties to a re-initialized JSON. Maybe stored on a player's token (using setProperty() instead of setLibProperty()).

Glad you caught that...I won't be able to fix it until this weekend at the earliest, unfortunately.

User avatar
RPTroll
TheBard
Posts: 3159
Joined: Tue Mar 21, 2006 7:26 pm
Location: Austin, Tx
Contact:

Re: Library Token: Dice Box

Post by RPTroll »

I ran into that in tonight's game. Dang. I thought I would be the first to report it.
ImageImage ImageImageImageImage
Support RPTools by shopping
Image
Image

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: Library Token: Dice Box

Post by Rumble »

Bump for an update. I moved to using arguments rather than storing information on properties; this should (though I don't really know) prevent overwriting/failure to clear properties. It also has the benefit of remembering what you set (target number, exploding, etc) if you update the dice number.

Newest version linked in the first post of this thread.

Ego Archive
Cave Troll
Posts: 26
Joined: Thu Apr 16, 2009 4:12 pm

Re: Library Token: Dice Box

Post by Ego Archive »

This is really great, I love the new look Rumble!

One suggestion (i'm not sure how possible it would be) is if you could select, via checkbox, the results as table images.

So say you are rolling 3d6, and the results are 6(3,2,5)+0; would it be possible to have it call a sub that would do a

Code: Select all

[h: tableImage(name, row)] 
call for each die result, and output the whole collection with the

Code: Select all

<image src='[r: tableImage("", value)]'></image>
image command?

If you think it's possible but don't have the time, I could see if I can figure it out. I just don't want to step on all your hard work. :)
Towndale: A user generated fantasy town for any game system.

MeMeMe
Dragon
Posts: 256
Joined: Tue Mar 31, 2009 7:44 pm

Re: Library Token: Dice Box

Post by MeMeMe »

It is possible: the technique is demonstrated at the end of this macro

I'd like to see the Dice Box macro hacked in this fashion, since it would make it easier to use for other systems where you don't simply add the dice. I can look at the output and count successes or whatever is needed.
MapTools Forks: Thread

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: Library Token: Dice Box

Post by Rumble »

MeMeMe wrote:It is possible: the technique is demonstrated at the end of this macro

I'd like to see the Dice Box macro hacked in this fashion, since it would make it easier to use for other systems where you don't simply add the dice. I can look at the output and count successes or whatever is needed.

Done.

This is a first pass at it. Run the "Configure Dice Box" macro to switch "show images" on. Images will be shown if:

1. You set Show Images in Configure Dice Box.
2. Explode is unchecked.
3. Tooltip Info is set to "Each Die."

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: Library Token: Dice Box

Post by Rumble »

Rumble wrote:Bump for an update. I moved to using arguments rather than storing information on properties; this should (though I don't really know) prevent overwriting/failure to clear properties. It also has the benefit of remembering what you set (target number, exploding, etc) if you update the dice number.

Newest version linked in the first post of this thread.

As a general "hey, neat trick!" tip that I just realized today. There's a way to use Library Token properties (or, in fact, ANY token property) for this kind of thing without overwriting each other; you just append the player's name to the property name when you set or get it. For example:

Code: Select all

[h:status = input ("coolProp|0|Set your cool property here!")]
[h:abort(status)]

[h:setLibProperty(getPlayerName()+".coolProp", coolprop)]
 
And voila, no overwriting. Just something that occurred to me. Potentially risky if you have multiple groups, but I thought it was clever.

MeMeMe
Dragon
Posts: 256
Joined: Tue Mar 31, 2009 7:44 pm

Re: Library Token: Dice Box

Post by MeMeMe »

That is clever.
You could solve the group problem, for those who need to, by appending a group prefix or suffix as well.
MapTools Forks: Thread

Post Reply

Return to “Drop-In Macro Resources”