DarthParametric

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.

It already uses patched TSLRCM dialog.tlk and 2DAs, so there's no compatibility problem using the approach I specified (hence why I specified it). Per the OP's Reddit post - https://www.reddit.com/r/kotor/comments/4637jl/kotor_2_how_would_you_go_about_turning_a_workshop/ - the mod in question can be located here: http://steamcommunity.com/sharedfiles/filedetails/?id=489204257 http://www.nexusmods.com/kotor2/mods/57 The author is TamerBill.

Based on the mods listed in your Reddit post (you should link them here btw), it looks like the Steam version has an additional 10 or so rows it is adding to dialog.tlk, above the 36 ones the Nexus version adds. It also looks like the scripts have changed. I decompiled them and had a look, and it seems like the shared ones are pretty much the same, but obviously the compiled ones have hardcoded values for 2DA references while the Nexus version uses memory tokens. It would be a pain in the ass to try and rejig those for a TSLPatcher install. If the author won't update to the Nexus, the most logical approach is to start from a fresh install with TSLRCM from the Workshop, subscribe to the mod in question on the Workshop, back up a copy of its Workshop folder somewhere then unsubscribe from it. Copy and paste the contents of it over the top of TSLRCM's Workshop folder. Then do all your other manual/TSLPatcher mod installs over the top of that.

Same thing. Open the UTI in KOTOR Tool, go the Properties tab, select/highlight the row you want to get rid of, hit the delete key. Save out the UTI. If you want to add in a new additional property, double click the little asterisk and it will pop up the property selection window the same as when editing an existing row.

In KOTOR Tool. Open the UTI, go to the Properties tab, double click on the Defense Bonus property, in the new window that pops up, make the changes I described above, click the Update button, then save it. Here's a UTI I edited for you, if you want to try testing it in-game: http://dpmods.wheb.org/files/kotor/misc/g_a_class4004.uti

Ah yeah, the base item is defense 4. You could try editing the Defense Bonus property and changing the type to "Decreased DB", set the sub-type to "DB Armor", and the value to "Penalty -1".

Just edit the UTI (g_a_class4004.uti) in KOTOR Tool. In the Properties tab, edit the Defense Bonus property and change the value from 2 to 3. Save it out to a file.

This should really be in the (newly minted) requests sub-forum. Perhaps a mod can move it. I guess someone did. I decided to take a crack at it. Got the basic shape roughed out, sans the little squiggly bits at the bottom of the metal emitter shroud: I'm not too sure yet how the emitter will go with the blade planes. I might have made it a bit too narrow. Will have to test it I guess.

I think the Revenge of Revan mod managed it, didn't they? Presumably they managed to compile a new model with a replacement character. Perhaps Logan23 or redrob41 could chime in with some specifics. The mod has its own sub-forum here. Maybe you could ask in the "Ask the Developer of Revenge of Revan....a Question" thread. http://deadlystream.com/forum/forum/5-revenge-of-revan/

SpartanG087: How about this one? http://www.gamefront.com/files/5533293/Revan_Mask_for_both_KOTOR_and_TSL

Not necessarily. Some mods still in circulation pre-date the existence of TSLPatcher.

http://www.gamefront.com/files/13259422/PC_Republic__2_0_ http://www.gamefront.com/files/10883020/Republic_Helmet http://www.gamefront.com/files/13325868/K1_Republic_Admiral_Uniforms_mod http://www.gamefront.com/files/10724822/Republic_Armour http://www.gamefront.com/files/12903189/Republic_Clothing http://www.gamefront.com/files/10623576/Party_Republic_Officers

That doesn't look like a retexture, it looks like a custom model. It looks a bit Mass Effect-ish to me. I was going to say it might be one of InyriForge's, but I can't see anything that looks like that.

I can make some (not all), but I'd need some specifics. I don't really have enough imagination to come up with designs by myself.