Jump to content

FNIS for Modders / FNIS 4.0 [WIP]


fore

Recommended Posts

Using SAE has another great advantage: as Fore mentioned, events to be triggered don't need to be set in the CK, they will be "directly" interpreted by the character graph. So, you dont need any mod dependency to play any animation with SAE, just as long as the behaviour file is loaded and knows the event that its being called. Furthermore, these events are inherited by all other "characters" attached to the Actor. Thats how tails (and the genitals in SOS) work. Even if a mod that wants to use SOS anims, for example, all you need to do is call the event that you know to exist (SOSSlowErect, SOSFastErect, etc), no need to set any master, or do any special function for the anims to be able to be called. This also offers the advantage (for body parts) to use event names already existing in the "main" character. If I were to add an animation event with the same event that plays the applaud anim on the tail behaviour, and use a specific animation for that, that animation would be played aswell whenever the actor started applauding (even though the event is being sent to the Actor and not directly to the tail).

Link to comment

 

With SAE is it just properties you don't have you set? Or are you able skip setting the idle animation in creation all together? Leaving just needing FNIS generation and knowing the event name?

 

If you use SAE, then there is no need to define idles in CK at all. Which makes it a little more error prone, since you can misspell the AE name. But that's easy to figure.

 

Well, as far as I know you must set events in CK because FNIS generation is just linking hkx animation files to idle names. Then in CK you define animation events from idles generated by FNIS. but im sure fore would explain it better.

 

Not quite. FNIS is linking anim files to AnimEvents. The idle objects need to be defined only when you initiate idles through CK (idle markers, packages, quest idles). Or if you prefer playidle over SAE.  :shy:

 

Is there any advantage to use playidle over SAE? Can SAE handle sequenced animations comprised of 4+ idles?  

 

Also, when you say SAE doesn't need defined properties,...you'll still need an anim script per animation sequence I imagine, otherwise no quest scripts would ever access the idles, unless you list them.

 

Now if you didn't need to add animations to a resource script,...and just had to make the animation script (minus listing properties), I'd figure SAE would be way less hassle.

 

I don't see any advantage for using playidle over SAE. Not for "basic" idles, not for SA.

I have no idea if we can make use if the idle conditions when called from a script. That would be the only advantage I can imagine.

 

Now I don't understand your statement about "an animation script per animation sequence" and "quest scripts". You can call SAE from whatever script you like. Provided you have the id of the actor. And then you can even say something like Debug.SendAnimationEvent(akTarget, "FNISSPc" + n)

 

As I said. I just canged FNIS Spells from playidle to SAA, removed proerties and idle definitions, and reduced the (small) .esp size by 40%.

 

 

Lol, sorry about that.  I dont know enough CK terminology to express my question clearly. So I'll draw on some pictures XD.

 

Ok this is where you define new idles from a newly generated mod behavior:

 

post-2323-0-55576300-1368941944_thumb.png

 

One of my questions is "Is this no longer unnecessary using SAE,..as long as they are generated,...do you not have to define them?

 

Heres what I meant by "an animation script per animation Sequence" and "quest scripts"

 

post-2323-0-13502800-1368941931_thumb.png

 

I assumed you still have to do this part in order to assign any use to the new animations (via quest scripts)

 

These are SexLab anim script,..identical to every other sequenced animation script I've seen in SexiS, or any other anim script mod.

 

Thanks for all the advice btw Fore, and everyone else here.

Link to comment

 

 

With SAE is it just properties you don't have you set? Or are you able skip setting the idle animation in creation all together? Leaving just needing FNIS generation and knowing the event name?

 

If you use SAE, then there is no need to define idles in CK at all. Which makes it a little more error prone, since you can misspell the AE name. But that's easy to figure.

 

Well, as far as I know you must set events in CK because FNIS generation is just linking hkx animation files to idle names. Then in CK you define animation events from idles generated by FNIS. but im sure fore would explain it better.

 

Not quite. FNIS is linking anim files to AnimEvents. The idle objects need to be defined only when you initiate idles through CK (idle markers, packages, quest idles). Or if you prefer playidle over SAE.  :shy:

 

Is there any advantage to use playidle over SAE? Can SAE handle sequenced animations comprised of 4+ idles?  

 

Also, when you say SAE doesn't need defined properties,...you'll still need an anim script per animation sequence I imagine, otherwise no quest scripts would ever access the idles, unless you list them.

 

