Random select from multiple tables within a single external file

Comments

• SSlothy

  January 4

  Sorted I had missed out a few things like the table name in the generator and the leading | in setting the {quest} variable.

  All working now, and just in case any other noobs have a similar issue, here is my working code.

  use: common\nbos\quests\quest1.ipt
  
  Table: thequest
  set: quest=[|[!dungeonhooks]|[!royalquests]|[!forestquests]|[!doorways]]
  {quest}
  
• jjdale

  January 5

  That's a valid approach, and you could also get exactly the same results from:

  use: common\nbos\quests\quest1.ipt
  
  Table: thequest
  [!dungeonhooks]
  [!royalquests]
  [!forestquests]
  [!doorways]
  

  This way would be easier if you wanted to weight them differently. Your way might be better if you are going to use that variable somewhere else as well.
• OOldeMusicke

  January 5

  In addition, there's a key difference between inline choices [|one|two|three} and listing them on separate lines of a table: IPP evaluates all the inline choices, but not all the table entries.

  That can make a difference when you're using deck pulls (the [! notation) and working with variables. In the notation you're using, you're using up a deck pull in all four quest tables. Maybe that's no problem for your current needs, but I point it out just in case.

  Here's an example:

  Table: Test
  [|[!dungeonhooks]|[!royalquests]|[!forestquests]|[!doorways]]&
  \nYour first quest is quest type #{quest}.&
  [|[!dungeonhooks]|[!royalquests]|[!forestquests]|[!doorways]]&
  \nYour second quest is quest type #{quest}.
  
  Table: dungeonhooks
  There's a dungeon.{quest==1}
  
  Table: royalquests
  The king commands.{quest==2}
  
  Table: forestquests
  There's a tree.{quest==3}
  
  Table: doorways
  There's a door.{quest==4}
  

  I show five runs of that file below. The first thing to note is that no matter which quest table it uses, the quest variable is always set to 4. That's because IPP is running all four choices before picking one. The variable will always be set to 4 because that's the last one it runs. The second thing to note is that the deck pick used up an entry in all four tables. In my example here, each table has only one quest, so the second quest never has any output.

  The king commands.
   Your first quest is quest #4.
   Your second quest is quest type #4.
  
  There's a door.
   Your first quest is quest #4.
   Your second quest is quest type #4.
  
  The king commands.
   Your first quest is quest #4.
   Your second quest is quest type #4.
  
  There's a dungeon.
   Your first quest is quest #4.
   Your second quest is quest type #4.
  
  The king commands.
   Your first quest is quest #4.
   Your second quest is quest type #4.
  

  If I implement this as a table selection as jdale shows above, both problems go away.

  But if you're calling just one table and then you're done, the difference won't matter in your particular case. The difference will matter only if you could make further calls to generate quests or if you'll do anything with variables created by the quest tables after you've chosen the quest.
• OOldeMusicke

  January 5

  Here's the method suggested by jdale. In this case, the quest tables are the same as they were before, but now I'm using a table selection instead of an in-line choice to pick one.

  Table: Test
  [!Pick a quest]&
  \nYour first quest is quest #{quest}.&
  \n[!Pick a quest]&
  \nYour second quest is quest type #{quest}.
  
  Table: Pick a Quest
  [!dungeonhooks]
  [!royalquests]
  [!forestquests]
  [!doorways]
  
  Table: dungeonhooks
  There's a dungeon.{quest==1}
  
  Table: royalquests
  The king commands.{quest==2}
  
  Table: forestquests
  There's a tree.{quest==3}
  
  Table: doorways
  There's a door.{quest==4}
  

  Here are five runs of the above. It gets everything right because IPP invokes only the quest table it chooses instead of running all four of them before it chooses. The quest variable always has the expected value, and there's always a first and second quest.

  The king commands.
   Your first quest is quest #2.
   There's a dungeon.
   Your second quest is quest type #1.
  
  There's a tree.
   Your first quest is quest #3.
   The king commands.
   Your second quest is quest type #2.
  
  There's a dungeon.
   Your first quest is quest #1.
   The king commands.
   Your second quest is quest type #2.
  
  There's a dungeon.
   Your first quest is quest #1.
   There's a door.
   Your second quest is quest type #4.
  
  There's a tree.
   Your first quest is quest #3.
   There's a door.
   Your second quest is quest type #4.
  
• SSlothy

  January 5

  Thanks for the help, this is awesome. I can see where all variances could be used, so will keep these at snippets for future use.
• jjdale

  January 6

  I didn't realize the inline options all got evaluated like that. Thanks OldeMusicke!

  I tend to use inline tables mainly to add some variety to adjectives.
• SSlothy

  January 6

  So reading more in to this, would I be better to have all the quests under a single table rather than being split down to into the different types.

  I noticed that I sometimes get blank lines returned, could this purely be the new line between the tables in the external file?
• OOldeMusicke

  January 6

  Merging or not merging depends on what you want from the tables. If you merge the quests into one table, you can weight individual quests as you see fit. If you'll call the merged table multiple times (within one run) using the [! deck pick notation, you'll get a different quest each time, but you might repeat types.

  A potential advantage of breaking them down by type would be if you want variety among the quest types, or if you want to weight quests by type (royal quests less common than dungeon quests, for instance). [!Pick a Quest] would get a different quest type each time you call it (until you run out of quest types). Merging the quest types means you could wind up with a few forest quests in a row, but maybe that's fine for your purposes.

  Blank lines can result in a few ways. I consider this first way a quirk, but not a bug. Consider this example:

  Table: Test
  hello
  
  Table: Another Table
  

  If I call Test 10 times, I get "hello" 10 times.

  But compare it to this example:

  Table: Test
  hello
  
  Table: Another Table
  

  They look identical, right? If I call this version of Test 10 times, I get a mix of "hello" and blank lines. The difference is the line between "hello" and the start of the next table. In the first example, the empty line is really empty. In the second example, the "empty" line has a space in it, so IPP considers it another entry in the table. Tip (for the Windows version): Hit the End key twice on a seemingly blank line. If the line is really empty, the cursor stays at the left end of the line. If there are trailing spaces, however, a second hit of the End key jumps to the true end of the line, after the spaces.

  Another way to get blank lines is when you have a lookup or dictionary table. If the index value doesn't have an entry and there's no default entry, you get a blank result.