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
