I am continuing to think about saved slice collections. I think I would like to have multiple separately indexed groups of slice collections.
For example, group 0 would be collections for the user to load with plotscripting. And maybe group 1 would be layouts for individual save games on the save/load screen. You would normally only need one of these in the group, but you could have more. And maybe group 2 would be layouts for save/load screens. You would normally have two of these, one for save and one for load. (but you could have more if you thought of a reason) And maybe group 3 would be layouts for the status screen. Again, you only need one, but you can have more if you want. And we would go on allocating groups of slice collections for different purposes as we ensliceify various screens. And soon I think I will start work on an EmbedSlice which is a container for another slice collection. The slice collection editor (which I am going to get around to officially renaming one of these days) would not be able to *directly* edit the children of an EmbedSlice, but it will be able to jump into a sub-editor for an embed slice, (which will be exactly like the regular editor but with the root slice constrained in size) I am also wondering how commands that search the slice tree should handle EmbedSlice. Should they search its children just like with a ContainerSlice? Or should tree searches stop on EmbedSlices, and expect the scripter to do another search rooted at or below the embed if they want to search inside it. (I am leaning towards the latter, but I value input on the subject) --- James Paige _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
