JCarter426

5 minutes ago, Tathrin said:

Yes, I also have the "Untold Love Story" mod installed (found here: https://www.gamefront.com/games/knights-of-the-old-republic/file/bastila-female-revan-untold-love-story) which is supposedly compatible with this mod as long as I install this one second, which I did...but it's possible that I installed it wrong, or that the person who reported their compatibility was in error.

It looks like whatever changes that mod makes to Bastila's dialogue is incompatible. However, the two mods do essentially the same thing, at least as far as Bastila is concerned.

If you want to use the rest of that mod, it should work if you delete the Bastila files before installing mine.

2 hours ago, Tathrin said:

I'm assuming that the fact that lev_m4aa, sta_m45ac, and unk_m44ac already existed in my modules folder and were skipped was due to another mod I installed earlier, so I deleted those three files (well, moved them to a backup folder in case I needed them actually) and ran the patcher again.

This is normal. You shouldn't move/remove them before running TSLPatcher. TSLPatcher will patch the existing files and this is usually fine.

2 hours ago, Tathrin said:

That still left three warnings:

• Unable to find a field label matching "EntryList\214\RepliesList\1\Active" in k_hbas_dialog.dlg, skipping...
• Unable to find a field label matching "ReplyList\106\EntriesList\0\Active" in k_hbas_dialog.dlg, skipping...
• Unable to find a field label matching "ReplyList\303\EntriesList\0\Active" in k_hbas_dialog.dlg, skipping...

This, however, is not normal and means the mod didn't install correctly.

Are you using any other mods that affect k_hbas_dialog.dlg? And if so, could you attach your backup copy of it?

1 hour ago, AmanoJyaku said:

I should point out Microsoft's documentation is mostly filled contrived examples. Post one of their examples on StackOverflow and prepare to be burned.

Yeah, I know. And with a managed language, they have the luxury of being more willy-nilly than if it were C++ or C. Still, I don't think they would be doing it all over the place if it were so universally unacceptable. It's safe as long as you don't read before assigning at some point, and modern IDEs and compilers go out of their way to prevent you from doing that by accident.

Again, if you have a compiler you can trust. I know the Visual Studio C++ compiler has some silly bugs, and Clang lets you do things it really shouldn't do because that code won't compile with anything else, to say nothing of NWNNSSComp.

1 hour ago, AmanoJyaku said:

There's a mantra you should repeat to yourself: code for correctness, worry about performance later. Modern CPUs are fast, and compilers are good at optimizing your code for those CPUs. A CPU that operates at 3 billion cycles per second does not benefit from saving a few dozen cycles by omitting a single variable initialization.

I know in most use cases it's minimal, but it can make a difference if you're processing huge amounts of data in a database, which C# and .NET are often used for. The reason C# allows uninitialized local variables, unlike, say, Java, is specifically for the performance gain. It mattered to somebody somewhere at some point.

1 hour ago, AmanoJyaku said:

I'm not sure I know what you mean by hiding variables, but if you place them where you use them then they aren't hidden. Conflicts can easily be avoided by using descriptive names.

I mean if you give a variable in an inner scope the same identifier as one in the outer scope. The variable in the outer scope is hidden.

Which you can also file under don't do that, but people make mistakes.

1 hour ago, AmanoJyaku said:

And a function should only be as large as the single task it performs.

Well yes, ideally you shouldn't have too much nested code in the first place. Another reason why I don't mind NWNNSSComp replacing nested else/if with else if.

2 hours ago, AmanoJyaku said:

I don't know who taught you this, but it's a practice that's frowned upon even with modern compilers. We try to learn good habits rather than relying on the compiler to handle things we could easily do ourselves. It's not uncommon for bugs to creep into compilers, and you can track these down more readily with proper code. This advice comes from the best programmers at places like Apple, Google, and Microsoft, and even the ISO C and C++ committees.

I've seen numerous examples in the documentation for C# and Java, including the very page on variable initialization in C#. The C++ textbooks I've read (Starting Out with C++, Professional C++, C++ Notes for Professionals) obviously warned about the dangers of using uninitialized variables, but still used the extensively when it was safe.

I was taught that a) it is theoretically more efficient in languages that don't require variables to be initialized (e.g. C++ and C#) as minimal as that efficiency gain may be, and b) it's more readable—if you don't know what the value will be, don't say that's the value, as that's potentially misleading.

3 hours ago, AmanoJyaku said:

