scroll wheel zoom disable for many animation sequences

[anjenthedog]

With regards to SL animations... curious why that is.

 

Some allow it, but many *seem* to actively disable the scrollwheel zoom (3rd person) while they're active. I'm not sure why.

[PippinTom]

I bet that majority of them if not all use animation objects (including furnitures, those invisible included) of some sort?

[badbat111]

i know billys cuffed animations dont allow scroll zoom maybe the animation files have set thing to disable controls ?

[Gukahn]

I can zoom with all animations. What kind of camera mod do you use? I'm using freeflycam 

[anjenthedog]

5 hours ago, Gukahn said:

I can zoom with all animations. What kind of camera mod do you use? I'm using freeflycam 

Improved camera. I can zoom if I go into tfc mode but not while in "vanila" third-person (ie what one might use while walking around in third person).

 

10 hours ago, PippinTom said:

I bet that majority of them if not all use animation objects (including furnitures, those invisible included) of some sort?

at least some yes, but not all that include furniture or other props. 

 

9 hours ago, badbat111 said:

maybe the animation files have set thing to disable controls

could be. Don't know why someone would do that, but yes, I suspect its intentional as well (with no proof, just a "feeling").

Edited August 19 by anjenthedog

[traison]

What do your calls to DisablePlayerControls look like in SL? Any modifications made there?

 

Other than that there's 2 other locations I know of that contain per-animation flags for what is allowed:

1. IDLE records, which is not applicable to SL scene animations.
2. HKX files. These I have not been able to inspect properly yet.

On 8/19/2026 at 4:56 PM, anjenthedog said:

Don't know why someone would do that, but yes

 

None of the following packs have animations that disable anything. Some of them have cameras that are upside-down or otherwise offset though. I plan to fix these once I get into the HKX files, if I can ever be bothered to.

• Leito
• Anubs
• Babo
• Billyy
• Evacuation
• FlufyFox
• GS
• Lords
• MCN
• Nibbles

 

Edit again: Turns out Babo has at least one animation in it that locks the scroll wheel zoom. See below for more details.

 

Personally I think I would be suspicious of dll containing mods, but I currently have nothing for how one might go about identifying which one. The 50-50 method probably works best here.

 

Edit: Actually the animation that has the camera upside down might disable camera controls. Can't remember exactly anymore. It might have been one of Billyy's ice wraith animations?

Edited August 20 by traison

[badbat111]

2 hours ago, traison said:

What do your calls to DisablePlayerControls look like in SL? Any modifications made there?

 

Other than that there's 2 other locations I know of that contain per-animation flags for what is allowed:

1. IDLE records, which is not applicable to SL scene animations.
2. HKX files. These I have not been able to inspect properly yet.

 

None of the following packs have animations that disable anything. Some of them have cameras that are upside-down or otherwise offset though. I plan to fix these once I get into the HKX files, if I can ever be bothered to.

• Leito
• Anubs
• Babo
• Billyy
• Evacuation
• FlufyFox
• GS
• Lords
• MCN
• Nibbles

Personally I think I would be suspicious of dll containing mods, but I currently have nothing for how one might go about identifying which one. The 50-50 method probably works best here.

 

Edit: Actually the animation that has the camera upside down might disable camera controls. Can't remember exactly anymore. It might have been one of Billyy's ice wraith animations?

the billy human cuffed yoked armbinder disables camera as well often i tryed using zoom in and zoom out some how the camera locks into what ever you have it set to before animation triggers and your stuck in that camera view point

[traison]

1 minute ago, badbat111 said:

the billy human cuffed yoked armbinder disables camera as well often i tryed using zoom in and zoom out some how the camera locks into what ever you have it set to before animation triggers and your stuck in that camera view point

 

Ah yes I skipped out on the BDSM stuff so I dunno about that.

[badbat111]

could the culprit be the anime objects since it applys items ?

[traison]

21 minutes ago, badbat111 said:

could the culprit be the anime objects since it applys items ?

 

OP already answered this.

[anjenthedog]

15 minutes ago, badbat111 said:

