Are my rollable tables broken?

I have been trying to use rollable tables to create semi-random images for my tokens. I create a rollable table with the selection of images that I want, then I produce the token from the rollable table menu, but when right click and tell it to roll the image, nothing changes. Note that if you drag a die icon from the chatbox into the grid, it functions as a rollable token, and seems to do exactly what I am trying to do with actual tokens. I'm not sure why this works when normal tokens do not. I even followed the instructions on this tutorial video , and while it works perfectly for him, it doesn't work on any of the tokens that I create. I am a Mentor using the most recent version of Firefox.

I've tried it twice: 6 with weighted values, and 7 with normal values

When I look at the chat box, it displays a unique image, but the token on the table does not change or match it. This is true even when everything is equally weighted at 1.

Yes, that is correct.

Operating System Macintosh OS X 10.8 Screen Resolution 1280 x 800 Web Browser Firefox 26.0 Browser Size 1280 x 618 Color Depth 24 bit Javascript Enabled Flash Version 11.9.900 Cookies Enabled

I even made a 2-item rollable table and tried to choose instead of roll, and once again the image shows up in the chatbox but not on the map.

Yeah, "mixed content" is showing up a lot, along with "Loading mixed (insecure) display content on a secure page"

Here's everything from dropping it, moving it slightly, and trying to make a roll: 23:28:10.406 Loading mixed (insecure) display content on a secure page "<a href="http://d20cors.herokuapp.com/?src=www.dundjinni.com/forums/uploads/TheSim/75B_Lizardman_Dead_XN.png&cb=5&quot;[Learn" rel="nofollow">http://d20cors.herokuapp.com/?src=www.dundjinni.com/forums/uploads/TheSim/75B_Lizardman_Dead_XN.png&cb=5"[Learn</a> More] app.js:21 23:28:10.468 GET <a href="http://d20cors.herokuapp.com/" rel="nofollow">http://d20cors.herokuapp.com/</a> [Mixed Content][HTTP/1.1 200 OK 1029ms] 23:28:11.572 "Update changed!" app.js:22 23:28:11.574 "Reorder by ZORDER" app.js:25 23:28:13.142 "Update changed!" app.js:22 23:28:20.993 GET <a href="https://s3.amazonaws.com/files.d20.io/images/1672" rel="nofollow">https://s3.amazonaws.com/files.d20.io/images/1672</a>... [HTTP/1.1 200 OK 502ms] 23:28:20.935 "Alerting!" app.js:32 is this what you wanted?

This has suddenly happened to me as well, after several successful uses of this ability. The difference between this instance, where it doesn't work, and the previous instances, where it did? I'm using tokens not-made by Devin Night! However, that's not entirely accurate; I have a still-functional set using not-his tokens. Maybe the difference is I'm using ones from dundjinni? Nope; the working one uses some of those as well. Here's the situation: I have a set of goblins; it works fine. I have a set of orcs; it works fine. I have a set of zombies; it works fine. I have a set of frogs; it doesn't work. The frogs are the most recent set made, hence my posting an error regarding them. For the frogs, I have five different images. The three made by Devin Night work. The two from dundjinni do not. I can change any DN frog to another, randomly. No frog from DN will change to a dundjinni frog. No frog set up initially as a dundjinni frog will change to a non-dundjinni frog. I removed one dundjinni frog from my rollable table and re-set the default token to the remaining dundjinni frog. I placed 9 instances of this frog on the grid; none change images when randomized. I placed 9 instances of the original DN frog on the grid; Some change images when randomized, but only to DN frogs. The chat window continues to show a full variety of images, despite those on screen changing 'sporadically' is I guess the best word for it. Interesting note: Despite removing one of two dundjinni images from the rollable table, the original set continues to indicate that it could, if it were working properly, include both dundjinni images in the random change; this is also the case if I choose sides. Here's an image that may help explain: Original Set: red, green, grey frogs, all Devin Night; Blue and Yellow, dundjinni; note lack of blue and yellow frogs; note presence of blue frog in 'change side' window. Copy Set: as above, but without blue frogs. Zombies: variety from many sources Orcs: All Devin Night From this, I am unable to logically determine any contributing factor that is not ruled out by working in another set. Experiment done: Copy campaign. Result: Interesting, to say the least... Absolutely nothing was done to this copy aside from entering it. Note that some of "Original Set" have changed; specifically note the blue and yellow frogs. Note that many of "Copy Set" have changed; specifically note the non-yellow frogs. Now I will go through and randomize each set, once. The results: Original set: lower-right frog changed from green to red; within bounds of chance except for DN/dundjinni issue. Copy set: upper-left frog changed from green to red; within bounds of chance except for DN/dundjinni issue. Zombies; Changed as expected, randomly. Orcs: Changed as expected, randomly. Windows 7, Flash 11.9.900, Chrome 31.0.1650.63 for what that's worth. Not sure where/how to find these 'errors' mentioned in a previous post. I'm way, way, waaaaay past my bedtime now, so I won't see any response until tonight. Thanks for looking into this; hope my data helps! PS: I've sent Kristin a private message containing a link to the copy of this campaign for closer examination. If GM access can not be obtained by someone on Roll20 staff, I will provide it when I wake up. PPS: I'll send one to Riley and one to Gauss as well, 'cuz y'all rock pretty hard too!