Now if you didn't need to add animations to a resource script,...and just had to make the animation script (minus listing properties), I'd figure SAE would be way less hassle.

 

I don't see any advantage for using playidle over SAE. Not for "basic" idles, not for SA.

I have no idea if we can make use if the idle conditions when called from a script. That would be the only advantage I can imagine.

 

Now I don't understand your statement about "an animation script per animation sequence" and "quest scripts". You can call SAE from whatever script you like. Provided you have the id of the actor. And then you can even say something like Debug.SendAnimationEvent(akTarget, "FNISSPc" + n)

 

As I said. I just canged FNIS Spells from playidle to SAA, removed proerties and idle definitions, and reduced the (small) .esp size by 40%.

 

 

Lol, sorry about that.  I dont know enough CK terminology to express my question clearly. So I'll draw on some pictures XD.

 

Ok this is where you define new idles from a newly generated mod behavior:

 

attachicon.gifdefining.png

 

One of my questions is "Is this no longer unnecessary using SAE,..as long as they are generated,...do you not have to define them?

 

Heres what I meant by "an animation script per animation Sequence" and "quest scripts"

 

attachicon.gifquest scripts.png

 

I assumed you still have to do this part in order to assign any use to the new animations (via quest scripts)

 

 

And as I understand it none of that is necessary with SAE. You can dynamically build animation sequences by just slipping a variable into like

SendAnimationEvent(target, "Arrok_Missionary_A" + position + "_S" + stage)

to start the animation based solely on name plus current actor and stage, which is where I see the main appeal.

 

The event exists in the behaviors file, which is already being pulled into Skyrim, the only need to define the idle like that, is for the sake of defining the property, which in turn is just for the sake of using playidle()

 

Though individual animation scripts are still semi-necessary in order to easily define and add separate settings such as the offsets and sounds that are used by a sequence. I have a couple ideas for maybe getting around that, nothing I would consider fully fleshed out or "clean" though, at least not until I dig into trying them out

 

Sorry Fore, kinda hijacking your thread with non FNIS talk.

Link to comment

 

 

 

With SAE is it just properties you don't have you set? Or are you able skip setting the idle animation in creation all together? Leaving just needing FNIS generation and knowing the event name?

 

If you use SAE, then there is no need to define idles in CK at all. Which makes it a little more error prone, since you can misspell the AE name. But that's easy to figure.

 

Well, as far as I know you must set events in CK because FNIS generation is just linking hkx animation files to idle names. Then in CK you define animation events from idles generated by FNIS. but im sure fore would explain it better.

 

Not quite. FNIS is linking anim files to AnimEvents. The idle objects need to be defined only when you initiate idles through CK (idle markers, packages, quest idles). Or if you prefer playidle over SAE.  :shy:

 

Is there any advantage to use playidle over SAE? Can SAE handle sequenced animations comprised of 4+ idles?  

 

Also, when you say SAE doesn't need defined properties,...you'll still need an anim script per animation sequence I imagine, otherwise no quest scripts would ever access the idles, unless you list them.

 

Now if you didn't need to add animations to a resource script,...and just had to make the animation script (minus listing properties), I'd figure SAE would be way less hassle.

 

I don't see any advantage for using playidle over SAE. Not for "basic" idles, not for SA.

I have no idea if we can make use if the idle conditions when called from a script. That would be the only advantage I can imagine.

 

Now I don't understand your statement about "an animation script per animation sequence" and "quest scripts". You can call SAE from whatever script you like. Provided you have the id of the actor. And then you can even say something like Debug.SendAnimationEvent(akTarget, "FNISSPc" + n)

 

As I said. I just canged FNIS Spells from playidle to SAA, removed proerties and idle definitions, and reduced the (small) .esp size by 40%.

 

 

Lol, sorry about that.  I dont know enough CK terminology to express my question clearly. So I'll draw on some pictures XD.

 

Ok this is where you define new idles from a newly generated mod behavior:

 

attachicon.gifdefining.png

 

One of my questions is "Is this no longer unnecessary using SAE,..as long as they are generated,...do you not have to define them?

 

Heres what I meant by "an animation script per animation Sequence" and "quest scripts"

 

attachicon.gifquest scripts.png

 

I assumed you still have to do this part in order to assign any use to the new animations (via quest scripts)

 

 

