I think for the "No Mannequins" version, the conditions file isn't going to be the same when used in conjunction with the female idles. So I don't think you can just let the mod manager overwrite the condition files when installing both the female animations and the male animations. Or I guess you can install the female set first, then let the male set overwrite.
Yes, that's correct - if using the No mannequin male version together with the female version for all npcs, then in that specific case the male set's txts must win. To be honest I haven't thought of this combination, so thanks for bringing it to attention Stickied for visibility.
Get the "Female Variant", and then the "No Mannequins" main file, and let the "No Mannequins" win the file conflicts. This will cover males and females but not mannequins. If you want to exclude the player character, look up the conditions in the player variant, and add the same line to the existing conditions in the above setup, and put a NOT before it.
If you know of available, free-resource sitting animations, then sure. So far, I haven't come across any of those. Pretty Sit Idles comes to mind, according to its permissions page, it can be modified and used as an asset, but it requires FNIS, and haven't yet explored how FNIS and DAR work together (mostly because my game runs quite a handful of inherently FNIS-incompatible mods).
FNIS and DAR works so well together, I daresay, more powerful than any PCEA implementation. I managed to throw in some animations in a DAR directory that would normally requiring FNIS. All it would need is just renaming the animation files corresponding to their vanilla equivalents.
EDIT: I'm going to test a combined version of your mod, along with those sit idles.
EDIT2: It works, but the random sitting idles from Pretty Sit work only on the player, while other NPCs use the default animation and idle for eating and drinking. I think I'll try Simple Sitting Animation.
I see. The problem is that I still can't test it, because as I said, my game is incompatible with FNIS, so I have no idea why it only applies to the player. Also, I can't seem to find Simple Sitting Animation on the site?
Is it possible to delay the idle animation poses? For instance rather than when the PC stops walking and going into a cross armed pose immediately, having the character do it as if they're waiting or getting bored? Just a little immersion breaking how they go into the idle pose immediately every time I stop walking. Not a huge deal but it would be a cool addition.
Possible, but only for the player, not other NPC's (with the way I know) and it's not a 10 minute project. DAR per se doesn't support delays, so the way you'd have to do this is to implement Serana's auto-sandbox AI script in an esp plugin that monitors the player and records if the player has settled. Setting the amount of delay you want here is possible. Then this script will have to output this condition to a Global, which you can then check on, using DAR with ValueEqualTo(GlobalVariable value1, GlobalVariable value2). In theory, this should cause the desired amount of delay on the player's idle animation. I might, or might not experiment with something like this. As I said, it's not just 10 minutes to write this But it certainly sounds cool.
Another way would be to include the vanilla pose delay into the animations themselves, but since I'm not animator myself, I don't know how to do that.
I don't have SSE, so I don't know. DAR for SSE seems to have the same documentation, so I think that part should be fine. Also, SSE seems to use the same hkx format for animations... so I'd say yes, you can use it, but don't take my word for it. Although it shouldn't break anything to just try and see. If it does work, please let us know
So i tested it and it seems to work, but i think i have a conflict with some of the animations i use, so not this mods fault. My character gets in a kind of T pose, but the arms are a little lower. Here the mods i use that could have a conflict with your mod: CGO Jump Behaivior 360 Movement Immersive animations Duel Wield improved Animations EVG Conditions Relaxed Sneak Animations
Hmm, I fail to see how these mods could conflict with this. Mods that are simply animation replacers shouldn't cause issues with a DAR mod, I use(d) CGO too, anything that doesn't concern idle animations is compatible, and EVG Conditions is also compatible because this mod has lower priorities. So if you're witnessing T-posing while idling with this mod installed, but otherwise not, I'm afraid that can only mean that the hkx files themselves are not interchangeable between LE and SSE, and they indeed need some sort of conversion before they can be used with SSE. Though again, I'm not an SSE user, so this is just my speculation.
Using all those mods, do you use Nemesis? Especially with the combination of Jump Behaviour, CGO and 360 Movement, I'd say Nemeesis becomes mandatory. If you run this file through Cathedral Assets Optimizer and install it, and then run Nemesis, it should run fine. That's what I'm going to do now!
If you don't have Nemesis installed, I think CGO's description page gives a run down on how it works. It patches all the animations so that they can run together and you don't get those T-pose moments.
Thank you for the tip, i'm already using Nemesis but i didn't thought i should use it for this mod too, well now i know better ^^
Edit: I've used Wabbajack to install Lexys LOTD (not sure if you guys know what it is), it already has Nemesis and i know how to use it, but I've no idea what Cathedral Assets Optimizer is :D But i will look into it, thank you guys again!
Catherdral Asset Optimizer is a tool to convert LE mods to SE mods. Texture only mods can be used without any issue. Other than that, if a mod contains any mesh/animation/bsa/plugin, you've to run it. Check out a many videos about how to use it. It's super simple. And you need to run FNIS/Nemesis everytime you add or remove any mod added new animation to/from you mod list.
Thanks, works flawlessly :) I just got rid of the vanilla idle replacer, as I prefer the one I'm curently using. It's always a pleasure to see new DAR mods popping in :)
I am using the DAR version of the mod and I absolutely love it !!!
I only have one small issue: male actors use all the idles when wearing a shield, which generates some unrealistic situations where the shield is cutting through their face/torso !!!
Is there any way I can configure the mod to avoid using certain stances if the actor is holding a shield ???
The general way to avoid issues like that is to use a shield worn on back mod, like All Geared Up Derivative - AllGUD.
Alternatively, it should be possible to add such a filter for DAR, using: NOT IsEquippedLeftHasKeyword(Keyword keyword) I'm not sure what the Keyword for shields are. If the editor ID goes here, I think it's "ArmorShield", if the formID, then it should be "0x000965b2". I'd try this first: In the _conditions.txt files, to the end of the last line, add an " AND" (no quotation marks), and in the next line, try adding: NOT IsEquippedLeftHasKeyword("Skyrim.esm" | 0x000965b2)
Thanks for the list of animations. I also put a few conditions in (so far) the first one is to stop mannequins from taking these poses (I've seen this for whatever reason) and the second is to not do the animation if you have a shield equipped. Pretty sure this works..
NOT IsRace("Skyrim.esm" | 0x0010760A) AND NOT IsEquippedLeftType(11) AND Random(0.2)
EDIT: Also you could use this mod to auto-unequip your shield - I mainly use if for the headgear function but the shield feature works OK too. Haven't tried it with this mod but I'd think the unequip would fire before you went into idle.
Thanks for the info I too wanted a non-mannequin version as well, because the mannequins in my game are... rebellious, to put it mildly. But I couldn't figure out what the condition for them would be, I tried to find an Actor Base in the game console help, but that didn't really work out. I never thought to use IsRace(). I'll upload a non-mannequin version soon
I will also test this shield criteria. If it doesn't interfere with shields on back mod (interfere as in that equipped shields now are displayed on the back, but the animation still wouldn't play even though it could and should), then I'll add that condition too.
Hi Whitewolf Great idea. Only thing is that the conditions should be like this for equal probability of the animations (including vanilla) appearing ingame: 67 -> random(0.5) 68 -> random(0.3333) 69 -> random(0.25) 70 -> random(0.2)
Right but doesn't having a too low probability make it fail too often? For example if you have 100 idle animations like myself. About making the default idle not showing up you can just remove the randomness all together for an animation instead of setting it to 1.
Not sure what you mean. If you want equal probabilities for all animations ingame you have to set the random chances the way I did it. Because right now the actual chances of the idles are :
For such a small amount of animations it is not a huge problem. For 100 animations it would be a problem. So in your case you should set the random chances to 1/100 for the first one (which is in the folder with highest number), 1/99 for the next etc. (Not sure having 100 idle animations is a good idea performance wise. You may want to research that)
And you are right about not setting a random chance at all for the final (non-vanilla) animation is the same as setting it to random(1)
What I mean is if one animation has a .001 chance to show wouldn't almost not show at all? Even if it's checked more often it will still skip it in favor of a higher chance one. In my case I have over 90 idles all set to 0.2 chance and I still see the default idle play the most often. I played a bunch and didn't notice any t-posing or stutter so I don't think the performance is affected too much (though replacing npc's idles seem too be pretty hit or miss) I have it capped at 30 fps though. The only other DAR mod I have is the Backflip one and another I made for random Pretty sitting animations so not that many.
Ok now I understand your question. In DAR the folder with the highest number has priority. If the condition check for the animation in that folder is successful that animation will 'win'. If the condition check fails it will fall back to the next folder (with a lower number) and finally if all checks fail it will fall back to the vanilla animation. Let's say you have one carrot, a dice and 6 persons. The person who rolls a 1 gets the carrot. Obviously the first person in line has an advantage because he gets to roll first. To make it equal the next person should roll with a 5-sided dice. He will then have a chance of 1/5 (the chance he wins the roll) * 5/6 (the chance person 1 lost) = 5/30 = 1/6 .
Hope that makes it clear
Edit: considering performance: I think all animations are loaded in memory at game start, but you should check the DAR forum on that
I understand what you are saying but in practice I wouldn't want to be either the guy that rolls first or the guy that would roll last cause in reality the middle guy with a decent chance to roll a d3 most likely will get the carrot.
In DAR case I'm not sure it works like in your carrot example cause as I've said, in a setup with a 90+ animations ALL with 20% chance to win I still see the default animation more than any other animation.
It's actually not specific to DAR, math itself works like this with conditionally propagating probabilities, and it's indeed quite easy to overlook, as I just did. So cim, you are absolutely right. I knew I should have paid more attention at the probability theory class I stand corrected, thanks, 1.1 is uploaded with the fixed values
Just cause you remembered 5th grade math doesn't mean DAR works like the russian roulette and cim is "absolutely right". I don't see anything in the documentation saying that's how it definitely works and from my experience it doesn't. But it's your mod.
DAR loads the animation with the highest priority folder number that matches all conditions. That is why in the OP, the highest number, 70, is associated with 0.2 probability. This is what we want: for all files to have an equal 20% chance, but DAR doesn't just pick 1 out of 5, instead it uses "progressive picking": it looks at the highest one and tests it, if it's true, then that is picked, if not, then it goes to the next one. (The series of evaluation in the actual implementation might differ, but this what it means that the highest priority folder, with all its conditions matched true, will be applied). So the first and highest number (70) has a 0.2 chance of being picked. However if this is false (with 0.8 probability), then the next is tried, but by reaching this 69, we are assuming that 70 already failed! This is a conditional probability situation, meaning that for the 69 to be tried for its 20%, you need to apply the 80% chance that 70 failed, which gives 0.2 / 0.8 = 0.25, which is the number in the OP. Apply this method iteratively and you get all the numbers as the stages of going to lower and lower priorities cascade.
We don't know if DAR does the evaluation like that (or at least I don't know), the implementation could be anything, but that is also not the point of my argument because it doesn't matter. What we do know and matters, because it's in DAR's custom conditions forum documentation, is that the folder with the highest priority, with all of its conditions matched true, wins. This is the known fact. And this translates into the exact model we described, because the hardwired condition that a higher priority folder wins even if another but lower folder is also matched true, introduces conditional probability. Here's how in details: Let's say both folders of 69 and 70 rolled well, therefore both are eligible for winning. It's a hardwired rule, that in this case, 70 will always win. This imposes, that for 69 to have even the faintest chance of winning, 70 must have already lost. This is an external condition. Note again, the order of the actual evaluation won't matter. If I evaluate 70 first and wins - because of the hardwired priority, 70 already won. If I evaluate 69 first and wins - ok, but secondly we still have to evaluate 70, and if that won too -> 70 wins again. Same result. If I go even deeper, say to folder 66, for this to win, it means all folders with a higher priority, up to 70 in this case, must have all failed their checks. Again, the order of evaluation doesn't matter. In the end, all were evaluated at some point and then compared - but if 66 was matched true but didn't win, it means that its condition, the low priority ruled it out, because a higher priority folder checked true too. This is what conditional probability means, that there is a huge IF, and assumption, that must be met before we could hope to achieve something, and try for the probability here. For the correct model, this must be built-in, that is why the probabilities go up as we go down in priority. An even simpler example that I can sketch up here, an example of just 3 folders for DAR, label them 1,2,3 for simplicity, with 3 of highest priority: We want 33% for each. The possibilities are: - At the highest level (3), the only condition is that it meets its own rng, which should therefore be set at 33%. - The second level will only appear, if 3 doesn't overwrite it. This is the external condition. So you could denote the winning of 2 like [(2's rng) && !(3's rng)] or something like that. And this, the whole bracket, is what we want to set at 33%. Therefore it's clear, that (2's rng) is not 33%, but instead 50% in this example (0.33 / (1 - 0.33)). - If we get to the lowest folder of 1, it means both 3 and 2 failed, but something must happen here, so the probability here is 100%. Yes, the probability for folder one is 100%, and this is actually the external vanillatweaked version replacer in my mod. Why 100%? Because it can only happen if both the others failed, because of DAR's probability system. So for the desired result, that 1 happens 33% of the time (outer bracket, [ ] ), its inner rng inside its bracket of [(1's rng) && !(2) && !(3)] must be 100%. And that is how the hardwired concept of DAR, that a higher priority folder will win over anything else that has lower priority, translates into this model.
P.S.: Sorry if my post feels overdetailed, by no means am I trying to offensively lecture you. It's very hard to judge over the internet, how much detail is necessary to convey a message well, without any seen immediate reaction from the other person. I'm really just trying to explain.
I understand what you mean as early as cim's first reply but I still have doubts it works like that. Mostly cause I don't know how often and when DAR checks for suitable animations. Also if it was like you say, with many animations, the higher priority animations would be used least because they would fail the check too often. Look at my previous posts to cim.
I see. I don't know that either, I can only guess. Since I do know that whenever you start to run and and then stop to idle, then the animations are re-evaluated, and since randomizers work well, not only for idles but for all kinds of animations, I think it's a safe guess that DAR checks its animations every time the game is trying to access them.
For the second part - no, I'm sorry, but that is where you are wrong. In the carrot example, as cim presented, each guy has the same overall probability to win with his rules. IF we get to the middle guy, then yes, he has a decent (and better than the first guy!) intrinsic chance to win. If. That IF introduces an additional external probability however, that decreases his overall probability to be equal to all of the other guys, and solves your paradox. For the many animations example: The overall aim is to have all animations appear with the same overall probablility. But to achieve this, their intrinsic RNG must respect the external priority conditions. I really don't know how else to say this. You are right when you say that the higher priority animations will indeed fail their intrinsic rng checks more often, that is true, but mind the emphasis on the "intrinsic", and also lower priority animations will pass them more often, true, but this is exactly what you want. Because lower priority animations not only have to pass their intrinsic rng, but also the additional external condition, that the higher priorities had failed. And adding this effect ensures, that the overall probabilities of all animations stay equal.
In DAR case I'm not sure it works like in your carrot example cause as I've said, in a setup with a 90+ animations ALL with 20% chance to win I still see the default animation more than any other animation.
This is a totally expected outcome if you use equal random chances for all animations (as I showed you in my third comment). Btw I tested it with another DAR mod and I suggest you test it yourself too since it seems hard to convince you otherwise ;)
There are already countless female idle replacers on nexus (personally I recommend Lifelike Idle Animations: https://www.nexusmods.com/skyrim/mods/59048 ), and this was originally meant as a male only replacer. But I guess the animations are "unisex" enough, so it probably won't hurt to add a female variant as an optional.
Ah, OK, by "female version" I only though about the animations themselves, not a specific randomizer variant. Indeed, there are not so many of those. I recommended the one I did, because its animation is very long and contains several poses, coming after one another. When multiple NPCs stand next to each other, because of the delayed starts of the idling, their poses appear quite random. But if you have or know about existing female animations that are specifically stated as a free resource, then sure, it's no problem to create their own true randomized mod.
DAR from Felisky384, is one of the Greatest thing for Skyrim , it enables customization and Immersion in a unique way, Thank you for this application, , it was really necessary
52 comments
For those who are interested
To be honest I haven't thought of this combination, so thanks for bringing it to attention
This will cover males and females but not mannequins.
If you want to exclude the player character, look up the conditions in the player variant, and add the same line to the existing conditions in the above setup, and put a NOT before it.
EDIT: I'm going to test a combined version of your mod, along with those sit idles.
EDIT2: It works, but the random sitting idles from Pretty Sit work only on the player, while other NPCs use the default animation and idle for eating and drinking. I think I'll try Simple Sitting Animation.
Also, I can't seem to find Simple Sitting Animation on the site?
Here's Simple Sit Animation: https://www.nexusmods.com/skyrim/mods/42656
Then I choose from much of dualsun's animation mods and threw them in.
Your mod will still work even under Nemesis, all's needed is to rename some unique idle animations to their Skyrim equivalent file names.
I would like to know how you did it.
DAR per se doesn't support delays, so the way you'd have to do this is to implement Serana's auto-sandbox AI script in an esp plugin that monitors the player and records if the player has settled. Setting the amount of delay you want here is possible. Then this script will have to output this condition to a Global, which you can then check on, using DAR with ValueEqualTo(GlobalVariable value1, GlobalVariable value2).
In theory, this should cause the desired amount of delay on the player's idle animation.
I might, or might not experiment with something like this. As I said, it's not just 10 minutes to write this
Another way would be to include the vanilla pose delay into the animations themselves, but since I'm not animator myself, I don't know how to do that.
Can i use it for SSE? Or is a port mandatory?
Although it shouldn't break anything to just try and see. If it does work, please let us know
My character gets in a kind of T pose, but the arms are a little lower.
Here the mods i use that could have a conflict with your mod:
CGO
Jump Behaivior
360 Movement
Immersive animations
Duel Wield improved Animations
EVG Conditions
Relaxed Sneak Animations
So if you're witnessing T-posing while idling with this mod installed, but otherwise not, I'm afraid that can only mean that the hkx files themselves are not interchangeable between LE and SSE, and they indeed need some sort of conversion before they can be used with SSE.
Though again, I'm not an SSE user, so this is just my speculation.
If you don't have Nemesis installed, I think CGO's description page gives a run down on how it works. It patches all the animations so that they can run together and you don't get those T-pose moments.
Edit:
I've used Wabbajack to install Lexys LOTD (not sure if you guys know what it is), it already has Nemesis and i know how to use it, but I've no idea what Cathedral Assets Optimizer is :D
But i will look into it, thank you guys again!
I just got rid of the vanilla idle replacer, as I prefer the one I'm curently using.
It's always a pleasure to see new DAR mods popping in :)
I am using the DAR version of the mod and I absolutely love it !!!
I only have one small issue: male actors use all the idles when wearing a shield, which generates some unrealistic situations where the shield is cutting through their face/torso !!!
Is there any way I can configure the mod to avoid using certain stances if the actor is holding a shield ???
Many thanks for any helpful replies,
Bendiwolf
Alternatively, it should be possible to add such a filter for DAR, using:
NOT IsEquippedLeftHasKeyword(Keyword keyword)
I'm not sure what the Keyword for shields are. If the editor ID goes here, I think it's "ArmorShield", if the formID, then it should be "0x000965b2".
I'd try this first:
In the _conditions.txt files, to the end of the last line, add an " AND" (no quotation marks), and in the next line, try adding:
NOT IsEquippedLeftHasKeyword("Skyrim.esm" | 0x000965b2)
But I could be wrong.
Could you tell me which animation goes with which folder in the mod (67,68,69,70)?
I tried to find a guide to which is which and could not.
Best, Bendiwolf :)
67 - Relaxed
68 - Examine (folded arms, lean in)
69 - Study
70 - Crossed Arms
I'll also include this into a readme file, in case someone else wants to use it as well.
Let me know if it works
NOT IsRace("Skyrim.esm" | 0x0010760A) AND
NOT IsEquippedLeftType(11) AND
Random(0.2)
EDIT: Also you could use this mod to auto-unequip your shield - I mainly use if for the headgear function but the shield feature works OK too. Haven't tried it with this mod but I'd think the unequip would fire before you went into idle.
Auto Equip Headgear
I actually kinda like the mannequins posing for me, but your help with the shield effect is invaluable !!!
I'll upload a non-mannequin version soon
I will also test this shield criteria. If it doesn't interfere with shields on back mod (interfere as in that equipped shields now are displayed on the back, but the animation still wouldn't play even though it could and should), then I'll add that condition too.
Great idea. Only thing is that the conditions should be like this for equal probability of the animations (including vanilla) appearing ingame:
67 -> random(0.5)
68 -> random(0.3333)
69 -> random(0.25)
70 -> random(0.2)
Seen the same error in other DAR mods
About making the default idle not showing up you can just remove the randomness all together for an animation instead of setting it to 1.
Because right now the actual chances of the idles are :
vanilla: ~41%
folder 67: ~10%
folder 68: ~13%
folder 69: 16%
folder 70: 20%
For such a small amount of animations it is not a huge problem. For 100 animations it would be a problem. So in your case you should set the random chances to 1/100 for the first one (which is in the folder with highest number), 1/99 for the next etc.
(Not sure having 100 idle animations is a good idea performance wise. You may want to research that)
And you are right about not setting a random chance at all for the final (non-vanilla) animation is the same as setting it to random(1)
I played a bunch and didn't notice any t-posing or stutter so I don't think the performance is affected too much (though replacing npc's idles seem too be pretty hit or miss) I have it capped at 30 fps though. The only other DAR mod I have is the Backflip one and another I made for random Pretty sitting animations so not that many.
Let's say you have one carrot, a dice and 6 persons. The person who rolls a 1 gets the carrot. Obviously the first person in line has an advantage because he gets to roll first. To make it equal the next person should roll with a 5-sided dice. He will then have a chance of 1/5 (the chance he wins the roll) * 5/6 (the chance person 1 lost) = 5/30 = 1/6 .
Hope that makes it clear
Edit: considering performance: I think all animations are loaded in memory at game start, but you should check the DAR forum on that
In DAR case I'm not sure it works like in your carrot example cause as I've said, in a setup with a 90+ animations ALL with 20% chance to win I still see the default animation more than any other animation.
So cim, you are absolutely right. I knew I should have paid more attention at the probability theory class
That is why in the OP, the highest number, 70, is associated with 0.2 probability. This is what we want: for all files to have an equal 20% chance, but DAR doesn't just pick 1 out of 5, instead it uses "progressive picking": it looks at the highest one and tests it, if it's true, then that is picked, if not, then it goes to the next one. (The series of evaluation in the actual implementation might differ, but this what it means that the highest priority folder, with all its conditions matched true, will be applied).
So the first and highest number (70) has a 0.2 chance of being picked. However if this is false (with 0.8 probability), then the next is tried, but by reaching this 69, we are assuming that 70 already failed! This is a conditional probability situation, meaning that for the 69 to be tried for its 20%, you need to apply the 80% chance that 70 failed, which gives 0.2 / 0.8 = 0.25, which is the number in the OP.
Apply this method iteratively and you get all the numbers as the stages of going to lower and lower priorities cascade.
What we do know and matters, because it's in DAR's custom conditions forum documentation, is that the folder with the highest priority, with all of its conditions matched true, wins.
This is the known fact. And this translates into the exact model we described, because the hardwired condition that a higher priority folder wins even if another but lower folder is also matched true, introduces conditional probability.
Here's how in details:
Let's say both folders of 69 and 70 rolled well, therefore both are eligible for winning. It's a hardwired rule, that in this case, 70 will always win. This imposes, that for 69 to have even the faintest chance of winning, 70 must have already lost. This is an external condition.
Note again, the order of the actual evaluation won't matter. If I evaluate 70 first and wins - because of the hardwired priority, 70 already won. If I evaluate 69 first and wins - ok, but secondly we still have to evaluate 70, and if that won too -> 70 wins again. Same result.
If I go even deeper, say to folder 66, for this to win, it means all folders with a higher priority, up to 70 in this case, must have all failed their checks. Again, the order of evaluation doesn't matter. In the end, all were evaluated at some point and then compared - but if 66 was matched true but didn't win, it means that its condition, the low priority ruled it out, because a higher priority folder checked true too. This is what conditional probability means, that there is a huge IF, and assumption, that must be met before we could hope to achieve something, and try for the probability here.
For the correct model, this must be built-in, that is why the probabilities go up as we go down in priority.
An even simpler example that I can sketch up here, an example of just 3 folders for DAR, label them 1,2,3 for simplicity, with 3 of highest priority: We want 33% for each. The possibilities are:
- At the highest level (3), the only condition is that it meets its own rng, which should therefore be set at 33%.
- The second level will only appear, if 3 doesn't overwrite it. This is the external condition. So you could denote the winning of 2 like [(2's rng) && !(3's rng)] or something like that. And this, the whole bracket, is what we want to set at 33%. Therefore it's clear, that (2's rng) is not 33%, but instead 50% in this example (0.33 / (1 - 0.33)).
- If we get to the lowest folder of 1, it means both 3 and 2 failed, but something must happen here, so the probability here is 100%. Yes, the probability for folder one is 100%, and this is actually the external vanillatweaked version replacer in my mod. Why 100%? Because it can only happen if both the others failed, because of DAR's probability system. So for the desired result, that 1 happens 33% of the time (outer bracket, [ ] ), its inner rng inside its bracket of [(1's rng) && !(2) && !(3)] must be 100%.
And that is how the hardwired concept of DAR, that a higher priority folder will win over anything else that has lower priority, translates into this model.
P.S.: Sorry if my post feels overdetailed, by no means am I trying to offensively lecture you. It's very hard to judge over the internet, how much detail is necessary to convey a message well, without any seen immediate reaction from the other person. I'm really just trying to explain.
For the second part - no, I'm sorry, but that is where you are wrong. In the carrot example, as cim presented, each guy has the same overall probability to win with his rules. IF we get to the middle guy, then yes, he has a decent (and better than the first guy!) intrinsic chance to win. If. That IF introduces an additional external probability however, that decreases his overall probability to be equal to all of the other guys, and solves your paradox.
For the many animations example: The overall aim is to have all animations appear with the same overall probablility. But to achieve this, their intrinsic RNG must respect the external priority conditions. I really don't know how else to say this.
You are right when you say that the higher priority animations will indeed fail their intrinsic rng checks more often, that is true, but mind the emphasis on the "intrinsic", and also lower priority animations will pass them more often, true, but this is exactly what you want. Because lower priority animations not only have to pass their intrinsic rng, but also the additional external condition, that the higher priorities had failed. And adding this effect ensures, that the overall probabilities of all animations stay equal.
r000 said:
This is a totally expected outcome if you use equal random chances for all animations (as I showed you in my third comment).
Btw I tested it with another DAR mod and I suggest you test it yourself too since it seems hard to convince you otherwise ;)
I recommended the one I did, because its animation is very long and contains several poses, coming after one another. When multiple NPCs stand next to each other, because of the delayed starts of the idling, their poses appear quite random.
But if you have or know about existing female animations that are specifically stated as a free resource, then sure, it's no problem to create their own true randomized mod.