Death sequence problem.
Hi, I'm testing a plugin where the player model is changed by a new model, and I change the model by this way:
PHP Code:
The sequences play fine, I'm using the offset m_szAnimExtention for force the CS to play some animations like ref_aim, ref_shoot, crouch_aim, crouch_shoot. But I tested taking the use of this offset off, but it wasn't the problem. The problem is the following: When the player dies, how it was, this doesn't matter, the upper part of the body ( controlled by pev_sequence ) is played, the arms and head moves like he is dying, but the lower part of the body doesn't move, it stays like in "dummy" animation. I made some tests handling the SetAnimation function with Orpheu, and I did some prints that reported the states of: * the parameter of SetAnimation function "PLAYER_ANIM" * m_Activity offset * pev->sequence * pev->gaitsequence and the values were the same, except pev_sequence, that is because the number of the animation where "dies" sequences resides arent the same because the default player has 111 sequences and this new model has 39 sequences. when Player dies with the default cs model: gaitsequence = 0 when player dies with the new model: gaitsequence = 0 So, the SetAnimation function place it at "dummy" sequence, I can't understand how the CS makes to move all the body when the player dies, and it doesn't stays with the legs at the state of "dummy" sequence. I will let some pictures just here: http://cloud.steampowered.com/ugc/55...75274BB128848/ http://cloud.steampowered.com/ugc/55...7105399F4DE34/ Can you see how the model stays with the legs like in "dummy" sequence. It is because the SetAnimation functions set pev_gaitsequence = 0 when player dies, but the default CS moves all body, and the value of gaitsequence is the same that with this plugin. +Data: PHP Code:
PHP Code:
|
Re: Death sequence problem.
Possible to attach the model ? I would like to test something.
|
Re: Death sequence problem.
Ok, here it is the same but with other reference, the same sequences.
http://www.mediafire.com/?nyetccsd2fh560q |
Re: Death sequence problem.
AddToFullPack :oops:
PHP Code:
|
Re: Death sequence problem.
I thought it was because you were missing sequence or missing activity but by reading model datas , it seems fine :
Spoiler
I've also check LookupActivity() ; It's well called for example with ACT_DIE_GUTSHOT and returns well a valid sequence like 28. About gaitsequence, it doesn't seem it's needed to be set for such animation (also same for hover, swim, etc.), being set on 0 is the normal behavior probably because it's a full sequence. At this point, no idea why the 'bottom" is fucked up ; it sounds like it's overwritten by something. Maybe there is a problem with the model or because it's a custom one ? EDIT : Tried things like : if I force LookupActivity to return a death animation, in-game, the animation is well played, but once I'm dead, it fucks up. Another try is I've hooked SetAnimation as post and when I'm dead, I set gaitsequence to the current sequence and I call ResetSequenceInfo (may not needed) ; then what you see is for some reason the death animation works fine, but randomly right after (once the other animation is done), it plays the same but it's fucked up (sometimes nothing is played, or the same is played properly or played and fucked up).
Spoiler
That's all for now, not sure what happens, it's weird. |
Re: Death sequence problem.
@Arkshine:
I tried the same things than you, but no result... Other thing that I've done is when PLAYER_ANIM == 4 in pre, supercede this and set values to randomly die sequences, but this doesn't matter, it plays the upper part of the body only... I don't know why, but it is killing me... I'll have to try other things, like a new ent, but forcing the sequence doesn't take effect... Maybe one forced solution? :P the best way possible... Edit: I'll try setting in total 111 sequences to the model, like CS default model, in the case it worked I will notice here, meanwhile other solutions are accepted. |
| All times are GMT -4. The time now is 20:32. |
Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.