vfig on 6/1/2024 at 18:45
so, infinite mouth flapping in Running Interference was easy to replicate. experimenting a little (i moved the two torch guards and their torch to just near the starting area), there are definite differences in behaviour when the ais are not immediately audible (e.g. due to being out of range)—and possibly also when they are not in view (or possibly only if they have never been in view?) when they start to speak. this latter has been harder to pin down, but i definitely was seeing a difference when i went in to game mode facing the two guards or facing away from them!
by disabling all the other "mono_loop" settings in guard schemas, the infinite mouth flapping stopped happening (which makes sense: it was the mono_loop that was preventing the speech ending callback being called, so the only difference was whether we got infinite unmoving mouth or infinite flapping). however, there are still visible issues with the two torch guards: sometimes their face and speech seem to be out of sync by several seconds; sometimes they still appear to be doing the canned flapping animation for some lines (though possibly that is a result of me not doing the schema modifications correctly and breaking some lines? i would need to check).
at the moment i dont know what is leading to the onscreen/offscreen differences. a very rough guess is that the Mesh Textures handling code, which the face textures piggybacks on, is not initializing for a given AI when it is not rendered (or at least, not until it is first rendered)?
edit: nothing to do with Mesh Textures at all: i think the core of this problem is that the face texture resources are only assigned (in FacePrerender()) for an AI the first time it is rendered; so i guess these differences are arising due to the speech callback firing before the ai is ever rendered? thats something i will have to dig into.
i also notice that SpeechStartCB() and SpeechEndCB() both free the ai's face pose string if they think it is finished with, but the "animated past the end of the string" path in FindBitmap() sets it to zero without freeing it. I dont think this is caused by the bug above, but it looks like it will be leaking memory, and so really ought to be fixed too.
Quote Posted by vfig
well, i will take a look into hooking up the schema loop callback, which isnt very complicated to do, and looks like it will have a decent chance of fixing the "stops animating" problem.
and i havent got around to this yet either—mostly because i dont have a great workflow for this sort of patching yet, and my osm code for the wip fm that i will have to cannibalize has been sitting waiting for a significant overhaul and compiler change to resolve some sporadic gamebreaking issues caused by ASLR and gcc's runtime... so the codebase isnt in a great state to take a copy of it and put it into service for this purpose quite yet.
that isnt a hard roadblock—cause really all i need to do right now is just get a proof of concept running, ignoring those issues and just restarting if they happen. but it makes it a lot harder for me to focus enough to work on, because my brain cant help but feel the weight of the dangling anvil of all the fixes that need to happen... sigh