And as I understand it none of that is necessary with SAE. Can dynamically build animation sequences by just slipping a variable into like SendAnimationEvent(target, "Arrok_Missionary_A1_S" + stage) to select the stage based solely on name. The event exists in the behaviors file, which is good enough for Skyrim, the only need to define the idle, is for the sake of defining the property, which in turn is just for the sake of using playidle()

 

Though individual animation scripts are still semi-necessary in order to easily define and add separate settings such as the offsets and sounds that are used by a sequence. I have a couple ideas for maybe getting around that, nothing I would consider fully fleshed out or "clean" though, at least not until I dig into trying them out

 

 

Well then this is gonna save a ton of time by discarding all the tedious nonsense.  Kinda makes me wonder why playidle was used by modders or Bethesda. Seems like a redundant command.

 

I have been keeping new animations consistent in offsets. Also, I've gone back one by one and slowly converted most of my older animations to the generic actors separated by 100.

 

I know you can also add sounds to the animation hkx packfile. Can also add mobility to the idles,..but that kind of stuff is a little beyond me.

Link to comment

Yep, thats it Ashal. Setting them up in the CK is pointless, as far as my observations go. All its needed like you said, its the havok assets to be loaded. These assets can even be dynamically loaded if you make use of the BehaviorGraphExtraData node. I havent tested it, but in theory, its possible to load a different project/character file with its own animations and behaviours, although I don't know what would happen if you had the same animation event doing different animations, but I suspect either only 1 animation would play or maybe you would get a multiply effect (or additive animation if you will). Or maybe the computer would just explode like a doomsday device! who knows! :D

 

Arrok, PlayIdles are not totally useless. You would still need them if you wanted to use them within animation packages so NPCs can use it on their own. Its a bit similar to TextureSets. Why would you need to use it if the Textures can be used directly by setting them in the Nif? Simply put, to allow customization without the need to use scripts. The command itself, is probably because it lets you easily use animations without the need to dig through XML files to see what event names you have, all you need is check what Idles (form) there are set in the CK.

Link to comment

Just a short update on FNIS 4.0, since my announcement was almost 2 weeks ago:

 

I have everything ready to make a first "4.0 alpha" release for furniture animation testing. However, when adding AnimObjects I ran into one of those problems which makes me curse the day I started with behaviors. As soon as the the AO is created, it will be pulled from the NPC. Something I have never experienced with basic AO animations. And I have no idea what could cause it.

 

So I will try a few more days to figure that out. If I can't find it, I will make the alpha at the end of the week.  :-/

Link to comment

Hey fore. Do you mean AnimObjects when used with furniture simultaneously?

 

Some more questions/ideas for future versions:

 

- do you think you could add this movement modification into your generator in form of "simple" patch as you did for Arm Fix etc?

"#2208" "hkbClipGenerator"
        "name" JumpFastBack
        "animationName" Animations\MT_JumpFast.hkx   ;<- MT_JumpFastBack.hkx 
        "triggers"  #2209

So everyone could put his own custom jump anim without much hassle.

 

Another question about 4.1 and later. Would it be possible to generate an exact copy of whole 'Bleedout' block as some kind of custom movement state? Actually it is movement state! without the need of offset blending. Exactly the movement type I was thinking of!

 

 

Btw could you put back that AO "sticky" parameter in 4.0 as we discussed earlier?  :rolleyes:  Just in case! I have feelings that it may be needed later, even with unequip AO event blanked... Or maybe you have some idea how I could remove already loaded AO that has said event set to None?

Link to comment

Hey fore. Do you mean AnimObjects when used with furniture simultaneously?

 

Some more questions/ideas for future versions:

 

- do you think you could add this movement modification into your generator in form of "simple" patch as you did for Arm Fix etc?

"#2208" "hkbClipGenerator"
        "name" JumpFastBack
        "animationName" Animations\MT_JumpFast.hkx   ;<- MT_JumpFastBack.hkx 
        "triggers"  #2209

So everyone could put his own custom jump anim without much hassle.

 

Another question about 4.1 and later. Would it be possible to generate an exact copy of whole 'Bleedout' block as some kind of custom movement state? Actually it is movement state! without the need of offset blending. Exactly the movement type I was thinking of!

 

 

Btw could you put back that AO "sticky" parameter in 4.0 as we discussed earlier?  :rolleyes:  Just in case! I have feelings that it may be needed later, even with unequip AO event blanked... Or maybe you have some idea how I could remove already loaded AO that has said event set to None?

 

