DarthParametric

Being a continuation/reboot of a formerly failed endeavour. -------------------- Edit: Now that they have finally broken cover, I can say very special thanks to bead-v for KOTORmax and MDLedit, without which getting these models into the game would not be possible, and ndix UR for TGA2TPC, which allows for the creation of functional tangent space normal maps.

Yeah I changed the tags to my custom ones. Here's the script (source is modified from the Star Forge one posted above):

Seeing as you have to wait until the end of the game to get the robes normally, I figured I'd explore an alternative to just telling people to use KSE, especially given that there are 90 UTIs for females. I've never messed around with dialogues or cameras before, so it took a bit of head scratching to figure things out. It went smoother than expected, but sweet Jesus cameras are a pain in the ass to position. I took the setup from the scripts that spawn the robes on the Star Forge, posted above. However I am not getting the VFX to generate on the cylinder. The Star Forge version has a white glowy effect, then a red shield effect. I'm assuming it is not finding my placeable to attach the VFX to for some reason.

Ahah! Success: Interestingly, GetFirstPC() is what I had when I was first muddling out a solution, cobbled together from various code snippets.

I ended up going with individual S/M/L models, so there is just a single appearance ID per iteration. int int1 = GetAppearanceType(OBJECT_SELF); // Get the PC's appearance if (int1 == 91) { // If P_FEM_A_SML_01 string1 = "DP_RevRobe_FA1S"; } else if (int1 == 92) { // If P_FEM_A_MED_01 string1 = "DP_RevRobe_FA1M"; } else if (int1 == 93) { // If P_FEM_A_LRG_01 string1 = "DP_RevRobe_FA1L"; }

I'd already changed that before compiling the test version. The two different types are 14 and 15 characters, so that shouldn't be the issue.

So I'm in the process of testing and it seems like the game is reading my scripts and works as intended for a male player, but when I tried editing the save to change to a female, it seems like it didn't register the changed sex. I still got the vanilla item (I confirmed this by editing the script and changing the UTI, it's the last one in the script, intended for males). I'm not sure if this is a problem with the save, or a problem with the script. I can't find any Star Forge saves for a "real" female character to confirm, but surely if I edited the gender flag and appearance value, that should be enough?

View File K1 Thigh-High Boots For Female Twi'lek Body (Modder's Resource) Here's another bit of scrap from my junk pile that someone may find a use for. A little while back I made some thigh-high boots for Bastila when Quanon was working on her Taris prisoner outfit. He didn't end up using them, so I tossed them into the abyss with my other rejects. The other day I was looking at the female Twi'lek body models for some reason, and I noticed that (the base version at least) has painted on thigh-high boots. On a whim, I imported my boot mesh and noted that, height-wise, they lined up almost perfectly. Even more interestingly, my UVs were very close in layout to the Twi'lek's legs, so much so that is was fairly trivial to rejig them to fit the existing textures. In practice I'm not sure how much purpose this serves, as from a distance it's basically impossible to tell the difference between painted on boots and my physically modelled boots, at least using vanilla textures, but I figured someone might find some use for it. Because the vanilla female Twi'lek model has existing animations (dancing), I have provided a hex edited copy of the original which is now used as the supermodel. That way the booted variant is a simple Override drop-in with no 2DA editing required. I have also provided some additional versions suitable for use as player bodies that use the regular S_Female03 supermodel, as well as being scaled to large, medium, and small. I've supplied modified versions for those variation textures that don't have boot textures. There is also an optional variant of the base green variation which has black boots instead of red. The intent of course, given how terrible the vanilla textures are, is that someone will release a proper high quality retextured version, but the NPC portion is useable out of the box if people so desire. You are free to incorporate the contents of this mod into your own work, as long as proper credit is provided. Do not redistribute the mod by itself. Submitter DarthParametric Submitted 05/19/2017 Category Modder's Resources  

