On Sat, Sep 13, 2025, 10:06 AM Ralph Versteegen <[email protected]> wrote:
> > 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. > Yes, that is a good idea. I can work on adding those to box styles. "Unspecified" transparency is a good idea too, I think that will work well. I will work on those. 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. > Yes, although I wonder what is the best way to keep separate the generic box styles, and the new ones from special screens. I still want a simple integer I'd for box styles. Maybe positive numbers for user styles and negative for special styles, or maybe special styles start at 10000 or something, and I just make the editor smart enough to only show the ones that have been used. > 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. > I don't have anything uncommitted right now. I was working on a new item screen collection but loading/saving it always removes the templates, so I didn't get anywhere with it. > >> >> 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. > Yes, that is a very good idea for Panel slice. That would be a very useful new feature. I might try that one myself if you are working on other things. > 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) > Interesting! I don't know enough about those things to comment usefully. > > >> >>> >>>> >>>> >>>>> >>>>>>> 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
