DarthParametric

There's nothing really unique to droids (mine or any others) that requires a specific tutorial. Any general texturing practices would apply, bearing in mind that you are texturing hard edged metal/plastic surfaces rather than skin/clothing for characters. As for 3D programs, if all you need is a model to visualise how textures are applied then an OBJ would be sufficient, and usable in pretty much any 3D app. I may make OBJs and UV templates available for texturers once modelling is finalised.

You can edit 2DAs and UTCs, can't you?

One design thing? There's a common body, but six different heads. The plan is for the T7 head version to replace T3-M4, the new T3 head version to replace 3C-FD, and then the other four head variants will be used for whatever various generic background astromechs there are in the games.

Well it really is the work of years, technically. The T7 body/head, protocol droid, and autotrooper were all modelled back in 2014/2015. I abandoned further work on them at the time because of issues compiling working models, detailed in the original, now defunct, Lucasforums thread.. All I have done recently is UV map the protocol droid, fix some map issues on the autotrooper, and model the variant astromech heads (as well as revise/redo the game-ready setup/export).

I figured I'd go with one final astromech head variant: I think I'll bestow that on 3C-FD as a nod to the original design. T3 was a given of course, as is 3C-FD. I guess that leaves T1-N1 as the only non-party member that engages in combat. I'll have to make sure he gets a head with a functional blaster.

I should start charging. Get the Bandon right arm for the introductory price of just $2.95*! Then each month expand your collection with a new and different appendage! *Regular price $15.95 per issue.

Here, try this gthegenerous and see if you can spot any issues: http://dpmods.wheb.org/files/kotor/tsl/VP_Female_Exile_PFHC06_Fix.7z There's still a small seam at the base of the ears to the start of the jawline, but that's as good as it is going to get for the moment. Shadows fixed as well. If it looks ok then maybe VP can replace the model in his current version with this one. It requires a pentagram and an artefact to bind your soul to, but I ran out of sacrificial goats before I could work out the kinks.

If VP allows it, I think I have a fix for it. Perhaps we can summon him to this thread with the appropriate rituals.

Ah, my apologies. I was looking at it in the bit just after you emerge from the kolto tank, and it would seem the softer lighting there masks it. Shoving her head directly under a light makes it obvious.

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?