DarthParametric

Here you go: https://www.darthparametric.com/files/kotor/misc/Onderon_Freighters.7z I scaled them down to about 10% of their original size, as they were huge.

The Rodian is a single body mesh with some unique animations, so you'd most likely want to scale medium and large meshes down to fit it, rather than trying to go the other way. The small body size was already the right scale so struck me as being much less of a pain in the ass. For the medium body though, a quick mockup would suggest something in the order of 95% would be about the right scale: It's a vest though, not a jacket, so I don't see that it is more appropriate than the small body.

If you want the jacket look but the vanilla body isn't working out for you, it seems like you could probably hijack the PMBBS body (assuming this is K1, although I think they did keep the scaled class clothes meshes in TSL). Lop off the hands and it would only need some minor repositioning of the forearms to align with the weirdly bowed Rodian arms (and its giant hands). Like so:

Kreia uses a unique stunt appearance with a cut animation in that scene as I recall. Anything that screws with her appearance.2da entries may cause it to bug out.

Nice. Who knew you could add an appearance.2da row to heads.2da. Now I want to see it in a conversation.

You can click on the little "ignore this warning" in the bottom right corner to still download the file. But obviously ignoring malware warnings is not something I'd recommend people be doing blindly.

You're getting this, or something similar I assume: It would seem the domain has been added to a blacklist for serving up PUPs/adware/malware.

Not sure how many more I'll do. Originally I only planned on hilts for Bastila, Malak, and Jolee, although I figured I'd throw in a bonus one or two.

Kexikus expressed an interest in a wooden saber, so I figured the Redeemer from SWTOR, AKA Master Orgus Din's saber would be worth a shot: Half timber, half metal, with some sort of plates on one side of the emitter. Defensive measure perhaps? As before, double, single, and short hilt variants.

It could be values for normal, binormal, and tangent. You can extract the values via Maxscript. You probably need to do some experiments with some simple shapes and see if you can figure out the order. Edit: If you want to use this simple pyramid mesh as a test - http://dpmods.wheb.org/files/kotor/misc/TEST_PYRAMID_ASCII.mdl - you can try the following values: Although I'm not 100% sure they are correct, but assuming you can get it compile and load without something exploding, we can progress to more complex shapes with shared normals across edge breaks/UV boundaries.

I don't think you have that level of granularity. You could presumably drop the SFX volume down to zero to knock them out, but that would kill everything else like weapon sounds, etc.

Malak's saber, per the canon reference: http://starwars.wikia.com/wiki/Darth_Malak's_lightsaber Once again, in single, double, and short versions: Edit: And base texture awaiting in-game env map:

First cab off the rank is the saber of Sith Holocron's latest squeeze Bastila This is based on the apparently canon appearance (which is just a gussied up version of the game model): Original source Wookieepedia - http://starwars.wikia.com/wiki/Bastila_Shan's_lightsaber As per Kexikus' directive, this comes in single and short hilt flavours, as well as the Bastila-specific double. Edit: And here's the base texture, ready for some env map shininess:

The Jolee's robe for TSL mod I did went the disguise for every head route, including companions. If you had an NPC or other dialogue way to get it, you could presumably script it.

Need to unwrap and texture it first. I'll upload it once it is done. Edit: Here we go. Download: https://www.darthparametric.com/files/kotor/k1/[K1]_Gungi_Saber.7z

Not modified meshes, no. Simple retextures for the original Sion mesh would be fine though. Nope, this sort of thing is completely outside my wheelhouse. I simply learned to bludgeon my way through certain elements of it out of shear necessity, trying to overcome issues with MDLOps, my mortal enemy.

You can ignore the 0x, that's just the designator that tells you that it is in hex. So take your 4 byte value, 3DA0A0A2, and split it into single byte chunks, 3D A0 A0 A2. Now reverse the order, A0 A0 A2 3D. Minor rounding error causes some differences, but the issue is endianness. This is where someone that actually knows what they are talking about has to step in and explain it to you.

Don't directly put files in the Override that you don't have to, particularly 2DAs. Use TSLPatcher and memory tokens which will allow you to add your content to existing files.

