DarthParametric

Good thing it only took someone four years to notice. That might have caused problems.

Read the linked thread. You can't have a hooded outfit without making a disguise due to how the engine duplicates animations between head and body models. If you want a different mask, edit SS's model.

It was a request. If you want the full getup, just use SS's mod directly.

Nothing has changed regarding fonts. Installing K1CP on Android would be the same as any other TSLPatcher mod. You presumably need to do it on a PC and then copy the files back. But I don't have the mobile version, so I have never done it myself. You'd have to ask someone conversant with it how to do it. And be aware that as of K1CP v1.8, it is no longer compatible with K1R, so you have to pick one or the other.

Just note that SS's mod requires a tweaked version to match his revised weapon models. So while the fix I made for the Community Patches works fine with the vanilla gun models, when used with this mod the guns will be slightly mispositioned, possibly with some minor clipping.

The vanilla issue is fixed by the Community Patches.

The problem is that integrated guns use the droid's racetex texture due to how appearance.2da works. SS has a fix, it just hasn't been uploaded yet.

This is not something you can do with placeables. Well not existing placeables anyway. What you are talking about is room model editing and/or creation. This has to be done in 3DS Max/GMax. It's not a topic that can be easily summarised in a couple of lines. As for screenshots, you can enable them in the ini under the [Game Options] section, setting EnableScreenShot=1 and in K1 you can also use GUIsInScreenShot=0 to always take screenshots without the GUI just like in first person mode (doesn't work in TSL though). Using the PrintScreen button will save screenshots in the game folder as TGAs.

In future, you shouldn't use K1R and K1CP together. Versions of K1CP after 1.7 aren't compatible. If you are getting crashes with the fade, try Disable Vertex Buffer Objects=1 in the [Graphics Options] of swkotor.ini if you don't already have that added. That's the only thing I can think of with that. It shouldn't be related to the script itself. As I said before, fading is the default behaviour that a lot of vanilla scripts use, so if you are encountering crashing elsewhere then that could be the cause.

A conversation is initiated between two objects. One is the owner of the dialogue (and all scripts attached to it) and the other is the listener. This is typically the player, but not always. The owner of a DLG is considered the default speaker of entry nodes unless someone else's tag is specified in the Speaker field for that node. All scripts attached to the DLG are executed by the owner. In practical terms, this means you don't need to use a tag for the owner, you can use OBJECT_SELF. You also don't need to assign commands to the owner - any command that isn't assigned to someone else defaults to the owner. But, as I said, a script (and the DLG itself) will immediately terminate when their owner is destroyed. This can create problems if you need a scene to continue on past a creature being destroyed and it was the owner. In essence, whoever you assign an ActionStartConversation to is the owner of that DLG and its scripts. If you assigned it to a placeable then the placeable is the owner. The game uses a lot of invisible placeables as owners for cutscenes, because it frees the designer up to do whatever they want to the NPC participants. As to your crashes, that is not normal behaviour. Not for a simple fade. That is the default behaviour anyway, so you'd be getting that all the time during the vanilla game. If you are using an EndConversation/EndConverAbort script then yes, I'd expect that could be the issue, since you are presumably destroying the owner of the DLG just as it tries to fire another script due to the delay.

Is the NPC the owner of the DLG/script? That can sometimes cause problems, since a script will immediately terminate as soon as its owner is destroyed. You can still destroy the owner as the final function in an exit node script, but this will usually happen in plain sight of the player unless you jump them somewhere else first. You can also command them to walk somewhere, like the module exit, first before destroying themselves. In general though, it's pretty straightforward: DestroyObject(oNPC, 0.0, TRUE, 0.0); The variables here are the creature to destroy, the delay in seconds before destroying them, not fading them out (so FALSE if you do want them to fade), and the delay in seconds before they start fading (which only matters if the previous term was set to FALSE). If the creature is the script owner then you can swap the object reference to OBJECT_SELF. But in that case I would delay calling the function until everything else in the script has finished executing, like so: DelayCommand(2.5, DestroyObject(oNPC, 0.0, TRUE, 0.0)); This will delay calling the function by 2.5 seconds, the value of which you can adjust as needed. If you want a creature to destroy itself after walking somewhere first, you can add the command to its action stack. This is commonly seen when an NPC "exits" an area. Often this can be part of the creature's UserDefine script, the case for which can be called at the end of the conversation. For example: ActionMoveToObject(GetObjectByTag("k_exit", 0), FALSE); ActionDoCommand(DestroyObject(OBJECT_SELF)); SetCommandable(FALSE); To issue those commands from a script owned by a different creature/object, you'd need to use AssignCommand to assign them to the NPC of interest. If you want more specific details, you need to provide more info about the circumstances of your scene and how it is currently set up.

You aren't doing it right. Left click drag a TPC over the window. Don't let go of the mouse button. Now hold down the ALT key. You'll see a message bar on the window pop up saying Export TGA. Now let go of the mouse button.

What you quoted tells you exactly how to convert to TGA.

I'd imagine that's a Blender script issue, not Max/KMax. As long as you don't compile to binary and then decompile, the smoothing you defined is stored in the ASCII. I don't really follow the status of KOTORBlender. You'd have to ask @ndix UR about it, but perhaps you can try the version on Github if you are still using an older version - https://github.com/ndixUR/kotorblender

Uninstall it (either an included uninstaller or via the Control Panel). Their installer sets a registry key for the initial destination you choose, and future installations will reuse that without asking unless you run the uninstaller.

Plot locals (i.e. 0 to 10) are in k_inc_utility in both games. The ones in other includes are AI (for the most part) related. 0-10 are the only ones you should be using for general purpose use. You'll potentially break things if you start using higher numbers.

They also work on triggers as well. It's common practice to set a local on a trigger the first time it fires. Gives more flexibility than outright destroying it for cases where you might want to reuse it. All of K1's random loot placeables use locals in their heartbeat scripts to stop them respawning (although Obsidian added a new function for TSL to just remove the script altogether after firing, to cut down on overhead on the Xbox). K1 makes extensive use of module locals for various quest states via the module includes.

If you are going to get into scripting, you'll be spending lots of time rewriting stuff. Comes with the territory. If you are making something for you self, by all means hack it together however you want. If you are planning on releasing something publicly though then you should be willing to refine it to make sure you don't do anything that isn't strictly necessary. It will make your life easier in the long run anyway when you come to setting up a TSLPatcher config. TalkedTo isn't anything special or unique. It's just local boolean constant 10. They added an extra utility function for it, but under the hood it's still just Get/SetLocalBoolean. If you want to use the strings and the functions for them outside generic scripts, you'll need to set k_inc_utility as an include.

You can set a local on a placeable or even the entire area. It's not limited to creatures.

There's no need to create a new global unless you need to track something across multiple modules. If you are only interacting with a single object/creature via one DLG then you can just use one of the existing locals that are set up for that purpose.

No, Xoreos Tools doesn't properly convert all textures. The best solution is to use ndix UR's TPCView - https://deadlystream.com/files/file/1552-tpcview Not only does it correctly convert them, but it also exports a TXI for any texture that needs it. To mass convert, select the TPCs, drag them over the TPCView window, hold down the ALT key, and release.