NOTE: This Article was written July 2019. It describes a situation (Load CTD whith more than a certain number of animations added by FNIS. This is caused by a bug in Skyrim.

In the meantime there are several SKSE plugins available which circumvent this Skyrim bug. Which means that the problem can be easily circumvented by users of many acustom animations. But for explenatory reasons, and because new users will not know about the fix, FNIS will still warn when the original limit is passed. The SKSE plugins that increase the Skyrim animation limit are:

Skyrim has a hard limit for custom character animations. For both LE and SE we can install up to 26,162 additional animations. No more, no less. Period. Of course only the most simple we know: basic animations, as they are used in poser mods. Everything else has its penalties, and that can bring down the limit to 9,000 and less.

Starting with V7.5, FNIS will warn you when you have reached the critical animation limit. FNIS XXL will also calculate the contribution of each FNIS depending mod towards this limit.

In order compare the required space for the different animations and functionalities I will use "unit" in this article. Each most simple animation takes up 1 unit. And with more than 26162 units you will have Load CTD.

1. What we know
  • the 26162 animations CTD limit is solely for simple 3rd person character. Creatures definitely don't count. I had an installation starting without any problems with 26k character, and 28k twice for 2 creature races. 1st person doesn't seem to be counting as well, although I have only tested with 2 custom 1st person behavior files (TK Dodge, AOG).
  • this limit isn't an animation limit, it is a "behavior" limit. It is dependent on certain types of functionality in the behavior files. If you use the new AGO patch in FNIS for example, the number of possible animations will automatically drop, although AGO doesn't add custom animations (only animation replacers and a few behavioral changes). But since the whole purpose of the behaviors is to control animations, it looks like depending on the animation count. But it is not. And that's why different users experience different numbers of animations when their game CTDs.
  • this limit seems to be caused by the fixed size of a memory chunk. Its size is the same for LE and SE, and it is not influenced at all by the memory shortage at start time that is addressed by sheson's fix.
  • this limit isn't a Havok based one. Since creatures seem to have "no" limit, it appears to be caused by one of those Bethesda work-around measures in order to have better access to behavior data. Like in character\meshes\animation*datasinglefile.txt.

2. Which parameters influence Animation CTD Limit

Currently (FNIS 7.5 XXL Beta 6) FNIS counts or calculates 23 different numbers in order to determine the Load CTD limit. There are possibly a few more that might have influence. However, I don't think they play a big role given the likelihood of certain FNIS parameters to be used.

Here are the most important ones, and their respective Load CTD contribution (in "unit", the space required for 1 simple animation):

  • "b -md" animation (1 unit): these most simple animations are "motion driven", which means NPCs are not protected during the animation from being pulled away from their spot by AI packages.
  • "s -md", "so -md" animations (2 units): header anim for sequenced animations.
  • "fu", "fuo", "ch" animations (2 units): header anim for furniture animations. Furniture animations are automatically protected from motion by the engine.
  • "+" animations (1 unit): continuation anim for "s", "so", "fu", "fuo", "ch" animations. These animations are automatically protected from motion when the header anim already is.
  • NO "-md" parameter (2 units): per default "b" and "s" animations are defined as animation driven, which prevents NPCs from moving away from their position due to AI packages while an animation is played. This is extra functionality, and takes 2 units (when the "-md" parameter is NOT present). The reason for that is the Havok node "BSIsActiveModifier" which is used to set and control Animation Variables. A node type btw which was implemented by Havok on behalf of Bethesda (which you can see from the first two letters "BS", no rubbish)
  • number of AA "clips" (1 unit): most vanilla animations appear (as "clipgenerator"s) more than once in the behavior files. FNIS counts these clipgens. See "Why are Alternate Animations so expensive?"
  • "-AV" parameters (2 units): for the same reason that not adding the "-md" takes 2 units, setting AV parameter also requires this amount of resources: they are implemented with the same "BSIsActiveModifier". For example to suppress FootIK, some animation mods set "bHumanoidFootIKDisable". This is quite a lot, although the "BSIsActiveModifier" only counts once even if more than one AV is defined, or when -md is not defined on the same animation. Also when set in the "s" header, the -AV setting is active for the whole sequence.
  • patch contribution (<n> units): as said before, it's not the animations that cause CTD, but behavior functionality. Best example: the tktk1 patch. It only adds 5 new animations, but takes up 76 units.
  • behavior file contribution (5/3 units): every custom behavior file created with the FNIS for modders tool contributes 5 units. Unless there are no "b" or "s" definition included (e.g. when only Alternate Animations are defined), then only 3 units are lost.

3. An example FNIS XXL generation (without optimization)

Note: This example was created with an earlier version of FNIS, and therefore looks slightly different from current results

  • ChAnims: Character animation slots added (can be more than actual files)
  • CTD: How many percent this mod / installation contributes reaching CTD
  • pOpt: How many percent this mod / installation can be optimized
  • max:How many animations you could approx. add (with similar animation types)

In this example there are 2 different "Notes" that indicate unnecessary waste of animation resources. Waste that can be easily fixed by users without any implication (although it should be the mod authors who should generally fix it in their downloads):

  • <mod> has at least one identical -AV defined in both 's' and '+' line. See "6. Possible optimizations, part 2: "-AV" parameters in "s"-animations"
  • <mod> has at least one AASet definition without any animation files provided. See "7. Possible optimizations, part 3: superfluous AAset definitions"

4. Why are Alternate Animations so expensive?

For Alternate Animations (AA) it doesn't matter how many animations are added, but instead how often these animations are used in the behavior files. The animation that is used most is mt_idle.hkx. This animation is used 16 times in the behaviors (in so-called clipgenerators). Sometimes to be blended with other animations, sometimes as start or end animations of a furniture sequence. The 545 vanilla animations that FNIS supports with AA are used in 1370 clip generators, which means that every vanilla animation appears 2.5 times in the behavior files. And each appearance counts.

Another reason that can cost a lot of additional load is the animation grouping that is implemented by FNIS. In order to discretely control each of the supported 545 animations, it would also need 545 different animation variables. And hundreds of Papyrus calls for mods like PCEA2 in order to change them. Therefore FNIS has grouped the animations, and each group is controlled by one single animation variable. Group sizes range from 1 (mt_idle) to 44 (1hm_attack). Usually when an animator makes one animation, he will also create other animations for the same group. That is certainly true for directional movement. It doesn't make sense to provide custom mt_walkright, but no mt_walkforwardleft.

However there is an animation replacer for example that adds only 1hm_attackRight. But since the 1hm_attack has 44 animations with a total of 47 clips, this one animation takes as much room as 47 units. And actually 94 units, if there is no other mod that provides 1hm_attack animations. Because the construct that distributes between the different clipgenerators also requires 1 unit. What a waste.

5. Possible optimizations, part 1: the "-md" parameter

This unpleasant inefficiency is owed to my own indulgence. :)

