Add GetFootIK and SetFootIK GECK script commands to NVSE

[Machiavelique2]

The current ToggleFootIK (or TFIK) command simply toggles the FootIK state, but it does not return any value. This makes it impossible to determine whether FootIK is currently enabled or disabled — which can be problematic when multiple mods interact with it.

This PR introduces two new script commands:

• GetFootIK (alias: GetFIK)
• SetFootIK (alias: SetFIK)

(bool) GetFootIK
Returns the current state of FootIK.
0: FootIK is disabled
1: FootIK is enabled

SetFootIK value:int
Enables or disables FootIK
SetFootIK 1 → enables FootIK
SetFootIK 0 → disables FootIK

⚠️ Note: FootIK state is not save baked, but its value is retained throughout the current game session. Upon restarting the game, FootIK is reset to its default value: enabled.

Also modified PluginManager.cpp to ensure successful build in Release CS configuration (I'm not sure about this part, so just feel free to ignore it).

[WallSoGB]

Seems a bit redundant, everything you did here is functionally identical to calling

SetINISetting "bFootIK:RagdollAnim" value

or

GetINISetting "bFootIK:RagdollAnim".

[Machiavelique2]

Thanks for the feedback — much appreciated!

You're absolutely right that the current FootIK flag can be read/modified via:

GetNumericINISetting "bFootIK:RagdollAnim"
Con_SetINISetting "bFootIK:RagdollAnim" value

However, I still believe GetFootIK and SetFootIK offer a few meaningful advantages:

• Clarity and readability: A command like SetFootIK 1 is immediately understandable, especially for modders who aren't familiar with INI structures or the specifics of where this setting is stored.

• Consistency with existing commands: The game provides TFIK in the console to toggle FootIK, but there’s no dedicated script command. While it’s technically possible to invoke TFIK via Con_TFIK, that approach relies on console execution and may be less intuitive for novice modders unfamiliar with this system. These new functions fill that gap while following the same naming convention (ToggleFootIK, GetFootIK, TFIK, SetFIK, etc.).

• Less reliance on file knowledge: bFootIK lives in GECKCustom.ini, which isn’t intuitive. Its connection to the in-game TFIK behavior isn’t clearly documented anywhere. Many users may not even be aware of the existence of the bFootIK setting, and syntax errors (like typos in the key name) can result in silent failures.

• Safety and precision: Direct memory access guarantees we're reading/writting the exact internal flag, with zero chance of typos.

That said, if it still feels too redundant for the core plugin, I totally understand and respect the decision — OpCodes are a limited resource, and must be preserved. :)

Thanks again for your time and review!

[onv-il]

Thanks for the detailed response — your points are well-reasoned, but I’d like to push back on a few of them to clarify why I still believe this functionality deserves a place in the core plugin.

1. Functional Redundancy Isn’t Always Redundant
   Yes, technically this can be done through GetNumericINISetting and Con_SetINISetting, but wrapping that behind a dedicated opcode has two key benefits:

   Safety and consistency: The wrapper encapsulates the specific INI keys in a way that reduces user error and future-proofs the script against internal changes (like a key being renamed or deprecated).

   Contextual clarity: SetFootIK(true) communicates intent far more directly than parsing numeric keys, improving legibility — which benefits all users, not just novices.

2. Readability Is a Functional Gain
   You mention that experienced modders are already comfortable with raw INI settings. That may be true, but code clarity isn’t just about helping beginners — it’s about reducing friction, bugs, and onboarding cost at every level. Core plugin opcodes like SetGodMode or DisableFastTravel also wrap accessible settings — yet they're retained because they’re useful and expressive.

3. Scope and OpCode Budget Considerations
   I understand opcode space is limited, but reserving it only for things that are strictly impossible elsewhere sets a bar that even some current opcodes arguably wouldn’t clear. The goal shouldn’t be to avoid all overlap, but to ask: Is this common, useful, and clean enough to justify inclusion? I’d argue this addition hits all three.

4. Fragmenting Core Features Hurts Ecosystem Consistency
   Leaving this to a community extension is a nice idea in theory, but it pushes a basic and commonly used feature into optional territory. That increases fragmentation and inconsistency across mods, making collaborative projects or shared scripts more brittle.

In summary, while this addition may appear small, its inclusion would promote better coding practices, improve usability, and reduce subtle bugs tied to manual INI manipulation — all with minimal overhead. I strongly believe it adds real value to the core plugin, and I hope you’ll reconsider its place within it.

Thanks again for taking the time to review and discuss — I appreciate the thoughtful dialogue.

[AVeryUncreativeUsername]

Thanks for the thoughtful reply — you make a strong case, but I’d like to challenge a few of the assumptions underlying it, particularly regarding the trade-offs between clarity, scope, and long-term plugin maintenance.

Redundancy Can’t Just Be Justified by Readability
The idea that wrapping existing functionality “isn’t redundant” because it improves safety and readability sounds appealing — but taken to its logical end, it justifies creating dedicated opcodes for every commonly used INI key. That’s not sustainable. The core plugin isn’t just about making things convenient — it’s about balancing clarity with control, and not bloating the opcode space with things that can be cleanly abstracted by the user if they wish.

Yes, SetFootIK(true) is more readable than an INI call. But scripting clarity is the responsibility of the script author. It’s fully possible to wrap that INI call in your own function and name it whatever you want. Elevating that readability concern into the core plugin is solving a problem that’s already solvable without adding new overhead.

The “Core Plugin = Expressiveness” Argument Doesn’t Hold
SetGodMode and DisableFastTravel are not just expressive — they encapsulate system-wide features with multi-layered impact, often beyond what a single INI toggle handles. Comparing those to a narrowly scoped animation setting like foot IK isn’t apples-to-apples. We need to preserve opcode space for features that extend capabilities — not just polish usability.

Fragmentation Isn’t Avoided by Centralization
You mention fragmentation, but ironically, overstuffing the core plugin leads to the exact same outcome. More opcodes = more to maintain, more to document, more room for divergence in behavior when the base grows too unwieldy. A lean core encourages thoughtful modularization, and pushing some features to community extensions doesn’t fragment — it empowers.

Besides, shared scripts and collaborative work benefit far more from clear conventions than from the core plugin trying to be the one-stop-shop for everything. If a wrapper is that useful, the community will standardize around it — organically.

Summary
I appreciate your focus on quality of life and user experience, but I think we need to be vigilant about what the core plugin should do versus what can be done elsewhere just as effectively. If every helpful shortcut makes the cut, the plugin ceases to be core — it becomes bloated. This proposal, while well-intentioned, opens the door to a precedent that could dilute the focus and maintainability of the core set.

Appreciate the discussion — always good to sharpen our thinking with opposing views.