Further experiments performed, New Rollable table made in each instance: Table contains only Devin Night frogs: Worked as expected Table contains Devin Night frogs as well as blue and yellow dundjinni frogs, replicating original setup: Same results, yellow and blue did not appear. Table contains only blue and yellow dundjinni frogs: Did not work at all; yellow frogs remained yellow despite blue frogs appearing in chat. Table contains both DN frogs and other frogs that are not the blue and yellow frogs, but are other images of frogs, also from dundjinni: Worked as expected. Conclusion: Rollable tables can be broken by specific images; there is no readily apparent method of determining which images will not work. To repeat this experiment independently, image search "frog" with Tokens filter. yellow and blue frogs found under 'From the Web", named "By Kepli - <a href="http://www.dundjinni.com" rel="nofollow">www.dundjinni.com</a>" PS: Additional experiment performed: Hypothesis: blue and yellow frogs are unusually large images, which causes the rollable table program to ignore them or otherwise treat them differently. Using map layer, dragged images from search to map layer to apply in native size rather than snap-to-grid resizing. Result: blue and yellow frogs are roughly similar in size to other images, and in fact smaller than certain other images. Conclusion: There is some other attribute of these two images which breaks the rollable table functionality, not found in all other images... or vice-versa, not found in these which the others have. PPS: Additional experiment performed: Hypothesis: Images made by kepli have inherent property disabling rollable tables Using search term 'kepli' found approximately 10 different floor tile samples made by kepli and hosted on dundjinni. Created rollable table with samples, created journal entry 'kepli tiles' and used kepli table as default token. Result: with one exception, all kepli tiles failed to change when randomized. Using search term 'tile' found approximately 10 different floor tile samples NOT made by kepli and hosted on dundjinni. Created rollable table with samples, created journal entry 'not kepli tiles' and used not-kepli table as default token. Result: with no apparent exceptions, all tiles changed when randomized. Conclusion: kepli files in particular have some property rendering them unsuitable for use with this application, and will not be used by me in the future.

As Phnord said, Devin Night's frogs work, whereas Kepli frogs do nothing. To answer any questions about file type, both DN and Kepli frogs are .png. One noteworthy distinction is that DN frogs are from the Roll20 marketplace and Kepli frogs are not. I attempted to use rollable tables with images from the marketplace, images from dundjinni, and images uploaded by me. All three worked, so there is something in particular about the initial group of sprites that caused this problem; still unsure. I attempted using background images a la Kristin's landing screen from another post, but the images I chose will also not roll.

