Home Artists Posts Import Register

Downloads

Content

Hey!

It appears that I've found all the places I needed to fix up to double the max animation limit in a project from 32k to 64k.

The default value is still 32k but you can increase that through the ingame settings menu (press insert to open, the key can be changed in the ini that's generated after the first run). Requires a game restart to take effect, of course.

When increasing the limit to the maximum, increase the havok heap size as well, as it'll crash when it's too small.

Both values can be set to the maximum allowed value by the settings menu, but I'm not sure whether that's a good idea to set them to max by default. That amount of animations is a lot. I don't think most people will hit the 32k limit.

I tried to figure out replacing the synchronized animations (killmoves) but still no dice. There's a lot of weird stuff happening there, the synchronized animation clips have their own index in the animation bindings, separate from the actual animation clips used in the synchronized animation. It's all very strange. They also contribute to the overall maximum animation limit (along with possibly other unknown stuff) so the animation counter in the ingame menu now shows the size of the animation bindings array - should be more correct and avoid edge cases where you're almost at the animation limit and trample over the space that needs to be reserved for the synchronized clips, and break everything.

I've reverted the changes from 0.3 (the ones that skipped the anim queue) and put them behind an experimental setting that's disabled by default, because of the issues some of you were experiencing. Seems it's not the way to go generally, at least for now - I can't find a way to reproduce these issues on my side (seems to work perfectly fine) so I don't know where to look - and even then I wouldn't be sure.

There's also a setting, enabled by default, that loads the male/female behavior projects right when you enter the main menu - so the animations get queued for loading as early as possible.

EDIT 0.4.1: Attempted to fix the random crash caused by bLoadDefaultBehaviorsInMainMenu, uncommented the code that loaded female behaviors (oops). Also found another place I missed related to the anim limit patch, and fixed it.


Comments

Anonymous

So unfortunatly it seams that 0.4.0 makes me crash on game load, here are my results: 0.2.4 -> loads fine 0.3.x -> loads fine 0.4.0: - Load before animations are loaded, crash (with StartOnSave) - Load while animations are loading, crash - Load after animations are loaded, crash I'm runnning 1.6.640.0 I'm very rusty on how to look at skyrim logs, but let me know if there are any others that you may need: https://pastebin.com/yVdgA92u

Anonymous

Hiya. This happened to me too. Found a workaround tho, it seems to not crash on new saves and after the animations has been loaded. On the main menu, type "coc whiterun" on the console, it should load all the animations then load your existing save.

tridbee

Hi, it seems like this update is working in my game like 0.2.4 again. One question about animation limit and havok heap size: Assuming I edited uAnimationLimit = 32767 to uAnimationLimit = 65534, how much should uHavokHeapSize be increased? I'm assuming I need to also double the heap size as well. EDIT: Doubling heap size will crash SKSE after launching it for a few seconds, definitely need to wait for answer about increasing heap size accordingly to animation limit. EDIT2: I've changed back to my overloaded animation setup that makes OAR give out warning about animation limit before with only uAnimationLimit set to 65534 and.. it worked! DAR animation works without issue as well but definitely need more playing around to make sure nothing is off with this loaded setup.

Ersh

Yeah I'm not entirely sure about the heap size. The vanilla value is 0x20000000, which crashes when 32k animations are loaded for both projects. By default I've doubled it already to 0x40000000. I've set the current max value allowed by the UI to whatever it is right now because anything above seemed to instantly crash. It does run fine in my case with the maximum value but as we all know by now, stuff that works for me tends to mysteriously not work for others :|

Anonymous

I think I may have found one of those unintended consequences for your changes to the animation queue. Sexlab (yep that one, I guess I'll be the one to bring it up) is experiencing some strange side effects to whatever was changed in v4.0 Specifically, the animations and the setup stage where it aligns actors is crazy fast after switching; not 100% sure but I think the animations played at frame limit, which is definitely not normal for Sexlab. (It works well enough, but I've always found it slow to fire off animations.) More importantly, if Sexlab has multiple scenes queued up to play back-to-back, it aligns actors well enough but then skips all queued scenes until the last one. (ie in my specific testing conditions, five actors had scenes to play, but only the last one actually animated.) Also noteworthy is that this behavior is absent from both release 0.2.4 and from DAR now that it's been updated. *update* I think the problem may have been baked into the save file, it corrected itself after awhile

Anonymous

I've been running all of these since 0.2, and this latest 0.4.0 seems to be functuioning better than all the previous iterations. Great job Ersh! Do I still need to run the Animation Queue anymore with this one?

Ersh

I didn't change anything else, I reverted the changes and it works like in 0.2.4 if you didn't enable the experimental setting.

Ersh

Yeah, if the progressbar in the upper right shows up (it will if you havent enabled the experimental setting) then it means the queue is used so you still need the fix.

Anonymous

One thing I noticed while having the UI open - can it be only the male animations are loaded during the main menu? All the others (female, first person) popped up just before loading a savegame is finished.

Ersh

Hm, it's supposed to be both male and female (not first person, couldn't find a simple way to do that)