Your MT_JumpFast modification is in 0_master.hkx. But this I don't patch, and will avoid to unless absolutely necessary. However, xp32 has made a change in this area for her Momo jump. and is releasing a mofidied, FNIS compatible 0_master. Maybe you want to talk to her.,

 

I haven't looked yet into bleedout, and right now I don't want to spend the time. So I can't say.

 

The "sticky" parameter I will add (do you have a better name? I don't think sticky is the right word, but I just can't come up with a better one).

 

I have tested a bit more with the event name (because there is a surprising similarity with the furniture AO problem I currently have). First, I think "None" is not a good idea, because that should imply you can never unequip this AO. So I used several existing AnimEvents, FNIS and vanilla. Result:

  • Unequip never worked
  • If I use a "short" animation file, the AO will be created, but immediately "accelerated to infinity". Before the animation ends, the AO is accelerated in and then deleted
  • "long" animation work (but AO won't unequip)

Have you any similar test effects? For me this is interesting, because I have the same effect when testing AO with furniture. I have yet to figure out, where this duration limit is. It could even be, that all vanilla furniture animations with AO are beyond this duration. Looks like one of those issues which take up so much time. :(

Link to comment

I think that most anim events arent sending events at all, thats why they dont work on unequip. I used custom FNIS events as well as few vanilla ones as unequip event for AO and ofc it didnt work either.

I found in this topic - http://forums.bethsoft.com/topic/1423396-onanimationevent/ - that most vanilla AnimEvents arent sending events. So maybe its that. Will test more events later, if it helps.

 

Your MT_JumpFast modification is in 0_master.hkx. But this I don't patch, and will avoid to unless absolutely necessary.

 

I thought you told that furnitures must be modified in master.hkx? There wont be probably any more patches, but its still safer I guess.

 

btw fore, one more question, do you think that animation "blending" between different jump directions can be changed in 0_master.hkx? I mean while pressing UP+right/left movement keys at once. I'm trying to find then eventually edit it myself, but well 13k lines of code is fun!

 

 

However, xp32 has made a change in this area for her Momo jump. and is releasing a mofidied, FNIS compatible 0_master. Maybe you want to talk to her.,

 

 Would rather modify it myself than ask her/him - most unpleasant modder I have ever met, trust me.

Link to comment

Very interesting thread, unfortunately I had missed that. Many good points. But I totally disagree with the 3 event types characterization. There is no "listening event" and no "events that send events". Events are always sent AND received (or raised AND caught). That's their nature. It's only a matter of where and how.

 

SEND

  1. by CK/script/engine: as SAE, playidle, packages, translated key strokes, ...
  2. (behavior) notification: the behavior graph is a tree of state machines. A notification event can be sent when a state machine enters or exits a specific state. "AnimObjectUnequip" is usually sent as exit notification
  3. (behavior) trigger: event sent at a specific time during execution of an animation file. E.g. "00NextClip" is often used to initiate the next animation within a sequence. OnAnimationEvent() will (only) fire when an event registered with RegisterForAnimationEvent() is triggered.

RECEIVE

  1. transition: a specific state defines which event will cause transition from this state to another one of the same state machine. "00NextClip" is often used to do that.
  2. wildcard transition: a state machine defines which event will cause transition FROM ANYWHERE in the graph to one of its states, or to a state in one of its children state machines.
  3. "engine": some of the events are not caught by the behavior files. "AnimObjLoad" and "AnimObjectUnequip" are completely handles by the engine. However these "engine" events all(?) have a property which cannot be passed with SAE() or PlayIdle().

Interesting idea that the AO unequip event is only works for some kind of events. But if so, these are NOT events that can be registered. "AnimObjectUnequip" is notified, and only triggered events are catchable.

 

Furniture animations are part of mt_behavior, not 0_master. 0_master I have only changed to add a link to FNIS_Root_Behavior. xp32 has taken this modified 0_master and added her Momo jump modifications. And I can assure you that xp is a very nice person. We have worked together on several occasions since almost a year. Maybe language?

 

Different jump direction is one of those more complicated areas (13k lines as you said) that I have successfully avoided so far.MAybe this is something you could investigate with HBT6.6? I know that merging of animations with different speed and angles is one of HBT's key features.

 

Link to comment

http://www.loverslab.com/topic/17750-adult-and-sex-mods-that-dont-use-fnis/ - A timely example

 

I don't suppose you could add a check to see if that "mt_behavior" file installed by AP is present and automatically remove it when the FNIS User Generator program is run. Only necessary because people:

 

A. Have a hard time finding that tidbit in the word wall that is the AP original post.

and

B. They forget or try to get away with skipping that instruction anyway.

 

Just a suggestion completely unrelated to the fascinating topic of how to run animations without those tedious declarations in the CK but it would perhaps save a lot of people grief and automatically make the product more reliable.

 

It also might be good to add a warning if you see folders that have animations in them but don't have the TXT file to declare them so you can catch the people who are still getting gacked by that non-feature in Nexus Mod Manager which should only remove readme files.

Link to comment

http://www.loverslab.com/topic/17750-adult-and-sex-mods-that-dont-use-fnis/ - A timely example

 

I don't suppose you could add a check to see if that "mt_behavior" file installed by AP is present and automatically remove it when the FNIS User Generator program is run. 

 

This check already exists. There is a warning for all unknown behavior files (all except those in "KnownCustomBehaviors.txt"). And for mt_behavior there is an additional one: ""behaviors/mt_behavior.hkx" will most likely cause problems. You should REMOVE it."

 

I didn't want to simply remove mt_behavior. FNIS should not prevent other mods from adding behaviors. And there is no objection that someone else makes a good custom mt_behavior. The problem with the AP one were specific (double definition of FNIS animevents, missing updates for new skyrim versions). 

 

This will change however for FNIS 4.0 when a custon mt_behavior will be generated.

 

As a side-note: I had to postpone the 4.0 alpha release since I have a totally weird problem with furnitures and animObjects. And I want to solve that first. 

 

 

http://www.loverslab.com/topic/17750-adult-and-sex-mods-that-dont-use-fnis/ - A timely example

 

It also might be good to add a warning if you see folders that have animations in them but don't have the TXT file to declare them so you can catch the people who are still getting gacked by that non-feature in Nexus Mod Manager which should only remove readme files.

 

I don't think it's a good idea to make this warning. I have seen many logs showing save folders and similar in there animation directory. They would all be warned. And when this NMM bug strikes (which should long be fixed now) then much worse things happen. Like mutilated text output, no languages, no patches.

 

Do you have any reason that users mess around with downloaded mods where your proposed warning could help?

Link to comment

Hi fore, really lame question.

 

Would it be possible to "NULL" animation the same way you plan to do with AOunequip event (sticky param)? So animation wouldnt happen, unequip event wouldnt either, so we could use custom FNIS event as simple AO equipper?

 

 

BTW hows current progress? found anything new about furnitures+AO issue?

Link to comment

OMG. I was chasing a phantom. The furnitures+AO problem was not a behavior problem. It was caused by the way some of Beth's animations are defined. 

 

These animations (like idlepraycrouched_loop.hkx) have the AnimObjectR bone pulled away far from the character. Probably to remove an AnimObject from the character during the animation, without having to unequip. And I was looking all the time for a problem in my behavior ...

 

Hi fore, really lame question.

 

Would it be possible to "NULL" animation the same way you plan to do with AOunequip event (sticky param)? So animation wouldnt happen, unequip event wouldnt either, so we could use custom FNIS event as simple AO equipper?

 

 

BTW hows current progress? found anything new about furnitures+AO issue?

 

I don't think the "NULL" animation is possible (didn't I tell you before, or was it someone else?) Behaviors will cause CTD when you null the generator parameter. And every generator will finally end in a ClipGenerator, the one which calls the animation file. There is one exception I know of: instead of a ClipGenerator there can be a ReferenceGenerator. But then it's expected that the AnimEvent is caught in the referenced behavior file.

 

You have to keep one thing in mind. Behaviors are a state machine. Every action is connected to a state. But the machine is always in exactly one state. To get into a new state implies that you leave the old one. No two states at a time.

Link to comment

I have released FNIS 4.0 ALPHA 1 (see the top post).

 

I hope, some of ou guys will start working on furniture animations now.  :)

 

