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!)
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. 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.) 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. 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. 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). > >>> 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
