Recursive Table Return Zero for Every roll

I am testing the recursive table script and every roll returns a 0. The table entries are simple rolls like [[1d4]] items. No luck. Any thoughts would be appreciated. thx

What macro/command are you using to call RecursiveTables? Can you post a screenshot of the table and one or two of the items?

Jarren said: What macro/command are you using to call RecursiveTables? Can you post a screenshot of the table and one or two of the items? Jarren, Here is a sample table called test2 and the command I am using in the chat box. I have much more complex tables but none appear to work. I have taken the spaces out of the command with no success. I'm using version 0.2.5 of the Recursive Table script. !rt --help works so I know the script is getting invoked. Baffled. thx

Just to add to this. I created a new game with most of the same scripts installed and re-created a simple table and it works. Worrisome. Script conflict maybe or something got corrupted in the game. I had this happen before (corruption) and had to copied the game to get it to work again.

What happens if you export the table from your active game into your test game and run it there? Do you still only get 0s?&nbsp; It also appears that there may be a bug for script-generated inline rolls:&nbsp; <a href="https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0" rel="nofollow">https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0</a>. &nbsp; Adding another set of double braces around the rolls may fix the problem.

I exported the table from old to new game. It works in the new. Jarren said: What happens if you export the table from your active game into your test game and run it there? Do you still only get 0s?&nbsp; It also appears that there may be a bug for script-generated inline rolls:&nbsp; <a href="https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0" rel="nofollow">https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0</a>. &nbsp; Adding another set of double braces around the rolls may fix the problem.

Jarren said: What happens if you export the table from your active game into your test game and run it there? Do you still only get 0s?&nbsp; It also appears that there may be a bug for script-generated inline rolls:&nbsp; <a href="https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0" rel="nofollow">https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0</a>. &nbsp; Adding another set of double braces around the rolls may fix the problem. As I mentioned I've had some kind of corruption problem in the past. I tried the debug trick of uninstalling half the script etc... to try and identify bad or conflicting script but no luck. Someone mentioned in the forums to copy the game and try there. I did and had to re-install the scripts etc.. and it worked. I hope this isn't an ongoing problem. Way to much work in the game to start afresh. thx

Jarren said: What happens if you export the table from your active game into your test game and run it there? Do you still only get 0s?&nbsp; It also appears that there may be a bug for script-generated inline rolls:&nbsp; <a href="https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0" rel="nofollow">https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0</a>. &nbsp; Adding another set of double braces around the rolls may fix the problem. i saw that post you mentioned but didn't see anything about adding an additional set of brackets. I'll try it. That guy added a macro at the bottom of the entry to force the roll. I hope that's not the solution.

Update to this issue. I disabled all API Scripts except RecursiveTables and ExportTables and then re-added them one at a time. Found two API scripts that caused issues with RecursiveTables - SimpleSounds and It's A Trap D&amp;D 5e Generic . I switched to It's A Trap (standard 3.13) and it appears to be compatible. I'll have to look through the code for SimpleSounds to see if I can determine the conflict or issue. Wish me luck! Issue #2 - When I import roll tables with inline rolls (e.g. [[1d4*10]] ), the table entries are saved as rolls (pre-rolled if you will). I tried wrapping the inline rolls with html code brackets " &amp;#91;" and " &amp;#93;" respectively before import but they get included in the table entry and the rolls do not work. Any thoughts. thx

Update to issue #2 - found discussion about using&nbsp; &lt;%%91%%&gt; and&nbsp; &lt;%%93%%&gt; for brackets. That fixed the problem. Successful import and roll. thx

joeuser said: i saw that post you mentioned but didn't see anything about adding an additional set of brackets. I'll try it. That guy added a macro at the bottom of the entry to force the roll. I hope that's not the solution. I was reading quickly and thought that's what Hellfire M. was saying here, but he actually changed the 1t for the roll to be [[1d1]]t, which is slightly more obnoxious to do: <a href="https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0/?pageforid=7885024#post-7885024" rel="nofollow">https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0/?pageforid=7885024#post-7885024</a> I found a solve, albeit a very complicated and tedious one. After trying the test table I found that most results were occurring as 0 when the die roll wasn't specified; [[1t[MagicItemTableI]]] so I changed it to [[[[1d1]]t[MagicItemTableI]]] and that seemed to fix the issue mostly but it still occurs rarely, I tried with simple inline table rolls and the error seemed to not occur at all, maybe the API hits the MB limit for processing and returns a failed result when it gets too complicated and crowded. Then a bit further in the linked threads you can see there was some more exploration by The Aaron about the random '0' value that can appear with rollable table results: <a href="https://app.roll20.net/forum/permalink/6778723/" rel="nofollow">https://app.roll20.net/forum/permalink/6778723/</a> So, I've built out a much more complicated reproduction script.&nbsp; The key appears to be a pattern where you have: [[XdX]] [[ [[XdX]]t[table] ]] [[ Xt[table] ]] That is, some number of regular dice rolls, has to be at least one, followed by a rollable table with a nested inline roll, at least one, followed by a rollable table without a nested inline roll, at least one. The more of the first there are, the more likely it will happen.&nbsp; With 9 [[XdX]] types followed by 1 each of the other 2, it has always exhibited the issue for me in test. 1 it happens ever so often, with 3-5 it happens most of the time. So unfortunately I don't think this has been solved yet, and it's possible that whatever macros you were using were excessively triggering this bug/quirk of rollable tables.

Thanks much for the input. I believe in this case it was a conflicting script as I mentioned above. It appears to be working with a few formatting issues yet unresolved. thx Jarren said: joeuser said: i saw that post you mentioned but didn't see anything about adding an additional set of brackets. I'll try it. That guy added a macro at the bottom of the entry to force the roll. I hope that's not the solution. I was reading quickly and thought that's what Hellfire M. was saying here, but he actually changed the 1t for the roll to be [[1d1]]t, which is slightly more obnoxious to do: <a href="https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0/?pageforid=7885024#post-7885024" rel="nofollow">https://app.roll20.net/forum/post/7883386/recursive-tables-rt-output-returning-0/?pageforid=7885024#post-7885024</a> I found a solve, albeit a very complicated and tedious one. After trying the test table I found that most results were occurring as 0 when the die roll wasn't specified; [[1t[MagicItemTableI]]] so I changed it to [[[[1d1]]t[MagicItemTableI]]] and that seemed to fix the issue mostly but it still occurs rarely, I tried with simple inline table rolls and the error seemed to not occur at all, maybe the API hits the MB limit for processing and returns a failed result when it gets too complicated and crowded. Then a bit further in the linked threads you can see there was some more exploration by The Aaron about the random '0' value that can appear with rollable table results: <a href="https://app.roll20.net/forum/permalink/6778723/" rel="nofollow">https://app.roll20.net/forum/permalink/6778723/</a> So, I've built out a much more complicated reproduction script.&nbsp; The key appears to be a pattern where you have: [[XdX]] [[ [[XdX]]t[table] ]] [[ Xt[table] ]] That is, some number of regular dice rolls, has to be at least one, followed by a rollable table with a nested inline roll, at least one, followed by a rollable table without a nested inline roll, at least one. The more of the first there are, the more likely it will happen.&nbsp; With 9 [[XdX]] types followed by 1 each of the other 2, it has always exhibited the issue for me in test. 1 it happens ever so often, with 3-5 it happens most of the time. So unfortunately I don't think this has been solved yet, and it's possible that whatever macros you were using were excessively triggering this bug/quirk of rollable tables.