JCarter426

Yeah, @zbyl2 and I discussed this before. As I recall, he was reluctant to replace the Vash dialogue in M4-78 because that was some of the only original game content included in the mod, but not opposed to anyone else doing so. That was in regards to replacing the voice entirely, however. If one of her voices can be cloned, there is no reason another can't be. It's simply a matter of training data, and they are both prolific voice actors. Perhaps. At the moment, voice cloning is not really being policed on YouTube. There will likely be high-profile cases involving defamation or work compensation, but I think in most cases it will be regarded as harmless and not worth fighting. It's not difficult for anyone with the technical know-how or the ability to follow a tutorial, so there's just no way to universally put a stop to it. Not unlike modding in many respects.

I intend to go through the Community Patches and all my own mods to convert all files to lowercase, and due to the monotony of such a task, I'm thinking of writing a program to do it. I only own the games on Windows, so it would be help to have someone who owns them on Mac, Linux, and/or iOS and is comfortable with installing mods on any of those systems to be able to test it. Specifically, I'd like to determine to what extent it's necessary to hex edit model files that reference the names of other files (e.g. textures). If I recall correctly, @A Future Pilot reported that files packaged in RIMs and MODs also have to be renamed, so there may be a similar issue here. Note that this issue does not affect the Android version. Even though the Android operating system is Unix-based, it is designed to be case insensitive so as to behave with file systems that are not case sensitive. It'd be nice to receive confirmation on that, though.

You're still in a cutcene, but you're controlling your player, and you can't move but you can move the camera around with the mouse? I just tested it. Happens to me too.

We knew you were up to something... It's a tough call between Nar Shaddaa and Onderon, but if I had to pick one, I would go with Onderon.

Nah, don't worry about it. I had noticed it and was planning to take a look at it eventually anyway.

There are only five animations, of which I think only two are glitched, so it should be a straightforward fix. I can likely copy over the original idle animations and stretch the arms out myself. The thing is, though, when I update one of these robe mods, I have to update all of them, and I usually put doing all that off until my vacation time. If you want to remove them in the meantime, you can do so with a hex editor. Open the relevant model file, search for pause1 and pause2, and overwrite those characters with something else of the same length, like xxxxx1 and xxxxx2. That changes the names of the animations, so the model no longer overrides those animations, so it defaults to the ones on the supermodel. That will get rid of the arm glitch but bring back the arm clipping.

It's version 1.4 of Cloaked Jedi Robes that adds the animation to PFBIS/PFBIM/PFBIL. I believe Cloaked Party Robes had it from 1.0.

The animations are from the female robe model PFBIM, and they override the animations on the supermodel. There are two idle and three walking animations which stretch the arms out a bit more to reduce clipping with the cloak. There is no male equivalent, so Jolee is using the supermodel version. Evidently only the female animations have the glitch. It looks like in the video, you are using an older version of Cloaked Jedi Robes from before I restored the animation to the female robes. Previously I had exported them without that animation.

Yes, it's not a conflict with anything you have. It's a problem with the original models that carry over to the mod versions.

That is determined by the texture's alpha channel. Depending on what you did with the texture, you might have saved it without an alpha channel or you might have scaled up the RGB but not the A or some such.

This seems to be an issue with the KOTOR 2 animation. As I recall, the robes have a custom idle animation to reduce clipping with the arms and the cloak. But the animation appears to have a glitch in it. I'll see if it's possible to improve that idle animation for both games when I get a chance. These are issues with Bastila and Jolee's original body models. Their skirt flaps are dangly meshes—they aren't animated. They move based on the wind and some other physics. Very limited physics. I looked into weighting Bastila's skirt flaps to the robe bones, but I couldn't get it quite right at the time. I didn't attempt it for Jolee. I was able to do it for Juhani, because she only has the back flap and that lined up with the cloak fairly well. Maybe I'll try again for the other two, but it didn't seem very promising the first time around.

Some do, but most do not, including those.

That should work, yes. Maybe you could edit the burn mark model to use a solid black texture globally, then localize the texture to be invisible where you don't want to see it. However, if it's not using a texture right now, and instead it's using particle color as I assume, then I'm not sure if it would be possible to give it the same look with a texture. Depends how it's set up.

The game will default to angle 1 if the angle it was otherwise told would result in camera clipping. This may be down to how your characters are positioned when the scene is triggered.

I haven't tested it, but I recall hearing mention that putting models into modules won't work except for the area models for that module. If the burn mark model uses a texture, you could try inserting an invisible texture. Those generally do work as long as there are no bump maps. Again, I haven't tested this, but allegedly they also must be TGA/TXI and not TPC.

I will also have to adjust to the new look, but I think the perspective in the original billboards is off. It looks like they go off to the distance in a straight line, when the rest of the background of Ahto City is curved. It makes them look flat, like they were draw on a wall in the sky, which obviously they were. Realistically, the last few would be hovering in the air, not connected to the rest of the structure. So I think something had to be done, and Kexikus' version fixes that.