Tables - Lua Stack capacity differences between FGC and FGU

[EOTB]

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.

[Minty23185Fresh]

@EOTB
My first inclination regarding the stack overflow is not that Smiteworks has purposely limited the stack size, but that because FGU seems to put so much more demand on the OS that default stack size has taken a hit.

I’d like to help. My PC is an older one and FGU puts the poor old dog through some strenuous exercises. Do I need to do anything besides load the .mod files you’ve included in a new campaign. And the possibly peruse the tables?
i.e. what specific steps do I need to do to trigger the issue?

[EOTB]

Hi Minty,

The modules contain the test tables and the gem items, with nothing else. I cut these out of the main OSRIC Treasure dev folder to make it easier to recreate the issue. All you should have to do is create a 2E campaign in FGU and activate the FGU test module. The top level test tables are at the top "00 Gemtest" which does contain the looping variance table, and "00 Gemtest no loop" in which the looping variance table is not connected.

Edit - I just updated the Gem test mod for FGU, as I apparently forgot to pull the "00 gemtest" tables into it, and while I'd changed the file name the module name was still the OSRIC treasure mod name - it's now mod-named "OSRIC gem test"

Apologies to anyone downloading the earlier version and suffering some confusion!

[Zarestia]

Looks like the overflow is coming from the chat / oob script. If that is really the cause, a checkbox to not display the rolls in chat might be the easiest solution for now (meaning no physical dice rolling).

[jharp]

*ahem* Insta-Dice might help...

[EOTB]

*ahem* Insta-Dice might help...

This is true, at least for the initial objective of avoiding sub-table die rolls. (Not sure if it cures the lua stack problem additionally). I'm sure the extension is great - I mean that sincerely - but I wanted the full functionality of OSRIC to be both free and in a smokin functionality. So when I went through and QA'd I redid the tables this way so that it wouldn't suck to use the deep table pulls if someone didn't buy the extension. The table redos are already complete on all the OSRIC mods, I just haven't uploaded them yet to the forge pending this review.

[jharp]

This is true, at least for the initial objective of avoiding sub-table die rolls. (Not sure if it cures the lua stack problem additionally). I'm sure the extension is great - I mean that sincerely - but I wanted the full functionality of OSRIC to be both free and in a smokin functionality. So when I went through and QA'd I redid the tables this way so that it wouldn't suck to use the deep table pulls if someone didn't buy the extension. The table redos are already complete on all the OSRIC mods, I just haven't uploaded them yet to the forge pending this review.

Sorry, yes it was only in relation to the graphical dice roll. *i'll slink off now*

[EOTB]

Your extension is awesome Jharp! if I played a bunch of different games I wasn't making content for, I'd buy it in a second.

[Moon Wizard]

As noted in further Discord discussion,
* FGU uses the same exact external library (DLL) as FGC.
* The main difference I can think of is UTF8 support in FGU vs. ASCII only in FGC, but not sure if this is relevant.
* Investigating this sort of issue is fairly time-consuming, so I'll need to find time to schedule future time for investigation to see what I uncover.

Regards,
JPG

[Moon Wizard]

The latest v4.2.0 beta build has reorganized handling of dice rolls without 3D physical dice to be cached to prevent the stack overflow condition.

Regards,
JPG