[BUG] Viewing a table that calls another has Script execution error

[Lonewolf]

I am investigating why when some 3ML created tables are opened this error message appears in log.

[ERROR]  Script execution error: [string "CoreRPG:campaign/scripts/table_main.lua"]:168: createWindow: Unable to create window

Note the table still works as intented.
Here is 3ML to create the error:

--------------------------------------------
### Cave Encounters
@@hiderollresults::#1
@@output::story
@@resultscols::#2
@@tablerows.*.fromrange::#1
@@tablerows._.results.*.result::A shallow, empty cave, unoccupied and available as convenient shelter.
@@tablerows._.torange::#2
@@tablerows.*.fromrange::#6
@@tablerows._.results.*.result::Deeper tunnels. The cavern goes far beyond the entrance. Roll again on the chart below if the group decides to delve farther.
@@tablerows._.results.*.result::[Cave Encounters 2]
@@tablerows.*.fromrange::#5
@@tablerows._.results.*.result::A shallow, occupied lair. As above, but the creatures are home and aren’t happy to be disturbed.
@@tablerows.*.fromrange::#3
@@tablerows._.results.*.result::A shallow, unoccupied lair. Scattered remains show a local creature sometimes rests here. Check the animals and monsters for the appropriate domain for an idea of what it could be.
@@tablerows._.torange::#4

--------------------------------------------
### Cave Encounters 2
@@hiderollresults::#1
@@output::story
@@resultscols::#1
@@tablerows.*.fromrange::#1
@@tablerows._.results.*.result::Maze. The characters are lost in dark and winding corridors for 1d6 hours. Make a new Survival roll to try again.
@@tablerows.*.fromrange::#2
@@tablerows._.results.*.result::Abandoned refuge. There is evidence (items, cave paintings, statues) that someone was here before, but they are long gone now. Draw a Forces card to see who the former occupants were.
@@tablerows._.torange::#3
@@tablerows.*.fromrange::#4
@@tablerows._.results.*.result::Occupied refuge. As above, but the residents are home and waiting to ambush any unwelcome intruders.
@@tablerows.*.fromrange::#5
@@tablerows._.results.*.result::Treasure. Long ago someone hid a magic item, martial manual, or 2d6 x 1,000 silver down in the darkness!
@@tablerows.*.fromrange::#6
@@tablerows._.results.*.result::Haven. The tunnel system leads to a hidden and mystical space. See Hidden Havens

Table 1 is rolled and the result out goes in a new story window. There is a 1 in 6 chance that the second table will be rolled on. This adds to the story window.
The only problem is looking at table one will produce the error. The table will function but just the act of looking at the table produces an error. Why?

[Moon Wizard]

It's the fact that in the database the top-level table record states that there are 2 columns in the table, but the individual row data only has 1 column. Changing the "@@resultscols::#2" to "@@resultscols::#1" in the first table should fix.

Regards,
JPG

[Lonewolf]

It's the fact that in the database the top-level table record states that there are 2 columns in the table, but the individual row data only has 1 column. Changing the "@@resultscols::#2" to "@@resultscols::#1" in the first table should fix.

Regards,
JPG

The second column does have data

@@tablerows.*.fromrange::#6
@@tablerows._.results.*.result::Deeper tunnels. The cavern goes far beyond the entrance. Roll again on the chart below if the group decides to delve farther.
@@tablerows._.results.*.result::[Cave Encounters 2]

On 6 there is data in each column. The same table can be created in builder. Some blank rows are fine and the still table works.

[Moon Wizard]

But, you only have the second column defined for one row; not for the other rows in the table.

Regards,
JPG

[Lonewolf]

But, you only have the second column defined for one row; not for the other rows in the table.

Regards,
JPG

Yes indeed. The natural conversion from builder to mark up will create a table that does not work. To avoid this a least one character must be added where there is blank space on the table to fix. It is not required for builder but is required for Module Maker.

Test table:
1 Builder can have a null value on a table and it will still work. However here I added a dash to blank space before creating markup. The result is correctly formatted table. A double result for evey row and simply prints a dash character to represent a null value when using Module Maker.
2 has just been converted without adding this dash. Here the output creates a bad table. With script table_main.lua execution error open on opening. The table will still work as expected after that.
3 Is the same as two but shows that a just adding an extra results line with no dash will also create a bad table. Again with script table_main.lua execution error on open opening. The table will still work as expected after that.

Module Marker can't have null results but this is ok in Builder-UI.

@@name::Test of table imports2
@@categoryname::Experiment
@@author::Lonewolf
@@file::Table_Test2
@@readonly::#1
@@playervisible::#0
@@anyruleset::#0

============================================
#### Tables :: Tables

--------------------------------------------
### Test 1
@@hiderollresults::#1
@@output::story
@@resultscols::#2
@@tablerows.*.fromrange::#1
@@tablerows._.results.*.result::Result 1
@@tablerows._.results.*.result::[Test 1]
@@tablerows._.torange::#3
@@tablerows.*.fromrange::#4
@@tablerows._.results.*.result::Result 2
@@tablerows._.results.*.result::-
@@tablerows._.torange::#6


--------------------------------------------
### Test 2
@@hiderollresults::#1
@@output::story
@@resultscols::#2
@@tablerows.*.fromrange::#1
@@tablerows._.results.*.result::Result 1
@@tablerows._.results.*.result::[Test 1]
@@tablerows._.torange::#3
@@tablerows.*.fromrange::#4
@@tablerows._.results.*.result::Result 2
@@tablerows._.torange::#6

--------------------------------------------
### Test 2
@@hiderollresults::#1
@@output::story
@@resultscols::#2
@@tablerows.*.fromrange::#1
@@tablerows._.results.*.result::Result 1
@@tablerows._.results.*.result::[Test 1]
@@tablerows._.torange::#3
@@tablerows.*.fromrange::#4
@@tablerows._.results.*.result::Result 2
@@tablerows._.results.*.result::
@@tablerows._.torange::#6

[Lonewolf]

I have been thinking user error all through testing. I am big fan of debugging users before touching code In Builder a user could just cannot not put in an empty field into a table field and get away with it. The default value is set as -- by UI and must be typed over with other data. Its a rare edge case where a table would need an empty field. It can be avoided most of the time with better table design. It only comes up when converting card based encounter systems to dice. If there absolutely no way to avoid putting in an empty field then @@tablerows._.results.*.result::-- does the same trick in MM. So there the proof that problem is between my chair and keyboard