FNIS for Modders / FNIS 4.0 [WIP]

[xaz]

Before you get me wrong: This problem affects _every_ animation event with an animation object (that I have tried). It's not specific to this particular one I mentioned. As I wrote, it's an example of a line in the definition which produces irregular results.

 

Also, I tried this using, of course, the released version.

 

Please don't discard this problem because of some detail here or there. I've been running this back and front and investigating issues for hours now, and I'm pretty sure there is a problem. I'm not saying it's on your end, because I just don't know, but I would at least consider it a possibility.

 

Again: downgrading to 4.0 beta 3 solves the problem right away, which to me is suspicious.

 

 

To sum up:

Running an animation object idle once, you get the right animation.

Running an animation object idle again, and you get the wrong animation.

 

This is true for all animations with animation objects using (only) 4.0 release. Not if you use 4.0 beta 3 (or earlier).

 

But the important part .... did you change anything which touches animation objects?

 

 

Edit: Cleared up language to get my point across.

[xaz]

You can reproduce it from the console. And again, even if you don't believe in the console, you see the same behavior in scripts as well, so don't disregard the console in this particular instance. You can also verify that behavior is correct with previous versions of FNIS.

 

Prerequisite: Two animations with animation objects attached to them. I'm going to use ZazApcAo251 and ZazApcAo252, but you can use any two of them.

 

player.playidle ZazApcAo251
player.playidle ZazApcAo252
player.playidle ZazApcAo252

