> > *clip* > > 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.
Actually, when FreeBasic add support for class inheritance (0.19? 0.20?) Then it will suddenly become remarably easy to create some really nice advanced menu customization, so I may just postpone those things till later. > 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: Actually, I was really hoping to do something like this. The things that make sense for a battle menu are different than the things that make sense for a menu on the map. You may notice that in the code is a MenuSet type which currently just defines the lumps used to store menu data, but could later be extended for working with other types of menus. class inheritance would make this much easier, as I could just write one version of the menu editor code, which would call class methods on the menu it works with, which could be different for different menu types. My holy grail is a menu editor for menus in custom (not to save as a lump in the RPG file of course, but to facilitate adding/reaaranging features in custom without too much source hacking) > -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) I don't understand this suggestion very well. Can you re-explain? > -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: > *clip* Hmmm... this is tough. it makes menu drawing and scrolling much harder. I'm not writing the idea off, but I am not prepared to try it just yet. > -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. I think at this point, it gets easier to go back to my idea of a rectangle collection editor, in which the rectangles that you are positioning can be menus, strings, boxes and sprites. > 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. Hmm... Interesting. What imagined for designing a hero picker is something like this: You would first edit a rectangle collection that represented a single hero's info. it would include: a border (invisible or visible) a sprite (walkabout or battle or portrait) the hero's name one or more optional strings representing hero stats one or more optional meters representing hero stats whatever other optional boxes and strings and sprites you add Then you would edit another rectangle collection editor that represents the whole hero picker, which would consist of four copies of the hero info collection that you just created. What I am unclear on is how to specify how your cursor will move over the selectable members of the rectangle collection. it would be nice to support any of in-a-row-horiontally and in-a-row-vertically and layed-out-in-a-grid > > 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. Yes, a return value is doable, but we will have to deal with the fact that menus can be non-modal, in which case a return value would no make sense (or maybe return value could be deffered to a "wait for menu" command for non-modal menus) --- James Paige _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
