DarthParametric

This belongs in the request forum. Apparently ninja moderators are amongst us, lurking in the shadows. All the Gamefront-hosted mods are still available. Can't find what the mirrored KF link to Gamefront was, so that leaves the Nexus harvested version - http://www.nexusmods.com/kotor/mods/144

The problem is the easiest way to discover offsets for various information is via compiling slightly different versions of a single ASCII model with MDLOps and comparing them, but MDLOps adds some confusion into the mix because of the way it works. For example, look at this test model compiled with MDLOps: The self-illum values are no longer the final bytes of the Controller Data chunk like there were in the above example, instead they are before a (presumed) blank/buffer block and the alpha value. Now for the game this doesn't pose a problem, as the model itself specifies what values can be found at what offsets within the file. But for people blindly hex editing, lack of consistency becomes a serious pain in the ass. It's difficult to make a tutorial saying "do XYZ", because in many situations that may not apply. In other words, the above example is less "here's how you do this" as much as "here's what I did for this specific model". What would be really useful (albeit almost certainly never going to happen) would be some sort of built-in hex editing functionality for the MDLOps Data Viewer. If it identified/labelled select values for a given mesh like self-illum, ambient/diffuse, etc. and 0-1 flags like render, shadow, etc. and let you change their values and save out a new file, that would be great. But like I said, I doubt that is likely to ever happen.

