<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 6 June 2017 at 10:54, Jeremy Bursey <span dir="ltr"><<a href="mailto:zippywings@hotmail.com" target="_blank">zippywings@hotmail.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">
<div id="m_-1465745265928415027m_-2580089315458247638divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir="ltr">
<p>Hey Guys,</p>
<p><br>
</p>
<p>I'm subscribed to the mailing list digest, not the individual messages, so I can't respond to the messages directly, but here's my input about the text/menu activation debate you started recently:</p>
<p><br>
</p>
<p>Regarding <i>Entrepreneur</i>, it uses text, menus, and slices to convey its information, sometimes all at once. It's just as chaotic as the rest of the game's design. But I try not to let any of the elements overlap, though the screen size sometimes makes
 that unavoidable.</p>
<p><br>
</p>
<p>What I'm moving toward in either the next release or the one after that is to use menus as choice box selections to allow for multiple player inputs at the shopping level (and wherever else choices are made), which players will select while the textbox is
 open. My preference is to move the item descriptions into vertically-placed textboxes (or text slices) that cover the right half of the screen and keep the choice boxes on the left, since that'll allow the player to see all of the choices at the same time
 rather than having to scroll through them, which I would need to do if I kept the text on the bottom and the choices on the top. This also means that I would need to take advantage of the custom screen size by changing the dimensions from 320x200 to 448x280
 in order to fit everything on screen comfortably.</p>
<p><br>
</p>
<p>So, I would need to display menus and textboxes together, or menus and text slices together to keep the current design functional and compatible with future development.</p>
<p><br>
</p>
<p>As far as menus and gameplay is concerned, the only element of the game that currently uses menus as a control item is the painting sequence at Pine Alley Drive. The protagonist moves according to menu selection, and the player has to select either "Done
 for Now" or "Done for Good" to regain control of the character. The text doesn't appear until the menu is closed, but it doesn't mean I would never want text to appear while it is activated. However, I'm not against writing text slices for that.</p>
<p><br>
</p>
<p>Regarding two textboxes on display at once (or stacking textboxes), I see a benefit to that if the screen size is large enough to justify it, but unless the two texts are both clearly visible, I don't see the point.
<i>Powerstick Man XE</i> and <i>Tightfloss Maiden</i> both fake double textboxes for their displays, and do it competently. Maybe it's easier to do it natively, but slice collections really do help make it work without the extra textbox. I'd say the advantage
 of having multiple textboxes on display at once is to simplify placement of each, whereas slice collections would have to be guesstimated against the existing textbox on display and would be placed depending on screen size, which could possibly lead to misalignment
 at higher resolutions. That's not so appealing.</p>
<p><br>
</p>
<p>Either way, games using two or more textboxes will and do exist. <i>Entrepreneur</i> uses textboxes to display end-of-day stats natively, which I prefer because I can more easily show stats via global variables, whereas slice collections require a bunch
 of strings I wouldn't want to use up in a single sitting, even if they're recyclable.</p></div></div></blockquote><div>You can do this easily. Just use either the expandstring script command to process ${V#} codes, or use the textboxtext command to simultaneously load the text of a textbox and expand the codes, which you can then display in a text slice.</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 id="m_-1465745265928415027m_-2580089315458247638divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir="ltr"><p> I'd rather have a textbox that can display an endless number of lines on a scroll bar than displaying two eight-line textboxes at once, but I wouldn't be against displaying
 stats in one box and a reaction text from the character at the same time in another. As you probably know, if I need it and can use it, I'll use it. And you should know by now that I'll probably need it.
<span>😉</span></p></div></div></blockquote><div>That's definitely a main goal of converting textboxes to a new file format.<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 id="m_-1465745265928415027m_-2580089315458247638divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir="ltr"><p><span></span></p>
<p><br>
</p>
<p>So, I hope this sheds some light on your conversation about what's being used and what should be used.</p>
<p><br>
</p>
<p>In short: Menus and textboxes should coexist, menus that control the hero should remain, displaying two textboxes at once is preferred but negligible, customizing the size and position of the textbox (vertically and horizontally) is necessary.</p>
<p><br>
</p>
<p>Hope that helps.<br>
</p>
<p><br>
</p>
<p><font size="2"><span style="font-size:10pt">Message: 2<br>
Date: Mon, 5 Jun 2017 09:06:02 -0700<br>
From: James Paige <<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>><br>
To: "<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.<wbr>org</a>"<br>
        <<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.<wbr>org</a>><br>
Subject: Re: [Ohrrpgce] Textboxes and menus<br>
Message-ID:<br>
        <<a href="mailto:CADqBxeYZHaMpTPAXHiJK2R1m5hi94ZgLcj-HFMnn%2BHUcwX8hGA@mail.gmail.com" target="_blank">CADqBxeYZHaMpTPAXHiJK2R1m5hi9<wbr>4ZgLcj-HFMnn+HUcwX8hGA@mail.gm<wbr>ail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Mon, Jun 5, 2017 at 7:39 AM, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>> wrote:<br>
<br>
><br>
><br>
> On 5 June 2017 at 05:57, James Paige <<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>> wrote:<br>
><br>
>><br>
>><br>
>> On Sat, Jun 3, 2017 at 8:28 PM, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>> Showing a textbox and a menu at once is wonky, and I didn't understand<br>
>>> at all how it worked until spending 20 min reading the source, so I think<br>
>>> it's safe to say tahat very few people do.<br>
>>> Keypresses only affect the top-most menu, but they generally are also<br>
>>> interpreted by the textbox, except the textbox is not affected if the menu<br>
>>> suspends gameplay.<br>
>>> (Interestingly, opening a menu is the only way to suspend choicebox<br>
>>> cursor controls)<br>
>>><br>
>>> So, if not suspending gameplay, pressing enter will cause both the<br>
>>> textbox to close and the menu to activate... unless the selected menu item<br>
>>> is one of the builtin menus, in which case the enter keypress will be<br>
>>> cleared when leaving the menu, so that the textbox doesn't close.<br>
>>><br>
>>> Even worse, when showing a textbox with a choice box at the same time as<br>
>>> a menu the arrows keys affect both of them! This clearly should be fixed,<br>
>>> but I think the Enter behaviour is bad too.<br>
>>><br>
>>> Currently you can give the menu sole focus by setting it to suspend<br>
>>> gameplay, and you can give the textbox focus by setting "No player control<br>
>>> of menu", although then you need to use a script to close the menu.<br>
>>><br>
>>> Clearly to change anything we need a backcompat bit, but it's not easy<br>
>>> 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<br>
>>> (whichever was opened last), and maybe even (virtually) put the textbox in<br>
>>> the menu stack.<br>
>>> So if a menu is opened from a textbox, or a textbox from a menu, then it<br>
>>> takes focus; but we also will want a way to override that; maybe the 'No<br>
>>> controls' menu bit can be repurposed.<br>
>>><br>
>><br>
>> I agree, the current behavior is a mess, and anything it does now is just<br>
>> implementation quirks, not planned or desired behavior.<br>
>><br>
>> I love the idea of menus or textboxes having focus. Now that you mention<br>
>> it, one of my forgotten plans as part of converting things to slices was to<br>
>> allow the text box layer and the menu layer to change their order so either<br>
>> one could be on top.<br>
>><br>
><br>
> Hmm. It makes sense that whatever has focus is on top (though I'm a big<br>
> fan of focus-follows-mouse :). And you would always override it anyway.<br>
><br>
> If a menu or textbox is opened without taking focus, then the textbox/menu<br>
> that opened it needs a way to close it when it closes. Menus can already<br>
> close textboxes but not the other way around.<br>
><br>
> Thinking about the most common case, a textbox with a menu instead of a<br>
> choice box, would be helpful. Of course that's another feature. (Should we<br>
> turn choiceboxes into menus? Or put a simplified menu editor in the textbox<br>
> editor (meaning it doesn't create a new menu ID in the menu editor, but<br>
> does create a MenuDef when you load it)? Or just add a shortcut for<br>
> creating a new normal menu and linking it to the textbox?)<br>
><br>
><br>
Ooh! I love the idea of choiceboxes using a simplified menu editor that<br>
creates a MenuDef without a menu ID.<br>
<br>
I *also* like the idea of a shortcut for creating a new menu linked to a<br>
textbox.<br>
<br>
I can't decide which is better...<br>
<br>
<br>
> If I remember correctly, my original intention for the "No player control<br>
>> of menus" was a somewhat ill-conceived pre-slice idea bout using menus as<br>
>> informational displays while the player was still waking around and acting<br>
>> normally. I don't know if anybody ever use that bit that way or not.<br>
>><br>
><br>
> I think it's used that way in Entrepreneur; or were all those displays<br>
> slices only?<br>
><br>
<br>
I don't remember<br>
<br>
<br>
><br>
><br>
>> Also, maybe we should think ahead to the possible ability to have<br>
>>> mutliple textboxes open at once, on a stack.<br>
>>><br>
>><br>
>> That could be useful, but lets not worry about it too much until somebody<br>
>> has a game idea that needs it.<br>
>><br>
><br>
> Maybe it's difficult to come up with a situation where it would be<br>
> *needed*, but aren't there a number of RPGs that show two textboxes at<br>
> once? Just don't ask me to name any... I can't remember playing any.<br>
> It's hard to see how that would actually work, though.<br>
><br>
<br>
Seems like a stack of multiple open textboxes would be a bit confusing.<br>
<br>
If somebody really needs that, they can already script it pretty<br>
painlessly, just by opening a textbox, grabbing the slice handle, and<br>
re-parenting it to the script layer<br>
<br>
... we might want a command that just loads a textbox as a slice, without<br>
triggering any of the apparatus of textbox chaining and conditionals.<br>
<br>
<br>
<br>
><br>
><br>
>><br>
>><br>
>>> (I also think it's strange that ESC doesn't advance textbox, so would<br>
>>> like to add a backcompat or pref bitset for that.)<br>
>>><br>
>>><br>
>> That sounds reasonable to me :)<br>
>><br>
>> I don't remember why I excluded ESC from doing that in the first place.<br>
>><br>
><br>
> Also, I suggest we make suspendboxadvance suspend choicebox controls too.<br>
> They're useless when you can't hit enter, unless you use a script to<br>
> advance the box instead, but that would be really weird...<br>
><br>
><br>
Yes, I think forgetting to disable choicebox controls on suspend box<br>
advance should probably be treated like a bug.</span></font><br>
</p>
</div>
</div>

</blockquote></div><br></div></div>