Talk:Plan for converting special screens to slices

TMC (talk): In addition to text embed codes we will also need special slice lookup codes for non-text template things: sprites for heroes in the hero picker and, eventually item graphics. Also, the containers that should contain menu tiles would need to be indicated with lookup codes. I suggest that the tiles be placed directly in the same slice collection as single children of the relevant slice so that they can be edited in context. But then the slice editor would have to track

How are menus going to work? They can track the current viewing position because that's just stored as the offsets of the children of the ScrollSlice. But we're going to need a generic data structure that stores what the currently selected menu item is (probably just as a child number rather than a slice handle). Maybe we want to support menus where the menu items (tiles) aren't directly parented to the ScrollSlice, but there is are some additional container and other decoration slices in between, for example:

Scroll slice

• Rectangle slice
  • Grid slice
    • A number of tile slices which are SelectableSlices

So I suggest something like:

Type SliceMenu
 selected_item as integer
 scroll_slice as Slice ptr
 items_parent_slice as Slice ptr
End Type

plus a a function to focus on a particular child and a usemenu equivalent

(I'm not that comfortable with storing slice pointers in general though; maybe it would be reasonable to use slice handles to avoid a class of bugs?)

I'd like to see customisable menus as part of the plan too. If they are part of the slice tree then it will be possible to draw over them, swipe them in from the side of the screen, etc.

Also, SelectSlices for selectable menu items seem really labour intensive to use because you've got to make so many copies and then customise the textcolour or whatever. I don't see a better way that's still completely general. (Complete generality shouldn't be the main goal though.) Notice that it would be very rare that you actually want to create a unique selectable menuitem/button. I think we need some kind of shortcut that creates the SelectSlice and all its children from a template. Maybe an extra option in addition to the slice types when adding a new slices? But that (or manually copy-pasting it) wouldn't make it easy to change the text or other property; you'd have to change all the copies. Still trying to think up improvements...