View File TSL Thigh-High Boots For Female Twi'lek Body (Modder's Resource) Here's another bit of scrap from my junk pile that someone may find a use for. A little while back I made some thigh-high boots for Bastila when Quanon was working on her Taris prisoner outfit. He didn't end up using them, so I tossed them into the abyss with my other rejects. The other day I was looking at the female Twi'lek body models for some reason, and I noticed that (the base version at least) has painted on thigh-high boots. On a whim, I imported my boot mesh and noted that, height-wise, they lined up almost perfectly. Even more interestingly, my UVs were very close in layout to the Twi'lek's legs, so much so that is was fairly trivial to rejig them to fit the existing textures. In practice I'm not sure how much purpose this serves, as from a distance it's basically impossible to tell the difference between painted on boots and my physically modelled boots, at least using vanilla textures, but I figured someone might find some use for it. Because the vanilla female Twi'lek model has existing animations (dancing), I have provided a hex edited copy of the original which is now used as the supermodel. That way the booted variant is a simple Override drop-in with no 2DA editing required. Also included is a booted version of the Twi'lek assassin body. Additionally, I have also provided a version suitable for use as a player body that uses the regular S_Female03 supermodel. I've supplied modified versions for those variation textures that don't have existing boot textures. There is also an optional variant of the base green variation which has black boots instead of red. The intent of course, given how terrible the vanilla textures are, is that someone will release a proper high quality retextured version, but the NPC portion is useable out of the box if people so desire. You are free to incorporate the contents of this mod into your own work, as long as proper credit is provided. Do not redistribute the mod by itself. As a side note for anyone using this directly rather than as a modder's resource, I would highly recommend the use of the optional alternate texture from RedRob41's Luxa Hair Fix mod. What can I say? I like hotpants. Only use the texture, mind, not the meshes. Submitter DarthParametric Submitted 05/19/2017 Category Modder's Resources  

Mission Vao Player's Head (Modder's Resource) View File This is something I fished out of my junk pile that I thought someone may find a use for. It is Mission's head model that has had the UVs adjusted to fit her face and lekku onto a single texture (because I am lazy, just her face and body texture side-by-side). This allows for DS transitions, which is not possible with the vanilla Mission head because it uses two different textures. The model is supplied with placeholder textures (colour shifted to test DS transitions), temp portraits, and a full TSLPatcher setup. All it needs is some new textures/portraits and it is ready to go. The revised version includes an optional head mesh with the lekku UVs scaled to make better use of the available UV space, including revised placeholder texture. UV templates are now included for both versions. Submitter DarthParametric Submitted 05/17/2017 Category Modder's Resources  

Whoops. That was an oversight on my part. I only did a cursory check. I thought the illuminated meshes were laying over the top, so didn't notice the gaps. Sorry about that. To fix it, we have to tackle it a different way. We'll need to edit the keyframe data for the animations to stop the self-illumination cycling. Start by decompiling the M12AA_01F model and open the ASCII output in a text editor. Search for the term "newanim" and you'll be taken down to the bottom of the file where the animation data is. Browsing through it, there are 11 meshes with animated self-illum, Mesh118, Mesh117, Object178, Object179, Object180, Object181, Object182, Object183, Mesh27, Mesh30, and Object189 (all children of dummy object M12AA_01FA). Looking at the model in Max, we can ignore Object189 as that is a light strip. There's also an AuroraLight with keyed colour, which we don't need to worry about. Of the 10 remaining meshes, there's the five in the center holoprojector I covered in the previous post, and the rest are scattered around the walls of the room. I assume that you will also want to edit these this time. The base static control panel meshes have their self-illum set to white, so we'll need to edit these blinking meshes so they have their self-illum always set to white as well. Open the binary model in the MDLOps data viewer. This time, we'll be looking in a different section, under Animations. If you expand the "animloop1" node, then under "nodes" you'll find the data for the individual objects: If we refer back to the ASCII file, we'll see the keyframe data for the first object, Mesh118: node dummy Mesh118 parent M12aa_01fa selfillumcolorkey 0 1 1 1 0.300000011920929 0 0 0 0.633333027362823 1 1 1 0.933332979679108 0 0 0 1.2333300113678 1 1 1 1.5 0 0 0 1.7666699886322 1 1 1 2 0 0 0 2.29999995231628 1 1 1 2.59999990463257 0 0 0 2.93333005905151 1 1 1 3.2666699886322 1 1 1 endlist endnode What we see here are 12 keyframes that are switching the value for self-illum between black (0 0 0) and white (1 1 1), which is how you get the lights blinking on and off. If we expand the node for Mesh118 in the Data Viewer and select "controllerdata" we see the following: In the right panel we can see it's pretty obvious our keyframe data comprises the values from 012 to 047. Looking at the hex, it's clear that 1 1 1 is 00 00 80 3F 00 00 80 3F 00 00 80 3F and 0 0 0 is 00 00 00 00 00 00 00 00 00 00 00 00. If we do a search for the entire keyframe chunk in a hex editor: 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F we only find a single instance: So we can replace it with data to change every keyframe to 1 1 1, like so: 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F Mesh117 only has two keyframes, so we need to search for the entire controller data chunk: 00 00 00 00 1F 11 51 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F Which again we find a single instance of, right below the chunk we just edited: We can replace that with: 00 00 00 00 1F 11 51 40 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F Repeat for the remaining objects. For Object178 you'll want to add the hex values from the "controllers" chunk as well to give you enough to work with. Note that this is identical to the data for Object180, so you can replace both in one go. Here are the search and replace hex chunks: It should be noted that you may end up with a bit of a halo around these meshes by virtue of the fact that they are physically separate. There's not really anything you can do about that without physically altering the meshes themselves. Hopefully it is less noticeable with a proper texture, but it might be problematic with a pale/light colour.

