DarthParametric

Nothing has changed regarding creating 3D models. You'd have to create your example in Max/GMax (or Blender), just as you have always had to, and will continue to have to do in the future. The new/improved compilers are just that - compilers. Their function is solely to create correctly formatted binary models.

That hasn't been necessary for over a year now. Both MDLEdit and MDLOps v1.0 will allow you to recompile edited level models with no issues, for the most part. For changing textures, MDLEdit will let you change the texture names directly in the editor itself (at the least the more recent beta versions anyway).

This was expressly noted:

I don't use them myself, as a general rule, but I believe this should be what you need for K1 - https://www.nexusmods.com/kotor/mods/1076

As detailed above: There will only be an existing MOD file if you have one from another mod. That's why they are used, so as not to overwrite the vanilla game files.

It won't work for players without creating a disguise item. I have no plans or interest in making one.

The is only a single GIT per module. As I said above, make a copy of the GIT somewhere and then edit it with K-GFF. You no longer need KTool after having extracted the RIMs. Have a look at the archive I linked to at the end of the summary.

You extract the entirety of both RIMs. Don't expand them or select any of the contents, just click on the top level and use the button noted above.

This is a brief overview. I would suggest starting by creating a folder to hold all your working files, with sub-folders as appropriate (here's an example) Extract both the RIM files for the module in KTool under RIMs -> Modules. Select unk_m41aa.rim and unk_m41aa_s.rim in turn and hit the "Extract Entire RIM File" button on the top right (I put them in the SOURCE folder in the above example) Using the ERF/RIM Editor, create a new MOD file named unk_m41aa.mod Select all the module's files you extracted in KTool, and drag them into the ERFEdit window, then save the MOD Make a copy of the module's GIT file, m41aa.git Open the GIT with K-GFF Start by going to View -> Fold All, then expand the base STRUCT node to reveal the GIT's structure Expand the CreatureList node If you expand the first few STRUCTS, you'll see there are already three Gizka in this module using two ResRefs - unk41_gizka and unk41_gizka002 Checking those UTCs in KTool, we can see some important dev notes in the Comments tab, so we'll go with unk41_gizka In K-GFF, right click on the first STRUCT and choose Copy STRUCT and then right click on the base CreatureList node, right click, and choose Paste STRUCT A duplicate of that STRUCT will appear at the bottom of the list, which we can now edit as appropriate Before proceeding further, you'll need some co-ordinates. You can generate these either via loading up the module layout in Max/GMax or by running around in-game with an armband that spits out co-ords of the player's position. Edit your new entry in the GIT, changing the X/Y/ZPosition values as appropriate You will see two values for rotation, XOrientation and YOrientation. These are the COS and SIN of the rotation in degrees, respectively. As these Gizka will be hopping around anyway, just leave the existing values. Repeat with duplicating and editing the STRUCT for however many new Gizka you want to add. Save the GIT when done. For testing purposes, you can just copy the MOD into your K1 modules folder, then open it with ERFEdit and drag and drop your edited GIT in. Save the MOD. Start the game and load a save from before entering the Central Beach module for the first time. Examine the quality of your handiwork. You'll probably want to test various position tweaks. They take a little bit to start hopping, so probably don't put them right outside the Hawk's loading ramp. Once you are happy, you can set up the mod with a TSLPatcher installer Read the included PDF for instructions on how to create a TSLPatcher setup The gist in this instance is you need to difference your edited GIT against the original and have it inject those changes into the MOD Here's a basic setup so you can see how it works

The specifics can vary depending on what exactly you want to do, but as a general rule you typically define what creatures are in a module via the module's GIT. This dictates exactly how many instances of a given UTC are in the module (each creature doesn't necessarily need a unique UTC, you can spawn any number of duplicates) and where they are positioned. Alternatively, some situations may instead call for the creature/s to be spawned via script. This is typically the case for cutscenes or quests, where you only want the creature/s to appear under specific circumstances. In the case of your Gizka example, assuming you want them to be neutral (i.e. non-combat) background creatures, adding them to the GIT would be the way to go. For that you could just reference the pre-existing generic c_gizka.utc without needing to add a custom UTC of your own. All you'd need to do is figure out how many you want and where to position them, then add that info to the module's GIT and inject it into a MOD (that should be Central Beach I believe - UNK_M41AA). If you wanted to get more fancy and make them interactable, you could look at the Yavin station and Ebon Hawk modules to see how they handled being able to kill them.

Oh god dammit.... Thanks for pointing that out. Fixed.

