It looks like you're new here. If you want to get involved, click one of these buttons!
Is it possible to use variables as the weights for a weighted table?
I want to weight the alignments of generated NPCs by their class and race. For example as a test I tried:
Table: NPC
A [@race] [@class] of [@alignment] alignment. (DEBUG - L:{L}|N:{N}|C:{C})
EndTable:
Table: race
{N==9} {L==1} {C==1} human
EndTable:
Table: class
{N=={N}+9} warrior
EndTable:
Table: alignment
Type: Weighted
{L}:lawful
{N}:neutral
{C}:chaotic
EndTable:
I would expect this to generate a human warrior of Neutral alignment about 18 out of 20 times. Instead, it generates as if each was evenly weighted.
Is there a different way to accomplish this?
Comments
Not sure why that doesn't work, but this gives a somewhat similar result:
You can bias it towards law or chaos by adjusting N. But you can't decrease the chance of neutral while increasing both law and chaos.
You could of course use some When statements to implement any odds you want, it's just not as elegant.
Yes, I though of trying it that way but ran into problems as the races and classes intersected and caused the elimination of certain combinations with this method. The push towards chaotic eliminated law completely in order to reduce neutral. And it just gets worse when I add the Good-N-Evil axis. And I eventually wanted a bias for races to choose certain classes.
I have no idea at all how to use When statements to do this.
Being able to use variables as weights for a table makes it all so clean and straight forward. I really want to use IPP for this, so I wish I knew if it was possible and I just have the wrong syntax or if it isn't currently possible at all.
Here's how you would do it with When statements:
Since there are three conditions, and When really only checks for two, I assigned the alignment to a variable which can then be overwritten by one of the other conditions.
Note I had to put the assignments in square brackets. I think curly brackets only work for numerical values.
Variables can't be used as weights because the weight is parsed by the program as the generator is loaded, while the table item lines are only processed as they are encountered.
@Ed_NBOS - Thanks, that's good to know, saddening, but good to know.
@jdale - OK.. I can see how that would work. This will certainly help with other table ideas I have kicking around. Not sure I have the patience to figure it out across the 9 possible alignments and the plethora of race/class combinations for 5e.
Anyway, thanks for your help, it will help with other conversions if not this one.
I guess this is one table that won't get converted over from TS. I'll just upgrade it to work in TS5 instead.
That what I get for trying to reduce the volume of software I use at the table. Also, I really just wanted to have my TS tables available from within The Keep. Oh well, c'est la vie.
Here's a long, rambling piece of code that may help a bit, if I haven't made too much of a mess of it. And it probably won't execute because it's just a piece of the overall .ipt file.
So looking at the TrainMod and Training tables...
TrainMod: Larger settlements will not only have more horses available for sale, but also more likelihood of horses that have been trained for special purposes (warhorse, trail horse, etc.). That might be along the lines of cities of more likely have a few more elves, villages a few more halflings, or something like that. (Maybe). So, I set the variable at 1.00 for "par value" and and make it less than 1.00 for larger settlements, greater than 1.00 for smaller settlements.
Training Table: Before this table runs, I do some arithmetic when rolling for breed and gender, to give me a unique 2 digit code for every possible breed/gender combo, then lookup that calculated (not rolled) two digit value. Now on this table, I have a very large die to roll (d450, d500, etc.) depending on which breed/gender combo (i.e. your elves can skew toward good and/or chaotic, gnomes neutral or whatever you're trying to weight by selecting the size of the die. Then multiplying that die by TrainMod factor makes it a bit larger or smaller die, depending on how large a settlement it is.
So a warm-blood mare in a hamlet would be rolling d625, while a warm-blood mare in a metropolis might be rolling a d300.
Now then, when we get to the tables that follow (one for each breed/gender possibility; in your case maybe just one per race), the rarer possibilities are the lowest range of rolls on the table.
For instance a warm-blood mare is trained as a warhorse on a roll of 31-60. For sale in a hamlet, that is a 30 in 625 chance; found in a metropolis, that is about twice as likely as it is a 30 in 300 chance.
Now for my horses, there needs to be a very large range default result at the high end of the table. For the horses, it's simple "untrained". The larger the die that is rolled (d625), the more likely to find an untrained horse/the more rare a trained horse.
Now, if there is no default, most likely alignment, there are other ways. I can follow up with weighting of gem sizes from another generator. I'll do that in another post. It's ugly, but it solved the problem of skewing the roll to highs or lows that completely eliminate the possibility of rolling any one choice.
This code is not going to be quite readily adapted to your generator, but it might give you a direction to explore:
{Code in next post}
Code for horses part 1:
Code for horses part 2:
Next 9 tables are chance of specialty training, by gender and temperment
Here's the table for gem size. You see, it's a 1d100 roll. But that is modified in the line that calls the table base monster CR level. It could be 1d100 +0 up to 1d100 +180 (and there's also variability in the call beyond just simple CR).
So, while 1d100 +0 has: 40% small; 30% medium; 7% Large.
If the roll sent to the table is 1d100 +80, it will result in 0% small; 55% medium; 42% Large.
Basically, why would a high CR opponent be carrying around a small gem? But, I could have made 101-103 = small if I wanted a slight possibility of a small gem being found in a high level treasure stash.
And, apologies if this thread is way off the mark and not helpful.
@Levendor ,
This looks quite promising.
OK, the horse tables are just, Wow! I can see how that would work. And I think I can see my way through that to make a start on converting my table.
Just to make sure I'm reading all of this correctly though, in the Count table, the comments for city and metropolis are wrong, right?
I would think they should have been 10-80 and 20-160 respectively.
Anyhow, I'll give it a go with a small subset of the races/classes and post what I get for further comment.
The Gem table, by the way, looks like pure simplicity until I trued working out relative probability, but it gives me some ideas.
Thanks
Okay, here is the random adventurer sub-table collection that I have so far.
Sub-classes are not done at all yet. though they should be fairly easy as they will use the same format as sub-races. I'm using my Greyhawk setting's global values for distribution of races (instead of more accurate regional values) and currently, class choice is not-biased by race selected - which it really should be.
For the alignment determination, I used the dice multiplier idea from @Levendor and combined it (though perhaps inelegantly) with the conditionals idea I started on from @jdale . I did end up switching from when statements to nested If() statements as I was unable to get the when statements to work as 'I thought they should'.
Thanks for all the help. I'll re-post if I figure out a clean way of biasing classes and regionalizing races.
Glad it gave you an idea. You're right on the city/metro comment. It still gives the intended result - more horses for sale to adventurers in a metro than a city.
I haven't had a chance to copy, run, and review your generator yet, but it looks like a grand thing!