could the culprit be the anime objects since it applys items ?

Perhaps, or maybe in some cases... but I'm not so sure. Some with props (tables, chairs etc)  do "break scrollwheel zoom", but some don't

 

I'm favoring the "it was purposely or unintentionally disabled by sequence, though I don't know why that would be done. 

 

@traison Not exactly sure which SL calls you're suggesting. Settings are ok in the MCM, but I suspect your'e talking about monitoring SL in the background, that I haven't done.

thanks for the list of "safe" animation sequences. It *might be that I haven't updated any of them in a long time, idk. will  start checking them ...could take a while but I'll be back.

[traison]

3 minutes ago, anjenthedog said:

Not exactly sure which SL calls you're suggesting. Settings are ok in the MCM, but I suspect your'e talking about monitoring SL in the background, that I haven't done.

 

sslActorAlias.pex and sslSystemConfig.pex contain calls to DisablePlayerControls. Arguments passed to both are as follows: true, true, false, false, false, false, false, false, 0

 

Description for what they do is in the API. The 3rd one for instance is abCamSwitch, 4th abLooking and the last one is aiDisablePOVType. I realize none of these specifically mention zooming in while in 3rd person but still. The fix for when you get stuck (with a totally broken camera) after a scene is in this DisablePlayerControls call as well: changing abActivate to true prevents the bug from happening, and this is kind of my point that not everything is spelled out.

[anjenthedog]

2 hours ago, traison said:

sslActorAlias.pex and sslSystemConfig.pex contain calls to DisablePlayerControls. Arguments passed to both are as follows: true, true, false, false, false, false, false, false, 0

 

Ah...thanks. I'll look at the .psc (since pex are compiled and look like gobbledeegook)

 

I can't swap an edited psc for a compiled pex, right?  (to cheat having to compile script, for testing purposes)  << one can hope (but probably futilely)

 

2 hours ago, traison said:

The fix for when you get stuck (with a totally broken camera)...

 

I should have mentioned that the scrollwheel zoom is locked out only for the duration of that animation sequence (and any others that play after which are also locked out for scroll wheel, prior to exiting SL control).

 

After ending/exiting the scenes entirely, zoomwheel works again. And in fact, if it switches from a zoomwheel-disabled sequence to an enabled sequence, prior to exiting the SL instance, the zoom will often (or always?...not sure always)  reenable.

[traison]

1 hour ago, anjenthedog said:

I'll look at the .psc (since pex are compiled and look like gobbledeegook)

 

This is fine as long as the psc is provided by the same mod as the pex. An assumption can be made then that they're probably the same script.

 

1 hour ago, anjenthedog said:

I can't swap an edited psc for a compiled pex, right?

 

Nope.

 

Same issue as back in 2019 huh?

 

Edit: Also lots of things on Google about the modifier keys getting stuck and blocking the mouse wheel. Spank the L/R Shift, L/R Alt and L/R Ctrl buttons a few times and test again.

Edited August 19 by traison

[PippinTom]

39 minutes ago, traison said:

Edit: Also lots of things on Google about the modifier keys getting stuck and blocking the mouse wheel. Spank the L/R Shift, L/R Alt and L/R Ctrl buttons a few times and test again.

 

It's not so trivial. And OP is not the only one that suffers because of that mousescoll lock. And it is not caused directly by SL enable/disable controls calls(*) - otherwise it would happen always or really rarely as anomaly of execution/choked papyrus pipe or something (and I did try tweak those all ways possible back-and-forth with no permanent improvement); but id does happen for specific animations (where it's more-or-less 100% repro - yet I'm not sure now - have holes in memory and rarely take notes on such issues) - there is bench animation by NCK30, no idea now how it's called (will note it down next time) which is perfect repro example/test subject... actually more than average few of NCK30 anims cause that issue, that's what has imprintend in my memory anyway - but probably without that 100% repro.

 

Anyway, issue already asked about - you probably don't remember - I even checked animations jsons in hope to find some pattern in suspected anims vs those that always work fine. I can't recall finding anything, but that may be due to my build in technical limitations