WARNING: Wall of text incoming. So, following on from part 1 (that I managed to post in the wrong thread, whoops), let us now delve even further into the dank underbelly of MDL hex editing. Finding and changing ASCII strings like textures is pretty basic. To change numerical values for things like the colour of VFX involves a few extra steps. Start by loading the binary MDL into MDLOps and clicking the Read button. When that is done, hit the View Data button. A new window will pop up. You probably want to maximise it to see everything. This is the model data viewer. It gives you a tree view of the model structure, and shows hex chunks for each element along with the specific values for each type of data. Expand the "nodes", well, node I guess. What we are interested in here is the smoke VFX. Based on the names, we can tell that we want to look at the four Fx_PuffySand nodes. Expand "Fx_PuffySand" -> "node_header" and select "controller_data". You'll see the righthand side of the screen populate with that node's data: The middle two windows are the binary data in hex and ASCII, and the far right window is a list of the source values for each particular block of data. You may want to refer to the breakdown of the MDL structure by original MDLOps author Chuck Chargin - https://web.archive.org/web/20151016191416/https://home.comcast.net/~cchargin/kotor/mdl_info.html - but don't worry too much if that's all over your head at the moment. Save it for later use. The important thing to note is that each chunk of data is of a certain length, which varies depending on the format it is stored in. If you recognise certain chunks of data, knowing how long they are may help you find where the specific chunk you are looking for is (you did your homework from the last lesson and Googled hex offsets, right?). At this juncture, it is most likely useful to refer to the decompiled ASCII model. If you find the section starting with "node emitter Fx_PuffySand" and compare it to the data viewer's righthand window, you'll be able to match some of the values and work out what is what. The first four bytes are empty/zero, the next 12 bytes are the position (XYZ) values, then another four bytes of zero value, then the next 16 bytes are orientation (XYZW quaternion). Here we run into one of the vagaries of MDLOps: the decompiled ASCII data doesn't match the binary data. If you spend any time with MDLOps, you'll be seeing this sort of thing a lot. In this instance though it isn't relevant to what we are doing, so we can ignore. Skim over the other values. There are lots of zeros, so we can't tell a lot of these apart. But you can see things like particle rotation, random velocity, and bounce coefficient. But what we are really interested in is colorStart, colorMid, and colorEnd. These are in a Vector3, basically RGB converted to 0-1 values. Fortunately in this case the data is in a convenient format to spot. ColorStart is 0.058823499828577,0.058823499828577,0.058823499828577. We can see three blocks of 12 bytes with repeating 4 byte segments. The first of these is E9F0703D which is equivalent to a float value of 0.0588235 (depending on how many figures you round to), the same as colorStart. Similarly we can confirm that A9D8D83D and CFBC3C3E match colorMid and colorEnd, respectively. So it seems that these are our colour values: Given that the values we are looking for are altogether in a contiguous 48 byte chunk (including 12 bytes of zero value padding): E9F0703D E9F0703D E9F0703D 00000000 A9D8D83D A9D8D83D A9D8D83D 00000000 CFBC3C3E CFBC3C3E CFBC3C3E 00000000 We can note this down as a single string to search for later in a hex editor, like so: E9F0703DE9F0703DE9F0703D00000000A9D8D83DA9D8D83DA9D8D83D00000000CFBC3C3ECFBC3C3ECFBC3C3E00000000 The reason we want that as a single string is that the bigger the chunk, the less likely it is that there will be matching data anywhere else in the file. We only want to edit these specific values, not accidentally overwrite something we shouldn't. Additionally, as you may have guessed from both the repeated values and the actual colour of the smoke in the menu, these are greyscale colours. We'll be using actual colour in this example, which means varying values. It's easier to replace it all in a single find and replace string, and it makes it less likely you'll make errors. We can now continue on with the other Fx_PuffySand nodes, noting their particular hex strings of interest. Fx_PuffySand01 is straightforward: with the string: CFBC3C3ECFBC3C3ECFBC3C3E00000000CFBC3C3ECFBC3C3ECFBC3C3E00000000C7C8C83DC7C8C83DC7C8C83D00000000 Fx_PuffySand02 has zero data values for colorStart and colorMid, but that's not a problem. We can determine from the other nodes that the data chunk we want is located at the same offset, plus it's simply a case of setting the first 32 bytes to zero. Which gives us: 0000000000000000000000000000000000000000000000000000000000000000D0B4343ED0B4343ED0B4343E00000000 And lastly Fx_PuffySand03: Which has zero values for colorStart: 00000000000000000000000000000000838A8A3E838A8A3E838A8A3E00000000D5CD4D3FD5CD4D3FD5CD4D3F00000000 So now we have the info we need from MDLOps, we can move across to the hex editor. But before we do that, we need to work out what colours we want to change the VFX to, and how to convert that into hex. We have four VFX emitters, so I'll choose four different colours just so the differences are obvious. While we are on the subject of colours, you will have noticed that each emitter has three sets of colours, start, middle, and end. This allows for the overall colour to change across the different stages of particle life. Start is when the particle is first emitted, mid during the middle of its lifetime, and end just before extinction. For smoke, you'd typically want the beginning to be dark, then gradually lighten in the mid and end phases before it fades out completely. If you look at the vanilla values, you'll see that's what they do. They start out almost black, then lighten to a mid- to dark grey. The colour is offset by the transparency, but more on that later. So, colour. For Fx_PuffySand colorStart the colour is 0.058823499828577,0.058823499828577,0.058823499828577. To convert this to a typical RGB value, we simply multiply each value by 255. In this instance the values are the same, and multiplying it by 255 gives 14.99999245628714, in other words an RGB of (near as damned) 15,15,15 which is almost black. Using this approach we can also go back the other way. Simply divide all your RGB values by 255. Let's start with a new set of colours for Fx_PuffySand. We'll go with 20,60,100 to begin, 30,100,155 in the midlife, and 50,150,250 at the end. That goes from a dark blue to a light blue. If we divide by 255 we get our Vector3s: 20,60,100 0.07843138,0.2352941,0.3921569 30,100,155 0.117647059,0.3921569,0.6078432 50,150,250 0.196078431,0.588235294,0.980392 Now we just need to convert those values into hex. All hex editors should have a base convert or calculator that will convert between different formats. You want to go from a float to a little endian hex value. You should be also able to Google an online hex converter if needed. So converting those values gives us: A1A0A03D F1F0703E C9C8C83E F1F0F03D C9C8C83E 9C9B1B3F ACC8483E 9296163F F8FA7A3F Which means with the 12 bytes of zero padding we get the following string: A1A0A03DF1F0703EC9C8C83E00000000F1F0F03DC9C8C83E9C9B1B3F00000000ACC8483E9296163FF8FA7A3F00000000 In the hex editor, if we search the MDL for the original string for Fx_PuffySand that we noted earlier, we find only a single instance, which is good. We can now replace that with the new string we just created. Doing so and loading up the editing menu in the game gives the following: Success, albeit perhaps a tad bright (I forgot to take into account transparency). Now let's do the same with Fx_PuffySand01. 50,10,10 0.196078431,0.039215686,0.039215686 140,28,28 0.549019608,0.109803922,0.109803922 250,54,54 0.980392157,0.211764706,0.211764706 C9C8483E A1A0203D A1A0203D 8D8C0C3F E1E0E03D E1E0E03D FBFA7A3F D9D8583E D9D8583E C9C8483EA1A0203DA1A0203D000000008D8C0C3FE1E0E03DE1E0E03D00000000FBFA7A3FD9D8583ED9D8583E00000000 Which gives: Fx_PuffySand02: 5,35,5 0.019607843,0.137254902,0.019607843 18,107,18 0.070588235,0.419607843,0.070588235 29,184,29 0.11372549,0.721568627,0.11372549 A1A0A03C 8D8C0C3E A1A0A03C 9190903D D7D6D63E 9190903D E9E8E83D B9B8383F E9E8E83D A1A0A03C8D8C0C3EA1A0A03C000000009190903DD7D6D63E9190903D00000000E9E8E83DB9B8383FE9E8E83D00000000 Which gives: And finally, Fx_PuffySand03: 35,10,55 0.137254902,0.039215686,0.215686275 85,25,130 0.333333333,0.098039216,0.509803922 135,40,205 0.529411765,0.156862745,0.803921569 Which gives: A thing of beauty. I'm surprised Obsidian didn't go with that colour scheme. Regarding transparency, I haven't played with it myself, but it looks to be the alphaMid value. That would seem to correspond to value 052 in the data viewer. Figuring out how to change that on your own will be a good learning experience.