Why not create variables local to the else branch's scope? That's the whole point of having scopes, to create variables only where they're needed. Variables placed in too high a scope, e.g. the global scope, are at risk of being overwritten erroneously.

This, on the other hand, I was taught was bad practice because it increases the chance of hiding variables by accident and creating conflicts. So I was told that it's better to avoid this except for temp variables in a for loop or for a swap. This was just within a function, though—obviously global variables have their own problems.

I was also told that, in terms of memory, it's better to allocate it at the start of a function and have it crash there if it's going to crash rather than in the middle of execution. But I question whether that's a realistic problem anymore.

3 hours ago, AmanoJyaku said:

As for the compiler knowing better than we do, that's true of professionally written compilers. Which nwnnsscomp is not. I've already listed some of the basic things it fails to optimize, e.g. failing to remove empty functions. To be fair, the original compiler from BioWare has an even bigger problem in that logical AND and logical OR are incorrect. Which nwnnsscomp doesn't fix...

Well... yes. I believe you. 😧

On 12/13/2020 at 11:12 AM, AmanoJyaku said:

You should never create uninitialized variables, but it was once a common practice.

This is still common practice, at least as far as I've been taught. Yeah, there are security issues if you then try to read one, but modern compilers either won't let you do that or will initialize it with a default value, if the language itself doesn't. With that in mind, I don't see the issue.

6 hours ago, AmanoJyaku said:

the result, while syntactically different, should functionally be the same as the original source

6 hours ago, DarthParametric said:

That seems fine to me. I was more concerned that certain files might not able to be decompiled at all. This is the case for DeNCS as well, based on my own experiments.

I agree. I'm not concerned about syntactically identical source code. The way the source code is written is... not always the best way, to put it lightly.

The issues you've mentioned before don't seem like they should cause problems to me. Like with the nested else/if vs a simple else if, that'll only be functionally different if you declare something local to the else branch's scope. And, obviously, don't do that. And I doubt the compiler would've optimized for it that way if it would produce functionally different code. It usually knows better than we do.

6 hours ago, AmanoJyaku said:

I don't know what the policy is for reverse engineering mods, but I assume that's frowned upon?

I think that depends on whether you ask Oracle or Google...

7 hours ago, Untold Prophecy said:

What would be really cool to see would be the possibility of sabers' sound effects changing depending on what color the lightsaber is, in a similar manner to how sound fonts work in the custom lightsaber collecting hobby. For example: you could have the green saber use effects from Luke's in ROTJ and the red model use sounds from Dooku's.

This isn't possible. Weapon sounds are determined by the base item type, and it isn't possible to add new lightsaber types. At most you could have different sounds for standard/short/double.

Yeah, there is not much benefit if I still have to type out a list. I can write a program that wouldn't require that. That part is no big deal.

What I'm unsure about is whether certain files would have to be edited internally. That's more involved.

The script that gives you the lightsaber/lightsaber part is a_give_quest_ls. The code that determines which lightsaber you get is with the rest of the random loot in k_inc_treas_k2 as AmanoJyaku says.

Assuming I make anything that is worth anything, it wouldn't be something you could run on your end. It would be something that mod creators would run on Windows.

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.

On 12/2/2020 at 10:08 AM, Salk said:

1) a "twitch" of the right arm of every model.

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.

On 12/2/2020 at 10:08 AM, Salk said:

2) Bastila's front "tail" of her clothes clip awfully much.

3) Jolee's front "tail" having wrong animation in the cycle

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.

6 hours ago, Salk said:

The burn mark model doesn't use any texture so my asking you is just a curiosity: if it did use a texture, I could have used an invisible one with the same name in the .mod file and that might have worked or did you mean something else?

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.

5 hours ago, Kexikus said:

May I ask what it is you don't like about Manaan? Not that I'm going to change anything at this point but I'm curious.

1 hour ago, La Ingobernable said:

The main problem I have is that I grew attached to the original structures seen from the docking bay. They look absolutely majestic and colossal in my eyes. They make you feel like you're in a truly alien world.

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.

I don't know, no. But I think the solution you described could work. As long as the global is increased, I think that should prevent the pre-Leviathan dialogue from firing.

I would want to check if there's any dialogue that doesn't reference Saul and therefore could be salvaged, though. Branches that you could pursue freely after the Leviathan no matter what, if they weren't available before, if there's no reason preventing it. That would require fiddling with the scripts there too, though.