-
August 1st, 2023, 00:55 #1
[BUG] Viewing a table that calls another has Script execution error
I am investigating why when some 3ML created tables are opened this error message appears in log.
Code:[ERROR] Script execution error: [string "CoreRPG:campaign/scripts/table_main.lua"]:168: createWindow: Unable to create window
Here is 3ML to create the error:
Code:-------------------------------------------- ### 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
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?Ultimate License holder.
Over 10 years on Fantasy Grounds !
-
August 1st, 2023, 18:09 #2
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,607
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
-
August 1st, 2023, 20:31 #3
The second column does have data
Code:@@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]
Ultimate License holder.
Over 10 years on Fantasy Grounds !
-
August 1st, 2023, 21:55 #4
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,607
But, you only have the second column defined for one row; not for the other rows in the table.
Regards,
JPG
-
August 1st, 2023, 23:23 #5
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.
Code:@@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
Last edited by Lonewolf; August 2nd, 2023 at 00:05.
Ultimate License holder.
Over 10 years on Fantasy Grounds !
-
August 2nd, 2023, 13:58 #6
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
Ultimate License holder.
Over 10 years on Fantasy Grounds !
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks