[Ohrrpgce] SVN: james/9958 load_plank_from_file() helper function

James Paige Bob at hamsterrepublic.com
Sun Jan 14 13:15:16 PST 2018


On Sunday, January 14, 2018, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> On 14 January 2018 at 14:09, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> I do think that keeping a logical separation between menus and special
>> screens is important, even if they both end up using plankmenu features
>> under the hood.
>>
>> A homogeneous vertically scrolling menu is not the same thing as a
>> potentially complex compound menu-like structure that allows cursor
>> movement in multiple directions and might have sub-sections that scroll
>> independently.
>>
>
> But my objection is against plankmenus only being available in
> built-in/special menus. They ought to be available to people to use in
> their scripts and slice collections, as Menu slices. So if the distinction
> in menu types shouldn't be "between menus and special screens" but "between
> MenuDef (Menu Editor) menus and plank (Menu slice) menus".
>

Oh, I agree that plank menus should not be limited just to built in special
menus. Yes, I just want MenuDef and plankmenys to reamain two different
things. I think we are probably on the same page here and I am just
stumbling a bit on terminology :)


> MenuDef menus really define 3 types of things:
> 1) the appearance of the menu, such as position, text color, item spacing,
> and the appearance of the menu items too
> 2) the 'logical' definitions of the items: captions, types/use actions,
> tag conditions, hide-if-disabled, close-menu-when-selected, etc
> 2.1) how the menu behaves: on close script, suspension of gameplay, no
> player control, open menu when closed, etc
>
> Plank menus defined as slice collections are a replacement for #1.
> But they don't cover #2 (aside from fixed captions) or #2.1 at all.
> Instead, you have to use slice extra data and so on and write custom logic.
> Menu slices/Menuitem slices need to cover #2, otherwise they're not really
> menus!
> I think they should also cover #2.1, because I see no benefit to not doing
> that, and the implementation of #2 and #2.1 are totally intertwined anyway,
> so it would be extra work to *not* implement #2.1.
>
> That's what I mean by overlap between the menu types: sharing that logic.
> In fact, currently MenuDef menus in general don't implement #2 and #2.1 at
> all, that stuff only works for in-game map-mode menus (which I'll call
> "custom" menus). MenuDef menus are used in Custom, and in battles, but the
> types and subtypes are only intended to accommodate custom menus and do
> nothing elsewhere, so even in battles the logic for tag conditions on menu
> items and so forth was all reimplemented. Would be nice if menu items had
> an option to call a FB callback (not exposed to users, obviously).
>


I think I follow. And the callback is a cool idea.

