Hi all,
I have a table to generate spell scrolls, and there's a 50/50 chance that the spells are clerical or magical. I've assigned 'clericSpells' or 'magicUserSpells' to a variable ($spellbook), then roll on the scroll table:
Set: spellbook = [|clericSpells|magicUserSpells]
<p>Scroll: [@2 {$spellbook} >> implode] </p>
This works properly and rolls twice on the appropriate spell table to give me a scroll with two cleric or two magic-user spells.
However, I want to limit the spell levels, so I revised the code with a built-in die roll:
Set: spellbook = [|clericSpells|magicUserSpells]
<p>Scroll: [#{1d2} {$spellbook}] </p>
This should give me a single clerical or magic-user spell of 1st- or 2nd-level. Instead, IPP throws a missing table error. If I replace the variable {$spellbook} with the actual table name (i.e., "clericSpells" or "magicUserSpells"), I get a spell as expected.
Is there a bug that prevents using variables in the [#n <tablename>] structure or do I have to assign the variable in-line?
Cheers,
Comments
Having said that, here's something I discovered by accident. You're correct that the following code doesn't seem to work: (by the way, the "$" before spellbook is unnecessary; doesn't hurt, but I don't like it)
Weirdly, this mostly similar code works just fine: I guess the ">> implode" forces IPP to recognize that you really are talking about a table.
Old habits die hard - I still use it to help me recognize vars. Plus, the "$" is important for the user-defined language filter I use in Notepad++ to highlight vars with colour-coding...
The "implode" issue (if it could be called that) goes back to our previous conversation. It's another minor weirdness - as long as the table is being called (even if via a variable), I'm not sure why it's necessary.
Perhaps another bug for Ed's attention? But thanks for the verification - at the very least, we have two data points on this subject.
Cheers,