DarthParametric

Modders
  • Content Count

    4,569
  • Joined

  • Last visited

  • Days Won

    514

Everything posted by DarthParametric

  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. Are you sure that's the name of it? There is no such script in the vanilla module. And a quick glance at the Lower Shadowlands and Great Walkway modules would suggest it is not from either of those. I can only assume it must be custom. What mod did it come from? I did muse over possible additional changes, including SFX, but it's far too much hassle. I'd have to make provisions for at least three separate interactions that each have different VOs of differing lengths. Each would require custom animations in order to smoothly transition between facings. And even then I don't know how much better it would be in practice.
  6. Oh god dammit.... Thanks for pointing that out. Fixed.
  7. 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  
  8. Version 1.1.0

    29,357 downloads

    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
  9. 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.
  10. You can't render out the fog as a separate pass by itself and comp them together afterwards?
  11. 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.
  12. 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.
  13. 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".
  14. 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.
  15. 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?
  16. Try iw_Vbldeshort_xxx - e.g. iw_Vbldeshort_001
  17. As the description says, it applies to Class 7 and Class 9 armours that use the PFBF and PFBH models. Mandalorian armours (Cassus Fett's is pictured) should all be Class 9 and use PFBH, aside from any that use the full body disguise Mando appearance.
  18. The vanilla Carth head in both games uses P_CarthH01. What do you mean by "player head"? If you are using a mod to make Carth a selectable head for the PC, then the texture could be named anything.
  19. You could start out by creating greebles for the existing meshes. That shouldn't prove too taxing. You can go with a combination of physical meshes and textures. Have a look at some close-up R2 pictures for ideas. There are all sorts of lights, vents, panels, etc.
  20. I'd suggest the easiest route would be a different head. It would be a fairly straightforward model change (you don't need to worry about a blaster given he is non-combat) and is also one of the primary methods of distinguishing astromechs in the OT era, which were basically all R2 bodies with different heads. For example:
  21. Chances are with modding that if you think you're done, you're probably not done. A couple of points I didn't address regarding skinned meshes: You can delete elements of a skinned mesh and still retain intact skin weights on the remaining portions. However you can't add new geometry without destroying the weights (basically it all boils down to vert ID numbers). If you want to merge two or more meshes into a single mesh, you'll have to recreate the skin weight data. When butting up two skinned meshes like this, you need to make sure that the weights for each paired vertex are identical, otherwise you'll get bad deformation and see gaps. I skipped over discussing it here because all the verts around the neck hole in the torso are weighted 1.0 to torsoupr_g, as are the bottom row of verts on the collar. But that's something to be mindful of when doing this sort of thing. Similar examples in KOTOR are splinting meshes at the shoulders or wrists (because of the engine's bones-per-mesh limit). If you look at those you'll see they typically try to minimise the number of bones at the split to one or two for simplicity. It's also debatable whether this is the "right" way to approach this problem. There's usually more than one way to skin a cat, as they say, and you could resolve this issue in an alternative manner. The obvious way would be to reshape the existing collars, adding in weighting to the neck_g bone. That would eliminate the need to mate two different meshes together and edit the UVs, but I considered it the more laborious approach for me personally.
  22. OK so here is how I went about the fix. We'll use PFBFS as the example, as the issue is most pronounced in the small models, along with the PFHA01 head. I should also preface this by saying this following is predicated on working in Max. I'm unsure if GMax will support all of it. I know in the past I have said "it's easy, just do XYZ", only to discover GMax doesn't have said ability. To start with, here is a closeup view of the problem areas. The back of the neck is particularly bad in this example, with a large section clipping through right down to the base: There's also the issue at the front with the center front vert clipping past the front of the collar. From the wireframe of the collar, you can see the reason for this is that the front of the collar is pushed inwards, past the front of the neck: As I stated in the previous post, the G model doesn't have the same issues. The collar is shorter and wider, and unlike the F/H models has weighting to the neck_g bone: We can take advantage of this fact and use the G collar to replace the existing F/H collars. So, on to the fix. The first step is to load up the G model and obtain our donor collar. Because of K1's three different sizes, this process will need to be repeated for each of the L, M, and S models, giving you three donor collar meshes, one for each body size. I'll just show the process with the S model, but the steps are identical for each. With the PFBGS ASCII model imported, select the Torso mesh and then Hide Unselected. It helps to hide the texture if those are loaded, and additionally change the object colour from white so it's easier to differentiate meshes in wireframe/edged face modes later on. Change to a side view and swap to a lasso selection mode. Unfold the Editable Mesh modifier in the stack and select the Element sub-mode. Now in the viewport select the collar elements: Switch back to a perspective view and ensure you have it all selected: Now Select Invert and Delete. That should leave the collar by itself: This is probably a good point to rename the mesh from Torso to something more appropriate, like Collar_G_S. Select the Skin modifier in the stack and find the Advanced Parameters section. Under that click the Save button, which will prompt you to choose a location to export an envelope (ENV) file. This file records the skin weights for each vertex in the mesh. We'll need this once we merge the donor collar mesh into the recipient model: Now you can Unhide All and, with the collar mesh selected, Select Invert and Delete. Now the only object in the scene should be the collar mesh. Save this as a Max/GMax file, then do a Reset to create a fresh scene. Import the PFBFS ASCII model. Just like with the G model, select the Torso mesh and hide everything else, disable the texture if necessary and change the object colour. Select the collar elements: The difference is this time we want to delete the collar, like so: Now go to File -> Import -> Merge and select the saved G collar file. In the Merge dialogue that pops up, select the collar mesh and hit OK: Now the collar mesh will be in the scene, although it won't mate cleanly with the hole in the torso: We'll need to do a bit of vertex shuffling to make a seamless join. The first step is to hide most of the torso mesh to make things easier to see. Go into the Polygon sub-mode of the Editable Mesh and select the ring of polys around the neck hole: Now Select Invert and hit Hide under the Selection section of the Polygon rollout: Now there's a minor adjustment to make in the Torso mesh. You'll see the back of the neck clips inside the collar, so we need to drag that out a bit: Select the Torso mesh and go to the Vertex sub-mode of the Editable Mesh. Select these two verts: And move them back past the collar: It is important to only move these verts, and not touch the verts connected to the rest of the torso. With that done, select the collar mesh and go into the Vertex sub-mode of the Editable Mesh. Go to Tools -> Grids and Snaps -> Grids and Snaps Settings and make sure only Vertex is enabled and toggle Snaps on in the toolbar. Now comes the process of selecting each vert around the collar and snapping it to the appropriate vert on the torso. You'll want to have Edged Faces enabled in the view settings to make things easier. Snaps can be finicky, so you may need to make use of Undo a lot until you get the hang of it. Hiding as much unwanted geometry as possible helps a lot here to avoid snapping to the wrong place, as well as making it easier to access verts amidst intersecting geometry. Additionally, because of the mismatched subdivision between the two meshes, the torso will need to have a couple of verts snapped to edges on the collar in order to close all the holes. All this is easier to demonstrate in a video: Now we have the collar cleanly mated to the torso, It's time to load in the skin weights. Unhide All, then with the collar mesh selected, click on the Skin modifier and under Parameters click on the Add button at the top of the Bone list. This will pop up a window of all the objects in the scene. Select the torsoupr_g and neck_g bones: In the Advanced Parameters section, click the Load button and find the ENV file you saved earlier. You'll get a a Load Envelopes window where you can match bones. Because we are using the same names, hitting the Match By Name button should be sufficient (although for future reference, bone names are case sensitive). If you left the original bone list untouched, you'll likely have a long list of extra bones in the Incoming Envelopes column. That's fine, you can safely ignore those. They have no weights as we deleted the rest of the torso mesh they were originally assigned to. Hit the OK button: You can hit the Edit Envelopes button to make sure your weights imported correctly: The final step is to address the texture. Because life is never that easy, each of the F/G/H models have completely different UV mapping, If you assign one of the F textures to the collar, you'll see its a mess: Because of how texture variants work, we'll need to edit the collar's UVs to match the F texture layout. To do that you'll want to check the UVs of the vanilla F collar (I probably should have mentioned that before you deleted it - whoops). It looks like this: Back with the G collar, add an Unwrap UVW modifier above Editable Mesh in the stack. Obviously the existing UVs will not be anywhere close to right: The interior section is pretty easy to fix with some rotation and scaling: The outer ring though will require a bit more finessing. First it will require a Flip Horizontal, then some Scale Horizontal to get it roughly the right width. After that, switch to Vertex mode and shuffle verts until you have something in the ballpark of the original layout: You don't have to try and slavishly copy the original to the pixel. Just get it looking more or less the same. You can see here I actually shifted the front seam (righthand side in the UV window) back a bit compared to the original, as the texture kind of fades out to mush further to the right. Once you are happy with the result, right click on the Unwrap UVW modifier and choose Collapse To. It is important to choose this and not Collapse All, as well as making sure the modifier is underneath the Skin and Trimesh modifiers. Otherwise you'll destroy those. And that is pretty much it. All that remains is to make the collar mesh a child of the base, export, and compile. Then you can test in-game. Edit: One additional step I missed. It's not entirely necessary, given that the G collar seems to work fine, but to be doubly sure you may want to pull the front verts out a little, like so: And here's the final result with the PFHA01 head:
  23. View File Female Armour Collar Fix This mod edits the models for the the female Class 7 (PFBF) and Class 9 (PFBH) armours. Along with Class 8 (PFBG), these three armours all feature a fabric collar. However, in the case of the F and H models this collar lacks any weighting to the neck bone, and due to its shape and height is prone to experiencing clipping of the neck with some head models. As the G armour apparently doesn't appear to suffer these issues, the collar from this armour (with some adjustment) was grafted onto the F/H bodies. The amount of clipping is somewhat variable depending on the head. It also seems far more prevalent on the small body size, but I have provided fixed models for all three body sizes. Compatibility: The UVs of the armours are unchanged, so they are still fully compatible with all vanilla textures and any retexture mods that stick to that layout Obviously the mod will not be compatible with any other mod that replaces the same models Permissions: This is intended as a half enduser mod, half modder's resource. People are free to include this content as part of other mods as long as credit is given. Acknowledgements: Thanks to @ebmar for making me aware of the issue via a screenshot for his Janice Nall mod Thanks to @bead-v for MDLEdit and KOTORMax Submitter DarthParametric Submitted 01/02/2019 Category Mods K1R Compatible Yes