EOTB
April 2nd, 2022, 20:43
Dungeons and Dragons (2E) campaign, no extensions
Background: first complete overhaul of the OSRIC data mods in an FGU environment (they were created in FGC), primarily to change the tables so all chained sub-tables no longer triggered a virtual dice roll (make d100 tables into d200 tables, etc.) and other misc Q&A for discovered errors.
Attachments: mods containing the tables used to test the issue, both in FGU where the problem was observed and in FG Classic as a control.
Issue: when running testing of the overhauled treasure tables, started experiencing LUA stack overflows errors nearly every time. The test table used was a random dragon hoard table, as it has a high change to pull from every type of treasure over a few tests when generating hoards; part of those tables is a 50% chance for 1d100 gems per dragon (up to 4 dragons appearing). The stack overflow cause was narrowed down to when the dragon hoard tables pulled on the gem treasure type tables, which nest into results for: 1) gem value class; 2) specific gem type within gem value class; and 3) individual gem value variance due to high/low "quality" (this essentially the the same gem value determination process existing in advanced versions of the game since 1979). If value variance results in a class step it can further nest into a reroll variance table which is possible (but very unlikely) to loop multiple times.
In discord discussion the first question raised was whether the step class reroll tables having a possible loop were causing the overflow. This is not the case. I created an isolated test table that called for 100 results from the top level gem table. Even with all looping disconnected I received a stack overflow 100% of the time I requested 100 gem results.
In FG Classic this same operation never caused a stack overflow. I went back to FGC, recreated the exact same test parameters, and called for a larger test of 400 results from the top level gem table (the max # of gems that the random dragon hoard(s) table could theoretically pull for 4 dragons encountered). To further ensure the max load was tested, the possibly-looping individual gem value variance tables weren't disconnected. FGC could provide these results without any stack overflows - I pulled 4 tests of 400 gem results; 4/4 no overflows.
There are no errors in table construction such as gaps in the rows, or numbers duplicated in the rows.
In further tests in FGU, on other broad/deep table chains such as caravan generation, I occasionally received stack overflows (~20% perhaps?). These tables also did not overflow in FG Classic. However since they did not trigger every single time in FGU as the gem tables do, I am providing the gem testing tables to isolate the issue.
Is this an issue to differences in FGU lua stack parameters as compared to a greater capacity in FG Classic, and if so can the capacity in FGU be made comparable to FG Classic?
Thank you in advance for any time spent exploring this anomaly.
Background: first complete overhaul of the OSRIC data mods in an FGU environment (they were created in FGC), primarily to change the tables so all chained sub-tables no longer triggered a virtual dice roll (make d100 tables into d200 tables, etc.) and other misc Q&A for discovered errors.
Attachments: mods containing the tables used to test the issue, both in FGU where the problem was observed and in FG Classic as a control.
Issue: when running testing of the overhauled treasure tables, started experiencing LUA stack overflows errors nearly every time. The test table used was a random dragon hoard table, as it has a high change to pull from every type of treasure over a few tests when generating hoards; part of those tables is a 50% chance for 1d100 gems per dragon (up to 4 dragons appearing). The stack overflow cause was narrowed down to when the dragon hoard tables pulled on the gem treasure type tables, which nest into results for: 1) gem value class; 2) specific gem type within gem value class; and 3) individual gem value variance due to high/low "quality" (this essentially the the same gem value determination process existing in advanced versions of the game since 1979). If value variance results in a class step it can further nest into a reroll variance table which is possible (but very unlikely) to loop multiple times.
In discord discussion the first question raised was whether the step class reroll tables having a possible loop were causing the overflow. This is not the case. I created an isolated test table that called for 100 results from the top level gem table. Even with all looping disconnected I received a stack overflow 100% of the time I requested 100 gem results.
In FG Classic this same operation never caused a stack overflow. I went back to FGC, recreated the exact same test parameters, and called for a larger test of 400 results from the top level gem table (the max # of gems that the random dragon hoard(s) table could theoretically pull for 4 dragons encountered). To further ensure the max load was tested, the possibly-looping individual gem value variance tables weren't disconnected. FGC could provide these results without any stack overflows - I pulled 4 tests of 400 gem results; 4/4 no overflows.
There are no errors in table construction such as gaps in the rows, or numbers duplicated in the rows.
In further tests in FGU, on other broad/deep table chains such as caravan generation, I occasionally received stack overflows (~20% perhaps?). These tables also did not overflow in FG Classic. However since they did not trigger every single time in FGU as the gem tables do, I am providing the gem testing tables to isolate the issue.
Is this an issue to differences in FGU lua stack parameters as compared to a greater capacity in FG Classic, and if so can the capacity in FGU be made comparable to FG Classic?
Thank you in advance for any time spent exploring this anomaly.