Notice how the correct animation plays only at the last command, and not the second command as one would expect. (Leave the console between each command obviously, otherwise you won't see animations.)

 

Does anyone know of any other mods that use FNIS and have animation objects?

[ZaZ]

I did run the generation tool for modders ( just so that the behavior file would be updated by the latest generate fnis for modders ) , and then the generation tool for users .

the same problem still exits as mentioned above .

 

Xaz the animation its playing is one of our own perhaps everytime the change is made   " zazapc001 " 

 

Cheers 

[xaz]

I did run the generation tool for modders ( just so that the behavior file would be updated by the latest generate fnis for modders ) , and then the generation tool for users .

the same problem still exits as mentioned above .

 

Xaz the animation its playing is one of our own perhaps everytime the change is made   " zazapc001 " 

 

Cheers

Indeed, but there are no idle definitions to play that animation, so it's very weird that it comes up. This is one of the reasons I suspect FNIS and not Zap ....

[fore]

Ok, I found a problem. And have a fix. But before I make an update, I want to do more testing, and it's too late tonight.

 

So you can make this tiny change yourself:

Open GenerateFNISforModders\templates\FNIS_Behavior_TEMPLATE.txt a,d change in line 131 (with the comment "HeadTrackingOn") from '7' to '5'. Like 9 lines below.

 

So the problem was, instead of sending headtracking on at exit (in some, not all cases), it would instead another (custom) animevent. -> different animation.

 

2 things I found and want to point out. FNIS is "better" than vanilla animations used with console playidle.

In vanilla you will generally see:

- 1st playidle goes into the animation, 2nd playidle goes back to default

- AnimObjects are not unequipped most of the time. Later on they will, but seems undetermined. So if you toggle between 2 AO anims, you mostly use 2 AnimObjects

 

In FNIS you se will MOST of the time:

- replace 1st playidle by 2nd one

- replacing the current idle will unequip the AO

 

Only SOMETIMES:

- the AO is not unequipped, and you will have 2 AOs. But only for one idle

- if you play idles 2 times in a row (like  1:idle1  2:idle1  3:idle2  4:idle2), it CAN be that in step 3 it looks like idle2 is started, but it then goes back to idle1 instead. Just like ilde1 from step 2 was saved, and is catching up in step 3

 

But I think that is really caused by the dirty console playidle, and will not further bother you. I have never seen things like that if you implement is with a script, like FNIS Spells.

 

[ZaZ]

Ok, I found a problem. And have a fix. But before I make an update, I want to do more testing, and it's too late tonight.

 

So you can make this tiny change yourself:

Open GenerateFNISforModders\templates\FNIS_Behavior_TEMPLATE.txt a,d change in line 131 (with the comment "HeadTrackingOn") from '7' to '5'. Like 9 lines below.

 

So the problem was, instead of sending headtracking on at exit (in some, not all cases), it would instead another (custom) animevent. -> different animation.

 

2 things I found and want to point out. FNIS is "better" than vanilla animations used with console playidle.

In vanilla you will generally see:

- 1st playidle goes into the animation, 2nd playidle goes back to default

- AnimObjects are not unequipped most of the time. Later on they will, but seems undetermined. So if you toggle between 2 AO anims, you mostly use 2 AnimObjects

 

In FNIS you se will MOST of the time:

- replace 1st playidle by 2nd one

- replacing the current idle will unequip the AO

 

Only SOMETIMES:

- the AO is not unequipped, and you will have 2 AOs. But only for one idle

- if you play idles 2 times in a row (like  1:idle1  2:idle1  3:idle2  4:idle2), it CAN be that in step 3 it looks like idle2 is started, but it then goes back to idle1 instead. Just like ilde1 from step 2 was saved, and is catching up in step 3

 

But I think that is really caused by the dirty console playidle, and will not further bother you. I have never seen things like that if you implement is with a script, like FNIS Spells.

Aight , I just tried this and the transitions are smooth between the two AO animations when using the console , 

Changing "7" to "5" on line 131 fixed this .

Ran the Gen FNIS for Modders and then the Fnis for Users ,

And it worked well 

 

Still have to try  a trial run with the prison overhaul , but  this seems stable enough  .

Thanx 

 

Cheers 

[xaz]

Thanks!! With the change to the template files, it seems to work as it should.

 

Two other things that you may want to fix, one being easy... the other one, I have no clue

1. There's an additional archive in my distribution of FNIS 4.0, which probably shouldn't be there (GenerateFNISforModders4.0_Beta4.1.7z)

2. When switching between animations, the animation object briefly disappears (possibly for a single frame), which looks like it's flashing. Is this fixable? (This has been there since at least 3.5)

 

[fore]

Thanks!! With the change to the template files, it seems to work as it should.

 

Two other things that you may want to fix, one being easy... the other one, I have no clue

1. There's an additional archive in my distribution of FNIS 4.0, which probably shouldn't be there (GenerateFNISforModders4.0_Beta4.1.7z)

2. When switching between animations, the animation object briefly disappears (possibly for a single frame), which looks like it's flashing. Is this fixable? (This has been there since at least 3.5)

 

Thanks. Please everyone keep telling me whatever you notice. Even if it seems of lesser importance. So this additional archive is removed next time.

 

You mean switching in SA or FU animations?

This "flashing" is unavoidable. It stems from the fact that there is no AO specific unequip. So if you change the number of AOs, or AOs themselves, within one SA or FU group, then I have to Unequip and Re-Equip between every 2 animations. Because you can freely move around between animations, and you nees the right set of AOs available every time.

 

This problem came up with Estrus for the first time. And that's why I added these "optimized" versions (sao, fuo). There the unequip is avoided wherever possible. With the price that you cannot move around the same way between any 2 animations  (you can, but it might end up with wrong AOs being equipped). 

 

Read the 4.0 Modder's doc for a little more info. 

[D_ManXX2]

 

So you can make this tiny change yourself:

Open GenerateFNISforModders\templates\FNIS_Behavior_TEMPLATE.txt a,d change in line 131 (with the comment "HeadTrackingOn") from '7' to '5'. Like 9 lines below.

 

So if i am reading this right, this is what is currently bugged in fnis why the npc not ragdolling correctly with sexlab ??

[srayesmanll]

 

So you can make this tiny change yourself:

Open GenerateFNISforModders\templates\FNIS_Behavior_TEMPLATE.txt a,d change in line 131 (with the comment "HeadTrackingOn") from '7' to '5'. Like 9 lines below.

 

So if i am reading this right, this is what is currently bugged in fnis why the npc not ragdolling correctly with sexlab ??

 

 

Not exactly.  Take a look at the sexlab thread.  Ashal has put a 1.21 beta that has fixed this issue.

[fore]

Ok, I found a problem. And have a fix. But before I make an update, I want to do more testing, and it's too late tonight.

 

So you can make this tiny change yourself:

Open GenerateFNISforModders\templates\FNIS_Behavior_TEMPLATE.txt a,d change in line 131 (with the comment "HeadTrackingOn") from '7' to '5'. Like 9 lines below.

 

Not necessary any more.

 

I have uploaded FNIS 4.0 Hotfix1 for Modders, which fixes this problem.

[fore]

I just uploaded a new version of FNIS 4_0 for Modders Documentation V1_2

 

It adds a lot of information about the use of furniture animations for

• NPC
• Player
• Player & NPC together

Might save modders some time for debugging. 

[Ashal]

Not sure if this is a bug or if I just misunderstand how the dog/wolf problem is or how the FNIS List.txt files work; but came across what I thought an odd behavior.

 

I had these two files, for dog and wolf:

 

FNIS_SexLabCreature_dog_List.txt

s Dog_Doggystyle_A2_S1 Canine_Doggystyle_A2_S1.hkx
+ Dog_Doggystyle_A2_S2 Canine_Doggystyle_A2_S2.hkx
+ Dog_Doggystyle_A2_S3 Canine_Doggystyle_A2_S3.hkx
+ Dog_Doggystyle_A2_S4 Canine_Doggystyle_A2_S4.hkx

s Dog_Missionary_A2_S1 Canine_Missionary_A2_S1.hkx
+ Dog_Missionary_A2_S2 Canine_Missionary_A2_S2.hkx
+ Dog_Missionary_A2_S3 Canine_Missionary_A2_S3.hkx
+ Dog_Missionary_A2_S4 Canine_Missionary_A2_S4.hkx

FNIS_SexLabCreature_wolf_List.txt

s Wolf_Doggystyle_A2_S1 Canine_Doggystyle_A2_S1.hkx
+ Wolf_Doggystyle_A2_S2 Canine_Doggystyle_A2_S2.hkx
+ Wolf_Doggystyle_A2_S3 Canine_Doggystyle_A2_S3.hkx
+ Wolf_Doggystyle_A2_S4 Canine_Doggystyle_A2_S4.hkx
 
s Wolf_Missionary_A2_S1 Canine_Missionary_A2_S1.hkx
+ Wolf_Missionary_A2_S2 Canine_Missionary_A2_S2.hkx
+ Wolf_Missionary_A2_S3 Canine_Missionary_A2_S3.hkx
+ Wolf_Missionary_A2_S4 Canine_Missionary_A2_S4.hkx

 

There is only the 8 animation files between the two, being used for both dog and wolf, all prefixed with Canine_ and replaced with Dog_ & Wolf_ respectively when defined.

 

Dog animations worked fine and as expected, using "sae Dog_Doggystyle_A2_S2" for example.

 

I know you can't use dog/wolf behaviors at the same time, so I went to test the Wolf animations, and renamed the behavior files by removing XXX from wolf behavior, adding it to dog behavior. Then regenerated the user behavior files.

 

Where the odd part comes in, after switching to the wolf behavior so I could test wolves; they wouldn't respond to "sae Wolf_Doggystyle_A2_S2"  as the wolf and dog FNIS List files would lead me to believe, wolves did however respond to the dogs version of it, "sae Dog_Doggystyle_A2_S2"

 

For now I've just removed dog/wolf specific prefixes and stuck them both with Canine_ prefixes to keep them logically consistent.

[fore]

Ok, I'll test with that. Maybe it can bring some light into this weird dog/wolf mixup.

 

Whenever you think there is any other oddity, just tell. Please.

[fore]

Not sure if this is a bug or if I just misunderstand how the dog/wolf problem is or how the FNIS List.txt files work; but came across what I thought an odd behavior.

 

............................

 

Yahoo! You gave me the right hint. I had totally skipped my mind, that "Behaviors\" is part of the References between the different behavior files (inside the same directory!!). And since wolf is the only one where the name is NOT "Behaviors", it's the link to ... dog. 

 

Amazingly this also fixes the dog CTD issue !!!

 

Thanks so much, Ashal.     

 

I will make an update as soon as possible. Since it also requires a new generator, it might take me till tomorrow. But that's a timeframe I think we can live with.

[fore]

Bad news folks. I can't make the promised FNIS update today.

 

Wolf's own animations (and not the dog ones) are activated now, and doggy won't CTD any more. But I can't trigger any Default AE. So after acyclic or sequenced animations the wolf freezes. This is not the case sensitive issue I had with Beta 4. It's totally wolf specific. And what makes it most weird: SAE(<Default_AE>) works.

 

So it's a behavior issue, but I just can't find it.

 

I'll keep you updated.

[fore]

FNIS 4.0.1 is available now. It fixes the dog/wolf issue.

 

I also added exit codes for integration of Mod Organizer / FNIS.

 

So in the future I can't do but recommend using MO. You will never need to remember any more if you have to run FNIS or not.

[Ashal]

Updated FNIS and creature pack, regenerated the dog/wolf behaviors for my mod, as well as for FNIS Zoo, then ran user tool.

 

Now wolves seem to have no animations whatsoever, they just stand frozen in place. Did I miss something?

[fore]

Updated FNIS and creature pack, regenerated the dog/wolf behaviors for my mod, as well as for FNIS Zoo, then ran user tool.

 

Now wolves seem to have no animations whatsoever, they just stand frozen in place. Did I miss something?

 

Are you sure you use the new Modder's Generator 4.0.1? Because that bug was hidden by the User's generator bug.

 

What do you now have in "behaviors wolf"? All 4 files from the release, plus FNISRoot_Behavior.hkx, wolfbehavior.hkx, FNIS_FNISZoo_wolf_Behavior.hkx, and FNIS_<your_mod>_wolf_Behavior.hkx?

 

If everything seems ok, send me the contents of your "behaviors wolf" and "characters wolf".

[Dayelyte]

*removed by user*

[Ashal]

Here's my full canine folder.

 

canine.zip

 

I was initially running FNIS from a ModOraganizer install path, which hasn't mattered in the past, but just to be sure I also tried installing FNIS + My mod to Data, and rerunning the tools from there, no change.

 

It's definitely running 4.0.1 and Creature Pack 4.0.4, re-installed both to be sure.

 

Also for what it's worth, GIT isn't recognizing any change to my FNIS behavior files at all, as far as it's concerned there's no difference between the ones generated with the 4.0.0 modder tool and the 4.0.1 modder tool, last modification time stamps are updated and that's it; it's not noticing any meaningful changes to commit to my repo after regenerating the wolf/dog behavior files.

[fore]

Ashal, I was looking into this issue the last 2 hours, and have no clue what's happening here.

 

I cleaned out my own wolfs files, re-installed the files from the release,  Zoo 1.2, and SL 1.22. Generated, and everything for the Zoo works in-game. I don't have the complete SL installed, just canine. But when you have a general wolf t-pose, then this set up should be enough to cause this issue. (Or is it just your SL animations that make a T?)

 

Reading one of the last posts in your SL thread there was a "work-around". And this could perfectly be explained if he would still use the User generator 4.0 (which made a reference to the "behaviors" = dog folder). Are you REALLY running GenerateFNISforUsers.exe 4.0.1. A file with 568,832 B, dated 2013-10-15 19:22?

 

Because I just made 2 changes for the release:

- Modder generator: no change in the contents, but the resulting behavior file now goes into the correct folder "behaviors wolf"

- User Generator: the behavior file references in FNISRoot_Behavior now go to "behavior wolf"

 

Or is it possible somehow an old "wolfbehavior_FNIS.hkx" is still in your "behavior wolf"? I'm speculating, but these things wouls all explain what you describe, but I can't reproduce.

 

Can you send me your "behaviors wolf" contents?  Ok, must have missed it.

[Ashal]

Are you REALLY running GenerateFNISforUsers.exe 4.0.1. A file with 568,832 B, dated 2013-10-15 19:22?

Here is the versions and details being run:

 

 

The files get sent to the appropriate behaviors wolf/ folder, and I cleaned out all copies of FNIS behaviors in Skyrim/Data, ModOrganizer/Overwrite and SexLab before replacing the 4.0.0 install completely with 4.0.1, with creature pack 4.0.4 merged on top of it, both files were downloaded off nexus just a couple hours ago before I started testing again just to be sure.

 

FNISZoo 1.2 is the only other animation related mod I have installed besides my own mod, and I tried with and without it.

 

 

It's all wolves animations, they are T Posing. Here is screenshot of a newly spawned wolf, frozen in place.

 

[fore]

You must have used the 4.0 User Generator. It's strange that other people claiming to use 4.0.1 have the same effect. But all symptoms are clear.

 

Your FNISRoot_Behavior.hkx has the link to Behaviors\FNIS_SexLabCreature_wolf_Behavior.hkx.

 

So I downloaded FNIS Behaviors 4.0.1 from Nexus, overwriting my own User Generator. Then I generated, with only SL installed for canine. And my Root behavior says 

behaviors wolf\FNIS_SexLabCreature_wolf_Behavior.hkx (lowercase "b", which is another indicator that I generated with 4.0.1, and you with 4.0)

 

Do you have an explanation for that?

 

Edit:

WTF is going on here??????????? Right now I'm out of any clue.

[Ashal]

You must have used the 4.0 User Generator. It's strange that other people claiming to use 4.0.1 have the same effect. But all symptoms are clear.

 

Your FNISRoot_Behavior.hkx has the link to Behaviors\FNIS_SexLabCreature_wolf_Behavior.hkx.

 

So I downloaded FNIS Behaviors 4.0.1 from Nexus, overwriting my own User Generator. Then I generated, with only SL installed for canine. And my Root behavior says 

behaviors wolf\FNIS_SexLabCreature_wolf_Behavior.hkx (lowercase "b", which is another indicator that I generated with 4.0.1, and you with 4.0)

 

Do you have an explanation for that?

Look at the above screenshots, I am definitely using the 4.0.1 generators.