Petra Pox

Seems like none of my movesets are working with OAR, it defaults to Elder Souls.

Anonymous

So good news on my end, 0.4.1 appears to solve every problem I had, I can use both features (load in menu, and experimental anim loading), no crashing, and no kraken, don't know what you did, but this version seams to be working withouth a hitch! Played for 1h and found no probolem, if I do find anything I'll write back, but so far thank you for the hard work! Edit: so after almost 6h of gameplay (I do love me some bank days), I think this is as stable as 0.2.4 for me, so far the ONLY time I saw something was a mini kraken during an animation (possibly when multiple conditions matched multiple animations, crouching, waepon at hand, attack, and health) but I've been unable to reproduce it, so yha, I'm loving this version :)

Ersh

Well that's not supposed to happen, OAR had parity with DAR for a while now. Which moveset isn't working? You can also inspect the animations in the in-game UI when you press insert. Find an animation on the list and see if the priority/conditions are evaluating correctly for the player.

Anonymous

How do you increase the Havok heap size?

Ersh

Either in the in-game UI in the settings submenu, or in the .ini created next to the plugin dll

Anonymous

So far so good. My previous DAR related crash in the Helgen opening sequence (DAR + some unmount animation from Tullius I cannot pinpoint) does not happen. Edit: works like a charm; problem was some Creation Kit conversions of Form 43 mods..

Ersh

Haven't got any better idea right now, it does sound like kind of a mess. Are there even any replacers for that particular animation that gets stuck?

Anonymous

Just want to echo what a few others are saying which is 1. disabled DAR and installed this and "it just works" (tm), and then 2. this mod drastically reduced my initial load time by half over DAR, which is always nice! Might of even gained a few frames back too. Keep up the good work!

Bruce

Hey Ersh, I'm not sure this is even possible but... can you make it so that if a DAR-based mod (say EVG Conditional Idles) has the same conditional folder # (or #'s) as another mod, OAR would recognize that, alert you to which mods were conflicting, and give you the option to choose which of those mod's folder numbers to change? And then change them to a non-existent number, higher or lower in the hierarchy depending on your choice? Again, not sure it is possible, but it sure would save a lot of time running through condition folder #'s. Especially if you are like me and have a ton of DAR animation mods. EDIT: And while I'm at it, if we were to try this out (since it is sounding like it is in a semi-polished form and saves significant loading time) would we just place it in the same location as we have our Dynamic Animation Replacer in the load order?

Bruce

Ah, I guess never mind on the first part of that. It was pointed out to me that DART does similar to what I am looking for. I just haven't had time to explore it yet. But the Edit part about placement stands.

Ersh

DAR mods are going to be mostly treated as legacy - they should work exactly the same, but I won't be adding special features just for them. Also I don't think that's technically possible as for the game (and plugins) the folders and their contents end up merged into one by the mod manager, so at that point there isn't any way to know that the conditions txt file has been overwritten by another one, etc. OAR mods are going to have a different structure, where the priority isn't set by folder name, so there won't be any *hard* conflicts like that, where two mods end up in the same folder, overwriting some files and making a total mess. But a warning when two mods share the same priority should be useful, as it's pretty much always unintended behavior. The user will be able to change a mod's priority easily in the UI. As for load order, it's just a .dll plugin, so no load order applies here. So: yes, but it doesn't matter :)