Welcome. It's what I do. q;} PS: I noticed during this process that I can delete the rollable table after setting up the randomizable tokens and they still work properly. PLEASE tell me this isn't a bug and will still be possible in the future... I hate to think I'll have 200 rollable tables on my screen when I'm done setting this thing up!

Thanks for the tip Kristin; I will experiment with that. Further data found: Attempted to make a set of gnoll tokens. Found a distressingly small selection, but decided on five that would be appropriate. Of the five, two worked, three did not. I hypothesized again that there was a difference in size, and was shown to be right in this instance (but remember, not in the previous (frog) experiment). Here is a screenshot of the images used; the two on the top (now three on top) are the ones that work. The three beneath them are ones I wanted to use; they do not work, singly or grouped. Note the size difference. The two on the right are images I consider unsuitable for my purposes; they also do not work. Each is listed with its source (except the two I don't want) Current hypothesis: Size does not matter (hehehe.) However, DETAIL does. Perhaps the rejected images have a higher resolution, pixels-per-inch, different color palette (theory consistent with the frogs), or similar property causing Roll20 to reject them? I continue to experiment...

New experiment: I went into the copy of my campaign, the one I'd given Kristin access to. While there, I deleted the rollable tables related to orcs and zombies. I left the frogs untouched. I copied this to a new campaign, and tested the randomizer. It worked! The zombies and orcs were randomized, despite a lack of a rollable table. The frogs remained semi-unresponsive. I copied THAT to a new campaign, and tested the randomizer. It worked! I copied THAT to a new campaign. I copied THAT to a new campaign. I copied THAT to a new campaign. I copied THAT to a new campaign. This is now (original name) copy copy copy copy copy copy. Each version was copied from the previous, new copy, not from the original. I then shut down all my windows, and rebooted my computer, without entering Copy^6. Upon reboot, still without actually entering Copy^6, I copied it into a new campaign. I entered Copy^7 and tested the randomizer. It worked as expected. Zombies and Orcs randomized perfectly; frogs randomized in the 'broken' manner I expected. PLEASE DO NOT 'FIX' THIS!!!!!!1!!1!!!!one!!!! It's not a bug, it's a feature!! It SHOULD work this way, even if that's not the intent... leave this part alone! I like being able to delete unwanted Rollable Tables, thank you! PS: Yes my sleep schedule is Fubared, thanks for noticing! q;}

I am very confused… not quite sure what you just accomplished...

Robert R. said: I have been trying to use rollable tables to create semi-random images for my tokens. I create a rollable table with the selection of images that I want, then I produce the token from the rollable table menu, but when right click and tell it to roll the image,... ...it works perfectly, even after deleting the rollable table used to create the semi-random images for my tokens. Is what I accomplished. q;} Within the limitation I've been working on, at least, namely that certain images do not work properly, even while the rollable table itself still exists. In addition to: Narrowing the issue down to one of several specific images, which provides a sample which can be used for further testing. Eliminating or verifying various hypotheses regarding why these work and those don't. Providing said information to the Devs, Mentors, GMs, players, and yourself (whatever you do around here... q;} ) Yeah. I need to get some sleep...

But it doesn't work perfectly. Did you make it work? I am very confused.

Kristin C. said: Phnord, I think you've bug tested this so hard that you've glimpsed the 4th dimension. I should buy some stock in Tylenol PM. ;) Baby, lemme tell ya... I swear I saw The Fifth Dimension! Robert R. said: But it doesn't work perfectly. Did you make it work? I am very confused. No, Robert... I'm still working on the same issue, just knocking bits off the edges. However, I did test the ability to delete the rollable table used to randomize token images linked to a journal entry, which is something I discovered while bug-testing the main issue. My hope is that this ability is not accidentally 'fixed' when the main issue is fixed! (It seemingly allows an uncluttered rollable table list.)

Please send me a join link and I will take a look.

You should already have one in your PMs but here comes another one.

Ah. I understand. There is a similar issue with Token images and Avatars after deletion. And Gauss, are you talking to me?

Sorry, yes I meant you Robert. :)