>
>
>>
>> By the way, I don't know if I ever explained where the "plank" in
>> plankmenu came from, or whether or not it is obvious.
>>
>> My mental image was this:
>>
>> https://i.imgur.com/WZmhCSS.jpg
>>
>> ...actually, this one probably does it better justice:
>> https://i.imgur.com/BDea9XY.jpg
>>
>> ...or this I guess? https://i.imgur.com/unDp3At.png ;)
>>
>
> A desperate act of last resort! A bridge to a new menu system was urgent!
> The final plank in the grand slicification scheme!
>
> (Yes, obviously what was meant :)
>
>>
>>
>> On Sat, Jan 13, 2018 at 4:34 PM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 14 January 2018 at 05:42, James Paige <Bob at hamsterrepublic.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Saturday, January 13, 2018, Ralph Versteegen <teeemcee at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 13 January 2018 at 05:24, James Paige <Bob at hamsterrepublic.com>
>>>>> wrote:
>>>>>
>>>>>> s/SliceLoadFromFile/load_plank_from_file/ in my previous mail
>>>>>>
>>>>>> Opps! ;)
>>>>>>
>>>>>
>>>>> Wait a minute, I just finally noticed you switched to my spelling, and
>>>>> have been doing it for a long time!
>>>>>
>>>>>
>>>>
>>>> Haha! It's a "thing" now :)
>>>>
>>>>
>>>>>
>>>>>> On Fri, Jan 12, 2018 at 8:19 AM, James Paige <Bob at hamsterrepublic.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Opps! I'll fix where I forgot to free the collection in
>>>>>>> SliceLoadFromFile
>>>>>>> It looks like I am leaking the whole collection every time, even if
>>>>>>> the load succeeds.
>>>>>>>
>>>>>>
>>>>> Oh, I didn't even notice that bug! That wasn't what I meant.  The only
>>>>> way to check whether SliceLoadFromFile failed or not is to check if any
>>>>> slices were actually loaded... but if they didn't load, then the
>>>>> lookupslice will fail anyway, so that "if col = 0 then ..." does nothing
>>>>>
>>>>>
>>>> Oh! Right! I can fix that. The next check after that, for whether
>>>> sl_plank_holder was found is good enough on it's own.
>>>>
>>>>
>>>>
>>>>>
>>>>>>> I'm looking forward to learning more about template slices and menu
>>>>>>> slices. I'll probably have to read your writeup before I understand :)
>>>>>>>
>>>>>>
>>>>> Hmm, this is a long and unfinished writeup, and at the top I have
>>>>> notes to myself to firsr finish and email, or in merge in two other
>>>>> writeups!
>>>>>
>>>>> Template slices is basically just hidden slices, ignored for almost
>>>>> all purposes (importantly, collision detection, so you can't click on them)
>>>>> but which are shown by default in the slice editor, tagged with [TEMPLATE].
>>>>> Their main use is to replace plank collections. If you want to add a new
>>>>> menu item to a plankmenu, just clone a template slice (indexed with a
>>>>> lookup code), instead of loading a collection and copying over the plank.
>>>>> Conceivably you could have multiple item templates. So, this will let you
>>>>> see the whole menu while you edit the menu slice collection.
>>>>> My branch: https://bitbucket.org/rbv/ohrr
>>>>> pgce/commits/d1963ff335e7afd8e82d12dd1d92df3251b2f6e8?at=templates
>>>>> (This turned out a bit messy, I wanted to try to clean it up)
>>>>>
>>>>>
>>>> Okay, I follow. That seems like a good idea. I like it. I feel like I
>>>> would use it.
>>>>
>>>
>>>>
>>>>
>>>>> As for the rest of it, let me just state this core crazy idea:
>>>>> Replace menu handles and menu item handles with menu slice handles and
>>>>> menu item slice handles.
>>>>>
>>>>> The "create menu" command would create *both* a new menu and a new
>>>>> menu slice, which appear to be exactly the same thing from the point of
>>>>> view of scripts. The handle it returns could be passed to any existing menu
>>>>> command, or used as a slice handle. Note that "create menu" fits the
>>>>> pattern for "create rect", "create text", etc.
>>>>> Having both menus and menu slices and making them different things
>>>>> with different kinds of handles, and adding commands to convert from one to
>>>>> the other, seems totally unnecessary and harmfully confusing. Three
>>>>> different handle types for heroes is endless trouble.
>>>>> Ditto for menu items: they also would become slices, but they would be
>>>>> different from other slice types in that they are always linked to a
>>>>> certain menu slice, must be a descendant of that slice, and can't be
>>>>> created independently. Typically they will have a single text slice child,
>>>>> and various existing menu and menu item command will have the effect of
>>>>> modifying that child.
>>>>> We could either merge MenuDef and plankmenu entirely at a low level,
>>>>> or at a higher one (so MenuDef builds on top of plankmenu or vice versa, or
>>>>> an abstraction layer over the two).
>>>>>
>>>>>
>>>>
>>>> That sounds like a difficult plan! I am not opposed, just saying it
>>>> sounds hard.
>>>>
>>>
>>>> I suppose having good unit tests for all the old menu scripting
>>>> commands will make it significantly easier. I know we have a bunch, I'll
>>>> have to go over them and see what is missing
>>>>
>>>> If I understand correctly, the goal would be to re-implement menus as
>>>> plankmenu-style slices, and to make MenuDef a backcompat wrapper around
>>>> them. (Am I close?)
>>>>
>>>
>>> Yes, it will be a lot of work.
>>>
>>> All my talk about scripting handles is a distraction of course, the main
>>> idea is to only have one unified menu system as seen by scripts, rather
>>> than two.
>>> Yes, loading a MenuDef menu could construct a plankmenu. That's the easy
>>> part. The hard part would be supporting script commands like "set menu text
>>> align", which would have to be rewritten to iterate over menu item slices,
>>> like plankmenus, unless they just destroy and recreate the menu (would be
>>> quite a cop-out).
>>> But if every plankmenu (menu slice) is also a MenuDef menu from the view
>>> of scripts, then each of the builtin menus like status should also support
>>> all the existing menu commands? Well, quite a lot of them won't make sense
>>> if the slice tree layout differs from the default MenuDef layout. I think
>>> it's OK if script commands like "set menu text align" just fail to do
>>> anything in that case; they would be specific to the subtype of menus built
>>> from a "real" MenuDef. Uh oh, looks as if we would effectively have two
>>> menu types anyway (*). (If we have two subtypes, then those script commands
>>> could maybe throw errors instead?)
>>> Very similar is the problem of how to let you create menus in the slice
>>> collection editor - or whether you could only create a menu slice that way
>>> when editing the collection for a builtin or MenuDef menu.
>>>
>>> (*) The two subtypes I mean are that every (classic MenuDef) menu has a
>>> menu slice (aka plank menu), but not every menu slice has a MenuDef menu.
>>> This seems pragmatic.
>>> But, even if there isn't complete overlap of the two, it would still be
>>> great to have as much overlap as possible. For example, it seems sane to
>>> make plankmenus part of the same focus system (menu stack) as existing
>>> menus.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>>> ---
>>>>>>> James
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 12, 2018 at 8:04 AM, Ralph Versteegen <
>>>>>>> teeemcee at gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12 January 2018 at 13:00, <subversion at hamsterrepublic.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> james
>>>>>>>>> 2018-01-11 16:00:45 -0800 (Thu, 11 Jan 2018)
>>>>>>>>> 38
>>>>>>>>> load_plank_from_file() helper function
>>>>>>>>> ---
>>>>>>>>> U   wip/plankmenu.bas
>>>>>>>>> U   wip/plankmenu.bi
>>>>>>>>>
>>>>>>>>
>>>>>>>> + DIM col as Slice Ptr
>>>>>>>> + col = NewSliceOfType(slSpecial)
>>>>>>>> + SliceLoadFromFile col, filename
>>>>>>>> + IF col = 0 THEN visible_debug "load_plank_from_file: unable to
>>>>>>>> load slices from """ & filename & """": RETURN 0
>>>>>>>>
>>>>>>>> This doesn't work:  if SliceLoadFromFile fails, it doesn't delete
>>>>>>>> col.
>>>>>>>>
>>>>>>>> I actually have a git branch where I was working on making
>>>>>>>> SliceLoadFromFile return a new slice instead of modify an existing one.
>>>>>>>> Which was a surprisingly large change. I don't remember why I didn't check
>>>>>>>> that in; maybe it didn't seem worth the effort to finish it.
>>>>>>>>
>>>>>>>> BTW, I have been working on changing the way that plankmenus work.
>>>>>>>> I am getting rid of "plank" collections and instead using template slices
>>>>>>>> parented directly to the menu slice collection. Oh... I didn't check in
>>>>>>>> template slices yet either? Well, it's basically just another Slice bit
>>>>>>>> which works very similarly to Slice.Visible. Well, after planks are gone
>>>>>>>> maybe plank menus should be renamed... I have a suggestion: Menu Slices. As
>>>>>>>> in, promote them to a new slice type so that they can be used by scripts
>>>>>>>> too, not just from FB. I have a long writeup about this which I haven't
>>>>>>>> finished yet...
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ohrrpgce mailing list
>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>> amster.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>> amster.org
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
>> _______________________________________________
>> 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/20180114/c9eeaa36/attachment-0001.html>


More information about the Ohrrpgce mailing list