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