Repository navigation
Reference notes for MenuItem sliders and Save/Load input #229
Description
TL;DR: Reference notes for anyone reconstructing the native menu sliders and Save/Load dialogs. No implementation is requested by this issue.
These observations explain how the existing controls pass values and handle keyboard input. They may help avoid reconstructing those behaviors incorrectly.
Proposed change: Use these findings when the corresponding functions are implemented:
- Save modal 10 uses text entry 2. Return invokes the existing Save action and overwrite confirmation; Load modal 9 uses a selectable list.
- Slider callbacks use the MenuItem fields at
+0x3C/+0x40/+0x44for minimum, maximum and current value. Operations 1, 7 and 2 read values, request the step and submit a change.+0x20is thumb width. - Load scrollbar operation 7 returns visible rows minus one.
drawHeaderTextBannerat0x475CC0appears to take six arguments: the caller pushes six and the callee returns withret 0x18. Check the five-argument declaration.
Status / review: Version: SHC 1.41 West. Findings come from assembly and native control checks; no implementation or binary match is claimed. This can be moved to project documentation if an issue is not the preferred place for reference notes.
Activity
TheRedDaemon commentedon Sep 11, 2026
Sorry, I have actually no idea what you want. Can you reparse your text with the instructions to clearly lead with an intention and context in simpler words before going into technical details?
Also, can you tell it to drop or shorten the prolog and epilog?
We usually assume you talk about SHC 1.41 West, since that is the main goal of the repo (others to follow, maybe, they might also end up in other repos). Or you can keep it as
Version: 1.41 SHA: ...In general there is a lot of context noice from what you are currently working on here, I assume. That is just not helpful. It could really need a filter pass.
Krarilotus commentedon Sep 12, 2026
Additional reference SHC1.41 rendering findings from the Custom Hotkeys editor (source unchanged):
(selected, rowIndex, 0). The primitive reads ButtonState geometry/hover, draws native GM156 table stripes/selection, and returns withret 0x0c. It does not need the Save/Load list model. Calling this primitive directly lets another native menu reuse the original skin without duplicating the row renderer or save-data accesses.(0, -1). The UI owner's published renderButtonBackground API exposes this primitive. Custom Hotkeys uses an explicit render target while preserving/restoring ButtonState.interacting for keyboard focus.ret 0x18. The sixth argument appears unused by this function, but is part of the original ABI. I did not call this function through the five-argument declaration or change generated files. A faithful reconstruction/metadata correction should retain six arguments.Reference SHA256
3bb0a8c1e72331b3a30a5aa93ed94beca0081b476b04c1960e26d5b45387ac5a. Native PID31988 loaded Custom Hotkeys10a6792, UCP3.0.7-77c6a/UI1.0.1 at1280x720; original table stripes, normal buttons, keyboard selection and both editor pages rendered correctly. The table/button primitive reuse was tested; the header ABI finding is static assembly evidence, not a reconstructed-build/reccmp result. No OpenSHC or other owner's active branch was edited.Krarilotus commentedon Sep 12, 2026
Follow-up to the Custom Hotkeys native skin findings: two details matter when reusing the existing primitives during gameplay.
renderTextToScreenConstwith those arguments rather than duplicating glyph-centering logic. Native PID24132 compared the custom editor against original Load/Back buttons.pDrawBufferChoiceValueto0 and supplied basic-button target0. That worked in the frontend but produced missing table/button textures during gameplay, reproduced in PID24132. The correction preserves the native menu renderer's current texture target; basic buttons use the original target-1 convention. At463B23 the primitive resolves-1 through46BB60, and its exit restores the prior target at1FEA094. Table-cell4692E0 inherits the current texture surface through4557B0.Frozen extension18ca42f, native PID16012, verified the correction on both gameplay editor pages after starting A Mighty Oasis: red rows, selected row, standard buttons and centered captions appeared normally. No Lua error. Reference executable remains SHC1.41 SHA256
3bb0a8c1e72331b3a30a5aa93ed94beca0081b476b04c1960e26d5b45387ac5a. No OpenSHC reconstruction or shared-owner branch was changed; these are reuse/ABI/ownership receipts for the existing primitives.Krarilotus commentedon Sep 12, 2026
Additional original UI primitive confirmed against SHC1.41 SHA256
3bb0a8c1e72331b3a30a5aa93ed94beca0081b476b04c1960e26d5b45387ac5a:MenuItemRenderFunction_General_TextInputDisplay(0x47CCA0)clearsButtonState.interactingat0xED31B8, then at0x47CCC2..0x47CCD7callsAlphaAndButtonSurface::renderBasicButton(0x463A90,this=0xF2C7BC)with style -1, surface -1. That is the reusable recessed text-field background; ordinary buttons use style0. The rest of47CCA0 reads the global UserTextHandler and renders its caret/text, so it should not be reused wholesale for an independent editor field.Custom Hotkeys now uses the published UI primitive with that style/target, temporarily restoring ButtonState.interacting afterward, and retains its existing exclusive draft-text owner. Frozen6a952f9/PID7852 verified the recessed search field and live filtering in-game without native text-state ownership changes. This is a caller/primitive finding, not a reconstructed C++ match or broader keyboard/replay acceptance claim. Evidence.
[-]Document verified Save/Load input owners and native scrollbar paging[/-][+]Reference notes for MenuItem sliders and Save/Load input[/+]