@zax:

I also released the "sticky" option. It works well in-game. However, in my final test I found out, that unfortunately FNIS animations will almost always unequip the AO. I have no idea why this could happen. There is no unequip event (any more). And I have also tested by removing other triggered events (e.g. idleForceDefaultState). Nothing did help. Maybe it's because of the the way all FNIS animations are integrated (seperate behavior file). But that's only a guess.

Link to comment
@zax:

I also released the "sticky" option. It works well in-game. However, in my final test I found out, that unfortunately FNIS animations will almost always unequip the AO. I have no idea why this could happen. There is no unequip event (any more). And I have also tested by removing other triggered events (e.g. idleForceDefaultState). Nothing did help. Maybe it's because of the the way all FNIS animations are integrated (seperate behavior file). But that's only a guess.

 

Do you mean that next animation will unequip AO from the previous one? Else, how did you test sticky option? Because if I removed unequip event for each AO in CK it didnt get removed by any animation, FNIS or vanilla. So it must be something with unequipevents, or maybe some other event calls unequip event as well. Gonna test it in game, brb.

 

Link to comment

zax, the next Skyrim AO animation will unequip the "sticky" FNIS AO. That's unavoidable. Or you need to find out, which other AnimEvents I can send to make a modified AO (with "None" or any other unequip AE) can be unequipped again. Cause when I tested AOs with different AEs, they could never be unequipped again. As you have experienced.

 

