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.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."
Library Token: Dice Box
Moderators: dorpond, trevor, Azhrei, giliath, Gamerdude, jay, Mr.Ice
-
- Dragon
- Posts: 685
- Joined: Wed Sep 03, 2008 12:34 pm
- Location: The Junkyard
Re: Library Token: Dice Box
-
- Dragon
- Posts: 685
- Joined: Wed Sep 03, 2008 12:34 pm
- Location: The Junkyard
Re: Library Token: Dice Box
So it wasn't as hard as I thought... I'd change simply change your json.get for the TN and mod to
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.
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"))]
-
- Dragon
- Posts: 685
- Joined: Wed Sep 03, 2008 12:34 pm
- Location: The Junkyard
Re: Library Token: Dice Box
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
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.
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"))]
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.
Re: Library Token: Dice Box
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).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.
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.
-
- Dragon
- Posts: 685
- Joined: Wed Sep 03, 2008 12:34 pm
- Location: The Junkyard
Re: Library Token: Dice Box
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.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).
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...
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.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.
Re: Library Token: Dice Box
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 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.
-
- Dragon
- Posts: 685
- Joined: Wed Sep 03, 2008 12:34 pm
- Location: The Junkyard
Re: Library Token: Dice Box
Wow, I just looked at the 2.8 version... huge difference from the 2.7 (I think) that I was looking at.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.
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.
Re: Library Token: Dice Box
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.
Re: Library Token: Dice Box
I ran into that in tonight's game. Dang. I thought I would be the first to report it.
Re: Library Token: Dice Box
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.
Newest version linked in the first post of this thread.
-
- Cave Troll
- Posts: 26
- Joined: Thu Apr 16, 2009 4:12 pm
Re: Library Token: Dice Box
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 acall for each die result, and output the whole collection with the 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.
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)]
Code: Select all
<image src='[r: tableImage("", value)]'></image>
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.
Re: Library Token: Dice Box
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.
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
Re: Library Token: Dice Box
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."
Re: Library Token: Dice Box
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)]
Re: Library Token: Dice Box
That is clever.
You could solve the group problem, for those who need to, by appending a group prefix or suffix as well.
You could solve the group problem, for those who need to, by appending a group prefix or suffix as well.
MapTools Forks: Thread