Bruce

Thanks for the info, Ersh. I spoke with walkswithwolf on WiZkiD's Discord last night and he updated me on many of your plans about DAR legacy work and heading in your own direction after that. It definitely sounds very promising. I will probably be trying it out after I eventually get all my duplicate folders fixed.

Anonymous

Sorry for necropost but just found out the culprit for the melting skeleton in my case was the Movement Behavior Overhaul by iRetrospect. It specifically melts when playing yamato running animation by anchor

Ersh

I don't think it's caused by any mod in particular, there's gotta be something wrong with how animations get loaded in the experimental mode, and rarely a random animation is affected.

Anonymous

Oh I see. Well I guess it makes sense why it's turned off in the first place. But hey, it seems to work properly in my case so I'll turn it on until some issue occurs. Keep doin what you're doin king.

Anonymous

I've cutover to 0.4.1 and its working flawlessly. Definitely more performant than DAR.

Anonymous

Hi Ersh. Firstly great work! I would like to report my experience about killmoves. I think I can confirm what you say about "trampling" over the space reserved for the synchronized clips. I use a lot of DAR animations (too much I confess because I accumulated them over the time and now I'm too lazy to sort them and ditch the ones I don't need anymore). On top of that, I have Violens which add killmoves on every occasion. With OAR 0.4.1, if a killmove sequence should happen, the animation is not played. Instead a normal attack animation is used. What is "fun" is that the enemy doesn't register any damage. Furthermore, he seems to be impervious to subsequent hits! If I desactivate Violens, normal killmoves work. If I replace OAR with DAR and keep Violens activated, killmoves work again. Here are the numbers in the animation counters ingame: DefaultMale: 20123 + 234 FirstPerson: 1261 + 209 DefaultFemale: 20425 + 234 I use a female character. I definitely need to trim down my DAR structure...

Anonymous

I've been using 0.4.1.7 and it works great.

Anonymous

Hey ersh, lovely work! I belive that OAR is currently incompatible with elden rim, not really sure why. Everthing else seens to be pretty fine, even the violens killmoves. I instaled OAR and the elden rim weapon arts stopped working. I just reinstalled DAR, and it seens to be working again, for some reason elden rim and OAR are not currently compatible, at least in my setup!

Naotenho nome

Hey Ersh, I just wan't to Reiterate what Edgar Toniolo said, at the moment OAR can't properly read the following animations : "combatidlea" "combatidleb" combatidlec" "combatidlesmalla", "combatidlesmallb" and "MT_PointFar_01". Upon casting spells with these animations, the character will just taunt or point (the original intention of said aninations). These are all animations used by Elden Rim as "proxy" to cast weapon arts, I myself used his script and this method for various custom spells. And speaking of Elden Rim, I have a suggestion if it's ok. The implementation of the following condition : - DistanceToForm(distance, form) It would be huge for making certain attacks trigger based on player distance and changing/triggering other animations for quest scenes and such based on distance to objects.

Ersh

Thanks, I'll try to replicate the issue. As for the condition suggestion, it's interesting but it seems a bit non-flexible by requiring a form. Something like DistanceToCombatTarget might be interesting, if it works as expected.

Naotenho nome

Thank you so much for checking it out, and thank you for considering the suggestion. My reasoning behind DIstancetoform is that it would be useful to make custom boss fights with additional moveset conditions. It would be possible to make a boss decide on which movesets to use against the player (or unique attacks against followers for example), it would allow for more flexibility creating bosses. With that being said, DistanceToCombatTarget is an incredible idea aswell! At any rate, your work already is incredible and thank you so much for everything you've been doing, OAR fixed a game breaking issue I had with DAR (memory leak, too many animations and conditions) and it's been a modlist saver.