The texture itself is irrelevant, inasmuch as self-illumination is controlled by the mesh. KOTOR only supports one texture per mesh, so level models comprise a whole bunch of separate meshes. In order to change the self-illum for those lights, you need to find the MDL for that particular room/chunk of the level, decompile it, open it up in Max/GMax, and find the mesh/meshes that you need to edit. In this case, the model in question would appear to be 151HAR08. For that room there are two meshes that comprise all the light sections. The ones that consists of the strips between the seats and one doorway offscreen in that pic (the second doorway is part of the adjoining MDL) and already has self-illum enabled is named HAR08_LITE_01. Interestingly, the second mesh that comprises the strips on the ceiling, under the windows, and at either end of the seats is also named HAR08_LITE_01, which is pretty atypical. It does actually have some self-illum, but the colour (which determines intensity) is set at a grey of 80,80,80, instead of the white 255,255,255 like the other mesh. If we compare the two meshes in the ASCII MDL, we can see the first mesh has: selfillumcolor 1 1 1 and the second mesh has something like: selfillumcolor 0.313726007938385 0.313726007938385 0.313726007938385 Now that we know what we are looking for, we need to extract a copy of the original MDL/MDX and open it up in MDLOps. Hit the Read button, then the View Data button. Expand the Nodes tree to expose the meshes. Normally your mesh (or meshes) would have a unique name, but in this instance we know from the hierarchy that the mesh we are interested in the second one of that name in the list. So scroll down until you get to the second instance of HAR08_LITE_01 (node #18 in this case) and expand it, like so: The last 12 bytes of the Controller Data chunk represents the self-illum (0.313726007938385 0.313726007938385 0.313726007938385) values: In this case, it equates to a hex value of B2A0A03E B2A0A03E B2A0A03E. If we check the other light mesh (node #15), we can see its self-illum value, 1 1 1, which is what we want to replicate: Which equates to a hex value of 0000803F 0000803F 0000803F. Now we can open up 151har08.mdl in a hex editor, and search for the hex string B2A0A03EB2A0A03EB2A0A03E. In this example it's easy, as there is only a single instance: It's a simple matter of replacing those bytes with the string 0000803F0000803F0000803F: In other cases it may not be so simple. For example if you search for 0000803F0000803F0000803F, you'll find 32 instances in that MDL. So for cases like that, you may need to include surrounding bytes in your search until you find a unique example. In this case, you might use the entire Controller Data chunk, seeing as it is pretty short. For the first light mesh, that would be 00000000 AA102FBE 2558E83F AE47A13F 00000000 00000000 00000000 00000000 0000803F 00000000 0000803F 00000000 0000803F 00000000 0000803F 0000803F 0000803F In this case there are two instances of that chunk, but it is fairly easy to spot the one we want by the surrounding bytes. For instance the preceding 64000000 FFFF0100 0D000E00 036EC501, which is the last 16 bytes of the Controllers chunk: So there you go, a crash course in hex editing for fun and profit. Here's the hex edited model from the example - http://dpmods.wheb.org/files/kotor/tsl/[TSL]_151HAR08_Self-Illum_Edit.7z

Those specific meshes in the level model would need their self-illum values hex edited.

You need to edit portraits.2da. That's the one that controls head textures.

It doesn't affect the textures. All it does is edit the model to change the render flag from 1 to 0 for the four meshes that make up the end platform. They are still there, they just aren't being rendered by the engine. It won't have any affect on the rest of the game.

Here, extract this into your Override and see what happens: http://dpmods.wheb.org/files/kotor/k1/[K1]_Manaan_Speeder_Track_MDL_Edit.7z

Nothing practical I would think. For one thing the textures are generic Manaan ones, (middle strip is LMG_Manwall09, side strips are LMG_Manfloor01, railings are LMG_Manwall15) so you'd have to hex edit the level model to use unique texture names to avoid causing issues elsewhere in that and other Manaan levels. For another, presumably any other textures are going to be similarly affected. It could be a GPU/driver issue perhaps. Do you know if it looks like this for everyone? I don't think I've ever bothered with the swoop races beyond the required one on Taris, so I have no personal experience of it. You could maybe try editing the model to raise the platform slightly so the water is no longer above it, but my previous attempts at that sort of thing haven't gone so hot, so maybe someone more familiar with level editing can chime in. One possibility might be just hiding the platform center sections altogether. That is easy enough to do with a simple hex edit, switching the mesh render flag.

I don't think the problem is the platform texture per se, it's the fact that there are multiple water planes that overlay and clip through the surface of the pad. Observe: Presumably the texture semantics that allow for the water effect have an adverse influence on anything they overlay.

For the dead Bioware link, use this - https://web.archive.org/web/20070209092240/http://nwn.bioware.com/developers/

Ah, so it is more of a MDLOps issue then, unsurprisingly. Scale could be useful for placeables, given they are static. I'd suspect it wouldn't be so great for animated meshes like characters (I'd have though Bioware would have just used that instead of having small/medium/large bodies if it worked).

Porting discussion lockdown in 3, 2, 1....

Maybe not great news for anyone that just started playing in the last week or two, but if you are planning on playing SWTOR, you might want to hold off for a few more days: http://www.swtor.com/dark-vs-light/ Basically you get rewards for every new character you create and level to 50 (and above for higher tiers) after the event starts on June 28. More info here: http://www.swtor.com/blog/dark-vs.-light-event-and-rewards-blog and here: http://swtorista.com/articles/swtor-dark-vs-light-event-list/ It kinda sucks for anyone who has already levelled all the classes, especially multiple times, but it's probably a great time to be someone new to the game.

I tried playing around with some trimesh options and comparing the compiled results. Test model was a simple cube trimesh (8 verts, 12 faces, 24 tverts) and an AuroraBase. Here's what I found. "scale" - Float. Default is 1.0. Changing it yielded no result. Compiled models were identical regardless. "transparencyhint" - Int. Default is 0. Changing it yielded no result. Compiled models were identical regardless. "alpha" - Float. Default is 1.0. 2 Bytes. http://dpimages.wheb.org/KOTOR_MDL_Test_01_Alpha.jpg "render" - Int., 0 or 1. Default is 1. 1 Byte (?). 1 = 256. ID'd in CChargin's data table (common mesh header, although # is different) http://dpimages.wheb.org/KOTOR_MDL_Test_02_Render.jpg "shadow" - Int., 0 or 1. Default is 0. 1 Byte (?).. 1 = 256. ID'd in CChargin's data table (common mesh header, although # is different) http://dpimages.wheb.org/KOTOR_MDL_Test_03_Shadow.jpg "rotatetexture" - Int., 0 or 1. Default is 0. Changing it yielded no result. Compiled models were identical regardless. "beaming" - Int., 0 or 1. Default is 0. Changing it yielded no result. Compiled models were identical regardless. "inheritcolor" - Int., 0 or 1. Default is 0. Changing it yielded no result. Compiled models were identical regardless. "tilefade" - Int. Appears it has 4 set values. 0 for "not a cap", 1 for "fadable, 2 for "base", 4 for "neighbour". Default is 0. Changing it yielded no result. Compiled models were identical regardless. I assume all those values that did nothing are redundant Aurora options that NWMax spits out. Or at the very least MDLOps just ignores them.

My HK model references the original HK model as the supermodel. It's not compatible with the melee mod because that mod changes the base HK model to a skinned mesh using the Wookiee rig and the standard Human animations. There's no way to "make" it compatible without replicating the same trick, and I have zero interest in doing so.

I have a bunch of characters on the US west coast server Harbinger. I also have few (mostly/all Republic I think) low to mid level chars on the EU RP server Progenitor, but as I mentioned in a reply to LiliArch's status I haven't really looked at them since launch.

Could you use a script to destroy the character at the end of the conversation and then spawn in a new non-interactive character that uses the same appearance?

For placeables it should just be the "usable" and "party interact" checkboxes in the advanced tab I think. I'm not sure about characters.

I assume even Obsidian couldn't resolve it, as there seems no reason otherwise to set it up as a full body model.

This is the animation sync issue I mentioned when setting up the hooded outfit as a standard body model, if anyone was curious: Interestingly you can see at the end that it just pops into sync (it had actually been out of sync for a minute or two prior). It also syncs if you move or otherwise undertake an animation besides the idle.

View File Handmaiden with Long Hair This mod is a head edit for the Handmaiden that gives her shoulder-length hair. It started life as part of experiments in aid of this request thread - http://deadlystream.com/forum/topic/4335-handmaiden-appearance/ The hair mesh is a transplant from Kreia, with the braids chopped off. In order to accommodate DS transitions, which requires the face and hair to share a single texture, the UVs for both meshes were compressed 50% horizontally to fit side-by-side within 0 to 1 UV space. The Handmaiden and Kreia textures were then combined into a single 1024x512 texture. The versions bundled with the installer are DDS, but I have provided the TGA sources as an additional download for those that may wish to undertake retextures. Additionally, the clothes models for Handmaiden’s hooded outfit have been modified. The vanilla bodies include the head mesh as part of the model (i.e. functionally speaking it is basically a disguise). Based on my experiments with removing the head and setting it up like a normal body model, it seems that there is an animation synchronisation issue that crops up between the head and the hood, which may be why Obsidian went the full body route. This mod changes the hood outfit models to use the new long haired head mesh. The hood has been enlarged to fit the Handmaiden's new larger hair mesh. Hopefully I've cured the most prominent clipping issues, but possibly in some extreme combat animations some might still occur. This mod doesn't alter the portraits, so should be compatible with any custom portrait mods. It uses custom model and texture names, so it should be unaffected by simple overrides, like retextures. However, it won't be compatible with any mods that alter the Handmaiden's appearance.2da or heads.2da entries. Submitter DarthParametric Submitted 06/21/2016 Category Mods TSLRCM Compatible  

It would take a bit of reworking. The "Sleeping Beauty" body doesn't even come close to having the proper neckline.

Yeah it's not just a retexture, it's basically a different face. The mesh has undergone some changes in the DS version, adding in additional polys, the vert positions for the nose/mouth/chin are altered quite significantly, and the UV map is completely different.