So I final tested only with unchanged AOs.

 

And then of course each FNIS animation (AO or not) with unequip. I just don't know how to avoid that. Maybe one of those cases where everything fails. And then, 9 months later, I come across the solution by a fluke. Like furnitures.  :)

Link to comment

Done some tests and it doesnt seem to be case with just FNIS idles. I observed some strange behavior, maybe its helpful for you, but it doesnt make sense to me at all.

 

-st FNIS idle with AO, directly into vanilla idle (ie BleedoutStart) = AnimObject stays through both of them

-st FNIS idle with AO, directly into non AO FNIS idle  = AnimObject stays

 

-st FNIS idle with AO, cancelled with space = AO stays

-st FNIS idle with AO, cancelled with space + second space (jump) = AO removed

 

-st FNIS idle with AO, cancelled with space, into any other FNIS idle = AO removed

-st FNIS idle with AO, cancelled with space, into vanilla idle = AO removed

 

DrawWeapon and Jump, both seems to be sending AnimObjectUnequip event

 

Link to comment

I have a little problem with animation events, may be you can solve it :

 

I designed a sequence of anims

 

MyAnimStart

MyAnimLoop

MyAnimStop

 

and I want  to control the number of loops through a script.

 

The idea is to use RegisterAnimEvent/Onanimevent to count the loops.

 

I tried the MyAnimLoop event but it fires only once when the anim starts.

IdleStop will not fire for each loop but only when the anim stops.

 

Is there a way to add a custom event somewhere ( through annotation in 3DS ) or is there a default event that will fire for each loop ?

 

FNIS adds the MyAnimStop_Done event. Is it possible to add some event for cyclic anims ?

Link to comment

"MyAnimEvent" is not an official SexLab event in any mod that I am aware of. From the name I would assume you're confusing an example hook event for an actual event.

 

From your description I would suggest hooking onto StageStart and AnimationChange, both of which are events sexlab sends when a new stage or new animation set respectively is played.

 

If you are unfamiliar with it http://git.loverslab.com/sexlab/wikis/guide-hooks should give some background information, provided you are familiar with Papyrus or SexLab as a, whoe.

Link to comment

I'm not using SexLab.

May be I was not clear enough.

 

I created some anims with 3DS, and added them using FNIS as a sequence

s -a  MyanimStart

+ MyanimLoop

+ -a MyanimStop

 

( I tested with

s -a  MyanimStart

+ -a MyanimLoop

+ -a MyanimStop

and the 3 anims play in sequence so I know my HKX files are correct )

 

 

When I PlayIdle this sequence after registering for the events I receive :

MyanimStart

IdleStop

MyAnimLoop

and the loop plays indefinitely

 

I want an event that would fire each time the loop is played

so that I can decrement a counter and send the MyanimStop event to end the loop.

But MyanimLoop is played only once.

Link to comment

I'm not using SexLab.

May be I was not clear enough.

 

I created some anims with 3DS, and added them using FNIS as a sequence

s -a  MyanimStart

+ MyanimLoop

+ -a MyanimStop

 

( I tested with

s -a  MyanimStart

+ -a MyanimLoop

+ -a MyanimStop

and the 3 anims play in sequence so I know my HKX files are correct )

 

 

When I PlayIdle this sequence after registering for the events I receive :

MyanimStart

IdleStop

MyAnimLoop

and the loop plays indefinitely

 

I want an event that would fire each time the loop is played

