DarthParametric

That is present in Max/GMax because of the way MDLOps splits meshes along UV boundaries. It would appear though that in-game it is fine (presumably any changes VP made were done with Tainia's replacer specifically for that reason). While you can fix it in Max/Gmax, it requires welding both the relevant tex verts along the UV seam/s and welding the mesh verts along the same seam/s. This will destroy all skin weights. What does need fixing is the shadows. He has shadows enabled for a few of the hair danglymeshes, which gives some wild tentacle shadow action, and the head bone has its shadow flag disabled, so there's a hole in shadow where the head should be. Easy enough to rectify with some hex editing.

You don't have to pay for a Nexus account.

If someone is able to skin them and texture them, then sure.

As is my way, I'm jumping between a bunch of different projects, doing bits and pieces as the mood strikes me. I've made two (Edit: now three four) of the alternative astromech heads: Edit 2: Also revised the round flat head one to add some more detail. In hindsight that was a poor choice of location for screenshots. I should really make a test module or something with decent lighting. Btw does anyone have a full list of significant astromechs in either game? Specifically ones that engage in combat. I know in TSL there is that one in the Czerka mainframe on Citadel Station that goes berserk. Any others? Because of the way the animations work, I need make a specific combat model (although I can probably just link the bullethook to the front of that gun looking bit on the top of the flathead one and ignore the animated bits).

So in essence what you are suggesting is to first make some sort of generic/universal hook, allowing 3rd party scripts to access that functionality without needing to directly edit the OnEnter scripts themselves? Is it possible to make something flexible enough that it would have much application outside of the menu idea? Yes, like so: Although I will say there are quite a few problems with that model in terms of skin weights. I had to skin wrap the vanilla mesh to generate new weights for the torso and arms because the original couldn't handle the level of deformation in the arms crossed animation. Given the way it is set up, I wonder if it wouldn't just be better to make a hybrid version that reverts to the original arms and torso and just adds on Deadman's skirt and pauldron. Also, something I never noticed before - Sion is floating about a foot off the ground in that menu. You just can't see it because of the fog. Maybe he looked too short otherwise.

Menu #1 will have to be a catch-all for Peragus, Telos, the Ebon Hawk, Malachor, etc. Maybe some of those edge cases will need OnEnter modifications, I'm not sure. I'll probably need someone else to do the heavy lifting on the scripting side of things. I am way out of my depth with this stuff. Yeah if you just wanted a replacement for the vanilla Sion menu it would be easy enough. You just have to edit mainmenu01 - delete the old Sion meshes, import the new Sion model and skin it to the rig, export. Seems like there are no permissions issues to worry about, just credit required for Deadman and Sapiens.

So every OnEnter script? That's like 80-odd scripts. Doesn't seem particularly practical, especially if you take into account having to double the work in order to make TSLRCM and non-TSLRCM versions. That's k_sup_galaxymap I believe? Btw, I noticed this in k_inc_hawk, the include for k_sup_galaxymap I figured it might be possible to slip in the menu swapping code into the main body of k_sup_galaxymap just after this: void main() { int nSelected = GetSelectedPlanet(); int nPrevPlanet = GetCurrentPlanet(); And take advantage of it already finding the planet you are on, which is what Fair Strides suggested earlier (which I kind of missed at the time).

So you'd still have to edit k_align_movie anyway, right? If for no other reason than to excise the menu swapping bit. Although I suppose it would be overridden soon enough if you have some other script constantly checking the module you're in.

I was aiming at the planet you are currently on. You are on Dantooine, show the Dantooine menu. You are on Nar Shaddaa, show the Nar Shaddaa menu, etc.

What does GetModule() return? An int or a string?

Wouldn't that only tell you if the player had ever been to that module, rather than if they were there right now?

Based on JCarter's snippert, I was going to suggest something like this: But I gather it won't be that simple then?

*Casts lesser thread necromancy* So I've been playing around with menu editing, like so: With completely custom menus an option in the near future, I was wondering how practical it would be to swap the TSL menus around based on planet/location rather than Sith Lord. I was looking at the vanilla and TSLRCM versions of k_align_movie, which seems to be where which menu is shown is determined. The initial bit of the vanilla script which checks if the player has left Telos (seems like it is unused?) gave me the idea: check what module the player is in, then set the GBL_MAIN_SITH_LORD value based on that. I know that KSE shows a "last module" value, so is that stored in such a way that it is readable via script? Assuming so, from all available locations you'd have to choose just 5, which we know is the hard coded limit. That's pretty restrictive, so you'd have to do some two-for-ones, screens that cover more than one location/theme. My thoughts are: Background: Peragus/Telos Character/s: T3? Kreia? Atton? HK-50? Sion? Atris? Handmaiden? Background: Nar Shaddaa Character/s: Zez-Kai Ell? Mira? Hanharr? Goto (hologram version)? Background: Dantooine (lots of flying manta ray things!) Character/s: Vrook? Disciple? Azkul? Background: Onderon/Dxun Character/s: Kavar? Mandalore? Vaklu vs Talia? Background: Korriban Character/s: Sion I know it is kind of odd to exclude Malachor V (especially as that was what I was playing with above), but something has to get the chop when 5 locations is all you have to work with. I'm also not sure where you'd put Nihilus or Traya in any of those. I assume the addition of the player is hard coded to some degree as well (in terms of specific menu number, animation, etc.). If so, that might also take them off the table as a possibility.

It's not a mod, it's a modder's resource. Someone needs to make a robe mod first, then this will be included or a dependency.

The N_DarthRevan UVs are trash. There are a whole bunch of faces that fly off 100s of tiles outside 0-1 space. So if you are getting weirdness, that's why. The PxBJ robes have some degenerate polys outside 0-1 space, but they are hidden so it's not a big deal. Although on closer inspection, the fingers are a complete mess... And of course there are overlaps galore, so yeah, another example of quality work by Bioware. Here are the UV templates: https://www.darthparametric.com/files/kotor/misc/PxBJ_Revan_UV_Templates.7z

If I may paraphrase Private First Class William L. Hudson, raster graphics follow the linear process of an express elevator to hell, going down. If you are starting with KOTOR textures as your basis, you are already in the sub-basement, and there's no real way back up.

View File Bao-Dur Head Model Neck Fix This is a modder's resource that adjusts the position of Bao-Dur's neck vertices so that they match the standard position of other heads. Bao-Dur's vanilla head will "float" if attached to standard bodies. This adjustment ensures the base of his neck will seat properly with the collars of standard body models, which is a necessity for potential future mods like Bao-Dur specific robes. 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 06/01/2017 Category Modder's Resources

http://deadlystream.com/forum/topic/5441-downloadbao-dur-head-model-neck-fix/

Also, be aware that some things are not resolvable simply by creating a bigger texture. Blasters, for example, all have irredeemable UV maps. No amount of retexturing will fix their inherent issue. The only practical solution is to re-map the models (or given how terrible the vanilla models are, just make entirely new ones, as per Toasty Fresh and Sithspecter).