Krari AI: Reference notes for MenuItem sliders and Save/Load input

[Krarilotus]

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/+0x44 for minimum, maximum and current value. Operations 1, 7 and 2 read values, request the step and submit a change. +0x20 is thumb width.
• Load scrollbar operation 7 returns visible rows minus one.
• drawHeaderTextBanner at 0x475CC0 appears to take six arguments: the caller pushes six and the callee returns with ret 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.

Save/Load notes · Slider notes

[TheRedDaemon]

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]

Additional reference SHC1.41 rendering findings from the Custom Hotkeys editor (source unchanged):

• Original Save/Load row renderer492C90 calls PencilRenderCore::drawTableCellBackground4692E0 with (selected, rowIndex, 0). The primitive reads ButtonState geometry/hover, draws native GM156 table stripes/selection, and returns with ret 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.
• Save/Load button renderer492A90 calls AlphaAndButtonSurface::renderBasicButton463A90 with (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.
• Declaration mismatch lead with assembly proof: generated PencilRenderCore.hpp/func.hpp declares drawHeaderTextBanner475CC0 with five int parameters. Original Load modal494210 pushes six arguments (text group0x4A, text index2, x, y, width0x130, height), and475DF1 returns with 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]

Follow-up to the Custom Hotkeys native skin findings: two details matter when reusing the existing primitives during gameplay.

• Original Save/Load caption code at492B46 uses font18, y+7, center alignment1 and x+width/2 for its30px buttons. Custom labels can use the published UI renderTextToScreenConst with those arguments rather than duplicating glyph-centering logic. Native PID24132 compared the custom editor against original Load/Back buttons.
• The earlier Custom Hotkeys wrapper forced pDrawBufferChoiceValue to0 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]

Additional original UI primitive confirmed against SHC1.41 SHA256 3bb0a8c1e72331b3a30a5aa93ed94beca0081b476b04c1960e26d5b45387ac5a:

MenuItemRenderFunction_General_TextInputDisplay(0x47CCA0) clears ButtonState.interacting at 0xED31B8, then at 0x47CCC2..0x47CCD7 calls AlphaAndButtonSurface::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.