Well, in my case there actually is a reason for that. The cameras are used in the Xor cutscene that's present across three different modules and each of them uses static cameras with the same IDs. I only edited that one instance and I'd rather not make it a special case by using animated cameras and thus requiring a unique dlg and thus requiring a unique trigger script.
Oh, that does make sense. That's a strange way to go about it, but I can see why they would do that.
You could still do it all in the same dialogue without requiring a new trigger, but it might end up being more work so it might not be worth it.
But you say that in a way that leads me to believe that it's always better to use animated cameras. Would you mind clarifying why that is? I always though that they'd be much more work.
a ) are required to be placed in a module's GIT file, which means they can't be placed after you've entered the module and make for a compatibility nightmare
b ) use the obscure quaternion rotation system
c ) are restricted to a single module
d ) can't be animated
a ) can be animated but don't have to be animated
b ) use intuitive XYZ values for rotation
c ) are contained in a model file that can be named whatever and used wherever (though difference in module layout is obviously still an issue)
There is one and only one thing static cameras can do that animated cameras can't: You can change cameras in the middle of a dialogue node with SetDialogPlaceableCamera. Unless I had to do that, I wouldn't ever use them. I hadn't ever considered a circumstance like the Xor encounter, though. That's a unique case because it can pop up in different areas, as you said.