DarthParametric

Yeah there are no cloth dynamics. They do have what they call danglymeshes, which fake movement by vertex displacement, but it's purely a rendering trick. They use if for minor elements like hair. If you want moving clothing though then you'll need to skin it. Depending on the specifics, you may need to use JC's TSL supermodels mod as a dependency so you could use its larger array of bones and supporting animations. Yes. At least tetxure-based alpha transparency. You can use mesh transparency, but that obviously affects the entire mesh, so it's not useful for cutouts like hair planes and the like. In TSL there's an added script function that lets you switch a creature's appearance, which would make this sort of thing more practical, but still extremely clunky. In K1 there's only the scripted disguise route, which is really not advisable because of potential issues disguises can cause.

There are no reflections. There's not even any specular. Just cubemaps, which the game refers to as environment maps or envmaps for short. You create a mask in the alpha channel of the diffuse map which defines what parts of the texture the envmap will affect. Then you specify the use of the envmap in the texture's TXI, which holds various render instructions. The TXI data is included in the texture itself when using Bioware's own texture container variant of DDS, known as TPC for the PC version (TXB for the Xbox), but is a loose text file (with TXI extention, hence the name) when using TGAs. Check out the Sith trooper textures. They are the most extreme example. They original planned on a belt model slot, but that was removed. The only options you have are a body model plus separate head model, or a single full body model. Notionally you can dynamically change appearances using disguises via scripting, but it's not particularly practical, especially for something as minor as what you're suggesting. I'm assuming you want sheathed weapons to hang from the belt? In its UTI, armour is assigned a class, which determines its protection level and what appearance column in appearance.2da it uses. It is also assigned a texture variation number, which determines what texture it will used based on the root texture name assigned in the 2DA. For example, take armour class C. A male player would have three separate appearance rows for the three starting classes, which each get their own model assignment with varying heights. In this case, PMBCS, PMBCM, and PMBCL (small, medium, large, or Smuggler, Scout, Soldier). Each model is then assigned a texture root name, which is typically the same for all three rows, PMBC in this case. For a given UTI using that slot, let's say it specifies texture variation 3. That means the game would assign PMBC03 as the texture. The texture variant value is a single byte, so 256 is the maximum value possible. The vanilla game typically only goes into the high single digits at most. There are no physics. The game doesn't even have collision meshes in the models. It uses extremely basic dynamic cylinder collision which is defined in appearance.2da by the perspace / creperspace columns, which from memory is a radius value from the root of the character. There is no ragdolling or anything like that. Everything uses canned animations.

Yeah your unwrap is just frankly terrible. Distorted and overlapping faces which is stretching a big portion of the grip section. And you also have this chunk of entirely broken UVs for the lights/buttons: As an aside, I'm not sure why you'd you have that ridiculous amount of subdivisions on such tiny mesh chunks given the main body is only a 10 sided cylinder. Frankly, that is exactly what you should do. But I have remapped the UVs and replaced the button meshes in an effort to try and preserve your existing work (well most of it), and generated a new procedural texture for it. I'd suggest that you watch some tutorial videos on how to properly unwrap cylinders for future reference. w_lghtsbr_050.7z

It's hard to really see anything in the pic. You'll need to post the model. I'm guessing it's probably the UV seam where you split the cylinder vertically to unwrap it. If that's the case, it's likely more of a texture issue than a model issue. What did you texture it in?

Yes. The logo is superimposed over the loading screen, so simply deleting the logo texture in the Override will revert it to the vanilla one. No. There are some mods that provide alternative logos, but I'm assuming you're not using any of those since you're complaining about it.

You don't. Odyssey was created before motion vectors were a thing. It also uses OpenGL.

Just delete the logo texture from the Override folder. Should be all you need to do - kotor2logo.tga

You stole my thin header theme!

The forum software has been updated, and it defaulted to the generic theme. You can change to one of two Deadlystream themes by scrolling to the bottom of any page and clicking on the Theme drop-down button on the bottom left.

He doesn't look happy.

Derp. I guess I'm a bit rusty. Too much time modding Owlcat games. I forgot to make the meshes children of the OdysseyBase. K1_Placeable_Severed_Arm_Restumped_Glass.7z K1_Placeable_Severed_Arm_Restumped.7z

