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
