see p. 380 (in 020122) for a description. basically: 2-6 oracles (generally of a similar function - peril, feature/description, etc) are gathered in an array. the d6 is then rolled with the d% to randomize which table among them is used.
with a bot instead of physical dice, it'd be possible to have more elaborate ways of randomizing these, but for the time being it's probably better to just implement this close to as-written. partly for scope control, partly because getting super fine-grained about probability may not add much for the amount of work it is. maybe later (or on a separate bot).
here's some ideas on how it could be implemented:
at its most basic a command could look like this: /array [title] [oracle1] [oracle2] [oracle3] [oracle4] [oracle5] [oracle6].
however: since arrays are generally organized around being a Peril, Feature, or Opportunity, we could cut down on the 'noise' of autocomplete options offered to the user by splitting them in to subcommands: /array [subcommand] [title] [oracle1] [oracle2] [oracle3] [oracle4] [oracle5] [oracle6], where subcommand is one of Peril, Feature, or Opportunity. we could still accept any ID in the autocomplete fields for those who really want to go "off-road", but only offer autocomplete options for the appropriate category (or include them, if the user input is within a character or two?), which in some cases may allow us to display all available options before the user even starts typing them. Dataforged already has some (mostly-complete) tags that flag oracle content as perils, features, and opportunities; down the road, users could be prompted to tag their own custom oracles in a similar way.
rather than outputting a single result, the command outputs an embed with a display analogous to the sample index card, showing which oracles are assigned to this array:
included with the embed are components for managing the oracle array. at minimum this would be just a button to generate a result from the array in a new roll.
it'd be handy to have one to manage/edit the array contents, too - perhaps by swapping out different arrays? an example of a use-case for that is suggested by the index card in the book: no single 'derelict peril' table exists, so it probably refers to the peril table of whatever derelict zone the players are exploring at present. given that derelict zones are likely to change multiple times over the course of a single derelict expedition, recreating the card every time could get old. so maybe tables that have a parallel across multiple subcategories could be offered? hmm. this sounds like a pain in the ass to determine programmatically, but it's something i could tag in dataforged, too. List<string> GroupWith, perhaps, or as another tag string? that'd make it easy to extend with user content.
not all 6 oracle parameters have to be set manually, necessarily. if the parameters are optional, we could assume that any unspecified rows are populated with the last specified oracle. then if someone provides just oracle1 and oracle3, oracle1 is assigned to 1-2 and oracle3 is assigned to 3-6.
a more involved implementation might involve storing oracle arrays in the DB... but they're generally so fleeting that i wonder if it's worth doing so. it might be better to hold off on that until we can get an MVP in people's hands to see how they like it.
see p. 380 (in 020122) for a description. basically: 2-6 oracles (generally of a similar function - peril, feature/description, etc) are gathered in an array. the d6 is then rolled with the d% to randomize which table among them is used.
with a bot instead of physical dice, it'd be possible to have more elaborate ways of randomizing these, but for the time being it's probably better to just implement this close to as-written. partly for scope control, partly because getting super fine-grained about probability may not add much for the amount of work it is. maybe later (or on a separate bot).
here's some ideas on how it could be implemented:
at its most basic a command could look like this:
/array [title] [oracle1] [oracle2] [oracle3] [oracle4] [oracle5] [oracle6].however: since arrays are generally organized around being a Peril, Feature, or Opportunity, we could cut down on the 'noise' of autocomplete options offered to the user by splitting them in to subcommands:
/array [subcommand] [title] [oracle1] [oracle2] [oracle3] [oracle4] [oracle5] [oracle6], wheresubcommandis one ofPeril,Feature, orOpportunity. we could still accept any ID in the autocomplete fields for those who really want to go "off-road", but only offer autocomplete options for the appropriate category (or include them, if the user input is within a character or two?), which in some cases may allow us to display all available options before the user even starts typing them. Dataforged already has some (mostly-complete) tags that flag oracle content as perils, features, and opportunities; down the road, users could be prompted to tag their own custom oracles in a similar way.rather than outputting a single result, the command outputs an embed with a display analogous to the sample index card, showing which oracles are assigned to this array:
included with the embed are components for managing the oracle array. at minimum this would be just a button to generate a result from the array in a new roll.
it'd be handy to have one to manage/edit the array contents, too - perhaps by swapping out different arrays? an example of a use-case for that is suggested by the index card in the book: no single 'derelict peril' table exists, so it probably refers to the peril table of whatever derelict zone the players are exploring at present. given that derelict zones are likely to change multiple times over the course of a single derelict expedition, recreating the card every time could get old. so maybe tables that have a parallel across multiple subcategories could be offered? hmm. this sounds like a pain in the ass to determine programmatically, but it's something i could tag in dataforged, too.
List<string> GroupWith, perhaps, or as another tag string? that'd make it easy to extend with user content.not all 6 oracle parameters have to be set manually, necessarily. if the parameters are optional, we could assume that any unspecified rows are populated with the last specified oracle. then if someone provides just
oracle1andoracle3,oracle1is assigned to 1-2 andoracle3is assigned to 3-6.a more involved implementation might involve storing oracle arrays in the DB... but they're generally so fleeting that i wonder if it's worth doing so. it might be better to hold off on that until we can get an MVP in people's hands to see how they like it.