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

Sun Jan 14 06:54:36 PST 2018

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".

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).

>
> 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/ohrrpgce/commits/d1963ff335e7afd8e
>>>> 82d12dd1d92df3251b2f6e8?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-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
>>
>>
>
> _______________________________________________
> 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/20180115/4edf665d/attachment-0001.html>