_________

*) There is always a possibility of 3rd party messing with SL, in form of DLL-crap-mod which at more or less the same time tries to execute same functions causing engine to choke on it. But so far I don't have a single suspect.

[traison]

30 minutes ago, PippinTom said:

It's not so trivial. And OP is not the only one that suffers because of that mousescoll lock.

 

Then if we also assume it's not a dll doing it the only thing I can think of is to go at this with a debugger and follow the wndproc messages through the assembly code to where it gets (presumably) ignored. 2-3 days of work minimum and I'd have to be on someone's computer that's having the issue. That does not include unpacking the exe, fixing a bug in SKSE, setting up my tools and potentially creating a bytecode patch. I suppose the fixed SKSE can be transfered over, but the unpacked exe could be considered piracy so that would have to happen locally I think.

 

A workaround should be considered instead. Anyone of you tried to playidle something else after the mouse wheel stops working? Like a Cicero dance animation or such?

[PippinTom]

Issue here is the mouseWheel not zooming in/out during (some) SL animations, especially if played in sequence (more anims in a row during single SL scene session), while AFAIK issue at hand is not mouseWheel being locked after SL scene, which, as already pointed out, can be rather easily fixed by interacting with any workbench type (it's handy to have one spawning bat ready for such situations). If that makes things a bit clearer.

[traison]

22 hours ago, PippinTom said:

Issue here is the mouseWheel not zooming in/out during (some) SL animations, especially if played in sequence (more anims in a row during single SL scene session), while AFAIK issue at hand is not mouseWheel being locked after SL scene, which, as already pointed out, can be rather easily fixed by interacting with any workbench type (it's handy to have one spawning bat ready for such situations). If that makes things a bit clearer.

 

Playidle can be issued at any time. I would do "playidle idlestudy" during the SL scene when the mouse wheel is no longer responding.

 

Edit: playidle does not work during SL scenes apparently. I'm assuming Debug.SendAnimationEvent overrides this.

Edited August 21 by traison

[anjenthedog]

11 hours ago, traison said:

Same issue as back in 2019 huh?

 

The zoomwheel lockup (in this case) is during an SL event only, and it lasts only until either a new sequence is called up using a random or selected new sequence action ("o" for random selection via SL, or "O"  to select one via Defeat), or the SL event is over. 

 

That 2019 issue was something else (glitch) that would lock up the camera view semi-permanently while in regular play mode (until visiting a crafting station, where the exit animation from the station fixes it)

[traison]

48 minutes ago, anjenthedog said:

That 2019 issue was something else (glitch) that would lock up the camera view semi-permanently while in regular play mode (until visiting a crafting station, where the exit animation from the station fixes it)

 

The way I read it suggested that it was different from the camera lockup issue I've seen in SL where the mouse controls die almost completely. When I had the abActivate issue I couldn't turn my camera for instance, since it would turn the character instead. Your 2019 post suggested you can turn the camera. Thus I left the door open for the posibility that even if the timespan of the issue is now different (before end of scene as opposed to continuing beyond the end of the scene), the root cause could be the same or similar.

 

Another idea: since it seems you can somewhat reliably replicate the problem, how about you switch the hkx files around between animation stages that usually work with the ones that usually don't work. Remember to rebuild behaviour files in-between.

 

And speaking of behaviour file generators. Rebuild with FNIS and test again if you haven't already.

[anjenthedog]

haven't made  a great deal of progress in testing "All" sequences, but I did confirm that when a scrollwheel-locked animation sequence is swapped for one that isn't (during the same SL event) using the sequence selection menu (hotkey O) or via a random select (hotkey o), scrollwheel zoom comes back, (and locks again if the previous locked sequence or another locked sequence is selected...and will unlock once again if a sequence is selected that doesn't contain said lock...repeat and rinse) so it appears to be related to the specific animation sequences

 

1 hour ago, traison said:

Your 2019 post suggested you can turn the camera

 

 

In that specific instance, pan was still available. More often than not,, it was a total lock of camera pan and zoom. ... navigation to a station was particularly laborious, since it meant going to tfc, panning till the camera faced in the direction of desired movement, exiting tfc, walking, going back to tfc for turn , repeat until target crafting station was approached so it could be triggered

 

Anyway, something changed between 1.5.80/1.5.97 and 1.6.1170...I never (?rarely?) get those kinds of camera glitches (2019 post) any more under 1.6.1170.

 

the SL sequence lockout of scrollwheel (for some sequences) however is present., but as said before that lock releases at the end of the SL event, or when a non-locked animation is selected.

Edited August 20 by anjenthedog

[anjenthedog]

59 minutes ago, traison said:

Another idea: since it seems you can somewhat reliably replicate the problem, how about you switch the hkx files around between animation stages that usually work with the ones that usually don't work. Remember to rebuild behaviour files in-between.

 I might come off as having a half of a brain cell sometimes, but I'm not that savvy. Not by a long shot.

[traison]

8 minutes ago, anjenthedog said:

In that specific instance, pan was still available. More often than not,, it was a total lock of camera pan and zoom.

 

Anyway, something changed between 1.5.80/1.5.97 and 1.6.1170...I never (?rarely?) get those kinds of camera glitches (2019 post) any more under 1.6.1170.

 

The abActivate issue is actually something the player does themselves; accidentally usually. I currently wouldn't attribute this to game version differences. I saw it in 97 and 1170.

 

6 minutes ago, anjenthedog said:

...I'm not that savvy.

 

Lets say you have a Billyy's missionary animation that works fine and a cowgirl anim that doesn't, this test would look like this:

Billyy_A1_Missionary_01.hkx -> Billyy_A1_Cowgirl_01.hkx
Billyy_A1_Missionary_02.hkx -> Billyy_A1_Cowgirl_02.hkx
Billyy_A1_Missionary_03.hkx -> Billyy_A1_Cowgirl_03.hkx
Billyy_A1_Missionary_01.hkx -> Billyy_A1_Cowgirl_04.hkx ; Assuming there is more cowgirl stages than missionary ones.

 

The hkx files you're looking for will all be in meshes\actors\character\animations.

 

If the cowgirl scene now doesn't break the mouse wheel we can rule out SL and dlls and limit it to the hkx files and the behaviour file generator. This would significantly reduce the pool of options.

[PippinTom]

Since I'm on a break from Skyrim and my memories seem to fade - I just started it to make see how it works, and did few random tests. And happily stumbled on one of those animations with 100% repro (in my setup anyway), this time I've noted a name, so here it i

      "id": "Babo_HorseTraining",
      "name": "Babo(Horse) Training",

AND/OR

      "id": "Babo_HorseTrainingAnal",
      "name": "Babo(Horse) Training Anal",

 

It does not fail as test subject, no matter if started standalone or in sequence with other animations.

 

PS: I don't think that even if cause of camera controls fuckup is direct result of something baked in animation file(s), it is intentional nor serves any purpose for the author(s). I would rather suspect some glitch caused by tools or their setting used when creating, exporting, converting them.

 

[traison]

2 hours ago, PippinTom said:

"id": "Babo_HorseTraining",
      "name": "Babo(Horse) Training",

...

It does not fail as test subject, no matter if started standalone or in sequence with other animations.

 

Was able to replicate here. Very interesting that I haven't stumbled upon this in my soon 15 years of modding Skyrim. Guess I'll have to spin up a virtual machine for hkxcmd and see if I can break one of them animations down to its components.

 

Edit: Looks like @PippinTom is right about it being an issue with AnimObjects. I removed the haybale and stockade from Babo_HorseTraining and the scroll wheel works again.

 

Edit again: Rebuilding with FNIS does not fix it.

 

Edit again: POV switching is also disabled, as in, the F key does not switch between 1st and 3rd person.

 

Edit again: epc 1 1 1 1 1 1 1 1 1 does not re-enable POV switching and playidle does not work during a SL scene like I assumed it would.

Edited August 21 by traison