SUPPORT-17888 Story Template issue involving Callout Internal Ref w Custom Naming

Already submitted a support request, but re-posing here per instructions.

Can you combine Callout Internal Referencing and Custom Naming? (it almost works, see below)

Say you have tables: [Table B C] with two columns, and b and c, each with a single column.

Call table b and c:
[b] > prints B
[c] > prints C
Call Table B C using Callout Internal Referencing:
[Table <b> <c>] > prints col1 col2

If I Call [Table B C] in the story template directly, the row and cell names work as expected:
[:Table B C:row] > prints col1 col2
[:#row|1#:cell1] > prints col1
[:#row|2#:cell2] > prints col2


<cell1> > prints col1
<cell2> > prints col2

Now I want to use Callout Internal Referencing in conjunction with Custom Naming (seems to work):
[:Table <b> <c>:row] > prints col1 col2
<row> > prints col1 col2


However, when I try to access the columns, this is what I get:
#row|1# > doesn't print col1, but instead prints NO DATA IN COLUMN 1
#row|2# > doesn't print col2, but instead prints NO DATA IN COLUMN 2
Which then prevents me from naming the cells from the row as before:
[:#row|1#:cell1] > prints col1
[:#row|2#:cell2] > prints col2

If not supported, can it be added/fixed?
Or suggest an alternative?
One alternative which I'm loath to try is to enumerate the combinations of table B and C as part of the original table with two columns by adding columns for tables b and c.

BONUS feature requets:

1) Have the ability to specify a fallback table to use when the resolved Callout Internal Referencing table doesn't exist. Maybe with a syntax like:
[Table <b> <c>!Default Table <foo>!Default Table <bar>!...!Default Final] so if [Table <b> <c>] doesn't resolve to an existing table, it would check for [Default Table <foo>] and then [Default Table <bar>] etc and stop checking at [Default Final] (and allow us to name the results using the existing syntax in combination [:...:name])

2) Also, might be useful to be able to do counters like so:
[:0:X] > prints 0 (already works)
[:[<X>]!0:X] and/or [:<X>!0:X] > prints 0 (initializes name X with value 0 if it doesn't already have a value and doesn't resolve to a table name)
[:[<X>+1]:X] > prints 1 (sets name X with the result of resolving [X+1], the general form would be [X+n] )

I moved this to the House of Healing forum.

I can't answer your question since I don't really understand the intricacies of the stuff that was added to the template behaviour. The only person that does I think is the author of the original extension. Since he's unlikely to see this post you might want to ask in this thread https://www.fantasygrounds.com/forum...ion-for-Unity)

Thanks - posted to the thread you recommended, but no luck.

Sorry this took me a while to get back to you – but I have a couple of suggestions.

First, while it wasn’t specifically a feature of the upgrade to do exactly what you’re asking, it’s also interesting that it doesn’t. I will poke around in the code.

Second, I recommend trying two different ways to approach this in the meantime – perhaps you can use cross template referencing in conjunction. It’s useful to know that all cross template references are resolved BEFORE regular references or callouts.

Another thing you might be able to try is creating a “ pre-loader“ template that runs the numbers first before you load the final template and use them with a cross template referencing. you might be able to do the first half of the rolling in the pre-loader template for instance, and do the second half in your final template.

Since I don’t know exactly what you are trying to achieve, I don’t know if those suggestions are helpful or not – but I use them a lot when I run into a brick wall.

As for your feature suggestions, those are pretty complicated to the end-user. Although I see people using these features to their fullest extent and surprising me in the ways they think to use them, I also think I’ve hit a soft limit to the complexity that should be baked in. Fallback tables are a neat idea, though with careful table design and structure they shouldn’t be absolutely necessary. I’m always grateful for more ideas though – so don’t hesitate to bring them up if you think of them!

Appreciate your reply. What I'm trying to do is to reduce the cross-product of combining multiple tables into a single table by deriving table names based upon table rolls. So instead of having to have a combined [Race] table that includes geneder, I can have separate [Race Male] [Race Female] tables with a separate [Gender] table so that only the gender specific values are in the [Gender] table (like pronouns) while the [Race Male] table can reference other tables that are specific (like [Elf Male Name] and [Elf Female Name] tables) - the notion of a default table could be used when there isn't a race-specific set of tables for names, for instance, but can be worked around by creating a [Default Name] table and referencing it instead of a race-specific table.

I've also discovered some creative ways of using tables in conjunction with story templates, so that in a story template, I can have a variable number of entries like [1d4x][Table] where [Table] has a single row like: <li> [Tables] </li> where [Tables] generates a random entry. The result is a bullet list of 1-4 entries :)

Hey I just stumbled upon this thread again- and you can absolutely do the race table thing. [:[Race] [Gender] Name:CharacterName] for instance, would resolve your [Race] table first (let's say it rolled "Elf"), your [Gender] table second (let's say it rolled "Male"), and then roll on the resulting table [Elf Male Name] and store that inside <CharacterName>. From then on, if you reference <CharacterName>, you will get whatever Male Elf name you dug up from that table earlier. Still no "fallback" table, but your [Default Name] table is exactly what I would prescribe here too.