 |
Which map? |
 |
Any map. The revenant deploys his sword by default. |
|
|
Is it not causing bugs then? I assumed that the revenant in question was stuck doing nothing like our paralysed sitters. Clearly not, since you logged this against 2.04. |
|
|
No, he's not stuck, but we do ask the revenant to turn and sit and sleep, so it's possible the constant "sheath" waitstate might get in the way. And I'm curious why the code says he should have his sword out when spawned and then ask him to sheathe it and the sheathing didn't occur (and finish). |
|
|
He's apparently missing a "draws_weapon" spawnarg. That gets read by the AI script object into tdm_ai_base::m_drawsWeapon during initialization. The sheathing animstate quits at the first check, and without releasing the wait state: // if (!m_DrawsWeapon) { // cannot sheathe weapon m_SheathingWeapon = 0; // grayman 0003331 animState(ANIMCHANNEL_TORSO, "Torso_Idle", 4); } // It wants a call to finishAction in there, mirroring the one in Torso_DrawWeapon, as well as a spawnarg I guess. I'll try it.. |
|
|
Ah, I think it's deliberate. There's a comment in the revenant def where you'd expect the spawnarg to be, "// Revenants always have their weapons out". |
|
|
So no change to entity def, but I added the finishaction which does clear up his wait state ok. at rev 14211 |
|
|
Ok, good. My bad. I fixed a few of these I found a month ago in other scripts, where an early exit failed to clear the waitstate. We should include a general check for this type of error when we go over the waitstate use in 2.04. |
|
|
Agreed. It would be great if we could do away with scripts having to switch them off at all. If that's not do-able, then erm yes some kind of check, automated if possible! |
- Anonymous
