Plan for slice tree

An interface for positioning, sizing, and styling floating rectangles or "slices" will unify the display of various types of positionable visual elements, as well as providing a single plotscripting interface for moving all such elements. It will make future menu/UI customization easier.

• implement a tree of slices, including their position, size, parent, color, and border style, and type and various other attributes. (in progress)
  • basic framework for trees of slices (done, press CTRL+F8 in wip version to run tests)
  • rectangle slice type with borders (done)
  • string slice type (done)
  • sprite slice type (done)
  • map layer slice type (mostly done)
    • Currently only supports slices representing the layers of the current map. There is not yet any way to load slices of non-current maps
  • backdrop slice type
  • grid slice type (done)
  • meta slice type, possibly editor-only
  • Add support for cropping/clipping slices (mostly done)
• retrofit existing display code to use slices wherever appropriate (started)
  • We can do plotstrings and plotsprites first. They will be easiest
    • draw plotsprites using slices (done)
    • draw plotstrings using slices (partly done)
  • We can do menus next, they will be relatively easy with the experience we gain from having already done strings and sprites
    • menu slice type (actually a compound slice of a box and some strings) (in progress)
  • textbox compound slice (done)
  • draw map layers using slices (done)
  • implement special menus with slices (more details below)
  • Different layers can be converted one-at-a-time with separate calls to DrawSlice(). Once all layers are converted, all these separate calls can be replaced by one DrawSlice call that uses SliceTable.root (in-progress)
• provide an interface (both in FreeBasic and in Plotscripting) to create a slice reference, which can then be controlled (done)
• provide an editor in custom that lets you visually arrange a rectangle collection with a given set of members. It should be possible to give these members symbolic names. (in progress)
  • slice collections will be divided into categories.
    • category 0 will be for user defined collections for plotscripts
    • other categories will be as templates for specific kinds of special formats for customizing built in screens menus and interfaces.
      • These categories will often only need to contain one slice collection.
      • I see no reason why plotscripts should not be allowed to load from the other categories too (category 0 is just specifically for plotscripts)
  • The slice collection editor should be usable to create templates for different purposes, such as a "battle interface layout" template, or a "equip menu layout" template, in addition to the generic "slice collection" templates for plotscripts.
• retrofit text boxes and ui menus to be customizable using the aforementioned slice collection editor
  • provide default slice collections that match to the existing structure of various ui menus (for backcompat)
    • Item menu
      • outer border (solid)
      • inner border (invisible, width determines number of columns)
      • info line (translucent)
    • Status menu
      • outer border (translucent)
      • header box (solid)
      • portrait box
      • stat box (solid, list should be scrollable, data to control which stats show up belongs in the hero data)
      • Misc stat box (solid)
      • HP pos
      • MP pos
      • Level MP table pos
      • money pos
    • Spell menu
      • outer border (translucent)
      • spell list list (solid)
      • hero name line (solid)
      • spell list border (solid)
      • spell list inner border (invisible, width determines columns)
      • cancel box (solid)
      • cancel string position
    • Equip menu
      • outer border (translucent)
      • Hero name (solid)
      • Hero portrait box (doesn't exist now, probably should)
      • equip type caption (solid)
      • stat preview (solid, data to control which stats appear belongs in the hero editor)
      • equip slot list (solid)
      • available equipment (solid, modal)
      • item info line (doesn't exist now, probably should)
    • Order menu
      • Hero name
      • Active party
      • (note, this also needs data to control whether the list should be horiz or vertical, and whether to use walkabouts, battle sprites, portraits or names. Does this data belong in the rectangle editor? probably not...)
    • Team menu
      • Same as above, plus a box for the reserve party
    • Save menu
      • Maybe there should be a separate rectangle collection for one save game info panel, and the save/load menu rectangle collections should just arrange several of these panels
    • Load menu
      • Same as above
    • hero-picker (like for entering spell or status menus)
      • See notes on Order menu
    • hero-picker (like for targetting cure spells and items outside of battle)
      • See notes on order menu. A "panel" based approach might work here. Should provide a box that could be filled with the current attack's target stat (would replace the current behaviour of always showing the target's HP)
    • Shop menu
      • Shop name (solid)
      • Shop options (solid)
      • Shopkeeper portrait box (doesn't exist yet)
    • Shop (buy/sell)
      • Available stuff outer box (solid)
      • Available stuff inner box (width would determine columns)
      • Selecting stuff info box (solid)
      • my gold box (solid, current position is confusing)
      • selected stuff price (solid, current position is confusing)
      • Selected stuff name
      • Selected stuff description
      • Selected stuff stock availability
      • Selected stuff equipability preview
      • Selected stuff how many you already own (doesn't exist yet)
    • Inn
      • Hero stats box (solid)
      • Inn outer box (translucent)
      • Inn price position
      • Your money position
      • Inn choice position (solid)
• make a plotscripting interface for loading slice collections you have created in custom (to make it easier to script completely unique menus)
• even some screens in custom could benefit from the slice interface. Although it makes little sense to have a user-rearrangeable sprite editor, converting the sprite editor's ui to use the same rectangle collection interface could make it easier for us to make changes and improvements with less work and less chance of breaking things.

Relative positions

A slice's position and can be relative to the whole screen, or relative to another existing slice, but the default is for it to be relative to the slice's parent. (slices are always relative to the screen in the current implementation, but plotscripting commands are provided for screen-oriented positioning)

Depth

Slices need to share a global "depth stack" with custom menus and text boxes, so that one will be able to do floating rectangles both on top of and underneath menus (already done for text boxes)

Top-level Pre-defined collections

Several pre-defined rectangle collections will be used to handle layering.

A plotscripter will be able to manually re-order these layers, insert new top-level container layers, and to move menus, boxes, strings from layer to layer. the above specification just provides the framework for (A) re-creating the existing behaviour in an extensible way (B) making it easy to fix bug 531 without hacks that will needlessly complicate future backcompat.

Handle numbers

scripts will access slices using handle numbers. These are arbitrary numbers which are allocated internally. The script author should not attempt to anticipate which numbers will be allocated, nor should they assume that the numbers will be allocated the same way in two different runs of the same script. Looping through handle numbers can be accomplished with commands like "first child" and "next sibling" (done)

Some special slices can also be searched for using slice lookup codes. see the "lookup slice" command (done)

In addition to the hard-coded lookup codes, the game author should be able to name user defined lookup codes. These names will be exported to the HSI file.

Draw Order

The slice tree is drawn depth first. The root is draw first. Then the first child of the root, then the first child of that child, and then the first child of that child. Only when a slice has no children does the drawing proceed to the next sibling slice, and only when a slice has no more siblings will the next sibling of the parent be drawn. Control over the drawing order of slices will be accomplished with commands such as "move slice behind" "move slice in front of" "set parent" ("set parent" is done)