so that I can decrement a counter and send the MyanimStop event to end the loop.

But MyanimLoop is played only once.

 

Ah yeah my apologies, I was confused thinking I was in the SexLab forums, only now am I noticing this is the FNIS thread. In my defense the notification of a reply to this thread was in the middle of a bunch of notifications to replies from SexLab threads, but that's drunken Friday night posting for you.

 

There may be an easier way, but to use SexLab as an example I setup animation events in the same way you're mentioning.

 

s -a  MyanimStart

+ MyanimLoop

+ -a MyanimStop

 

Then I use papyrus to loop through the idle. Something like this:

 

Debug.SendAnimationEvent(actor, "MyAnimStart")

float timer = 10.0
float stageStart = Utility.GetCurrentRealTime()
float progress = 0.0
advance = false
while !advance
        Utility.Wait(0.2)
	progress = Utility.GetCurrentRealTime() - stageStart
	if progress >= timer
		advance = true
        endIf
endWhile

Debug.SendAnimationEvent(actor, "MyAnimStop")

This would start MyAnimLoop via the acyclic MyAnimStart, and continue looping it indefinitely until the timer while loop finishes and it plays MyAnimStop.

Link to comment

 

I want an event that would fire each time the loop is played

so that I can decrement a counter and send the MyanimStop event to end the loop.

But MyanimLoop is played only once.

 

 

 

This would start MyAnimLoop via the acyclic MyAnimStart, and continue looping it indefinitely until the timer while loop finishes and it plays MyAnimStop.

 

I just made a quit test. And it seems not possible to get the kind of event thor would like to have. 

 

Events that can be caught with OnAnimEvent() have to be sent through an hkbClipGenerator. But apparently this only works for acyclic animations. Which makes sense from the game point of view. The game makes very little use of scripted animation calls, and I can't think of any situattion where the game needs this kind of information from a cyclic animation.

 

So you I think you need some sort of timing. Although I would recommend RegisterForSingleUpdate() over Ashal's wait loop.

Link to comment

So you I think you need some sort of timing. Although I would recommend RegisterForSingleUpdate() over Ashal's wait loop.

 

 

 

 

RegisterForSingleUpdate() was inconsistent with it's timing in all my testing, doing RegsiterForSingleUpdate(10) would sometimes take 5 seconds to trigger, sometimes 15. I may be misremembering though, I know for sure Utility.Wait(10) has this problem atleast; which is why I do the loop based on CurrentRealTime().

 

Wait loop also allows for some additional control placed inside of it; such as being able to easily intervene and abort the animation sequence and perform checks while the idle plays, making sure the idle is still playing and the actor hasn't moved or died somehow in the process. Though I suppose you could do the same with updates, it would just take some refashioning with UnregisterForUpdate() and a separate control loop to do the checks instead of a timer loop, but then that seems to defeat the whole point.

 

edit: Or maybe I'm just wrong on all accounts, I haven't experimented with states much. Thinking about it more now, doing updates and a control loop to control animation sequences could very well be a cleaner solution.

Link to comment
I just made a quit test. And it seems not possible to get the kind of event thor would like to have. 

 

Events that can be caught with OnAnimEvent() have to be sent through an hkbClipGenerator. But apparently this only works for acyclic animations. Which makes sense from the game point of view. The game makes very little use of scripted animation calls, and I can't think of any situattion where the game needs this kind of information from a cyclic animation.

 

So you I think you need some sort of timing. Although I would recommend RegisterForSingleUpdate() over Ashal's wait loop.

 

 

Thanks for your answer.

 

I used  utility.wait( NbLoops * LoopDuration ) inside OnAnimEvent() after registering for "MyAnimLoop"

 

and it works fine.

 

 

Debug.SendAnimationEvent(actor, "MyAnimStart")

float timer = 10.0
float stageStart = Utility.GetCurrentRealTime()
float progress = 0.0
advance = false
while !advance
        Utility.Wait(0.2)
	progress = Utility.GetCurrentRealTime() - stageStart
	if progress >= timer
		advance = true
        endIf
endWhile

Debug.SendAnimationEvent(actor, "MyAnimStop")

GetCurrentRealTime() is counting time even when game is paused.

 

As a side note, your coding is not very efficient :

float StageStop = GetCurrentRealTime() + 10
while StageStop > GetCurrentRealTime()
  Utility.wait(0.2)
endwhile

does the same with less effort from the processor

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use