I've done it. Do you want the stump still UV'd to fit the vanilla PLC_GenCorpse texture, or expanded take up the full 0:1 UV space since you presumably have a standalone texture? I can do the same with the hand and arm. Resize their UVs and assign them a single custom texture. Edit: I just went ahead and remapped it. Hand, arm, stump all now share one unified custom texture. UV layout guide is included in the attached (using the custom texture name). As for releasing it, go ahead, you know the drill.

Gruesome. But I should really add a few more polys to that stump.

Seems like the stump has some transparency. Also, did I never make a better version of that? It really is terrible.

Seems to be a bit of UV distortion. Those screw heads are stretched horizontally.

Nothing. The game is a quarter of a century old and was designed for a Pentium II Celeron with 64MB of pooled system and video memory. The problems people encounter today are due to poor OpenGL support in their shitty drivers (i.e. AMD), not being overtaxed by added textures. The bigger issue is you probably won't notice any difference with or without a normal map, so they are mostly a waste of time. They used it sparingly because there was a limit to what they could fit in the Xbox's aforementioned pocket calculator-sized memory. And its presence in the first place was likely a legacy of Aurora/NWN. The engine doesn't accept normal maps in TGA format, so back in the old days it simply wasn't possible to make use of them. Additionally, even if you have a correct texture the relevant mesh/es in the model need a flag set for it, which wasn't exposed in the old modding tools. As to why more recent mods don't make use of them, some do. But like I said, it's mostly a waste of time because you can't even tell.

You use the normal as a normal. Odyssey's normal implementation is pretty crap though. The source has to be de-swizzled and the Y (green) channel flipped because TOR is DirectX (-Y) and Odyssey is OpenGL (+Y). Odyssey doesn't have specular, so you're stuck with using envmaps. For stuff like clothes or anything else that gets tinted, you can bake the colour into the diffuse via the Blender plugin. Refer to the wiki on the SWTOR Slicers Github page for details.

The circles are on the edge of their assigned UVs. The easiest thing would be to adjust the textures. Altering the UVs means editing the model. Edit: Assuming they are using the vanilla UVs, they are weird: So say your texture is 1024 x 1024. You'd actually want to draw it inside an area of 1024 x ~922. If you're working in PS or some other program with guides, just set a guide a horizontal guide at 90% and stay above that.

Going to go out on a limb here and suggest that this is your problem...

Like a lot of other things in the game, the answer is via scripting. For vanilla modules, typically this is done in concert with the module's GIT file, which has provision for a day music track and a night music track (a leftover from Neverwinter Nights). This is linked to an row ID in ambientmusic.2da which points to the music track that loops in the background. Using scripting, you can start/stop the current music and switch it to a different track. For example, in K1 when you encounter Malak in the Leviathan Hanger, the trigger script switches the module from its default music, track 11 (mus_area_sewers), to track 8 (mus_theme_malak): https://github.com/KOTORCommunityPatches/Vanilla_KOTOR_Script_Source/blob/master/K1/Modules/M40AC_Leviathan_Hangar_lev_m40ac/k_plev_malakmov2.nss#L5 Or in TSL, for the introduction of Nihilus, it switches from track 8 (mus_sith) to 4 (mus_nihilus ) https://github.com/KOTORCommunityPatches/Vanilla_KOTOR_Script_Source/tree/master/TSL/TSLRCM/Modules/852NIH_Ravager_Bridge/a_nih_intro.nss Or this script in TSLRCM, which switches the Ebon Hawk's default track to the romance track (mus_s_romance) which they added to their version of ambientmusic.2da: https://github.com/KOTORCommunityPatches/Vanilla_KOTOR_Script_Source/blob/master/TSL/TSLRCM/Modules/006EBO_Ebon_Hawk_(post-Dantooine)/a_006romance.nss At the end of your conversion, you can add another script to the exit node of the DLG which stops the new music track, switches it back to the original one, then sets that to play. Typically any time you need to know how to do something, there's a vanilla example you can crib from.

Jesus. I don't remember that being a thing.