A NOTE About updating to 1.7!!! Please Read if you have issues with it!
I have recently migrated my install to version 1130, and apparently now my CK saves plugins as version 1.71, which is not recognized by earlier game versions. In version 1.7.1, I changed plugin header version to 1.70 for compatibility.
If you update to 1.7.1, and mod MCM does not appear:
If you ever installed the "HeelsFix NFF Crash Fix" Patch - REMOVE it! If you have installed "Heels Fix - Settings Loader" Mod - REMOVE it! It will not be compatible with 1.7 In general, if you have ANY mod (aside from translations) that has file conflicts with Heels Fix - REMOVE it!
If you are updating to 1.7.1 from 1.6.2 on a game in progress, your MCM options page will likely have "Enable NPC Fixes" set to "Cloak". If you have SPID installed, my suggestion is to: Set it to "Disable" Go into a different cell. Switch to "SPID" Save the game. Load this game. Go again to a different cell.
If you are upgrading to 1.3+ from 1.2 or less for a game in-progress, please be sure to read this.
I am doing away with separate .esp and .esl versions. 1.3 is an ESP-FE, flagged light, and will not take a slot. Also, a new 'garbage collection' system is being added. So please, please PLEASE, follow these steps:
Load your game in progress.
Go to Heels Fix MCM, take a note of your settings, then disable everything.
Move to an interior location and make a manual save.
Exit the game and uninstall your existing version of Heels Fix.
Start the game again and load last save. It will give you warning about HeelsFix missing., that is OK
Make another manual save and exit game.
STRONGLY recommended: open you last save file in Fallrim Tools ReSaver, and use 'Remove unattached instances'
Install new HeelsFix.
Launch game, loaded the cleaned save. You can now go to HeelsFix MCM to re-enable the corrections.
Version 1.7.2 Plugin header version fixed, SPID effect management fixed, Info page in the MCM has extra options if NPC is targeted.
Version 1.7: SPID mode, auto Heel Refresher, Vampire Lord bugfix. If you have SPID installed, make sure to pick the 'SPID' option in the 'Enable NPC Fixes'. Otherwise pick the 'Cloak' option. If you are commonly affected by RaceMenu loading issues where NPCs on heels revert to 'sunk' state, you can try using the Heel Refresh timer. Every set number of minutes, it will cycle shoes off/on for NPCs wearing heels. Please note that it may wreak havoc on various follower outfit management systems. Just leave the slider on 0 to disable. Transforming into a vampire lord or werewolf should reapply the correction effect on transforming back.,
Version 1.6.2: Fixed a scaled actor correction issue. Thanks to gades28 for getting it my attention so I could figure it out and fix it. Primarily affecting extremely scaled actors (below 0.75, above 1.5), the root position adjustment was applied in absolute terms, not scaled.Now fixed.
Version 1.6.1: Adding a Spell for use as DAR conditional. Actors wearing heels receive effect-less ability spell. Spell is removed when heels are removed or NPC goes out of range. This Spell can be used as DAR conditional: HasSpell("HeelsFix.esp" | 0x811 )
Version 1.5.1: RacemenuHH handling, MJF handling, Heel Refresh spell. If you installed Wood Chopping Block Patch, you should remove it when updating to 1.5.1!!! Since people keep trying to use RacemenuHH along with HeelsFix, I added code that will actively detect and disable RacemenuHH, and clean out all its effects. Note: in 1.5, this part had a bug that prevented mod from loading properly. Fixed in 1.5.1
Mu Joint Fix: added code to detect it and provide counter-correction. My general recommendation: - Data\SKSE\Plugins\MuJointFix.ini - set 'FurnitureDisable = false' - HeelsFix MCM: Keep 'FurnitureDisable' checked. Knee Correction Amount = 3.0 is good for vanilla sitting idle (knees at 90°). Set it lower for 'sexy sit (legs stretched out) idles.
Heel Refresh spell (Illusion type) - sold by Lucan in Riverwood, or use AddItem or console to get it. It will help refresh an NPC footwear and correction effect without actually having to go into their inventory. Just a convenience feature.
Version 1.4: Camera corrections With new 'Correct First Person' option checked, players view will be corrected accordingly when wearing high heels. The 'Correct Third Person' option similarly adjusts third person camera when wearing heels. However, this feature is 100% incompatible with any other third person camera improvement mod. If you use Smoothcam or Customizable Camera, just use that mod to set your camera a bit higher.
If you use "Show Player in Menus", DO NOT install its "Heels Fix Patch" - just disable 'Correct Third Person' in Heels Fix MCM.
Version 1.3.1: Scaling fix. The 'Correct Scaling' (heel and non-heel) were just using GetScale to determine actor scaling and fix amount needed. Problem: the Height slider in Racemenu places a direct scaling override on player root, which GetScale does not 'see'. This update adds a NetImmerse call to obtain the root scaling override and factor it in the calculation. Now, if you changed your player height in 'Body Scales' tab of Racemenu, Heels Fix will see it. On that note: that height slider in Racemenu does not play very nice with a number of other things. I.e. none of the adult animation frameworks (Flower Girls, OStim, SexLab) handle it properly - you are going to have alignment issues. I much prefer to use the Player Size Adjuster and First Person Camera Height Fix SSE . It applies player scaling in a manner that's visible to GetScale.
What is in 1.3: It is now a single ESP-FE mod. Mo more ESP/ESL confusion. 'Smooth frames' feature was removed. It never worked well and added unneeded complexity to code. If you WERE using it and liked it, please let me know. Added support for a bunch more furniture markers - mainly from various DLCs. Added a garbage collection mechanism. How it works:
Whenever applying an effect to actor, it registers it in a central list.
Removing effect from actor unregisters it from list. Occasionally the effect 'sticks' and is not removed.
When player enters an interior location, the mod will go through list of registered effects, and kill the correction effect on any actor not in same cell.
It is a problem I did observe occasionally. Happens when a heel-wearing NPC gets up from a chair. It is like an 'inverse ragdoll' And afraid, just like the issue with other problems: 'swimming over shallow water', 'heels randomly sinking', 'NPC becomes impossible to target/interact with' - I have observed this happening even when Heels Fix is not even installed. Whether this particular one has to do with Racemenu, or CBPC, or FSMP, or XP32, I can't really tell. But the issue does not lie with Heels Fix. I can only describe the effect of my mod:
When an actor wears an item tagged with "HH_OFFSET=X" tag, the skee64.dll SKSE plugin, which comes as part of Racemenu, detects it, and lifts the actor by X. The Heels Fix correcting effect, if present, detects this 'lift' and thus knows the actor wears heels. But when the actor stands or walks/runs etc, Heels Fix does nothing. When the heel-wearing actor sits down, Heels Fix will:
Apply a positional transform to lower actor root by X. (So that butt is on the chair and not floating above it)
Apply a rotational transform to get actor legs slightly up.
Depending on the type of furniture being used, different transforms can be employed (I.e. rotate actor spine a bit when leaning on a counter) When the actor stands back up, all Heels Fix does is REMOVE the tranforms it has applied, and goes back to doing NOTHING.
On a positive note, I don't think I have observed this issue yet with Skyring AE version 1130, which is what I am currently using. (I did not update to 1170 yet) but that could just be chance - the problem is fairly rare.
If you have a way to replicate, that would be helpful. What NPC, what outfit, in what location? (Mod links if possible) What game version? And are you certain it only replicates when Heels Fix is installed and enabled for NPCs?
Very insightful. While I didn't think it was this mod (or Racemenu) causing the issue, any information I can obtain that will point me in the right direction to solving this is greatly appreciated.
It only seems to happen in VR for me. I can load this same mod library into AE and I have yet to see it happen. It only occurs with SMP/HDT armors, and I have yet to see it occur on a physics armor that doesn't have the Heels functionality built into the foot piece.
Happens when NPC's are getting up from sleep, getting up from chairs, or getting off of a horse.
I ran my mod library through CAO (Animations, Textures, and Meshes optimization only.) and the results seem hopeful, but I think I'll need to stress test it for a week to be sure. I will update the post if (More likely when) it fails.
I suspect there's something in 3BA meshes that SkyrimVR doesn't like. I could be completely wrong about this.
Edit: Nope. Didn't work. I'll figure it out someday.
Doesn't just happen with heels. I've seen it happen with male NPC's, but only ones wearing SMP equipment. Only happens when changing from sitting/sleeping/crafting back to walking. Also, animation goes back to normal if the NPC happens to sit down. It's incredibly strange.
I had this issue for a very long time with the SMP equipment in terms of heels but what seems to have fixed it for me were the following steps: - modifying the race menu ini skee64.ini if you are running Obody NG make sure that those values are set as per below: bEnableBodyMorph=1 ; Default[1] bEnableBodyGen=0 ; Default[1]
Those functions were introduced in the newer versions of racemenu and are not quite stable yet so they may cause crashes I would recommend to turn them off: bBodyMorphGPUCopy=0 ; Default[1] bBodyMorphRebind=0 ; Default[1]
Doubling the morphing memory limit this is mandatory only if you are using bodymorphs such as ObodyNG for example: uBodyMorphMemoryLimit=512000000 ; Default[256000000]
After that installing the FSMP with AVX 512 instructions instead of AVX or AVX 2 seems to solve the problem as the AVX 512 function calls are simply faster. In the FOMOD of FSMP select the AVX 512 option before that ensure that your CPU supports it if it doesn't then I am sorry but you will have to live with that bug until the FSMP author figures out a way to fix this issue for other AVX versions of the library.
I additionally have turned off wind in the FSMP ini configuration file since i am running SMP wind but I don't think that it has any effect on this issue.
Please let me know if it solved the helicopter heels rapidly spinning with the npc floating in the air issue.
I will mess with these for a bit and let you know. This is a very time consuming bug to test/fix since it can either be minutes, hours, or days between seeing it happen.
Seems hopeful, but I've said that so many times in the past two years.
Unfortunately this didn't work in my case. I'm SkyrimVR (and a different RaceMenu version due to this) and so I'm a bit of an exceptional case.
All of the other changes I've confirmed ineffective in my case. I'm testing for this one: bEnableEquippableTransforms=0
Of course, having this disabled I honestly may as well disable racemenu entirely as there is no heels adjustment with it off. As I've been doing this for two years I can't remember if having racemenu removed entirely prevented the issue, because I could swear I've had load orders where I didn't bother with Racemenu and it was still happening.
That said, I'd prefer to have heels sinking into the ground than random NPC's I'm trying to fight floating up in the air out of striking distance, or their hitboxes being hidden by an invisible actual NPC while the model for them floats in the air. If this works and I don't have heels adustment, I'll unfortunately take it.
Ideally, if this is true cause of the issue, I think I'll have to wait until racemenu VR version updates to current and hope for the best.
It's the way the skeleton gets calculated after position change that is causing it. I haven't pasted everything in the first post that I made but from what I noticed is that having this setting set to false helps with the skeleton recalculating every few seconds that also caused a weird stop and reset on the smp clothing as well as boobs of the target character for a second this reset the jiggle physics intermittenly evey few seconds. If you turn it to false that doesn't happen anymore so try this in your hdt config xml and you won't get the skeleton reset which should help with those characters wearing heels : <autoAdjustMaxSkeletons>false</autoAdjustMaxSkeletons>
Since you are a VR user obviously the dll version for racemenu is different for you but it's not racemenu on it's own causing the issue it's a combination of fsmp and racemenu for characters when wearing heels. Just as a side note even though the skeleton won't refresh automatically every few seconds this may potentially cause performance issues for you so that needs to be said however that heel helicopter for npc issue should not occur I will also paste as a spoiler my hdt config below so it might help in case I miss something again: Config:
Spoiler:
Show
<?xml version="1.0" encoding="utf-8"?> <configs> <smp> <!-- ######################## LOGS #################################### --> <!-- logLevel: (int 0-5) level of logs 0 = kLevel_FatalError 1 = kLevel_Error 2 = kLevel_Warning 3 = kLevel_Message 4 = kLevel_VerboseMessage 5 = kLevel_DebugMessage --> <logLevel>0</logLevel> <!-- #################### NPC FACE PARTS ############################## --> <!-- enableNPCFaceParts: (boolean) enables physics for NPC face parts. If no value is set, default is true. --> <enableNPCFaceParts>true</enableNPCFaceParts> <!-- disableSMPHairWhenWigEquipped: (boolean) if enabled, when you have at the same time smp hair and smp wig, now, only the wig is physically calculated. More precisely, if you have an armor on the hair or longhair slot, no headpart is physically calculated. You very probably want this, except if you use a hidden helmet mod. If no value is set, default is false. --> <disableSMPHairWhenWigEquipped>true</disableSMPHairWhenWigEquipped> <!-- ##################### CLAMP ROTATIONS ############################ --> <!-- clampRotations: (boolean) limits the PC rotation speed when turning a large angle, so that your character rotates slowly instead of instantly. If no value is set, default is true. --> <clampRotations>true</clampRotations> <!-- rotationSpeedLimit: (float) rotation speed limit of the PC in radians per second. Must be positive. If no value is set, default is 10.0. --> <rotationSpeedLimit>10.0</rotationSpeedLimit> <!-- unclampedResets: (boolean) when unclamped, if you do a large turn (full 180° for example), we will attempt to apply physics for that enormous turn. Setting this to true will instead trigger a physics reset on the actor if the turn is large enough. You can try setting this false and decide if you're OK with the results. If no value is set, default is true. --> <unclampedResets>true</unclampedResets> <!-- unclampedResetAngle: (int) the angle value in degrees to reset at. You'll probably want to tweak this until you're happy. There is no limitation on value, use your common sense. If no value is set, default is 120°. --> <unclampedResetAngle>130.0</unclampedResetAngle> <!-- ######################### CLOCK ################################## --> <!-- useRealTime: (boolean) when enabled, use the RealTime clock instead of the WorldTime clock. This is quite a conceptual change: the physics are calculated not depending on what we think is the inner game clock, but depending on what we think is the external real clock. Theoretically this should be a worse choice, as we calculate physics for the game world with its own world clock. But the preliminary tests show a better stability of the physics simulation when the game time is strongly slowed, when the fps are high (for example 100+), and of course with a combination of both. My hypothesis for this better physics simulation is that the inner game clock has a larger error margin / a larger deviation than the real world clock, and that this causes artifacts in the physics simulation. Players tests will indicate if this is a choice to keep. If no value is set, default is false. --> <useRealTime>true</useRealTime> <!-- ######################### CULLING ################################### --> <!-- minCullingDistance: (float) the minimum distance from the camera under which no skeleton is culled. If no value is set, default is 500. It's useful if for example the skeleton origin is very near, behind the camera, but some parts of the skeleton are in front of the camera and need to be animated. --> <minCullingDistance>500</minCullingDistance> <!-- ################# MAX SKELETONS NUMBER ########################### --> <!-- autoAdjustMaxSkeletons: (boolean) sets dynamically the maximum number of simultaneous skeletons/actors for which physics is calculated, between 1 and maximumActiveSkeletons (below) to consume only the allocated percentageOfFrameTime. This can result in only one active skeleton when the load is heavy. The algorithm will prioritize closer skeletons within the center of your field of view. If disabled, fps may drop when you have too many active skeletons. If no value is set, default is true. --> <autoAdjustMaxSkeletons>false</autoAdjustMaxSkeletons> <!-- maximumActiveSkeletons: (int) the configured maximum number of simultaneous skeletons/actors for which physics is calculated, when autoAdjustMaxSkeletons is enabled. If autoAdjustMaxSkeletons is disabled, the maximum simultaneously active skeletons number is 10 (hardcoded). There is no limit on the value. If no value is set, default is 20. --> <maximumActiveSkeletons>5</maximumActiveSkeletons> <!-- percentageOfFrameTime: (int 1-100) [requires autoAdjustMaxSkeleton = true] percentage of the configured min-fps period allocated to additional physics calculus. Each frame, FSMP uses a certain time to calculate physics (T). Each frame, the work done by the Skyrim executable can be split into 2 parts: one that can be parallelized with the FSMP calculus (T1), one that can't because it depend on it (T2). If the FSMP calculus T is shorter than T1, then physics doesn't cost any fps. If it is longer, the Skyrim executable must wait (T - T1) for the physics calculus to finish. This setting allows you to choose how much fps you're willing to lose to increase the number of skeletons with physics at the same time :) FSMP being heavily parallelized, adding a 10th skeleton on top of 9 doesn't cost a lot, so you should do your tests with a reasonable number of skeletons (10?), and set this setting depending on what performance you want to have in a heavy context. Whiterun seems a good place. Absolutely check what happens with the log at level 4 (verbose); it depends A LOT on your personal setup. If your min-fps is 60 and your percentage is 30, then the allocated time for additional physics calculus during a frame is 1/60s * 30% = 5ms. If no value is set, default is 30, which is NOT optimized. --> <percentageOfFrameTime>18</percentageOfFrameTime> <!-- sampleSize: (int) how many samples (sample taken every min_fps frames/every second) to determine the average ms per activeSkeleton. This is used to log performance statistics and also used to calculate the processing time average used to limit the number of active skeletons. Increasing the sample size will flatten outliers but can slow adjustment responsiveness. The value must be equal or greater to 1. If no value is set, default is 5. --> <sampleSize>5</sampleSize> <!-- ################## PC PHYSICS WHILE IN 1ST PERSON VIEW ########### --> <!-- disable1stPersonViewPhysics: (boolean) if set to true, the physics of the PC won't be calculated when in 1st person view, to save performance. If no value is set, default is false. --> <disable1stPersonViewPhysics>false</disable1stPersonViewPhysics> <!-- ##################### CUDA ####################################### --> <!-- enableCuda: (boolean) experimental GPU collision algorithm. Try this if you have a slow CPU and fast GPU. This setting will be ignored if you haven't installed the CUDA-enabled version. If no value is set, default is false. --> <enableCuda>false</enableCuda> </smp> <solver> <!-- ################ BULLET PHYSICS ENGINE SETTINGS ################# --> <!-- numIterations: (int 4-128) could be simplified as 'simulation accuracy', lower values will gain performance at the cost of less quality. If no value is set, default is 10. --> <numIterations>8</numIterations> <!-- groupIterations: (int 0-4096) If no value is set, default is 2. --> <groupIterations>16</groupIterations> <!-- groupEnableMLCP: (boolean) Turns on the higher quality constraint solver, better constraint simulation at the cost of performance. If no value is set, default is true. --> <groupEnableMLCP>false</groupEnableMLCP> <!-- erp: (float ]0-1[) The error correction force applied per simulation step, constraints will drift apart naturally, this value will exert a force to move them back to where they are supposed to be. Do not use the 0 and 1 values. If no value is set, default is 0.2. --> <erp>0.2</erp> <!-- ################ PHYSICS SIMULATION FREQUENCY ################### --> <!-- min-fps: (int 60-300), is the main frequency at which physics simulation will advance; in fact, it defines the main period of time at which the physics simulation will advance; (p=1/f). min-fps should never be configured under 60, or the bullet physics engine will badly bug. The higher it is, the better your physics simulation will be and the more costly for your CPU/GPU. 120 costs twice as much cpu as 60. If no value is set, default is 60. --> <min-fps>60</min-fps> <!-- ################### PHYSICS SLOWDOWNS ########################### --> <!-- maxSubSteps: (int, 1-60) this setting allows you to choose between fps and physics simulation quality, at low fps. maxSubSteps is the maximum number of physics calculus steps, each frame. Slowdowns are experienced when fps are below min-fps/maxSubSteps. With the default value, slowdowns are experienced below 60/4 = 15 fps. The higher it is, the more costly your physics simulation will be at low fps. 2 substeps cost twice as 1 substep. When fps are above min-fps, one substep is enough; when fps are between min-fps/n and min-fps/(n+1), n+1 substeps are necessary. The max value is 60, which allows for slowdowns below 5 fps when min-fps is at 300 (max value). If no value is set, default is 4. --> <maxSubSteps>1</maxSubSteps> </solver> <!-- ################### WIND EFFECTS ########################### --> <wind> <!-- enabled: (bool) Whether to enable wind effects, default is true. Wind in Skyrim is not developed well and appears to be a static direction. Wind can be detected generally from the sky object or by a weather object. Wind can be tested when snow or rain is falling (e.g., SkyrimStormSnow) --> <enabled>false</enabled> <!-- windStrength: (float) Base strength of wind. Compare to gravity which uses 9.8 m/s^2, default is 2.0. --> <windStrength>2.0</windStrength> <!-- distanceForNoWind: (float) How close to an obstruction for wind to be fully blocked. This scales linearly with distanceForMaxWind. default is 50.0. --> <distanceForNoWind>50.0</distanceForNoWind> <!-- distanceForMaxWind: (float) How far from an obstruction for wind to be not blocked. This scales linearly with distanceForNoWind. default is 3000.0. --> <distanceForMaxWind>2000.0</distanceForMaxWind> </wind> </configs>
This is one of the last mods I would've thought would be causing this bug. I have SPID distribution for Magecore and Elle's Tavern Maid outfit, and pretty much every NPC that has those outfits equipped float away after interacting with any furniture. It was pretty hilarious at first, but it's annoying now because enemies with Magecore equipped can attack me in mid air and I can't reach them with melee. I'm playing on 1.6.640, and I'm using the latest version of Heels Fix, if it matters. I've only noticed it in interior cells. Probably gonna uninstall until the bug is fixed.
I wish I could give you some better news, but this is a bug I observed a number of times, and I tried messaging Expired (author of Racemenu) about this, to no avail. It is not HeelsFix-related, I did reproduce this bug a number of times even without HeelsFix installed. A few others also reported happening to them while not using my mod. It looks like it is most likely to happen when Racemenu 'forgets' to render a heel offset and NPC sits down or starts using a chair or bed when 'sunk'. And yeah, it is like NPC is 'transparent' to the cursor - you can get an option to use a chair or bed while the cursor is over the NPC. And once it starts happening to an NPC, they sort of remain 'bugged'. It seems to be fairly rare, though. One method I use to deal with it in-game it open console, click NPC and use 'moveto player' command.
Ahh, finally a mention of this bug! It started when I got kind of 'forced' into upgrading to AE, but I haven't been able to even find a mention of it.
I recently moved to a new PC with a faster CPU (I7-14700) and it seems to happen more often. I used an app that moves things from one PC to another. I'd been better off to just reinstall Skyrim and all the mods; might have cleared this up.
how to apply it to an npc ? it's not working automatically after using the mcm switch and using the console apply fix ability command on an npc (and yes I tried re-equipping)
Thanks for the reply... I never encounter this bug until I use this mod and have NPC wearing heels. I think there must be some sort of correlation to it.
Tbh, I was at complete opposite of you. I can never be able to replicate this bug without using this mod. :p
Hope one day u and the author of racemenu can figure out a way to handle this.
Bump I've also gotten this even way before heels fix. It's def 100% racemenu heels offset. Only way is to disable the heels offset setting. A band-aid solution is to use "Remote interactions" to talk to them.
I'm sure you've been asked this a lot, but is there a specific method this should be downloaded and installed? Or is it a 'normal' download processes and then configured in MCM? Pretty sure I know the answer... but I want to be sure. Here's to hoping my gal won't float everywhere now lol
You generally want to make sure your prerequisites are in place, especially Racemenu. And that the heels work already (that is, equipping them lifts the character). If you are currently using RacemenuHH mod, good idea to disable it in MCM, switch to another cell, and make a save. Other than that, yeah, just download and install. Once HeelsFix MCM is registered, go in and enable stuff. For NPCs, choose SPID if you have it installed, otherwise choose Cloak.
With this mod every time i get to inside cell with player and/or follower/s with high heels i get CTD, happens everytime (prolly the moment mod trying to adjust height), trainwreck is throwing something about hkpConstraintInstance* (i can provide full crashlog if needed).After ctd i can play inside that cell thou if game happens to make autosave in time. Playing on vr version.
This Mod is NOT trying to 'adjust height' when switching cells. Only thing it might be doing is clearing its effect from NPCs no longer in same cell. Try disabling all features of this mod in MCM and see if the crashing still occurs. If it does, then it is not this mod. If it does nor, I suggest enabling Papyrus logging, and turning on this mod's Debug Logging. Then attach your Papyrus log when you CTD.
I'm also a VR player and encountered the same issue, but after looking through the forum post, I believe it's not related to this mod, it should be related to RaceMenuVR, because i disabled this mod, I can still reproduce the issue
seems I've found a way to avoid this bug(Perhaps), You can also give this method a try. 1.Disable Engine Fixes VR config (Important) a.MemoryManager = false (Important) b.AnimationLoadSignedCrash = false c.CellInit = false (Important) d.FixShadowSceneCrash = false (Important) e.BSLightingShaderForceAlphaTest=false latest verson f.FixShadowSceneNodeNullptrCrash = false latest verson g.SelectAllocator = 1 2.Disabled RaceMenuVR config a.bEnableOverlays=0 b.bEnableBodyGen=0 c.bParallelMorphing=0 (Important) 3.Upgrade Skyrim ESL Support (Optianl) a.RaceMenu ESL Patch (Important) b.PapyrusUtil ESL Patch (Optianl) 4.Upgrade FSMP
Lastly, a heartfelt thank you to the author,this is an excellent mod! Let's not let misunderstandings hurt contributor.
Greatly appreciate taking the time to explore this. Indeed, with my my mod claiming to be (and actually being) the replacement/upgrade for "RacemenuHH", and RacemenuHH confusing description making almost everyone mistakenly believe it is more than just a basic height corrector, a lot of heel-related issues tend to land at my feet. I am used to it by now...
character feet just sink into the ground after equipping anything. It only happen when I equip anything armor cloth pants jewel ring, etc. Equip any of those and the heels just reset the character position and the feet will sink into the ground I have the correct version of racemenu I been trying to fix it for literally hours but still cannot fix it
Yes, it is one of Racemenu glitches that I talk about in this article (near end of section III). Basically, if the engine is busy, skee64 'skips' rendering of wearable transforms (which is what heel offset is). For me, this glitch primarily manifests during first couple minutes after game starts, then it normalizes. I even made a short youtube video demonstrating it. (Don't mind the obnoxious voice-over, I was experimenting with AI voice generation)
That dll comes with Racemenu. I do happen to be one of Expired supporters on Patreon, and I did write to him there about this issue a couple of times - but am yet to get any kind of response...
sorry for the long reply nexus never really notifies me if anyone replies to my post at all xD but I do play for an hour long but I never see the issue fixed maybe it's bc I only wear it for a couple of min and change to wear something else that's why it never got fix?
The issue generally does not fix itself - you need to take the shoes off and put them back on. With regards to sinking when you put on something else, it seems to directly correlate with how loaded the game engine is when it happens. Depends on how capable the PC is, what other mods might be running, what else might be going on with that specific NPC etc. For me, the first couple minutes after the game is loaded, the problem is fairly consistent (equipping/unequipping anything sinks the feet), then it goes away. But if I use Vilja, she sinks after practically every cell transition. Vilja has absolutely horrendous outfit management scripting, which generates a storm of equip/unequip events on cell changes, enter/exit combat, etc. So much so, I stopped putting heels on her. SDA for Serana tends to be guilty of the same.
how I can avoid heels sink underground when I change non heels armour items - body armour for example. When I equip body heels goes underground but after I re-equip them they behaives normal
hi there, thanks for your work! I have been enjoying it a lot. How ever, Im testing this: https://www.nexusmods.com/skyrimspecialedition/mods/85599?tab=files And it seems not to be compatible... I mean, heels fix do not fix... any tip?
Me and SonderBain have.... creative differences. SonderBain likes their animation poses EXACTLY the way they are, so they make a separate version of each for high heels, to be used instead of a correcting mod. Maybe only exception being RacemenuHH, which simply lowers the actor. The problem with SonderBain approach is that it only works for a specific heel height. Anything significantly shorter or taller is going to look kinda weird. So, if you want to use their animation mods while using Heels Fix (Sitting, Leaning), my general recommendation is to just delete all the 'HH' versions. That is, after installing the mod, go to Data\meshes\actors\character\animations\OpenAnimationReplacer\SDB MFSAO\and delete all subdirectories that end with _HH
Hey, I cannot for the life of me get this mod to work. HHOffset is already on for body slide and so, but I'm still clipping through the floor. Any help would be greatly appreciated
This mod is not what 'lifts' the heel-wearing character. You need to make sure your SKSE/AddressLibrary/RaceMenu are installed and up to date and skee64.dll is there and working properly. Specifically, Documents/My Games/Skyrim Special Edition/SKSE, look for 'skee64.log' If your PC is configured to not display 'known' extensions, it will be just called 'skee64'. It should be timestamped with last time you ran the game and first line in it should be:
Also, I am also not quite sure if your issue is that you can't make ANY heels work, or you are failing to make specific heels work. If so, in the Outfit Studio it should look like this:
And of course, after you save the project, you need to actually run BodySlide and build this project.
Also, you might have some weird combo of mods causing this. For example, someone was having an issue with sunk heels whenever they used 'Yamato Scabbard Remastered' mod with an SMP tassel, Mu Join Fix would sink their heels.
Yeah Net Imemerse Override is enabled in the skee log.
I have racemenu installed for 1.6.353 ( I know its ancient, just never bothered to upgrade as i have way too many mods). However, im not finding any skee64.dll
So that may just be the issue.
Gonna let you know how that goes.
Thanks once again for clarifying what exactly "lifts" the character.
664 comments
I have recently migrated my install to version 1130, and apparently now my CK saves plugins as version 1.71, which is not recognized by earlier game versions. In version 1.7.1, I changed plugin header version to 1.70 for compatibility.
If you update to 1.7.1, and mod MCM does not appear:
If you ever installed the "HeelsFix NFF Crash Fix" Patch - REMOVE it!
If you have installed "Heels Fix - Settings Loader" Mod - REMOVE it! It will not be compatible with 1.7
In general, if you have ANY mod (aside from translations) that has file conflicts with Heels Fix - REMOVE it!
If you are updating to 1.7.1 from 1.6.2 on a game in progress, your MCM options page will likely have "Enable NPC Fixes" set to "Cloak".
If you have SPID installed, my suggestion is to:
Set it to "Disable"
Go into a different cell.
Switch to "SPID"
Save the game. Load this game. Go again to a different cell.
I am doing away with separate .esp and .esl versions. 1.3 is an ESP-FE, flagged light, and will not take a slot. Also, a new 'garbage collection' system is being added. So please, please PLEASE, follow these steps:
Version 1.7.2
Plugin header version fixed, SPID effect management fixed, Info page in the MCM has extra options if NPC is targeted.
Version 1.7: SPID mode, auto Heel Refresher, Vampire Lord bugfix.
If you have SPID installed, make sure to pick the 'SPID' option in the 'Enable NPC Fixes'. Otherwise pick the 'Cloak' option.
If you are commonly affected by RaceMenu loading issues where NPCs on heels revert to 'sunk' state, you can try using the Heel Refresh timer. Every set number of minutes, it will cycle shoes off/on for NPCs wearing heels. Please note that it may wreak havoc on various follower outfit management systems. Just leave the slider on 0 to disable.
Transforming into a vampire lord or werewolf should reapply the correction effect on transforming back.,
Version 1.6.2: Fixed a scaled actor correction issue.
Thanks to gades28 for getting it my attention so I could figure it out and fix it. Primarily affecting extremely scaled actors (below 0.75, above 1.5), the root position adjustment was applied in absolute terms, not scaled.Now fixed.
Version 1.6.1: Adding a Spell for use as DAR conditional.
Actors wearing heels receive effect-less ability spell. Spell is removed when heels are removed or NPC goes out of range.
This Spell can be used as DAR conditional:
HasSpell("HeelsFix.esp" | 0x811 )
Version 1.5.1: RacemenuHH handling, MJF handling, Heel Refresh spell.
If you installed Wood Chopping Block Patch, you should remove it when updating to 1.5.1!!!
Since people keep trying to use RacemenuHH along with HeelsFix, I added code that will actively detect and disable RacemenuHH, and clean out all its effects. Note: in 1.5, this part had a bug that prevented mod from loading properly. Fixed in 1.5.1
Mu Joint Fix: added code to detect it and provide counter-correction. My general recommendation:
- Data\SKSE\Plugins\MuJointFix.ini - set 'FurnitureDisable = false'
- HeelsFix MCM: Keep 'FurnitureDisable' checked. Knee Correction Amount = 3.0 is good for vanilla sitting idle (knees at 90°). Set it lower for 'sexy sit (legs stretched out) idles.
Heel Refresh spell (Illusion type) - sold by Lucan in Riverwood, or use AddItem or console to get it. It will help refresh an NPC footwear and correction effect without actually having to go into their inventory. Just a convenience feature.
Version 1.4: Camera corrections
With new 'Correct First Person' option checked, players view will be corrected accordingly when wearing high heels.
The 'Correct Third Person' option similarly adjusts third person camera when wearing heels. However, this feature is 100% incompatible with any other third person camera improvement mod. If you use Smoothcam or Customizable Camera, just use that mod to set your camera a bit higher.
If you use "Show Player in Menus", DO NOT install its "Heels Fix Patch" - just disable 'Correct Third Person' in Heels Fix MCM.
Version 1.3.1: Scaling fix.
The 'Correct Scaling' (heel and non-heel) were just using GetScale to determine actor scaling and fix amount needed. Problem: the Height slider in Racemenu places a direct scaling override on player root, which GetScale does not 'see'. This update adds a NetImmerse call to obtain the root scaling override and factor it in the calculation. Now, if you changed your player height in 'Body Scales' tab of Racemenu, Heels Fix will see it.
On that note: that height slider in Racemenu does not play very nice with a number of other things. I.e. none of the adult animation frameworks (Flower Girls, OStim, SexLab) handle it properly - you are going to have alignment issues. I much prefer to use the Player Size Adjuster and First Person Camera Height Fix SSE . It applies player scaling in a manner that's visible to GetScale.
What is in 1.3:
It is now a single ESP-FE mod. Mo more ESP/ESL confusion.
'Smooth frames' feature was removed. It never worked well and added unneeded complexity to code. If you WERE using it and liked it, please let me know.
Added support for a bunch more furniture markers - mainly from various DLCs.
Added a garbage collection mechanism. How it works:
When an actor wears an item tagged with "HH_OFFSET=X" tag, the skee64.dll SKSE plugin, which comes as part of Racemenu, detects it, and lifts the actor by X. The Heels Fix correcting effect, if present, detects this 'lift' and thus knows the actor wears heels. But when the actor stands or walks/runs etc, Heels Fix does nothing.
When the heel-wearing actor sits down, Heels Fix will:
- Apply a positional transform to lower actor root by X. (So that butt is on the chair and not floating above it)
- Apply a rotational transform to get actor legs slightly up.
Depending on the type of furniture being used, different transforms can be employed (I.e. rotate actor spine a bit when leaning on a counter)When the actor stands back up, all Heels Fix does is REMOVE the tranforms it has applied, and goes back to doing NOTHING.
On a positive note, I don't think I have observed this issue yet with Skyring AE version 1130, which is what I am currently using. (I did not update to 1170 yet) but that could just be chance - the problem is fairly rare.
It only seems to happen in VR for me. I can load this same mod library into AE and I have yet to see it happen. It only occurs with SMP/HDT armors, and I have yet to see it occur on a physics armor that doesn't have the Heels functionality built into the foot piece.
Happens when NPC's are getting up from sleep, getting up from chairs, or getting off of a horse.
Will provide further edits later.
I suspect there's something in 3BA meshes that SkyrimVR doesn't like. I could be completely wrong about this.
Edit: Nope. Didn't work. I'll figure it out someday.
Doesn't just happen with heels. I've seen it happen with male NPC's, but only ones wearing SMP equipment. Only happens when changing from sitting/sleeping/crafting back to walking. Also, animation goes back to normal if the NPC happens to sit down. It's incredibly strange.
- modifying the race menu ini skee64.ini
if you are running Obody NG make sure that those values are set as per below:
bEnableBodyMorph=1 ; Default[1]
bEnableBodyGen=0 ; Default[1]
Those functions were introduced in the newer versions of racemenu and are not quite stable yet so they may cause crashes I would recommend to turn them off:
bBodyMorphGPUCopy=0 ; Default[1]
bBodyMorphRebind=0 ; Default[1]
Doubling the morphing memory limit this is mandatory only if you are using bodymorphs such as ObodyNG for example:
uBodyMorphMemoryLimit=512000000 ; Default[256000000]
After that installing the FSMP with AVX 512 instructions instead of AVX or AVX 2 seems to solve the problem as the AVX 512 function calls are simply faster. In the FOMOD of FSMP select the AVX 512 option before that ensure that your CPU supports it if it doesn't then I am sorry but you will have to live with that bug until the FSMP author figures out a way to fix this issue for other AVX versions of the library.
I additionally have turned off wind in the FSMP ini configuration file since i am running SMP wind but I don't think that it has any effect on this issue.
Please let me know if it solved the helicopter heels rapidly spinning with the npc floating in the air issue.
Seems hopeful, but I've said that so many times in the past two years.
Unfortunately this didn't work in my case. I'm SkyrimVR (and a different RaceMenu version due to this) and so I'm a bit of an exceptional case.
All of the other changes I've confirmed ineffective in my case. I'm testing for this one:
bEnableEquippableTransforms=0
Of course, having this disabled I honestly may as well disable racemenu entirely as there is no heels adjustment with it off. As I've been doing this for two years I can't remember if having racemenu removed entirely prevented the issue, because I could swear I've had load orders where I didn't bother with Racemenu and it was still happening.
That said, I'd prefer to have heels sinking into the ground than random NPC's I'm trying to fight floating up in the air out of striking distance, or their hitboxes being hidden by an invisible actual NPC while the model for them floats in the air. If this works and I don't have heels adustment, I'll unfortunately take it.
Ideally, if this is true cause of the issue, I think I'll have to wait until racemenu VR version updates to current and hope for the best.
<autoAdjustMaxSkeletons>false</autoAdjustMaxSkeletons>
Since you are a VR user obviously the dll version for racemenu is different for you but it's not racemenu on it's own causing the issue it's a combination of fsmp and racemenu for characters when wearing heels. Just as a side note even though the skeleton won't refresh automatically every few seconds this may potentially cause performance issues for you so that needs to be said however that heel helicopter for npc issue should not occur I will also paste as a spoiler my hdt config below so it might help in case I miss something again:
Config:
<?xml version="1.0" encoding="utf-8"?>
<configs>
<smp>
<!-- ######################## LOGS #################################### -->
<!--
logLevel: (int 0-5) level of logs
0 = kLevel_FatalError
1 = kLevel_Error
2 = kLevel_Warning
3 = kLevel_Message
4 = kLevel_VerboseMessage
5 = kLevel_DebugMessage
-->
<logLevel>0</logLevel>
<!-- #################### NPC FACE PARTS ############################## -->
<!--
enableNPCFaceParts: (boolean) enables physics for NPC face parts.
If no value is set, default is true.
-->
<enableNPCFaceParts>true</enableNPCFaceParts>
<!--
disableSMPHairWhenWigEquipped: (boolean) if enabled, when you have at the
same time smp hair and smp wig, now, only the wig is physically calculated.
More precisely, if you have an armor on the hair or longhair slot, no headpart
is physically calculated.
You very probably want this, except if you use a hidden helmet mod.
If no value is set, default is false.
-->
<disableSMPHairWhenWigEquipped>true</disableSMPHairWhenWigEquipped>
<!-- ##################### CLAMP ROTATIONS ############################ -->
<!--
clampRotations: (boolean) limits the PC rotation speed when turning a
large angle, so that your character rotates slowly instead of instantly.
If no value is set, default is true.
-->
<clampRotations>true</clampRotations>
<!--
rotationSpeedLimit: (float) rotation speed limit of the PC in radians per
second. Must be positive.
If no value is set, default is 10.0.
-->
<rotationSpeedLimit>10.0</rotationSpeedLimit>
<!--
unclampedResets: (boolean) when unclamped, if you do a large turn (full
180° for example), we will attempt to apply physics for that enormous
turn. Setting this to true will instead trigger a physics reset on the
actor if the turn is large enough. You can try setting this false and
decide if you're OK with the results.
If no value is set, default is true.
-->
<unclampedResets>true</unclampedResets>
<!--
unclampedResetAngle: (int) the angle value in degrees to reset at. You'll
probably want to tweak this until you're happy. There is no limitation on
value, use your common sense.
If no value is set, default is 120°.
-->
<unclampedResetAngle>130.0</unclampedResetAngle>
<!-- ######################### CLOCK ################################## -->
<!--
useRealTime: (boolean) when enabled, use the RealTime clock instead of
the WorldTime clock.
This is quite a conceptual change: the physics are calculated not
depending on what we think is the inner game clock, but depending on what we
think is the external real clock. Theoretically this should be a worse choice,
as we calculate physics for the game world with its own world clock. But the
preliminary tests show a better stability of the physics simulation when the
game time is strongly slowed, when the fps are high (for example 100+), and of
course with a combination of both. My hypothesis for this better physics
simulation is that the inner game clock has a larger error margin / a
larger deviation than the real world clock, and that this causes
artifacts in the physics simulation.
Players tests will indicate if this is a choice to keep.
If no value is set, default is false.
-->
<useRealTime>true</useRealTime>
<!-- ######################### CULLING ################################### -->
<!--
minCullingDistance: (float) the minimum distance from the camera under which
no skeleton is culled.
If no value is set, default is 500. It's useful if for example the skeleton
origin is very near, behind the camera, but some parts of the skeleton
are in front of the camera and need to be animated.
-->
<minCullingDistance>500</minCullingDistance>
<!-- ################# MAX SKELETONS NUMBER ########################### -->
<!--
autoAdjustMaxSkeletons: (boolean) sets dynamically the maximum number of
simultaneous skeletons/actors for which physics is calculated, between 1
and maximumActiveSkeletons (below) to consume only the allocated
percentageOfFrameTime.
This can result in only one active skeleton when the load is heavy.
The algorithm will prioritize closer skeletons within the center of your
field of view.
If disabled, fps may drop when you have too many active skeletons.
If no value is set, default is true.
-->
<autoAdjustMaxSkeletons>false</autoAdjustMaxSkeletons>
<!--
maximumActiveSkeletons: (int) the configured maximum number of
simultaneous skeletons/actors for which physics is calculated, when
autoAdjustMaxSkeletons is enabled. If autoAdjustMaxSkeletons is disabled,
the maximum simultaneously active skeletons number is 10 (hardcoded).
There is no limit on the value.
If no value is set, default is 20.
-->
<maximumActiveSkeletons>5</maximumActiveSkeletons>
<!--
percentageOfFrameTime: (int 1-100) [requires autoAdjustMaxSkeleton = true]
percentage of the configured min-fps period allocated to additional physics calculus.
Each frame, FSMP uses a certain time to calculate physics (T).
Each frame, the work done by the Skyrim executable can be split into 2 parts:
one that can be parallelized with the FSMP calculus (T1),
one that can't because it depend on it (T2).
If the FSMP calculus T is shorter than T1, then physics doesn't cost any fps.
If it is longer, the Skyrim executable must wait (T - T1) for the physics calculus to finish.
This setting allows you to choose how much fps you're willing to lose to increase
the number of skeletons with physics at the same time :)
FSMP being heavily parallelized, adding a 10th skeleton on top of 9
doesn't cost a lot, so you should do your tests with a reasonable number
of skeletons (10?), and set this setting depending on what performance
you want to have in a heavy context. Whiterun seems a good place.
Absolutely check what happens with the log at level 4 (verbose);
it depends A LOT on your personal setup.
If your min-fps is 60 and your percentage is 30, then the allocated time
for additional physics calculus during a frame is 1/60s * 30% = 5ms.
If no value is set, default is 30, which is NOT optimized.
-->
<percentageOfFrameTime>18</percentageOfFrameTime>
<!--
sampleSize: (int) how many samples (sample taken every min_fps
frames/every second) to determine the average ms per activeSkeleton.
This is used to log performance statistics and also used to calculate
the processing time average used to limit the number of active skeletons.
Increasing the sample size will flatten outliers but can slow adjustment
responsiveness.
The value must be equal or greater to 1.
If no value is set, default is 5.
-->
<sampleSize>5</sampleSize>
<!-- ################## PC PHYSICS WHILE IN 1ST PERSON VIEW ########### -->
<!--
disable1stPersonViewPhysics: (boolean) if set to true, the physics of the
PC won't be calculated when in 1st person view, to save performance.
If no value is set, default is false.
-->
<disable1stPersonViewPhysics>false</disable1stPersonViewPhysics>
<!-- ##################### CUDA ####################################### -->
<!--
enableCuda: (boolean) experimental GPU collision algorithm. Try this if
you have a slow CPU and fast GPU. This setting will be ignored if you
haven't installed the CUDA-enabled version.
If no value is set, default is false.
-->
<enableCuda>false</enableCuda>
</smp>
<solver>
<!-- ################ BULLET PHYSICS ENGINE SETTINGS ################# -->
<!--
numIterations: (int 4-128) could be simplified as 'simulation accuracy',
lower values will gain performance at the cost of less quality.
If no value is set, default is 10.
-->
<numIterations>8</numIterations>
<!--
groupIterations: (int 0-4096)
If no value is set, default is 2.
-->
<groupIterations>16</groupIterations>
<!--
groupEnableMLCP: (boolean) Turns on the higher quality constraint solver,
better constraint simulation at the cost of performance.
If no value is set, default is true.
-->
<groupEnableMLCP>false</groupEnableMLCP>
<!--
erp: (float ]0-1[) The error correction force applied per simulation
step, constraints will drift apart naturally, this value will exert a
force to move them back to where they are supposed to be.
Do not use the 0 and 1 values.
If no value is set, default is 0.2.
-->
<erp>0.2</erp>
<!-- ################ PHYSICS SIMULATION FREQUENCY ################### -->
<!--
min-fps: (int 60-300), is the main frequency at which physics simulation will
advance; in fact, it defines the main period of time at which the physics
simulation will advance; (p=1/f). min-fps should never be configured
under 60, or the bullet physics engine will badly bug. The higher it is,
the better your physics simulation will be and the more costly for your
CPU/GPU. 120 costs twice as much cpu as 60.
If no value is set, default is 60.
-->
<min-fps>60</min-fps>
<!-- ################### PHYSICS SLOWDOWNS ########################### -->
<!--
maxSubSteps: (int, 1-60) this setting allows you to choose between fps and
physics simulation quality, at low fps.
maxSubSteps is the maximum number of physics calculus steps, each frame.
Slowdowns are experienced when fps are below min-fps/maxSubSteps.
With the default value, slowdowns are experienced below 60/4 = 15 fps.
The higher it is, the more costly your physics simulation will be at low
fps. 2 substeps cost twice as 1 substep.
When fps are above min-fps, one substep is enough; when fps are between
min-fps/n and min-fps/(n+1), n+1 substeps are necessary.
The max value is 60, which allows for slowdowns below 5 fps when min-fps
is at 300 (max value).
If no value is set, default is 4.
-->
<maxSubSteps>1</maxSubSteps>
</solver>
<!-- ################### WIND EFFECTS ########################### -->
<wind>
<!--
enabled: (bool) Whether to enable wind effects, default is true.
Wind in Skyrim is not developed well and appears to be a static direction.
Wind can be detected generally from the sky object or by a weather object.
Wind can be tested when snow or rain is falling (e.g., SkyrimStormSnow)
-->
<enabled>false</enabled>
<!--
windStrength: (float) Base strength of wind. Compare to gravity which uses
9.8 m/s^2, default is 2.0.
-->
<windStrength>2.0</windStrength>
<!--
distanceForNoWind: (float) How close to an obstruction for wind to be fully blocked.
This scales linearly with distanceForMaxWind. default is 50.0.
-->
<distanceForNoWind>50.0</distanceForNoWind>
<!--
distanceForMaxWind: (float) How far from an obstruction for wind to be not blocked.
This scales linearly with distanceForNoWind. default is 3000.0.
-->
<distanceForMaxWind>2000.0</distanceForMaxWind>
</wind>
</configs>
I recently moved to a new PC with a faster CPU (I7-14700) and it seems to happen more often. I used an app that moves things from one PC to another. I'd been better off to just reinstall Skyrim and all the mods; might have cleared this up.
Tbh, I was at complete opposite of you. I can never be able to replicate this bug without using this mod. :p
Hope one day u and the author of racemenu can figure out a way to handle this.
Other than that, yeah, just download and install. Once HeelsFix MCM is registered, go in and enable stuff. For NPCs, choose SPID if you have it installed, otherwise choose Cloak.
seems I've found a way to avoid this bug(Perhaps), You can also give this method a try.
1.Disable Engine Fixes VR config (Important)
a.MemoryManager = false (Important)
b.AnimationLoadSignedCrash = false
c.CellInit = false (Important)
d.FixShadowSceneCrash = false (Important)
e.BSLightingShaderForceAlphaTest=false latest verson
f.FixShadowSceneNodeNullptrCrash = false latest verson
g.SelectAllocator = 1
2.Disabled RaceMenuVR config
a.bEnableOverlays=0
b.bEnableBodyGen=0
c.bParallelMorphing=0 (Important)
3.Upgrade Skyrim ESL Support (Optianl)
a.RaceMenu ESL Patch (Important)
b.PapyrusUtil ESL Patch (Optianl)
4.Upgrade FSMP
Lastly, a heartfelt thank you to the author,this is an excellent mod! Let's not let misunderstandings hurt contributor.
Like Figure 1
levitate
Unable to fit properly
When I equip body heels goes underground but after I re-equip them they behaives normal
I have been enjoying it a lot.
How ever, Im testing this: https://www.nexusmods.com/skyrimspecialedition/mods/85599?tab=files
And it seems not to be compatible... I mean, heels fix do not fix... any tip?
So, if you want to use their animation mods while using Heels Fix (Sitting, Leaning), my general recommendation is to just delete all the 'HH' versions. That is, after installing the mod, go to Data\meshes\actors\character\animations\OpenAnimationReplacer\SDB MFSAO\and delete all subdirectories that end with _HH
Specifically, Documents/My Games/Skyrim Special Edition/SKSE, look for 'skee64.log' If your PC is configured to not display 'known' extensions, it will be just called 'skee64'. It should be timestamped with last time you ran the game and first line in it should be:
[2024-03-31 16:41:29.188] [logger] [debug] NetImmerse Override Enabled
Also, I am also not quite sure if your issue is that you can't make ANY heels work, or you are failing to make specific heels work.
If so, in the Outfit Studio it should look like this:
And of course, after you save the project, you need to actually run BodySlide and build this project.
Also, you might have some weird combo of mods causing this. For example, someone was having an issue with sunk heels whenever they used 'Yamato Scabbard Remastered' mod with an SMP tassel, Mu Join Fix would sink their heels.
Yeah Net Imemerse Override is enabled in the skee log.
I have racemenu installed for 1.6.353 ( I know its ancient, just never bothered to upgrade as i have way too many mods). However, im not finding any skee64.dll
So that may just be the issue.
Gonna let you know how that goes.
Thanks once again for clarifying what exactly "lifts" the character.