I think we should add default transparency/translucency settings to box styles, with existing textboxes and rect slices overriding them instead of using the defaults... although "set rect style" would be a problem. Maybe existing box styles should be initialised to "unspecified" transparency which does not modify rect slices when the style is applied. I mention this because some of the box styles are used in builtin menus as either opaque or transparent boxes so separating those into two box styles would provide much better control.
I want to add gradient, textured (repeating sprite) and maybe 9-slice box backgrounds. By the way I think we should add more box styles rather than limiting to 15. I don't think there ever was a good reason for that limit. On Sun, 14 Sept 2025 at 00:05, James Paige <[email protected]> wrote: > 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? > Well, if you already have useful changes you could commit them and we can change it later. I'll try to do some work now on dynamic props and other things to make them usable for that. > > 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? >> > Cover Children only appears in the slice editor in priviledged/editor mode. It works and is already used in a couple places, but IIRC interacts badly with Layout slices and Fill Parent, in which case it requires multiple slice refreshes to settle. It might need some substantial implementation change to fix. BTW, Cover Children does nothing on Grid, Panel and Layout slices, although the slice editor doesn't disallow it yet. Layout slices are also still hidden but are basically done. I only wanted to change one small edge case concerning how they interact with Fill Parent. I think. It's really time I got onto that. I'll take a look tomorrow. One option would be to use Cover Children to have the description box cover the text, then parent it to a layout slice set to place children in columns growing upwards, which has two children, first the description box and then the item list. Then have the item list set to Fill Parent so that it takes up the unused vertical space in the column above the description. However IIRC having Fill Parent fill the rest of a row/column like that is exactly the edge case behaviour that I want to implement, but which doesn't work like that yet. I also wish Panel slices could do the same thing, with a setting to use the size of the first child plus padding and give the rest of the space to the second child, as I think that would be more intuitive. I think that when you first implemented panels, I hoped that they could do that. By "use that height as the value for a dynamic property to size the panel slice" do you mean having a function that can be called in a dynamic property to get the size of a certain child ("child width(index)"?) Like Cover Children, that has the problem that there would be a one tick delay before it sees changes to the child's size. I guess it could force an early/additional refresh, like the "slice screen x" command. With some work the double refresh could be optimised away. Actually, functions getting the size of the parent slice also currently would have the same problem, because UpdateSliceDynamicProps would be called before all refreshing. I'm not actually sure yet about when dynamic properties should be evaluated. I was thinking of moving it to inside RefreshChild/etc (however that currently only happens for slices that are drawn, but that matches how Select slices work), or maybe even inside AdvanceSlice (which advances animations) > >> >>> >>> >>>> >>>>>> 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
