Heya! Not much changed with that code I posted and what I ended with before - it is after the trig lookup. I just went frame by frame with my code and didn't notice any bugs with camera switching. I would need a video or screenshot with my code running to look into it. I'm not sure about the characters, as the bug happens outside the trig calcs and angle setup area. It would either require following the code from the initial counter, which seems like an ordeal, or finding the memory for a buggy character and trying to follow read/writes for it, which may or may not work out. Also, if you haven't fiddled with Symbols, you might want to. It makes it easier to jump around the code and whatnot. Older versions (5.0-3819) lets you tag single lines of code (right click -> add function then Symbols -> save symbol map).
With the new skill effect bug, I'll probably record the intro movies and every character skill and compare with my fix, to make sure nothing is breaking. It'll take awhile to get that done.
/edit I wrote a value finder. You probably want to use it during 30fps. I'll probably find the buggy soldier memory in a few minutes with this, but not sure I can follow it to the bug.
Zeroes angles for assets between the value placed in memory at 8066da80 and 8066da84
Breakpoint 803e1a90 and look at r6 to see what asset pointers/values are being used.
For example, on the second part of the intro movies:
Something above 92793000 sets the camera values, so you want to exclude those from being zero'd, so that goes into 8066da84 to exclude everything above 92793000
Then if you put 92750000 into 8066da80, you'll break all the soldiers, helping to get closer to the values of the soldiers we want to find (the buggy ones)
8066daa0 can change the behavior from forcing zeroes to something else, like 90 degree angles. Use float values.
$movie value finder range
C23E1A90 00000006
8062FFE0 7C033040
41A10020 8062FFE4
7C033040 41A00014
3BA00000 C3E20000
C3C20000 C3A20000
7F63DB78 00000000
/edit2 Ok, I figured out the location bug. I had to crack open the game code in a text editor and do a regex for " psq_st.*qr3 ", which is how they round off the counter to see if it has a fractional component. I found each one and deleted it in game, until the game bugged out. There weren't that many to test, but I had trouble confirming what that code did until I adapted the soldier finder code to that area. In the end it's: 803e0c94 and below. The game sets asset locations here, but it's a bit tricky because it only does one value at a time and not x/y/z. I'm not even sure most things have y or z components, it seems they manage to make it 1 dimensional for many things. ANYWAY, the bug is that it appears to re-use models that have gone off-screen, by changing their location to a place they need a new model to appear. Since the code averages locations for fractional frames, the model only moves halfway to its new location, which puts it in the wrong place for one buggy frame. The fix will be to detect large variations in location and skip averaging if it is too large, and hopefully nothing moves across the screen too fast, or I'll have to do something more complex.
Buggy memory breakpoints: Range from 92753564 to 927536a8 during soldier intro movie, running from the hill to the sniping/scope part.
The other bug that I thought was easy, is more complicated. With Mechonis' fingers disappearing for a frame and also affecting stationary/dead soldiers being displayed. I don't think I need to look for where the bug occurs though.
/edit I've been back at work on the main code. Tweaking a few things. Probably be a few more days before I post a new update.
).