On Nov 12, 2007 2:02 PM, James Paige <[EMAIL PROTECTED]> wrote: > On Sun, Nov 11, 2007 at 10:20:15PM +1300, Ralph Versteegen wrote: > > On Nov 11, 2007 7:42 PM, James Paige <[EMAIL PROTECTED]> wrote: > > > > > > On Sun, Nov 11, 2007 at 07:12:18PM +1300, Ralph Versteegen wrote: > > > > On Nov 11, 2007 6:30 PM, <[EMAIL PROTECTED]> wrote: > > > > > james > > > > > 2007-11-10 21:30:27 -0800 (Sat, 10 Nov 2007) > > > > > 169 > > > > > Implement the "Close if selected" bitset for menu items > > > > > Also fixed a bug where using an item from your inventory that > > > > > triggers a text box was failing to close the > > > > > menu > > > > > --- > > > > > U wip/game.bas > > > > > > > > Not that I've looked at your changes, but I've noticed several item > > > > use bugs lately. I wonder what happened? > > > > > > Can you be more specific? What sort of item use bugs? > > > > > > --- > > > James > > > > I've only made some notes of symptoms, I'll investigate and fix them > > later (specifically, I think graphic glitches, glitches in the hero > > chooser, missing sound effects, ???) > > Hmm, okay, well let me know what you find out. > > > Which reminds me, was there a plan to extend the hero chooser? For > > instance, for it to show various (specifiable) data, like HP or name, > > for each hero? And that this would somehow be built into the new menu > > system? > > I have been thinking about that. I'm not sure how it would work yet, but > I would like to do something like that. > > One possibility is to implement a Final-fantasy-esque > hero-status-summary-and-chooser which can optionally be turned on for > *any* menu. > > Another possibility is to make an editor that allows you to arrange > various information displays, including menus... something like the > "rectangle collection" editor that I have discussed previously. I > imagine a tool flexible enough to reproduce all of the existing standard > menus... but it sounds like a heck of a lot of work, and I am not sure > if I am ready for it yet...
I don't think we need the ability to reproduce the existing menus, or at least not worry about it until down the road, if it's possible without terrible complexity. Here's a rough idea for allowing complicated hero choosers and other graphical things people want, but its perhaps a little unwieldy: -Optional: Implement an option on menus for a special menu item data type, so you could make a custom menu for selecting heroes, items, spells, etc (actually I can't think of many other special types... maps?). If you don't do this, then you would allow menus of mixed types instead, which might end up confusing? Either way: -Add ability to associate data with each menu choice. For example, in the menu item editor, you could specify "Selects hero: Bob" on an item, or "Selects 2nd hero" Actually, what we really need is 'template' menu items. You would create a single menu item "for each active party hero" for example, and when you access this menu in-game, this item would be duplicated however-many times. Each of these would be associated with a different hero, but appear identically (for the moment, see below) -In addition in menu items, add graphical (non-selectable) objects to menus. These come in two sorts: linked to a menu item (editor accessed via menu item editor), and linked to menu (editor accessed directly from top menu). Where an id is required, Some types of graphical objects: =Walkabouts *ID/palette: either hardcoded, or "current selected hero" (global menu graphic only) or "menu item hero" (menu item graphic only) *Options: direction, animated/nonanimated/animated if selected =Strings *Subtypes: Normal string *Subtypes on a Hero (of a hero either hardcoded/selected/menu item as above): Name, current stat number #, current/max stat #, hero level, FF1 MP *Subtypes on an Item (as above): Name, description, Name x count, count, others? *Etc *Options: foreground/background colour (as a UI colour?), what to do (eg, blink, colour) if selected (if attached to a menu item) =Hero graphics *Options: frame/animation both for unselected (or not associated to menu item) and selected =Other graphics? =Rectangles and lines? =All would also have the option to not appear at all if associated with a menu item which isn't selected, or disabled And then allow these to be positioned relative either to the menu, or to the menu item depending on what sort it is. -Menu items would be composed of a single string by default, which ought to be a graphic so that its type can be changed. See the example below. -We'll probably options to set the size of each menu item too, so that the menu knows how far apart to place the items. -Optional/later: Options for the layout of menu items, to allow horizontal placement of menu items, like the current hero chooser, or a grid pattern like the item menu. Now, to construct a hero selector, for example, you would create a new menu (special menu type: hero, horizontally arranged menu items) with a single menu item "For each active party hero", add a walkabout graphic to that item with the options: id/palette: "menu item hero", direction: down, animate if selected, position the walkabout a bit above the default menu item string. Then you can either leave the menu name blank, or change its type to "Hero name:menu item hero". Maybe you need to set a rectangle for the size of the menu item, to help the layout of the menu, and you're done. > > > Well, not anymore I suppose. But it would still be A++ super > > for scripts (a way to construct simple menus with scripts, like > > "choice := create menu (2 [a string id], $"Next", $"Help")" would also > > be really cool, but not at all necessary I suppose, because you could > > do the same thing with more work in the menu editor) > > Yeah, I would like to talk about how a plotscripting interface to the > menu system should work. > > Of course there should be commands to open and close menus created in > the editor, but there is no reason we couldn't also have commands to > generate a menu entirely by script. > Well, first of all, if we can call menus by scripts, we should also be able to set the return value somehow (linking every item to a script or tag is absurd). Returning the number of the menu item selected (if the menu has the close on selection bit) might not be too useful, especially if something like the above 'template' idea is implemented, but could be the default. Useful would be the hero number of menu items which are of the hero subtype, etc. The scripting interface will get complicated very quickly, I'll leave it until later. > --- > James TMC _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
