The gap
For "show the player a few choices, run a bit of script for whichever one they pick" - a very common pattern (attribute-setting menus, confirmations, simple branching) - there are two options today, and both have real friction for this specific shape of problem:
ShowMenu / show menu: requires building the option list manually with Split("Male;Female", ";") before you can show anything, then a switch/case on the result to react to each choice. Works, but the Split-then-switch combo is boilerplate every single time, and gets old fast for anyone building more than a couple of these.
Pages (ShowPage, src/Engine/Core/CorePages.aslx): much nicer choice syntax - options are just a dictionary of target → label - but it's built around each option linking to another object in the tree (a dialoguepage). If a choice doesn't actually need a page of its own (no real "content" to show, just "set this attribute and carry on"), you still have to create a whole extra page object with a pagescript/pagescripttext type just to hold that one script. Concretely: a 2-question character-creation flow (gender, then class) needs 8 separate page objects, most of which exist purely to run a couple of lines and redirect - there's no page-free way to say "here's a choice, here's what each option does."
Where this showed up
Prototyped a Pages-based rewrite of howto/rpg/character_creation.md's gender/class selection while evaluating whether Pages should replace that doc's ShowMenu+Split example. It works (verified end-to-end against the live engine), but needed more objects and more indirection than the Split+switch version it would have replaced, for a flow that isn't really "dialogue" - just a short linear questionnaire. Kept the doc as ShowMenu-based as a result.
Possible shape of a fix
Something like a menu-builder script command/function that takes a list of (label, script) pairs directly - inline scripts per option, no separate list-building step and no page object required - would cover the middle ground between "raw ShowMenu + Split + switch" and "full Pages" that neither option serves well today.
The gap
For "show the player a few choices, run a bit of script for whichever one they pick" - a very common pattern (attribute-setting menus, confirmations, simple branching) - there are two options today, and both have real friction for this specific shape of problem:
ShowMenu/show menu: requires building the option list manually withSplit("Male;Female", ";")before you can show anything, then aswitch/caseon the result to react to each choice. Works, but theSplit-then-switchcombo is boilerplate every single time, and gets old fast for anyone building more than a couple of these.Pages (
ShowPage,src/Engine/Core/CorePages.aslx): much nicer choice syntax - options are just a dictionary of target → label - but it's built around each option linking to another object in the tree (adialoguepage). If a choice doesn't actually need a page of its own (no real "content" to show, just "set this attribute and carry on"), you still have to create a whole extra page object with apagescript/pagescripttexttype just to hold that one script. Concretely: a 2-question character-creation flow (gender, then class) needs 8 separate page objects, most of which exist purely to run a couple of lines and redirect - there's no page-free way to say "here's a choice, here's what each option does."Where this showed up
Prototyped a Pages-based rewrite of
howto/rpg/character_creation.md's gender/class selection while evaluating whether Pages should replace that doc'sShowMenu+Splitexample. It works (verified end-to-end against the live engine), but needed more objects and more indirection than theSplit+switchversion it would have replaced, for a flow that isn't really "dialogue" - just a short linear questionnaire. Kept the doc asShowMenu-based as a result.Possible shape of a fix
Something like a menu-builder script command/function that takes a list of (label, script) pairs directly - inline scripts per option, no separate list-building step and no page object required - would cover the middle ground between "raw ShowMenu + Split + switch" and "full Pages" that neither option serves well today.