Aller au contenu

Photo

VFX Bug - Body Aligned VFX shifts during animation


  • Veuillez vous connecter pour répondre
24 réponses à ce sujet

#1
henesua

henesua
  • Members
  • 3 878 messages
I have encountered a bug with a VFX. I am using Amethyst Dragon's Quiver VFX. And after a particular animation the VFX get screwed up.

Quiver as expected
Image IPB

Quiver unexpectedly shifts during animation
Image IPB

Image IPB


Here's the VFX line for the quiver

1720    VFX_QUIVER_BROWN_HUMAN_MALE    D    0    ****    qvr_brn_hm    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    ****    1   

Column for model: Imp_Impact_Node

Here's the bit of code that leads to the animation I believe is causing the problem:

    ClearAllActions();

    if(GetArea(oDest)==GetArea(OBJECT_SELF))
        TurnToFaceObject(oDest);

    switch (iSkill)
    {
        case MS_SKILL_CLIMB:
            DelayCommand(1.0, ActionJumpToObject(oDest, TRUE));
            if(!bFail)
                SendCompanions(OBJECT_SELF,oDest,"Climb");
            else
                DelayCommand(1.1, MSDoMoveFail(iSkill));
            DelayCommand(0.1, PlaySound("fs_dirt_hard1"));
            DelayCommand(0.5, PlaySound("fs_dirt_hard2"));
            DelayCommand(1.0, PlaySound("fs_dirt_hard3"));
            PlayAnimation(ANIMATION_LOOPING_TALK_FORCEFUL);
            break;

Modifié par henesua, 12 janvier 2014 - 04:17 .


#2
The Amethyst Dragon

The Amethyst Dragon
  • Members
  • 1 880 messages
Yup, known bug that isn't with the quivers, it's the PC model.

The VFX is attached to the PC's "impact" node. During certain animations (I've noticed it mostly with Vaei's sleep and jump animations), that node is shifted/rotated...and doesn't get put back the way it should.

If you have a way to force your PC to be re-rendered, it will correct the node/VFX orientation. If your module/PW has a way to change a character's phenotype, that's a quick way...for instance, mine makes use of the alternative combat animation styles made by ragnarok_mr4, and PCs can switch styles at will.

#3
ShadowM

ShadowM
  • Members
  • 768 messages
Can you put together a sample module with the problem so I can test it?

#4
henesua

henesua
  • Members
  • 3 878 messages
Thanks, Amethyst Dragon. That bug was not known to me. Glad to hear I was on the right case with the animation. Am testing now to find out which animations cause problems.

ShadowM, are you interested in fixing these animations? I use a lot of custom content from diverse sources. It could take a while to create a test module for you.

#5
Shadooow

Shadooow
  • Members
  • 4 470 messages
isnt that this issue: http://social.biowar...7236394#7268261 ?

if it is its already present in community patch 1.71 since beta 7or so...

#6
OldTimeRadio

OldTimeRadio
  • Members
  • 1 400 messages
Right on, ShaDoOoW!  I was thinking the same thing.  If not, it'll be interesting to see what's causing it.

#7
Pstemarie

Pstemarie
  • Members
  • 2 745 messages
Running a test on this - I have removed all animation keys from ALL of the dummy nodes in Project Q's a_ba. So far I have noticed no ill effects to any of the animations. Granted I cannot test all possible issues because I do not use the same CC as others. I am willing to share the model if anyone wants to run additional testing.

In my experience with animating NWN models, the dummy nodes should NOT have animation keys. According to my nephew who works for Cryptic, the only time you would have animation keys on a dummy node is if it is serving as a "bone". According to him, NWN models are backwards in that the rendered geometry is animated as opposed to a skeleton of nonrendered bones to which the rendered geometry is parented.

Modifié par Pstemarie, 12 janvier 2014 - 04:30 .


#8
ShadowM

ShadowM
  • Members
  • 768 messages
Check a_ba_non_combat Impact node for me(use modified vaei base models) I think that the one that causing the problem. Like Pstemarie said it should not have any animations on it. I do some testing.

Update: That seem to fix the problem for me. Glad this came up I did not know about this glitch.

Modifié par ShadowM, 12 janvier 2014 - 04:40 .


#9
Pstemarie

Pstemarie
  • Members
  • 2 745 messages
I gone through the rest of the Project Q a_ba series and removed all animation keys attached to dummy nodes. So far no glitches to report. Putting these into Project Q v1.8 pending more tests.

#10
henesua

henesua
  • Members
  • 3 878 messages
Vaei's animations are causing problems for me too. As well as Talking Forcefully. Can't find any others. I went though anims 0-42.

Here's the magic wand activation script I used in game to test the animations of the wand's target.

I would appreciate having copies of the animations so I can paste them into my file. I'm gonna try that with the Project Q version first.

Some day I may get to working on animations for NWN, but not today. Got much too much to work on.

#11
ShadowM

ShadowM
  • Members
  • 768 messages
That animation is in a_ba_non_combat that I mentioned just send me the file or put it in project page and I download and I fix it and send it back to you. I an easy fix. Like always save a backup.

#12
henesua

henesua
  • Members
  • 3 878 messages
For the record Talk Forcefully is in a_ba. I have Vaei's animations (via Q) in a_ba_noncombat.

And all and any help is appreciated, thanks.

Modifié par henesua, 12 janvier 2014 - 05:50 .


#13
Pstemarie

Pstemarie
  • Members
  • 2 745 messages
Henesua, the Q fixes for the a_ba set are in the Project Q 1.8 Dev folder on dropbox.

Just a thought - has anyone thought about what would happen if all the dummy nodes - except the rootdummy - were removed from the animation supers and were just part of the pheno model? Since they aren't supposed to be animated anyway I don't think it would break anything.

Modifié par Pstemarie, 12 janvier 2014 - 06:27 .


#14
Wall3T

Wall3T
  • Members
  • 461 messages
this happens often when using custom animations. I find that removing and re-applying the vfx in-game fixes the issue also

#15
Pstemarie

Pstemarie
  • Members
  • 2 745 messages

oOKyeOo wrote...

This happens often when using custom animations. I find that removing and re-applying the vfx in-game fixes the issue also


I wouldn't exactly call that a fix, it's more of a bandaid that fails to address the overarching problem. Similar issues also occur when applied to models not using custom animations. Fixing the animation super is a rather simple solution and saves unnecessary scripting. It took me about 10 minutes to fix the models.

If the BioWare animation supers had been given more critical review in the first place... 

:devil:

Modifié par Pstemarie, 12 janvier 2014 - 08:02 .


#16
henesua

henesua
  • Members
  • 3 878 messages
I really appreciate the fixes to this, and the advice. ShadowM fixed my files, but I appreciate the fixes to Q, Pstemarie, since I use Q.

In addition this episode inspired me to actually use the climb up and jump down animations that were released together some time back by Failed Bard.  I've had them in my HAK since he released them, but not made use of them.

This is a great community. Hopefully I will be able to soon share the PW which the Vives team is working on. Anyone interested in play will be welcome of course.

#17
Wall3T

Wall3T
  • Members
  • 461 messages

Pstemarie wrote...

oOKyeOo wrote...

This happens often when using custom animations. I find that removing and re-applying the vfx in-game fixes the issue also


I wouldn't exactly call that a fix, it's more of a bandaid that fails to address the overarching problem. Similar issues also occur when applied to models not using custom animations. Fixing the animation super is a rather simple solution and saves unnecessary scripting. It took me about 10 minutes to fix the models.

If the BioWare animation supers had been given more critical review in the first place... 

:devil:


i like to think of it as duct tape really :lol:

and Henesua, your pw sounds amazing already. id totaly would play

Modifié par oOKyeOo, 12 janvier 2014 - 11:15 .


#18
henesua

henesua
  • Members
  • 3 878 messages
thanks, o0Kye0o. Vives is not my PW though. This is a collaborative effort. Its a complete remake of the old Vives PW which began in 2002/2003. Interesting enough given the animations we are fixing, Vaei was one of the core members who gave the world its - at the time - unique features.

Anyway, about animations. I was wondering if anyone knew the animation indexes for the disappear/appear and related animations. or... are these only usable as effects?

Modifié par henesua, 13 janvier 2014 - 01:01 .


#19
Pstemarie

Pstemarie
  • Members
  • 2 745 messages
They are effects. No animation constant is defined for them in nwscript.nss. There is an integer assignment though because Ihe scripting for EffectDisappearAppear has an integer callout for the animation. The default value for the animation integer is 1. Beholders use 2.

You could try using the constants ANIMATION_LOOPING_APPEAR and ANIMATION_LOOPING_DISAPPEAR or
ANIMATION_FIREFORGET_APPEAR  and ANIMATION_FIREFORGET_DISAPPEAR. Considering the naming convention for the other animation constants it is quite probable that one of these values will work - it just might be coded internally as opposed to being in nwscript.nss

Modifié par Pstemarie, 13 janvier 2014 - 02:33 .


#20
henesua

henesua
  • Members
  • 3 878 messages
*nods*

Yes, as far as I know, there are no constants in nwscript for the disappear/appear animations, but I was wondering if there was a number for them. Every animation is identified by a number in nwscript (thats what the constants do), and there are many numbers that are not identified with constants (43 - 99 for example). But I have not taken the time to go through each one to see if there are any animations at those. Once upon a time way back in the beginning of my play with all of this (like 2010) I did run an iterative loop on spiders for every animation, but I foolishly didn't record what each number did and I can not remember if the disappear or appear animations were amongst them.

Well when I have a moment, I'll rewrite that script, and run it on a spider and/or beholder and see what happens at the unnamed indexes.

Currently I am rewriting my move skill script to make better use of animations and be more versatile. I really like that OldManWhistler made the original that so many PWs installed, but I've reworked the functionality of it so much that its time I do a complete rewrite and eliminate the mess. Will take me an evening when I have one.

Thanks again for the work on the animations. I love animations. They are magical treasures that bring the characters to life. Thank you very much for all you've done. Like reworking the coat animations for some of the alt combat phenos in Q. I do hope you get to fencing one of these days (my favorite one of those), but I am patient. What you've done so far and what you are doing now (with TNO) is great stuff and much appreciated. Same goes to you ShadowM and Amethyst Dragon. It is all appreciated. I love that I don't have to do all this stuff myself, but that we can all share our efforts collectively.

Modifié par henesua, 13 janvier 2014 - 04:03 .


#21
Pstemarie

Pstemarie
  • Members
  • 2 745 messages
FYI (sorry short hi-jack) - I have added Failed.Bard's Custom1 (Climb Wall) and Custom2 (Jump Down) animations to Project Q's a_ba.mdl animation super.

#22
3RavensMore

3RavensMore
  • Members
  • 703 messages
Does Q also included the rope climb and jump animations?

#23
Proleric

Proleric
  • Members
  • 2 356 messages

henesua wrote...

*nods*

Yes, as far as I know, there are no constants in nwscript for the disappear/appear animations, but I was wondering if there was a number for them. Every animation is identified by a number in nwscript (thats what the constants do), and there are many numbers that are not identified with constants (43 - 99 for example). But I have not taken the time to go through each one to see if there are any animations at those.....

I haven't found any new numbers (gave up around 200 IIRC). Some of the animations seem to be hard-coded in certain engine functions, and may be nerfed, to boot. For example, Zombie Walk (walkinj) works as an item property on PCs, but not on other creatures that have that animation (not even zombies - go figure), so I had to make a new phenotype, in which the walk animation is the zombie walk. (Meanwhile, back on topic...)

#24
henesua

henesua
  • Members
  • 3 878 messages

Proleric1 wrote...

I haven't found any new numbers (gave up around 200 IIRC). Some of the animations seem to be hard-coded in certain engine functions, and may be nerfed, to boot. For example, Zombie Walk (walkinj) works as an item property on PCs, but not on other creatures that have that animation (not even zombies - go figure), so I had to make a new phenotype, in which the walk animation is the zombie walk. (Meanwhile, back on topic...)


Thanks for the info, Proleric1. Thats good to know and saves me some time.

#25
meaglyn

meaglyn
  • Members
  • 811 messages

Pstemarie wrote...

Henesua, the Q fixes for the a_ba set are in the Project Q 1.8 Dev folder on dropbox.


Since there isn't likely to be a Q1.8, any chance of us mere mortals getting copies of these?

pretty please?