JoshuaGrams
commented
3 years ago I think you can just store a "deck" as an array of passage names, and instead of calling QBN.cards, call QBN.filter(deck, [handLimit], [ordered?]).
Last I knew it had to be passage names and not passage objects like you'd get from Story.lookupWith or similar, because SugarCube's history code didn't know how to maintain Passage objects from one "moment" (page) to the next so they'd get broken every time you clicked through to a new passage.
But...yeah, a deck "feels" to me just like any other true/false condition: "are you in this location?" etc. so I usually just use a requirement and set a temp variable to activate the deck I want:
<<set _deck to "SpookyManor">>
<<set _cards to `QBN.cards()`>>
<<unset _deck>>This is a little more verbose, but you can stick it in a widget if you're doing it a lot. And it has the advantage that you can easily combine multiple "decks" if that makes sense, rather than having to do QBN.filter(deck1.concat(deck2, deck3)) or whatever. Though that's actually shorter than multiple <<set>> calls. Huh.
Anyway. QBN.filter should probably do the job? If you run into trouble with that, or need more help with the exact syntax or whatever, let me know and I'll write it up in detail.
Would it be possible to implement multiple parallel "decks" to be drawn from in response to different player actions? Say, if they choose to investigate the Spooky Old Manor you draw from the "things that might happen in a haunted house" deck, and if they choose to go to dinner instead you draw from the "random sandwich deck", and then later in the evening when they go to bed they get a draw from the "random nightmare deck".
There's probably a single deck workaround using a system of pulleys, chewing gum, and temp variables related to why they're making the pull, but it'd be easier for me to design, visualize, and implement if I could use multiple discrete decks running in parallel.