<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 8, 2017 at 8:56 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 7 June 2017 at 05:49, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-2340955359631211036m_-2801157287093034977h5">On Tue, Jun 6, 2017 at 8:38 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 6 June 2017 at 04:06, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Jun 5, 2017 at 7:39 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 5 June 2017 at 05:57, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_-2340955359631211036m_-2801157287093034977m_-8118554176947612971m_1471647157034303933m_8820792684167222974gmail-m_1098977975081671294m_9221349151112462728m_-8140271043966776398gmail-">On Sat, Jun 3, 2017 at 8:28 PM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Showing a textbox and a menu at once is wonky, and I didn't understand at all how it worked until spending 20 min reading the source, so I think it's safe to say tahat very few people do.<br>Keypresses only affect the top-most menu, but they generally are also interpreted by the textbox, except the textbox is not affected if the menu suspends gameplay.<br></div><div>(Interestingly, opening a menu is the only way to suspend choicebox cursor controls)<br></div><div><br></div><div>So, if not suspending gameplay, pressing enter will cause both the textbox to close and the menu to activate... unless the selected menu item is one of the builtin menus, in which case the enter keypress will be cleared when leaving the menu, so that the textbox doesn't close.<br></div><div><br></div>Even worse, when showing a textbox with a choice box at the same time as a menu the arrows keys affect both of them! This clearly should be fixed, but I think the Enter behaviour is bad too.<br></div><div><div><br></div><div>Currently you can give the menu sole focus by setting it to suspend gameplay, and you can give the textbox focus by setting "No player control of menu", although then you need to use a script to close the menu.<br><br></div><div>Clearly to change anything we need a backcompat bit, but it's not easy to see what to change to. I want to simplify, not make it make complicated.<br>I think we need to track whether the textbox or the menu has focus (whichever was opened last), and maybe even (virtually) put the textbox in the menu stack.<br></div><div>So if a menu is opened from a textbox, or a textbox from a menu, then it takes focus; but we also will want a way to override that; maybe the 'No controls' menu bit can be repurposed.</div></div></div></blockquote><div><br></div></span><div>I agree, the current behavior is a mess, and anything it does now is just implementation quirks, not planned or desired behavior.<br></div><div><br>I love the idea of menus or textboxes having focus. Now that you mention it, one of my forgotten plans as part of converting things to slices was to allow the text box layer and the menu layer to change their order so either one could be on top.<br></div></div></div></div></blockquote><div><br></div></span><div>Hmm. It makes sense that whatever has focus is on top (though I'm a big fan of focus-follows-mouse :). And you would always override it anyway.<br><br></div><div>If a menu or textbox is opened without taking focus, then the textbox/menu that opened it needs a way to close it when it closes. Menus can already close textboxes but not the other way around.<br><br></div><div>Thinking about the most common case, a textbox with a menu instead of a choice box, would be helpful. Of course that's another feature. (Should we turn choiceboxes into menus? Or put a simplified menu editor in the textbox editor (meaning it doesn't create a new menu ID in the menu editor, but does create a MenuDef when you load it)? Or just add a shortcut for creating a new normal menu and linking it to the textbox?)<br></div><span><div><br></div></span></div></div></div></blockquote><div><br></div></span><div>Ooh! I love the idea of choiceboxes using a simplified menu editor that creates a MenuDef without a menu ID.<br><br></div><div>I *also* like the idea of a shortcut for creating a new menu linked to a textbox.<br><br></div><div>I can't decide which is better...<br></div></div></div></div></blockquote><div><br></div><div><br></div></span><div>I like the idea of a simplified menu editor too, but wonder if we'll just end up replicating the menu editor. Couldn't the simplified view just be a part of the menu editor proper?<br></div><div>I imagine the simplified view would just:<br></div><div>-skip the toplevel menu editor menu, since most options aren't really needed, or are defined by the textbox<br></div><div>-default new menu items to Caption type, close if selected (this is a reasonable default anyway)<br></div><div>-have a simpler way to select the effect of each menu item. For example, maybe press TAB to switch focus to a small floating side window with just 1-2 options. This sort of thing clearly can be added to the menu editor proper too... in fact it seems I am talking about the 'proper' menu editor.<br></div></div></div></div></blockquote><div><br></div></div></div><div>I like all of that. <br><br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><br>My thoughts are very confused on all of this, but...<br>Choiceboxes currently aren't mutually
exclusive with opening a new menu from the conditionals menu, but it would be horrible to have two different ways to open a MenuDef from a texbox. Maybe allow you to either open an independent menu (as currently... and keep the option in the Conditionals?), or have a menu attached to the box as a choice box, but not both.<br><div>Also choiceboxes aren't treated like menus. So does this mean that they can't be converted to MenuDefs? And we can't replace the limited choiceboxes with MenuDefs, unless we don't put them on the normal menu stack? That seems a bit awful.<br></div><div>But maybe it's alright if the flexible MenuDef replacement for choice boxes (whether they get normal menu IDs or not) don't behave like existing (backcompat) choiceboxes, but instead are normal menus. This would allow the box and menu to close independently unless we force-linked the two. (Eg if from the choice-menu you open a submenu, and then advancetextbox gets called, both menus and the textbox are closed)<br><br></div></div></div></div></blockquote><div><br></div></span><div>Thinking about this more, maybe it is a mistake to try and convert choiceboxes into MenuDef?<br><br></div><div>Maybe it is better to just improve the interoperability of menus and textboxes, and add features to the textbox editor to make it easier to combine menus with textboxes. <br><br></div><div>It would not be so bad if Choiceboxes remained a little odd-thing that textboxes can do for backcompat but that aren't important anymore. <br></div></div></div></div></blockquote><div><br></div></div></div><div>I was imagining that the better interoperability would include an upgraded choicebox editor which is either the real menu editor, or a simplified version. But I guess keeping around an obsolete choicebox system instead of replacing it is simpler in several ways than getting choiceboxes and menus to behave identically, even if it means having a second system around. (There could be a per-textbox option between 'basic choicebox' and 'menu')<br><br></div><div>Conceivably, we could even add the menu-integration first, and in future add an upgrade routine which turns choiceboxes to new-style menus (which might not initially be possible due to missing bitsets). This makes me much more comfortable about actually starting on it!<br></div><br></div></div></div></blockquote><div><br></div><div>That sounds good! I like that!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div>(Another problem is that choiceboxes are slice-based, and therefore can be manipulated with scripts) <br></div></div></div></blockquote><div><br></div><div>I wonder if anybody has done it?<br><br></div><div>Checking definitively seems impossible, but checking if anybody has ever used the choicebox's slice lookup codes have ever been used might be plausible.<br><br></div><div>That is indeed a downside of converting things into slices. Backwards compatible changes to sliceified GUI is dang hard to do.<br><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br></div><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>If I remember correctly, my original intention for the "No player control of menus" was a somewhat ill-conceived pre-slice idea bout using menus as informational displays while the player was still waking around and acting normally. I don't know if anybody ever use that bit that way or not.<br></div></div></div></div></blockquote><div><br></div></span><div>I think it's used that way in Entrepreneur; or were all those displays slices only?<br></div></div></div></div></blockquote><div><br></div></span><div>I don't remember<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_-2340955359631211036m_-2801157287093034977m_-8118554176947612971m_1471647157034303933m_8820792684167222974gmail-m_1098977975081671294m_9221349151112462728m_-8140271043966776398gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div>Also, maybe we should think ahead to the possible ability to have mutliple textboxes open at once, on a stack.<br></div></div></div></blockquote><div><br></div></span><div>That could be useful, but lets not worry about it too much until somebody has a game idea that needs it.</div></div></div></div></blockquote><div><br></div></span><div>Maybe it's difficult to come up with a situation where it would be *needed*, but aren't there a number of RPGs that show two textboxes at once? Just don't ask me to name any... I can't remember playing any.<br></div><div>It's hard to see how that would actually work, though.<br></div></div></div></div></blockquote><div><br></div></span><div>Seems like a stack of multiple open textboxes would be a bit confusing.<br></div></div></div></div></blockquote><div><br></div></span><div>I guess it's quite unimportant.<br></div><div>But I think I see how I would implement it: rather than a stack of textboxes (which would imply that some of the on-close actions of the others haven't happened yet), just add a 'keep previous textbox visible' bit to a textbox to keep the old text slices. So a limit of two textboxes displayed at once. The main use of the feature would be to display a conversation between two characters.<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>If somebody really needs that, they can already script it pretty painlessly, just by opening a textbox, grabbing the slice handle, and re-parenting it to the script layer<br></div></div></div></div></blockquote><div><br></div></span><div>I don't think you can do that, because it's protected. <br></div></div></div></div></blockquote><div><br></div></span><div>Maybe not. I guess we probably do need a command to load a textbox as a slice... either that or a command that can make an unprotected clone of a protected slice.<br></div></div></div></div></blockquote><div><br></div></span><div>A command to copy a slice subtree would be useful in general. It would have to either remove protection flags and special lookup codes, or fail. (It would still have to fail regardless when copying special slice types, or maybe turn them into container slices.)<br></div><div> <br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>... we might want a command that just loads a textbox as a slice, without triggering any of the apparatus of textbox chaining and conditionals.<br></div></div></div></div></span></blockquote></div></div></div></blockquote></span></div><br></div></div>
<br></span><span class="">______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></span></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.<wbr>org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
<br></blockquote></div><br></div></div>