And we should probably have ${STAT:#}, ${MAXSTAT:#} and ${BASESTAT:#} as alternatives to the builtin names.

Bob the Hamster (talk): I guess I didn't spell it out explicitly enough in the plan, but yes, I do indeed intend to use lookup codes for marking a bunch of things, such as sprites and container grids, as well as indicating SelectSlices within "Tiles" or the few standalone buttons

I don't understand this suggestion: "I suggest that the tiles be placed directly in the same slice collection as single children of the relevant slice so that they can be edited in context"

I plan for menu handling to still be somewhat hard-coded for each type of special screen. For example, the equip screen has two modes hard coded into it, one for your equipment list and one for the list of equipable stuff. The slice collection lets you customize how those two modes are visualized, but the switching between them is still hardcoded. The individual menus that are based on tiles embedded in a grid will be handled with a specialized (but relatively generic) function that uses a MenuState, or something very similar.

There will be a helper function for when a menu item tile is selected. First it will use a lookup code to find the tile's SelectSlice and change its state. Then it will look up the parent tree for a ScrollSlice, and if found, it will move the container grid so that the selected tile is scrolled into view. I am probably not doing a great job of explaining it, but I have a pretty clear idea of how it will work in my head.

I understand your suggestion about the SliceMenu type, but I don't know how to make that work with the slice editor. We don't have any way of saving/loading slice-to-slice into the .slice reload document

However, I think a type like that could be useful internally to the implementation of special screens using slice collections.

Is this line: "I'd like to see customisable menus as part of the plan too. If they are part of the slice tree then it will be possible to draw over them, swipe them in from the side of the screen, etc." talking about MenuDef menus? If so, I agree that making them more customizable in this way is good, but I want to finish this plan first before I tackle those.

I agree that SelectSlices are rather cumbersome, but I think they will still be usable, and I can't think of anything better at the moment.

It might pay to create something like a MenuTextSlice which is a superset of TextSlice that allows color selections for all of Normal,Selected,Disabled,SelectedDisabled,Special,SelectedSpecial. Collections such as the Inventory Item Tile would use a special lookup code to indicate which SelectSlice(s) should be used for indicating selection, and there is no reason the same lookup codes couldn't point to a MenuTextSlice as well.

Oh! I was also surprised to notice the MenuSlice and MenuItemSlice types that are implemented in slices.bas I had been ignoring that code, incorrectly assuming that the whole block was still commented out. I am unable to see any place where they are actually used.

And I like the "${STAT:#}, ${MAXSTAT:#} and ${BASESTAT:#}" suggestion. I will do that.

TMC (talk): All of your explanations are clear (and answer most of the questions I had which you didn't understand) except for a couple:

I don't understand this suggestion: "I suggest that the tiles be placed directly in the same slice collection as single children of the relevant slice so that they can be edited in context"

Sounds like you were going to do anyway (which is what I assumed), and marking the menu tile slice with a lookup code.

Rather than the MenuTextSlice you mentioned, I would just use the colours that are defined in the UI Colours menu. It would be pretty rare that you would want to do a different set of colours, and if you did you could use the maximally general SelectSlice approach. In fact maybe we could have a special UI colour index for TextSlices which causes it to use whichever of the Selected, Disabled, etc, UI colours is appropriate.

I understand your suggestion about the SliceMenu type, but I don't know how to make that work with the slice editor. We don't have any way of saving/loading slice-to-slice into the .slice reload document

I don't know what you mean by "slice-to-slice" loading. Anyway it's a runtime datatype, like MenuState, so would never be saved.

The individual menus that are based on tiles embedded in a grid will be handled with a specialized (but relatively generic) function that uses a MenuState, or something very similar.

This is actually the SliceMenu datatype and methods I was suggesting. I assume we'd get rid of .first. .last would be replaced with the number of menu item slices actually present. .rect, .spacing, .top, and .size members of MenuState would no longer be needed because the ScrollSlice handles that. tog isn't needed because of TextSlice UI colours. .active and .need_update would probably still be useful (so could go in SliceMenu). Not sure about .has_been_drawn

Is this line: "I'd like to see customisable menus as part of the plan too. If they are part of the slice tree then it will be possible to draw over them, swipe them in from the side of the screen, etc." talking about MenuDef menus?

Yes. I think it's very closely related, though I guess it will have its problems to overcome.

I forgot we had those Menu and MenuItem slices too. They've been there for 5 1/2 years! They don't fit into this plan so probably about time to delete them.

Bob the Hamster (talk):

"In fact maybe we could have a special UI colour index for TextSlices which causes it to use whichever of the Selected, Disabled, etc, UI colours is appropriate."

Hey, I like where you are going with that. I feel like I would still want it to be possible to have some text in a whatever-menu-tile collection that does not auto-color, so perhaps rather than a special uicolor index, what if there was a new TextSlice boolean property that toggled whether or not it uses magic menu colors. When this is turned on, the manual color options could vanish from the editor. [EDIT: re-reading what I just said, I realize it isn't actually meaningfully different than what you were suggesting already :) ]

I have no idea what I meant by "slice-to-slice" loading either! I think I must have been typing something else, changed my mind, and failed to delete it completely. Your clarification about MenuState being a runtime type only clears things up for me. I was misunderstanding before.

I think that the tools created for completing this plan will make it much easier to convert user defined menus, but even more excitingly, I think I can use all this stuff for converting battle to slices too! :)

TMC (talk): If such a meta-selection UI colour is used, it would probably imply that it's on a TextSlice which is a descent of a SelectSlice (because something needs to store the selection state) which doesn't have multiple children but always shows the same thing. So I suppose these means that SelectState would have two modes: multiple children, or just one child which is rendered differently?

In future, spritesets could also have animations (possibly single frames) labelled as 'Selected', 'Disabled', etc, which work in the same way as the UI selection meta-colour. That would help cover a lot of use cases without having to use duplicate SelectSlice children.

Also, I meant to say that if you search the slice tree using lookup codes, then the hypothetical MenuSlice UDT would only need to store a single slice ptr, or even just a lookup code if a unique one exists. (My guess is that you were thinking about serialising Slice pointers)

TMC (talk):

I don't understand this suggestion: "I suggest that the tiles be placed directly in the same slice collection as single children of the relevant slice so that they can be edited in context"

Sounds like you were going to do anyway (which is what I assumed), and marking the menu tile slice with a lookup code.

Looking at your recent changes, I see that I was wrong here: the tiles are totally separate slice collections. I was suggesting that the menu slice collection and all the tiles be part of a single slice collection and then separated when loaded in-game by lookup codes. I think that would make it easier to see what the final menu is actually going to look like, especially for the load and save menus. But of course I understand that this adds additional work to coding the slice editor, which would need to treat the tiles as different special slice collections...