Story Template Output Troubles

[Frankison]

Hello, I have spent an incredible amount of hours tinkering with the various options in Story Templates, and I feel like I have a pretty good understanding of what works and what doesn't. I am perplexed however as to why the bottom example is not working.

Template Data
Race Ability Roll: [:NPCG Ability Score Rolls <Race>|2:STRr]
Class Ability Table: [:NPCG Ability Score STR <Class>:CSTR]
Exceptional Strength Table: [:NPCG Ability Score PSTR:PSTR]
Class Ability Result: [:#CSTR|<STRr>#:STR]
Ability Call Back: <STR>
Exceptional Strength Call Back: #PSTR|<STR>#

Template Output
Race Ability Roll: 5
Class Ability Table: 9 9 9 9 9 9 9 9 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Exceptional Strength Table: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (69) 0 0 0 0 0 0 0
Class Ability Result: 9
Ability Call Back: 9
Exceptional Strength Call Back: #PSTR|9#

For some reason the last step in the column number calls back correctly but not the table.

I included a screenshot of an example.

[JimSocks]

Super-niche and complicated examples are hard to sus out where they are going awry without an intimate knowledge of the structure of all the tables involved unfortunately.

Though it looks like your last call differs from all the others a bit, though I can’t definitively say that’s the issue here.

Try using a cross-template storage/reference combo, even if you aren’t planning on using the data in another template. Cross-template data takes a different path than regular callouts/references, and sometimes that can be just what the doctor ordered.

[Frankison]

I played with cross-templates for a while but I could not get them to do what I needed either. I admit I'm not extremely savvy on those but I could get basic features to work. I've watched your video many times and I found it very helpful.
That Said, This screen shot should help you understand what I'm trying to do and the logical things I've tried that I feel should work. I kept the tables very simple so you can see what I'm trying to do.
Essentially I have 3 tables;
Table A is the roll.
Table B is the stat result from the roll.
Table C is any bonuses from the results of table B.

Its the table C output that I can't get to work no matter what I try.

[DCrumb]

Wouldn't your Table C formula look very similar to your Table B formula, so {:#<c>|<d>#:e}? Storing the bonus result into a variable e? Therefore your stat would be in d, and the bonus in e?

[Frankison]

{:#<c>|<d>#:e} Will just store the data as {e} for later use.
Also the <c> is not the correct syntax. I just put that because I was trying every combination just to make sure I didn't miss something.
#c|<b># should be the correct syntax as that calls the table and its asking for the column from the results of table B.
I can't even get the story templet to output the result.
Third Tier reference just doesn't seem to work.
I have tried every combination of <> #|# {} {#|#} {:#|#:n} that I can think of.
Right now the only solution I have is to have a table that rolls The Class and Race together.
This gets pretty crazy as I'm sure you can imagine. If you have say 6 Races that's 6 Tables just for Fighter.
This also makes it very difficult if not impossible to have a story template roll for a random race. Not a huge deal but it would be a nice feature to include.

I also want to clarify that screen shot is just a quick example. This story template is for AD&D 2e. Character classes have a lot of parameters that I'm trying to include based on RAW.
Races have Ability Bonuses and Penalties.
Classes have minimum ability requirements.
Warriors have different HP and STR bonus's than non-warrior classes.

Anyway if its not an option that can be added or clarified for me, I'd like to know so I know that I need to commit to making race/class ability tables for every race/class combination.

[Frankison]

Good afternoon I wanted to revisit this as there has not been any viable solution recommended nor any updates.

I played with Cross Template Storage as much as I could figure out based on the videos I was able to find. The examples provided did not solve any of the issues.

The real problem seems to be that I cannot use a table column to call out a specific column in another table. No matter how I try it I just get one of two errors,

A straight up table call out returns the following: |!!|!|Table B Stat Bonus|8|!|!!|

and a cross reference either says No Stored Data or #Bonus|8# depending on how I attempt to use it.

I feel the examples I have given above more than explain the issue I am having, and are simple enough to replicate the issue.

Can I please be notified if this is being looked into or if I should just assume there will be no fix.

v/r,

Frank

[Frankison]

It saddens me that this is being ignored. :cry:

[Moon Wizard]

You should PM JimSocks directly. He provided and supports the feature.

Regards,
JPG

[Zacchaeus]

It saddens me that this is being ignored. :cry:

Sorry but the only person who really understands these things is JimSocks and he's not around a lot anymore as far as I can see. I'd do what Moon Wizard suggests and hope that he gets back to yiou.

[JimSocks]

TLDR: So, this isn't something the system was built to support.

Namely, you are trying to do too many things in the same template in a row, also in an order that isn't going to work even if it was set up to support doing all those operations in a row. Your chief problem is when you try to use #column|references#, the order in which those are resolved isn't going to work with what you want to do, especially with how cross-template references are resolved as well. You see, it does things in a very certain order of operations, and some things only work in that order- sort of like PEMDAS if you are into math stuff. Also because of the order, some things won't work at all because the system has to store values and hold them in reserve while checking and replacing others before printing the stored values. It's all a complicated dance to get them to all work in concert, but I have done my best to recurse the most used operations in order to make this transparent for the vast majority of users.

Additionally, the WAY in which cross-template data is stored (in conjunction with it's order) means it's storing the EXACT phrase "#b|<a>#" and NOT what those resolve out to- because again: the order of operations. Try to call {d} in another template, and you'll see what I mean. It looks like it's resolving fine in your single template, but that's a trick being played on you by the order of operations- {d} spits out #b|<a>#, which is later resolved and appears to look just fine- but that number was NOT stored in {d}, it was the exact phrase "#b|<a>#" instead! (but WHY doesn't {:#b|<a>#:d} resolve the column reference, you might ask- again, this is because it's not TIME YET to do that in the order of operations- cross template resolving comes way beforehand, so it just stores the raw "#b|<a>#" text as {d} )

What you can do, is either roll on half the things in a pre-loader template (a story template who's only purpose it is, is to roll and store values for other templates to use), and call those using cross-template referencing in your main templates, or make lots of tables instead. In the Campaign Generator mod I am making, I choose the former of these two options once right at the very beginning, but then in several internal templates I choose the latter just because more than one pre-loader template is clunky to the user so I do all the table work on the back end so they don't have to deal with that. You are correct, this can result in a lot of tables- but it can still be random with some clever ordering and tables calling other tables. Here is one more super sneaky trick you can toy with to try to outsmart the order of operations- I use it to great effect and it helped me get around some interesting order of operations problems, but again it relies on using a pre-loader template:


{:Region Race:Main City Race}
{:MC Racial Variation Words:MRacial Noun}
{:?<MRacial Noun>:MC Racial Noun}

In the above example- [Region Race] spits out a race, let's say "Gnome". That gets stored in a cross-template reference as {Main City Race}. Next, the table [MC Racial Variation Words] only has one result possible inside of it- a line that reads: [{Main City Race} Variation Words] as it's only table item- so [MC Racial Variation Words] essentially also has a cross-template reference inside it's results that was JUST rolled and stored one line earlier. That is then stored in MRacial Noun, which is IMMEDIATELY referenced in the next line. Then I store that inside MC Racial Noun for use elsewhere. Now, because of the order of operations, if I re-order these lines at all this will NOT work- it has to go in this order. Furthermore, if I try to call {MC Racial Noun} or {#MC Racial Noun|4#} in this same template- it won't work, either! However, if I call either of those in a NEW template, then I get "Gnomish", or whatever racial noun I stored with all that trickery earlier.

So to recap, when the system parses your story template for things to take action on- it does so in the following order I spoke about above (see next post). The "PEMDAS" below might help you to understand the "why" behind why some things work while others may not... or maybe this will come out as senseless gibberish that won't help you at all, but perhaps might help someone else as time goes on.

I know this isn't what you hoped to hear, but your use-case just isn't supported by the code, as it's trying to do too much in the same template, in an order which isn't going to work. Apologies for not being swift on the investigation, but work has me sent off to a land far far away for awhile.

[JimSocks]

Story Templates Order of Operations:
The "PEMDAS"-like list below might help you to understand the "why" behind why some things work while others may not. This is how Story Templates work to parse your text and give you a beautiful Story Output- in this EXACT order. This could affect you for instance, if you try to put a column reference inside of a cross-template callout, as detailed in the post before this one. The order doesn't allow for that, because cross-template callouts are resolved first. Here is the order, in order:

*Each of these steps is also resolved TOP to BOTTOM in your text. In other words, lines you write below are affected by/processed after the lines existing above them in your body of text, within each respective step outlined below.

Cross Template Write in the template title area
Cross Template Write in the main body of text


(so, the first two things it does is look for callouts to store cross-template values you can reference later in this same template, or in another somewhere else. NOTE that from this point on, your template will no longer have ANY cross-template callouts in it until later when a table might dredge one up. Also note how it does the title area FIRST in a lot of these operations- it treats the title almost as an entirely separate entity- and that can be used to your advantage sometimes!)



perform Callout Storage References in the template title area
perform Callout Storage References in the main body of text


(so, next it looks for references to cross-template data to replace in the text. At this point on, there will now be NO cross-template references left until later when a table might dredge one (or thirty) up.)



replace Date in the title
replace Date in the main body


(now it's looking for date callouts, and replacing them with what the user wanted)



perform Internal Callouts in the title
perform Internal Callouts in the main text


(these are looking for callouts nested within callouts, and replacing them first. ie [:a [tableA] and [tableB] inside a parent:StorageName])



perform Internal References in the title
perform Internal References in the main body


(now it's looking for references nested within any table callouts. ie: [a <tableA> and <tableB> inside a parent] NOTE: It doesn't solve these yet- it can't. Instead, it saves them for later along with the whole table. If you ever get a result like "|!!|!|Table text|!|!!|", you can be sure you are having a syntax issue with either this exact step, or it's brother later on. NOTE: This ALSO is looking for #column|references# that are stored inside table callouts, and does the same thing with them, too- storing the whole enchilada for later solving.)



perform Table Lookups in the title
perform Table Lookups in the main body


(NOW we get to rolling on regular tables that are left, since the things nested within them (cross-template stuff and internal callouts, at least) should be resolved now, leaving us with regular table names. But what if those tables spit out cross-template callouts or references!? That's why the next things up are...)



Cross Template Write in the title
Cross Template Write in the main body text


(Again! Here we resolve storing cross-template goodies that came out of our tables. Of note- this is the LAST TIME your text will be checked for things you want to WRITE into a cross-template storage value. If you try to store anything after this into a cross-template storage spot, it won't work.)



perform Callout Storage References in the title
perform Callout Storage References in the main body text


(And this again too! Because tables can dig up cross-template references too, and this will resolve them. This will NOT be the last check for retrieving cross-template references you stored earlier- we get more chances for that below again.)



perform Column Reference Links in the title
perform Column Reference Links in the body


(Here it's looking for the #column|References# you might have lying around all by their lonesome, and resolves them. Note that cross-template ones were done way earlier, this is just for regular ones.)



perform Literal Replacements in the title
perform Literal Replacements in the text


(Don't worry about this step, but it's here. This just cleans up some code so it reads itself correctly. Code doesn't like some symbols, and this makes sure it turns a blind eye to them. The only way this might be an issue for someone, is if they start using really non-normal ascii characters in their table names or callouts. Don't do that.)



resolve Internal References in the title
resolve Internal References in the main text


(NOW it solves the internal references from earlier. Because of some physics involved, this was the best way to crack this nut. This is the other place you might hunt down an issue where your output has |!!|!| in it, as this is the brother we talked about earlier. Usually issues here have to do with syntax like odd ascii characters.)



perform Callout Storage References in the main body text
perform Callout Storage References in the main body text AGAIN


(Now it looks for references to cross-template data to replace in the text TWO MORE TIMES. Yes, this is entirely on purpose. When tables start digging deep, you need these additional checks. It comes up more than you might think, and I have had folks ask me for MORE recurses of this so they can have their tables dig even deeper. In the future if I get enough requests for this, I may add the extra recurses as it doesn't cost much processor-wise by this point- but for now it's just two re-looks here. Of note: This is the very last time a table or reference will be resolved anywhere.)



perform Link Replacements in the main text


(Find anything you intended to be a link, or that came out of a table and was supposed to be a link, and well... make it a link)



perform Indefinite Articles in the title
perform Indefinite Articles in the main body


(Look for areas the user wanted correct articles placed into the output, and make those pesky buggers right!)



perform Capitalize in the title
perform Capitalize in the main body


(Lastly, look for areas the user thought a table result might start a sentence, and capitalize it if it actually ended up doing so)