At a time when no one was really worried (and knew) about animation limits, I was asked to make "animation driven" (ad) animations the default for "b" and "s" animations. "ad" animations are animations that contain their own motion data, and don't react on character motion. Neither the player can be moved with controls during the duration of the animations, nor NPCs with AI packages. Which has the advantage for animation mods that they don't need to make NPCs immovable by other means to keep them in place during the animations if an AI package should fire.

But the animation limit penalty is tremendous. It takes 2 units unit to make this work.
"b" animations need 3 units instead of 1 (+200%), which reduces the number of animations from 26162 to 8720, if you had an installation with "b" animations only. "s" sequences with 4 ("s+++") animations still need 7 units instead of 5 (+40%).

Attention if you want to make the following changes yourself: DO NOT FORGET to create the behavior file using GenerateFNIS_for_Modders

In order to avoid this penalty you can define "b" and "s" animations with the "-md" parameter. But that can result in player and NPCs moving away during an animation UNLESS the mod has it's own precaution to avoid it (like DisablePlayerControls() and DoNothing packages). We have to make mod authors aware and convince them to use "-md" parameters whenever possible. And I think that some mods already do these things in order to prevent NPCs moving away in between animations.[/color]

6. Possible optimizations, part 2: "-AV" parameters in "s"-animations only

Attention if you want to make the following changes yourself: DO NOT FORGET to create the behavior file using GenerateFNIS_for_Modders

