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, >> >> 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