Eureka!! Kristin gave me the clue I needed: Kristin C. said: Phnord, I wouldn't be surprised if those tokens disappear after a **** reload **** of the campaign. If you delete images from your art library it doesn't automatically strip them from those in use in your campaign - until you refresh your campaign that is. Reload? What happens if I reload the campaign? So I tried it. I set up a group of frogs: Then I randomized the group (showing chat window for results): And I hit F5 to refresh the campaign and this is what happened: Note that the only frog that changed in the first instance is the one that changed from grey/green to red... all the others were either originally blue or yellow, or changed to blue or yellow. (Note also that the rollable table used to create these tokens is long since destroyed!) Hey, that worked, I said at this point... and re-built my Gnoll set. Here's the results: Original group Randomized, with chatlog: And after hitting F5: (funny story; I ran this experiment 'live' while I was typing this post. At this point, while trying to type F5, I accidentally hit the F5 button on my keyboard and lost the entire post! Hahahaha! What you've read so far is a recreation of what I'd tried to post up to this point!) So, what I can conclude from all this is that there is a bug in the functionality of this system. BUT, the bug is not in the rollable tables, nor the images, nor the tokens, nor any other part of the system that we, the players, can access. The bug is specifically located in the part of the system that replaces the token image in real time on the screen! In other words, you have a multi-sided image. That image can be changed, randomly or by selection. That change is saved. That change is then sent to the imaging processor for lack of a better term. The imaging processor then changes the drawn token BUT if the drawn token has an attribute it doesn't like, it hangs and that image is not changed. If it doesn't dislike it, the image is instantly changed. This is where the bug is located! However, the change is still registered somewhere! Now that the image has been changed and registered, then the next time the image is loaded, the proper image is called up and shown by the imaging processor. I hope that makes sense. I hope that's enough information to fix this bug. I really, really hope that you don't mess with any other part of the system... please let me keep deleting rollable tables after their usefulness is ended!! Regardless, I've found a way to work around the bug, and that's good enough for me. Everyone else... good luck to ya! Hahahaha! PS: Thanks to Robert R for letting me hijack your thread!

I repeated the test and got the same results. It's hell to reload a google hangout in the middle, so no mid-session campaign building, but it's a start. I hope the devs find the problem at its core. Thanks to everyone who helped!

That's some amazing bug testing, Phnord. I wouldn't worry about the loss of other functionality. It's fundamental to the way rollable tokens work that i cant see that easily changing. Here's an example: you create a rollable table, then make a token. The list of possible images is saved with that token. If you then modify the original rollable table (add or remove images), those changes do not affect the token you have already created. Once a rollable token is created, it is not linked in any way to the rollable table any more. At the moment of creation, they have the same set of images in a table, but they are separate, independent copies of that table.

Thanks GG! Just my natural scientist comin' to the front again... hypothesis, experiment, conclude, hypothesize again. When I find a problem like this I just gotta try to figure it out, can't help myself! And yeah, what you say about the rollable tokens makes sense. Coming from an old-school background, where things like memory limitations applied, I guess I just assumed that limiting the memory needed would be a thing. (Having the token reference the table would require each token to use less memory; having each token store all the various images requires more.) Guess that's not the case these days, what with Gigabytes of RAM and Terabyte hard drives! (Sniff... I miss my Commodore 64 (64 KILObytes of memory! ROFL!) sometimes.) Devs, hope you're working on this! I have done all I can on my end, the rest is up to y'all! Good luck!

I will attempt to confirm this later this week. :)

So... uh, any news on this? I've managed to solve my own problems through the time-consuming process of blatantly stealing others' artwork, running it through GIMP, and reloading it as my own. So far, no image created in this manner has proven itself unsuitable for this application. However, it's (as I mentioned) time-consuming and boringly repetitive, not to mention borderline ethically unacceptable. On the plus side, the images do look a lot better, as in some cases I've removed the white background. Still, it'd be nice to know that all my bug-testing didn't go to waste. If you need help finding more images that don't work, lemme know. I've located quite a few by now!

