Oh, yes! And the thing about converting the hard-coded box-styles in built-in menus into new styles -- yes, very much, and that is really high on my to-do list. I might even switch to it next, since maybe I should wait for more dynamic slice attribute features before I proceed with inventory screen changes?
On Sat, Sep 13, 2025, 7:50 AM James Paige <[email protected]> wrote: > > > On Fri, Sep 12, 2025, 11:46 PM Ralph Versteegen <[email protected]> > wrote: > >> Why did Wandering Hamster have those lumps? Is it because you created >> them, or was that due to some work you were doing on the engine but never >> committed? >> I've always confidently assumed that noone has ever created those lumps >> as probably noone knows how to do so properly (needing to import a file >> from a copy of the source code). And if they created them any other way, >> they would have broken their builtin menus and would have been forced to >> delete them or revert their .rpg. I certainly never told anyone to create >> them. But I'd forgotten those lumps aren't even read. (Also, I'm shocked >> it's already 4 years since we made those changes to collection loading!) >> > > Yeah, I must have created those lumps in WH with uncommitted code, but for > a while there I was afraid I had committed it years ago and there might be > a bunch of games. So glad I was wrong! > > >> I also think we should name the lumps differently anyway, using >> descriptive names. walkabouts.rgfx is far preferable to ohrrpgce.pt4. I >> don't want to have to refer to a list of constants every time. >> > > Yes, I agree. For new lumps we should use better names > > >> On Wed, 10 Sept 2025 at 12:18, James Paige via Ohrrpgce < >> [email protected]> wrote: >> >>> Haha! Oh my! >>> >>> After reading the code further, I can see that the lumps inside the rpg >>> file for special screens are not read at all anymore, and as far as I can >>> tell, they haven't been since at least 2021, maybe longer. >>> >>> Looks like I was worried for nothing, and maybe Wandering Hamster really >>> is the only game that still has those completely unused lumps :D >>> >>> So I can already safely make changes to >>> sourceslices/default_item_screen.slice >>> >>> --- >>> James >>> >>> >>> On Tue, Sep 9, 2025 at 6:41 PM James Paige <[email protected]> >>> wrote: >>> >>>> Okay, I thought about it a little more, and I don't need to delete the >>>> lumps or show a pop-up warning >>>> >>>> Very few games will have those lumps, and even fewer (if any) will have >>>> made meaningful edits to them. I might have told somebody to go in there to >>>> change a box style, or change translucency settings, but I don't know if >>>> anybody ever actually did. >>>> >>>> I'll just stop reading those lumps, and log a warning about it. >>>> >>>> --- >>>> James >>>> >>>> On Tue, Sep 9, 2025 at 5:21 PM James Paige < >>>> [email protected]> wrote: >>>> >>>>> So I want to make some changes to the slice collection that is used by >>>>> the built-in item menu. >>>>> >>>>> I realize that this gets loaded from slicetree_1_0.reld inside the rpg >>>>> file. >>>>> >>>>> So to make an engine-side change to it, I have to add a fixbit to >>>>> delete that file, and regenerate it from the default >>>>> sourceslices/default_item_screen.slice >>>>> >>>>> And that of course nukes any changes anybody might have made to it. >>>>> >>>>> I'm thinking having copies of those collections inside the RPG file >>>>> was a terrible idea. >>>>> >>>>> It is very lucky that we hid them inside the "spam" menu, but I really >>>>> have no idea who might have gone in there and tweaked those files for >>>>> their >>>>> own games. >>>>> >>>>> That means I CAN'T delete that file with a fixbit. The best I can do >>>>> is pop up a warning if it exists, letting people know they will need to >>>>> delete it to get new inventory features. (And I have to add a way to >>>>> delete >>>>> it, probably also in the "spam" menu) >>>>> >>>>> It was a mistake to put a copy of the slice collection in the rpg >>>>> under any circumstance, and it is a mistake to allow end-users to edit it >>>>> (Thank goodness I never got further on the plan to allow that) >>>>> >>>>> So where does that leave us? >>>>> >>>>> I still want to continue adding features to the built-in items screen. >>>>> Some of them have to have hard-coded magic no matter how many slice >>>>> features we add. >>>>> >>>> >>>>> So here is a rough plan of what I hope to do: >>>>> * Disable creating slicetree_1_0.reld inside the rpg file >>>>> * Add a safety backcompat warning when you open an RPG file where that >>>>> lump exists. Add an option to delete it to allow those few games that >>>>> might >>>>> have customized it to delete it if they want to un-break new items menu >>>>> features (I REALLY hope there aren't too many of these games) >>>>> * I can then refactor sourceslices/default_item_screen.slice as needed >>>>> without fear of further breakage beyond the above >>>>> >>>>> As for how to give game authors access to edit built-in slice >>>>> collections without breaking future-compat of their games, I don't know >>>>> how >>>>> to move forward with that yet. Probably the best option is a split path: >>>>> 1. Further built-in customization of specific things like number of >>>>> inventory columns, or which box styles to use. >>>>> >>>> 2. Continue adding features that will facilitate people scripting their >>>>> own completely custom special screens not dependent on the slice >>>>> collections of the built-in screens, >>>>> >>>> >> This sounds like you're thinking of abandoning the plan to let people >> customise the collections. I don't agree with that: we should let people >> customise them, because it is a hundred times less work to tweak a slice >> collection than to script a custom menu, and I very much want to encourage >> that personalisation. (I'll also note running scripts inside the builtin >> menus would be another way for people to customise them, which also makes >> games reliant on the existing collection structures.) >> > > Yeah, I panicked. Exposing built-in slice collections is still a good > idea, once we are properly prepared. > > > >> Yes, new features (e.g. adding tabs to the Status screen so that the >> different modes are discoverable) will sometimes require we edit the slice >> collections, and anyone who is using a custom collection will miss out on >> it, but I think it's far more important to let people create the game they >> want, than to preserve our ability to retroactively improve the UI in all >> existing games. As long as the builtin UI already fully supports all input >> methods on every platform, we don't *need* to retroactively improve it. >> >> We should try to make the existing collections and builtin logic robust >> to anticipate likely future changes before we allow people to change them, >> which is why I've been against exposing the editors until now. In general, >> we will need to be conservative, disabling new logic (e.g. to modify >> properties of slices) that could break existing games, but we can take >> steps to allow us to increase the scope of changes we can make without >> breakage. There are many different types of robustness, one of which is >> avoiding the need for people to edit their collections to make use of a new >> feature like variable-width font, because the default collection already >> used clipping containers before it was necessary. >> >> Builtin logic should be disabled if the requisite slices (marked with >> lookup codes) are missing, and also any corresponding editor settings for >> new features, e.g. number of inventory columns, should ideally be greyed >> out, with explanation. We should make it easy to switch between the default >> builtin collection and customised ones in the editor (e.g. collection ID 0 >> could be the default, and uneditable) so you can see what's changed and to >> copy slices over. And add a setting to select which of the multiple >> collections should be used. >> > > Yeah, this is all good, and I do feel reassured. I like the idea of > getting out certain editor settings when certain lookup codes are not found. > > >> For example, the controls in the inventory screen should just work >> regardless of the number of columns. Isn't that the point of plankmenu? So >> ultimately we won't need a setting to change the number of columns, but >> feel free to add one now. >> > > You are right! I tested this on a game with a wife screen size, and > changing the grid slice with F8. Everything still works perfectly with more > columns > > The slice editor is intimidating to learn so settings like that which make >> it easier to change UI seem useful. More useful still would be settings to >> change UI elements like background rect translucency across multiple >> menus... That's really what the box styles editor *should* be for. I think >> we should duplicate all the box styles used in menus, and clearly label >> them. How boxstyles are used by builtin menus is a very FAQ. End digression. >> >> Context vars and dynamic props are already implemented and usable and I >> was meaning to prod you to use them! What's missing is there is no >> saving/loading of dynamic properties in slicetree files; one of the things >> I was going to add next, but that's not a problem for menus that don't load >> collections from files. Also note. you need to manually >> call UpdateSliceDynamicProps each tick. >> I haven't finished it yet but I'm also working on allowing dynamic >> properties to be expressions containing arithmetic and comparison >> operators, global variables, builtin globals/constants, function calls, and >> 'if' operators. Functions include things like the parent's width/height. >> I'm leaning towards using - instead of -- for subtraction. >> >> I want to cut down on the amount of hard coded logic, and number of >> special lookup codes, as much as possible. For example SL_STATUS_PORTRAIT >> can be replaced with .record = {portrait} and SL_STATUS_HIDE_IF_NO_PORTRAIT >> can be replaced with Visible = {portrait >= 0}. A big advantage of context >> vars and dynamic properties is that it's much less magic, although it's >> more steps than just setting slice properties from FB. The variables still >> are set by hidden logic, and magic lookup codes are replaced by magic >> context vars, but how those values are applied to the slices is not hidden >> and can be changed. And getting rid of lookup codes gives people far more >> flexibility e.g. to replace one slice with two. >> >> A lot of the builtin logic is for changing the sizes and position of >> slices depending on the amount of content or screen size, and that's really >> hard to formulate for arbitrary collections. We use dynamic properties to >> improve the situation for these too. At the simplest level we can put our >> computed slice sizes/positions in context vars and do something like >> infopanel.Height = {default info height}. This way, anyone can easily >> override the builtin logic, or adjust it to {default info height + 4}. >> Better still we can put at least part of the calculation in the dynamic >> prop, like {visible stats * 10 + if(hero has LMP, 20, 0) + 20} (poor >> example, because actually we should finish off 'Cover Children' and use it >> a lot). >> > > That's great! I guess I didn't realize how much of that was done already, > and yes, when it is all done I need to use it very much! > > Also "Cover Children"! I knew we had started that, and it was unfinished, > but I couldn't remember what it was called and was having trouble finding > it :D > > So the new built-in magic I wanted to add was to make the inventory > description box taller if the lines wrapped. I wanted the inventory area to > shrink in proportion, within reason. > > I think if I finished Cover Children and used it for the vertical size of > the description box, and then maybe use that height as the value for a > dynamic property to size the panel slice, it might work with no hard-coded > logic? > > >> >> >>> >>>>> Thoughts? >>>>> >>>>> tldr; reviewing the current built-in items menu code made me fear that >>>>> I was going down a bad path, even worse than the flexmenu debacle. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>> Ohrrpgce mailing list >>> [email protected] >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >>
_______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