Some mods have set animation variables in an "s" or "so" definition, and then again in the "+" successor lines. (E.g. "bHumanoidFootIKDisable" which does what the name indicates: release the actor's feet from the ground). These repeated definitions are unnecessary, because any AV setting defined for the header animation last during whe execution of the whole sequence. The require 2 units per "+" line. Simply remove the whole "-" parameter, if "AV" is its only component. Or remove it from the the comma-separated list (e.g "+ -o,AVbHumanoidFootIKDisable" simply becomes "+ -o").

7. Possible optimizations, part 3: superfluous AAset definitions

An AA set you can define space for up to ten entities of one group. But when this number is too big (i.e. the mod doesn't provide at least one animation from that group for that entity), then this is an apparent waste.

In order to find this unnecessary definition (for a specific <mod>) go to the FNIS log file and find lines like this:
AAgroup <mod> _mt: 0:2/2 1:2/2 2:2/1 3:2/0***

This example shows that <mod> has defined 4 entities for the animation group _mt (with "AAset _mt 4"). This group consists of 2 animations. <mod> now provides both animations for the first entity, one for the 3rd, and NONE for the 4th entity (indicated by "3:2/0***"). If this "0***" is shown for the very last entity of this group, the AAset definition can be reduced by 1 ("AAset -mt 3" in this example).

If this "0***" is shown for any other entity but the last, then only the author can remove that waste. THe logic for activating the set would need to be changed.

8. The same example FNIS XXL generation AFTER optimization

This "optimized generation" has made room for almost 4,000 simple animations (15% less CTD contribution), although only 47 animations have been omitted.

Attention if you want to make the following changes yourself: DO NOT FORGET to create the behavior file using GenerateFNIS_for_Modders

  • Removed unnecessary "AV" parameters in AnubsHuman, FlowerGirlsSE, and NibblesAnims. See "6. Possible optimizations, part 2: "-AV" parameters in "s"-animations"
  • Reduced unnecessary "AAset" definitions in DD, and DD2. See "7. Possible optimizations, part 3: superfluous AAset definitions"
  • Removed inefficiently used Alternate Animations in FNIS PCEA2: xp32_New_Anim_Pack(mt_jumpfast), Bergzore_ImmersiveAnim(2hm_runleft 2hm_runright), yukl_YY2H_Mystic(1hm_attackright 2hm_runstrafeleft 2hm_runstraferight 2hm_sprintforwardsword mt_sprintforwardsword magic_SprintForward), yukl_YY2Hander_male(2hm_runstrafeleft 2hm_runstraferight 2hm_sprintforwardsword), cyh0405_OrientalSwordsmanship(2hm_sprintforwardsword 2hm_runforward 2hm_runleft 2hm_runright). I'm not propagating to generally get rid of these animations. But if I were in desperate need for more animation space I would remove exactly those. See "4. Why are Alternate Animations so expensive?"
  • Added "md" parameter to all "b" and "s" definitions in FlowerGirlsSE, and Sexlab. Note: DO NOT DO THIS YOURSELF. This should only be done by the owner of those mods. Because most likely they will also have to add functionality which prevents actors from moving. I only wanted to demonstrate all possibilities, and their results. See "5. Possible optimizations, part 1: the "-md" parameter"

9. What we don't know (and where YOU could help)

Usually FNIS seems to be quite reliable in calculating the CTD limit. Usually it is within the 26162 +/-10 range. But for some Beta test users there was a difference between -160 and -220. Less than 1%, but still annoying. Because when I repeated their tests I got a proper result. And after they re-installed Skyrim they could not reproduce the old difference either. The conclusion is that there is something "outside" of the behavior files which causes. Maybe an SKSE plugin, maybe a modifed skeleton. Maybe even another form of "Load CTD" that will crash the game when the resources are reserved. Maybe YOU have an installation that can give us a clue?

How do you figure out your own "CTD limit"? The following tests should be done in 2 configurations:
  • with your full animation load
  • with without any animations files installed
You test it by "filling up" your installation with the Fillup Mods (in the FNIS files section). With these files it is no problem (although sometimes quite exhausting) to find the limit accurate to one unit. Just look at the LC result of a run without Fillup Mods, and then calculate how many animations are required to get LC to 26162. But keep in mind that each of the Fillup mods you use also takes up the additional space of 5 animations.

Just look at the LC result of a run without Fillup mods, and then calculate how many animations are required to get to 26162.
(But keep in mind that each of the Fillup mods you use also takes up the space of 5.3 animations).
Fillup mods:
  • xCTDmd01, 1000 animations
  • xCTDmd2_01 to xCTDmd2_13, 2000 animations each
  • xCTDmdx_100 to xCTDmdx_900, n times 100 animations (as the name indicates)
  • xCTDmdy_01 to xCTDmdy_99, n times 1 animation (as the name indicates)
(Sorry for the strange names. They have "historic" reasons)
If you have no animation mods at all (except FNIS) you can get to the LC:26162 point by filling up with all of xCTDmd2_01 to xCTDmd2_13 plus xCTDmdy_89:
13*2000 + 89 + 14*5 (for 14 Fillup mods) + 3 (for the empty FNIS Base) = 26000 + 89 + 70 + 3 = 26162.

To find the exact CTD limit it is best to use the halving method. Usually if the game doesn't load at 26162, I'll try at 26154 (26162-8). If this works out the next test will be at 26158 (26154+4), and so on. Although these numbers are not so interesting for me: too good. Should however 26154 not load as well, you might be a valuable candidate. Start with something that gets you to 25906 (26162-256) and start halving from there.

If you have an escapee, please put the file GenerateFNIS_for_Users\temporary_logs\FNISListCollect.txt on a file server, and post the link and the limits at which you have tested (succeeded + failed).

Article information

Added on

Edited on

Written by



  1. LeFlemard
    • member
    • 10 kudos
    mmm, how did you do it for dd2? All the AA set are in the category "If this "0***" is shown for any other entity but the last, then only the author can remove that waste. " as far as I can see...
    1. fore
      • premium
      • 1,295 kudos
      By reducing the number of sets PLUS checking the logic of the DD2 scripts.

      You have to keep in mind that by removing one set somewhere below the last, all other sets above it will need an animation variable value reduced by one in order to be properly executed. And that has to be part of the logic the animation mod author has put in place.