[Ohrrpgce] Choice Boxes overhaul

[James Paige]

I think you are on the right track with this.

The complexity of the top level menu editor is also what made me shy away
from wanting to merge choice boxes and menus in the past.

So I think that yes, this is a good plan.

On Monday, November 19, 2018, Ralph Versteegen <teeemcee at gmail.com> wrote:

> On Tue, 20 Nov 2018 at 15:47, Ralph Versteegen <teeemcee at gmail.com> wrote:
> >
> > So (on a whim) I was about to start on a HeartBug request to add more
> > textbox choices and allow longer choice text. For years, I've held off
> > doing any such thing, thinking it would be better to just convert
> > choices to menus, or at least, to convert SAY to RELOAD. But that
> > still seems a long way off, due to the weird ways textboxes and menus
> > interact, which I don't look forward to trying to solve. Plus I didn't
> > totally like the idea, because the menu editor is scary and not  so
> > convenient, while the choicebox editor is wonderfully simple.
> >
> > Now, extending the length of the two existing choice text will be
> > messy, but doable. SAY is already the messiest of all lumps, anyway.
> >
> > But if there are more than 2 choices (I was thinking, say, 5), then
> > setting a tag to determine the next textbox/script isn't going to work
> > well for more than two choices. Better to just directly set the next
> > textbox/script on a choice. Not having to name a tag, set it, and test
> > it in the conditionals menu will be huge improvement too!
> >
> > ...Would be nice if you could set choice colors too.
> >
> > Putting all this in the choice menu (and in SAY) would be really
> > messy, it would be better to have... the menu item detail editor.
> >
> > We already have support for multiple files containing MenuDefs and
> > MenuDefItems (the MenuSet UDT), though I don't know why that was
> > implemented.
> > So I'm proposing converting the choice box in-game to a MenuDef,
> > adding a new menuitem lump for choicebox items, but not a new lump for
> > the choicebox menu itself. Many of the settings in MenuDef don't make
> > sense (eg on-close script, most bits) or are determined by the
> > textbox.  Omitting the top-level menu editor will make the choicebox
> > editor simpler. Plus we can very easily add it and a dedicated lump
> > later, with no backcompat headache.
> To clarify, I proposing only embedding the menu item editor in the
> choicebox
> editor, not the menu editor, and likewise only storing the MenuDefItems
> in a new textbox_choices.bin lump, not any MenuDef. (Though we could make
> part of the MenuDef editable and just store it in SAY)
>
> The nice part of this plan is that SAY doesn't even need modifying! Only
> an upgrade is needed to copy the existing choices to textbox_choices.bin
>
> >
> > Maybe I will hide a couple of the things in the menu item detail menu
> > - the extra data and the "Close when selected bitset. Maybe I should
> > disallow the Special menu item type too? But I don't really see a
> > reason to.
> >
> > For now, the choicebox menu could just be unable to scripts until the
> *unavailable to scripts
>
> > textbox-menu mess is cleaned up. Or maybe handles for menu items in
> > the choice menu could be obtained with a special script command.
> >
> > The only problem I see is that the choicebox currently has some
> > slices, and if they are replaced with a draw_menu call (which can be
> > done from a SpecialSlice to ensure correct layering/position), they
> > could break scripts. Actually, I doubt anyone uses them anyway.
> > But actually, I could easily enough create a new function to set up a
> > rect slice, scroll slice and text slices to draw a MenuDef.
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20181120/d4aa18b1/attachment-0001.html>