I think he would greatly benefit from a Sean Connery-style chest beard.

First you will need to find the model for the central lounge section of the Ebon Hawk. In this instance I already know it is M12AA_01F. You need to extract the binary model, the MDL/MDX pair, somewhere. Don't convert it to ASCII. Run MDLOps, hit "Select file" and browse to the MDL, set the type to Kotor 1, hit the "Read model" button, then when the output window shows that is complete, hit the "View data" button: You will be presented with a multi panel window (you probably want to maximise it so you can see what you are doing) that shows the model structure on the left, the hex data in the center, and the actual values in decimal on the right. Expand the "nodes" sub-section on the left to see all the individual child objects: We already established previously by looking at the model in Max that the meshes we are interested in are named Mesh27, Mesh30, Mesh117, Mesh118, and Object181, so find those in the list: Now if you expand one of those, let's start with first in the list Mesh118, and click on "subhead", you'll see some data populate the center and righthand panels. Scroll down to the bottom of the righthand panel. I know from past experience that the value for an enabled render flag is 256, which we can see towards the bottom there. For more info on the structure of a model, check out Chuck Chargin's model data table. Now this particular instance is easy, because that is the only value of 256 present. However, the shadow flag also has a value of 256 when enabled, but in this case shadows are disabled, so we don't have to worry about that. But for the record, the render flag should be after the shadow flag. With the target value identified, we need to find the hex value for it so that we can change the value. If you look on the righthand panel, you can see there are five values that follow the render flag value: 0, 0.0199781320989132, 0, 848320, 701705. If we look at the last 4 bytes of data, we see that is 09 B5 0A 00. If we convert that to an integer, we get 162859520, which obviously doesn't correspond to anything. However, KOTOR models are in little endian byte order. Basically what that means is for a 4 byte chunk ABCD, the data is actually stored backwards as DCBA. That means in this case we reverse our chunk to 00 0A B5 09. If you convert this to an integer you get 701705, which is the last value listed in the righthand panel. We can continue working backwards in this manner. 848320 is the 4 bytes C0 F1 0C 00 (00 0C F1 C0), 0 is 4 bytes 00 00 00 00. When we get to 0.0199781320989132, we need to deal with a float rather than an integer, so need a different converter (here's one). This is the 4 bytes 2E A9 A3 3C (3C A3 A9 2E). Now we have the 4 bytes 00 01 00 00, which we know from the righthand panel must comprise two values, our render flag 256 and 0. A conversion tells us 256 in hex is 01 00, which if we reverse is 00 01. So we know the first 2 bytes of that 00 01 00 00 chunk is our render flag. Now we can't just search for a 2 byte chunk 00 01 in a hex editor, there are over 2,700 instances of that in this file. We need that unqiue instance, so we include the surrounding bytes. If we search for the string 00 01 00 00 2E A9 A3 3C 00 00 00 00 C0 F1 0C 00 09 B5 0A 00 then we find a single instance. If we compare the preceeding bytes, we can see they also match what we see in the MDLOps data viewer. Knowing that, we can do a search and replace. We replace 00 01 00 00 2E A9 A3 3C 00 00 00 00 C0 F1 0C 00 09 B5 0A 00 with 00 00 00 00 2E A9 A3 3C 00 00 00 00 C0 F1 0C 00 09 B5 0A 00 which will change the render flag from 00 01 to 00 00, thus setting it to off. Now you just need to do that for all four remaining meshes. To save you some time, here are the search and replace strings you need: Mesh117: 00 01 E6 3D 6A 08 AF 3C 00 00 00 00 80 FD 0C 00 AB C1 0A 00 00 00 E6 3D 6A 08 AF 3C 00 00 00 00 80 FD 0C 00 AB C1 0A 00 Object181: 00 01 00 00 43 F3 2B 3C 00 00 00 00 60 10 0D 00 A9 D7 0A 00 00 00 00 00 43 F3 2B 3C 00 00 00 00 60 10 0D 00 A9 D7 0A 00 Mesh27: 00 01 36 00 1A 7D E5 3C 00 00 00 00 80 21 0D 00 CF EF 0A 00 00 00 36 00 1A 7D E5 3C 00 00 00 00 80 21 0D 00 CF EF 0A 00 Mesh30: 00 01 00 00 2D 7A D4 3C 00 00 00 00 C0 26 0D 00 BB F6 0A 00 00 00 00 00 2D 7A D4 3C 00 00 00 00 C0 26 0D 00 BB F6 0A 00 With all the edits done, you should get something like this:

You should ask a moderator to split this thread, as all this animation stuff is off-topic. It would be more visible as its own thread. To answer your question, I don't know.

The animation is literally called "stealth". It can be found in S_Male02 (i.e. it is shared by both sexes).

A supermodel is the model that another model draws its animations from. For example, player models draw their animations from a chained series of supermodels with various shared and unique male/female animations. When the game tells the model to play a specific animation, it checks if that animation is included in the model, if not then it looks at the specified supermodel and checks it for the animation (and further on, if it also references a supermodel itself, like for players). "Super" in this sense just means "above", referring to the fact that the model with the animations is higher up the chain in terms of priority. The original C_Terentatek model has unique animations. For the scaled versions I just imported geometry only, scaled up the scene, changed the name of the AuroraBase, changed the animation scale value to match the world scale change, and then changed the supermodel from null to C_Terentatek. Thus the scaled versions have no inherent animations themselves, they rely on the original model for those.

The squares are additional meshes with animated self-illum. The two main side panel meshes are hologlow01 and hologril01, with the top panel main mesh being mcholmach02. You then have 5 other meshes spread across the panels: Mesh27, Mesh30, Mesh117, Mesh118, Object181. They all share the same texture, LEH_scre02, they just have their self-illum values keyed to cycle between black and white. For example: node dummy Mesh27 parent M12aa_01fa selfillumcolorkey 0 0 0 0 0.266667008399963 1 1 1 0.533333003520966 0 0 0 0.766667008399963 1 1 1 1.03332996368408 0 0 0 1.29999995231628 1 1 1 1.56666994094849 0 0 0 1.79999995231628 1 1 1 2.09999990463257 0 0 0 2.40000009536743 1 1 1 2.70000004768372 0 0 0 2.96667003631592 1 1 1 3.2666699886322 0 0 0 endlist endnodeYour problem isn't a texture issue, it's a mesh issue. You'll need to hex edit all the relevant level models and set the render flags for those 5 meshes to 0.

It's telling that what they have shown is mostly just environment stuff. A trained monkey can make props and level models (I should know, that's what I did in the aforementioned project). The real challenge is in gameplay: combat mechanics, scripting, AI, conversations/dialogue, UI, etc.

Just to clarify, they use the original model as the supermodel, so you'll need an appearance.2da edit even if you want to replace the regular sized version (i.e. don't try changing the name of these models to C_Terentatek, point appearance.2da to these new models).

The eyes use the face texture. Any mod that alters the eyes would be incompatible with any other face texture mod.

Here you go. I did some quick tests and they seemed OK. If you want to have them in addition to the original sized version, you'll need to add some appearance.2da rows for them and edit UTCs as appropriate. https://www.darthparametric.com/files/kotor/k1/[K1]_Terentatek_Resized.7z