Like I said above, the original textures are named P_KreiaA and P_KreiaH. You have to rename them to KreiaJediRbe and KreiaJediFce to keep the same number of characters. Well you can name them whatever you want, as long as the character length matches. As to how I know certain stuff, I'm certainly no font of all knowledge. But modding is no different to learning anything else. Read, watch, practice, ask questions, experiment - all the usual trial and error stuff. Work out what you want to do, search for information, ask if anyone can point you in the right direction. Sometimes you'll get a blow-by-blow account, other times you'll have to just start poking and see what happens. Eventually you'll figure out what works and what doesn't, what you can do and what you need help with. And when you see someone ask "how do I do X?" and you know how to do X, you pass the information along. And thus the modding circle is complete, young Padawan.

What editor you use doesn't matter so much. There are a gazillion around. I'm sure someone can chime in with suggestions on a decent free one. As to the editing itself, if you want to use the Kreia menu, open up mainmenu04.mdl in a hex editor and use whatever search tools it has to find the textures. As a shortcut, if you do a quick .decompile with MDLOps, you'll get a text file with all the textures listed. We know that the ones were are interested in are P_KreiaEvilH and P_KreiaEvilA. So do a search for those text strings. In this case we find 5 instances of P_KreiaEvilA and 8 instances of P_KreiaEvilH. Now in this example it is easy, all of those a just texture references. But in some instances there may be full or partial strings shared between textures and other elements like meshes and so forth, which can require manually picking out which ones to change. But in this case a simple Find and Replace function will do the trick. Now as I mentioned above, a crucial element of hex editing is to keep your replacement strings to the exact number of characters. If you don't, Bad Things™ will happen. Google "hex offsets" to learn why. Anyway, in this case both our text strings have 12 characters each, so we need two unique 12 character strings to replace them. Like so: P_KreiaEvilH = KreiaJediFce P_KreiaEvilA = KreiaJediRbe Now punch those into a Find and Replace function, Replace All, and you are done. Save it out and grab the MDX, then make copies that you rename to all the menu model variants (01 to 06) and put them in the Override folder. Now go find the neutral Kreia textures, P_KreiaA and P_KreiaH, and rename them to KreiaJediRbe and KreiaJediFce respectively. Put those in the Override as well. Then start it up, you should go from this: to this: Now you also want the smoke colour changed, right? That's a tad more tricky. You'll have to wait for part 2.

The whole point of a sub-forum was to stop single mega threads. Everyone should make a separate thread per request.

Changing references in the ASCII model is fine, but that's only of any use if you can actually compile it into a working binary model. My feelings on it probably amount to "good luck with that". Hence why I suggested hex editing. You are replacing the references in the vanilla binary model, so you don't have to deal with the vagaries of MDLOps. That's why I'm curious myself as to what they did for Revenge of Revan. Compiling a working animated model with VFX seems highly unlikely (assuming they actually have an animated character and VFX - I've only seen a small, blurry screenshot). I figured they might have used a script-based approach and hijacked the way the DS endgame shows the player character.

If you want to make changes like that, you'd be far better off just hex editing the original binary model. Trying to use MDLOps is a road to nowhere (other than Frustrationville). And as Kexikus alludes to, you'll want to use a custom name for your retexture. Just make sure to keep the same number of characters as the one you are replacing though if hex editing.

Based on the earlier mention of only possibly using TSLPatcher for a final release, I would guess this is all just dumped straight into the Override.