I haven't forgotten, the week has not yet expired. :)

Hey Gauss! Were you able to replicate this? Need more information? Lemme know!

Is this still a thing that someone's working on? I'd be glad to help more if needed, just let me know...

He logged into my game about a week ago to check it out. I haven't heard anything since.

Just letting you know, I am just a Moderator (a volunteer) and not a Developer. I do not fix anything but I do spend my spare time to try to help the Devs identify the bugs so they can spend more time fixing them and upgrading the system and spend less time troubleshooting. With that said, I have been busy the last month and this bug is the kind of bug that will take me a lot of time trying to figure out what is actually causing it. Last week I did let Robert know that I had confirmed the bug but because the Devs had already been notified by Kristin on January 5th (she stated this in this post here: <a href="https://app.roll20.net/forum/post/554359/#post-560" rel="nofollow">https://app.roll20.net/forum/post/554359/#post-560</a>... ) there was really no rush for me to identify the cause and send it over to them. :) I did spend a few minutes tonight to discover a workaround for you. If you download the web images that do not work (such as the frogs) from the source and then re-upload them to Roll20 they will work correctly in a table. One other note, when troubleshooting, concise reporting is easier for us to read and understand than long reporting. A simple step by step procedure to reproduce things will also help. Here is an example of a step by step procedure to reproduce this bug: Image used in step by step procedure: Steps to reproduce: 1) Create Table 2) In art library tab search for "frogs" 3) Add new item 4) Drag a frog image (one of those shown above) from art library tab to new item. 5) Save new item 6) Repeat steps 3-5 for the frogs shown in my screenshot shown above. 7) Save table 8) Create a rollable token from the table. 9) Either choose a side of the token or roll the token. Result: The new image will not display on the token. Note1: Refreshing the browser will show the correct image on the token (the one that did not display prior to refreshing the browser). Note2: If you download the images and then upload them to a table the rollable token works correctly.

Hey Gauss Thanks for the response. I'd assumed that the debugging system required you (or another mod) to replicate the bug before reporting it to the Dev's, and I guess I was right. I was just worried that it had slipped your mind or maybe you weren't able to replicate it or something. When I saw someone else with the same problem in another thread, I decided to bump this one just to make sure things were moving forward. And yes, your example is a much better way of reporting the bug; but remember, we didn't have all that information to start with. We reported the bug when we found it with what information we had at the time, and came back later with updates as we did what we could on our end to help narrow down the exact nature and location of the bug. Not to come off as snarky, but I'm not going to not-report a bug, just because I haven't done that same level of bug-testing in the future... y'all are gonna get updates as I go along, assuming I do so at all, and that will be somewhat messy in comparison. It's just the nature of the beast, ya know. My workaround so far has involved taking a screenshot of the image and running it through GIMP, then re-uploading it. It's nice to know that additional step isn't needed (although I'll still do so for images on a white background; I prefer the cleaner look of a .PNG). Anyway, I'm just glad to know that this is continuing to be worked on. It may not be a feature every user uses in every game, but it has that potential and as such, I'd like to see it fixed for everyone. -Phnord

I think he was just talking about the formatting. it was a bit scattered and hard to follow, and therefore hard to replicate.

Yeah, it was that. Sorry! I'll try to do better in the future.

Phnord , as I stated, it was reported to the Devs two weeks ago by Kristin. Thus, I did not have to report it to them. We (the Moderators) do not need to replicate the problem to pass it along to the Devs. I do that to help the Devs.

Riley: Have I mentioned lately that y'all are awesome? Thanks for fixing this! If it's something the layman can understand, and isn't a trade secret, can you let us in on what the problem was? Gauss, thanks for your help regardless; sorry if I seemed impatient! RobertR, thanks again for letting me hijack your thread! -Phnord

Not a problem. Glad we're getting it worked out. And Gauss, nothing personal, but let me know when it's cool to kick you from my roster.

Am I still showing up in your campaign? I had removed myself this morning.

got it. Thanks :)