View File Control Panel For Kashyyyk Shadowlands Forcefield This mod makes some minor changes to the forcefield in the Upper Shadowlands on Kashyyyk that gates access to the Lower Shadowlands. In the vanilla game, the forcefield is never actually disabled. Rather, the sound effect is simply turned off while the camera is pointed away from the forcefield, followed by an immediate area transition. It appears that Bioware did this due to issues with opening and closing doors via scripting. Additionally, there are no apparent controls for the forcefield, simply a frame and the field itself. The level model containing the forcefield has been edited to add a computer panel, fix a gap above the forcefield via some adjustments to the frame geometry, move some vines out of camera shot during dialogue, and prevent grass planes from spawning too close to the ramp and clipping through. The dialogue that occurs when interacting with the field has had some scripts injected to play animations implying that the forcefield is being switched off via the control panel. Jolee will now approach the control panel when the dialogue starts, and will face it when disabling the field. The field itself is now shown shutting down before the party transitions to the Lower Shadowlands. Additionally, there appears to have been an error in leaving out a script on one of the nodes that would stop Jolee from saying "You aren't going to ask about it?" even if you had actually asked about it, which has been fixed. Compatibility: The K1 Community Patch edits the Upper Shadowlands OnEnter script. Those changes are also incorporated into this mod. If you are using a mod that forcibly overwrites MOD files (like NPC Overhaul), make sure you install that mod first. This mod will patch a pre-existing kas_m24aa.mod in the Modules folder. Not compatible with any other mod that replaces the same level model (m24aa_09a). Not compatible with any other mod that puts kas24_force_01.dlg in the Override folder (although such a case should be fixable with a compatibility patch). Known Issues: In order to get the forcefield to close and function properly again after a level transition, it was necessary to resort to a hack function Bioware implemented for (presumably) the same issue they had with doors on the Yavin space station. In testing this has worked perfectly fine, however, the specifics of the hack are undocumented, so there may be edge cases I haven't encountered. If anyone experiences any issues with it, let me know. As you can see in the video, there's a subtitle error for one of Jolee's lines. Fixing it is better left to dedicated dialog.tlk overhaul. The mod doesn't touch the Lower Shadowlands module, so there's no active field or control panel on that side. Perhaps that could be an optional extra added in a future update. Acknowledgements: Thanks to @A Future Pilot for permission to distribute a modified version of K1CP's k_pkas24aa_enter.ncs Thanks to @JCarter426 for various scripting advice and troubleshooting, past and present Thanks to @LiliArch for correctly guessing that it wasn't just Bioware being lazy, which lead me to find Bioware's hack Thanks to @bead-v for MDLEdit and KOTORMax Thanks to @ndix UR for TGA2TPC The control panel textures include a mishmash of various textures from The Old Republic MMO The robes worn in the screenshots/video are from @JCarter426's Fashion Line I: Cloaked Jedi Robes for K1 Thanks to @ebmar for pointing out the lack of TSLPatcher.exe in the initial release Submitter DarthParametric Submitted 01/08/2019 Category Mods K1R Compatible Yes  

It is k_hbas_dialog.dlg in BIFs -> templates.bif -> Dialog.

Isn't that just a fade to black in the vanilla game? I thought the kiss was a mod. Edit: Yeah, here's the scene There's a mod that adds in a different animation for Bastila and the PC (ANIMATION_LOOPING_TALK_PLEADING it would seem) and changes the camera angle in order to fake the kiss.

You can't render out the fog as a separate pass by itself and comp them together afterwards?

The eyes (and eyelashes) are effectively bones, so yes, any misnamed bone will not inherit animation. The eyeball trimeshes must be named eyeRA/eyeLA and the lashes trimeshes eyeRlid/eyeLlid.

Oh I didn't see you already had a TSL play as Carth mod. That one should be fine to use as long as you run TSLPatcher and install it properly. It appears to use "P_PCarthH" as the head texture name.

Player head mods require 2DA edits. Additionally, K1 and TSL have different model formats, you can't use one directly in the other without first recompiling for the target game. What you want to do is not just a simple case of "drop a texture in the Override folder".

Your problem is that your itemclass value is too many characters. Your icon textures end up being 17 characters long, which exceeds the maximum allowed (16). Change your itemclass to something like "w_vbldeshrt" and your icon filenames to match, like "iw_vbldeshrt_001" and it works: Additionally, your UTI filenames do not match your ResRefs. Change the filenames to all lower case to properly match. And I would recommend not using DDS for icons, as KSE can't load them, which causes an error. Stick with TGA or TPC. And unless you have permission to redistribute IF's content, I would advise you to remove the archive from your post.

It should be the item class, not the model. Edit: Wait, I think I have run into this issue before. It's possibly a save game issue. How are you adding it? Via KSE?

Try iw_Vbldeshort_xxx - e.g. iw_Vbldeshort_001

What's the icon's filename?