DarthParametric

I think a hybrid with "evil Kreia" would look a lot better:

That Darth Atris sure is wacky looking. I wonder who thought that funny hat was a good idea?

Wouldn't the holobook things be better off going red?

It would be more apparent if you pointed out (for those that don't check the original source) that the comments are by Dark0ne, the owner and founder of the Nexus. I said when the news of the GameFront archiving was first announced that I was extremely surprised for exactly this reason, that it seemed to fly directly in the face of prior public statements by Dark0ne regarding mod author rights and respect thereof. I found this statement particularly amusing: Now granted, Nexus isn't an official site, but Jesus, that's the exact same problem they have with their stupid GameFront archiving. Also, as an aside, I am #9 on his list.

You seem to change avatars more often than I change pants. Looking at the girlies there, I am again reminded of how much better their 1st/intermediate DS transition faces look (sans veins). I wonder if I should make some sort of emo/goth girl mod.

There is no rigging/skinning required, unless you are planning on using a skinned mesh. The droids all typically drive the trimeshes directly. Obviously you'll need to keep the same number of meshes, with the same names, and same pivots. Regarding animations, you'll typically want to use a custom model name, export without animation, and reference the original model as the super model.

No need for an external app. Just add the following to your registry: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\GWX] "DisableGWX"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\OSUpgrade] "AllowOSUpgrade"=dword:00000000 "ReservationsAllowed"=dword:00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "DisableOSUpgrade"=dword:00000001 Also, concerning updates, there are a whole raft of them to block. But be aware that MS is routinely re-enabling them and changing their KB number in order to obfuscate them, so you'll want to manually check the corresponding KB notes for each one before approving.

It was a completely custom series of meshes, with only the helper objects from the original T3-M4 model remaining. It wasn't the character classification issue, but whatever the root cause was the camera issue sounds like it was the same. As to other droids, HK will work as a basis for new meshes. Protocol droids are a bust. I think Max, like most 3D apps, only outputs 4 sig figures anyway, so anything beyond that is probably worthless. Something else that might be worth stealing from KAurora, if possible, would be its support for emitters.

Fair Strides is the KAurora source keymaster. I'm not sure whether you'll be able to get access to it though. Presumably Magnus would have open sourced it from the get-go (or at least after dropping it) if he intended to grant access to all and sundry.

I never really understood the holographic book thing. Surely they would just have holocrons for ancient/traditional stuff, then computer terminals for everything else.

I probably wouldn't get too excited about NWN2 stuff. While Odyssey derived from Aurora (NWN1) and there is a lot of legacy crossover, Electron (NWN2) saw some pretty marked changes under the hood by Obsidian. I'm not sure much there is of relevance to Odyssey games.

Yeah it's a freaking mess. At current count there are 929 mods for K1 and 827 mods for TSL uploaded by "GameFrontArchiver" (over 60,000 files across all games). At least once you gain control you can actually delete them outright, which is a relief. But there is a bunch of stuff there that will never get claimed that should never have been uploaded. As you said, broken/outdated/duplicate versions.

Depends on what you mean. It should be possible to transplant any of the standard body models based on my experience so far. If you are talking about retexturing, that sort of thing is outside my wheelhouse. At this point I'd say even just sticking with the vanilla textures would be a big improvement in terms of diversity. You could always just focus on finishing off the head retextures to get it released, then worry about body retextures as a supplemental download at a later date.

Jesus, what a pain in the ass. They didn't even do some basic checks to look for pre-existing uploads or authors. Now I not only have to manually claim all this crap (and via email, they could have at least made a form), I have to try and delete or hide the duplicates. I wish they had just kept their mitts off it.

Didn't JCarter have some sort of test level? I recall redrob41 talking about it.

I've had a hell of a time with script-based ones in the past. See, for example, my misadventures in trying to get the Lobot-style cyborg head guy to lay on the freaking bed at the start of TSL in said head's WIP thread. Although that one doesn't count I guess, being a character. I did have plenty of trouble with actual placeables though, like the G-Wing shuttle, when messing about with that replacement I-Wing model. Can't say I have ever done that. I didn't even know that was a thing. I have gone the GIT/MOD route before for release-candidate stuff, but typically find scripting useful to iteratively adjust positions. So it was my imagination then. Hrmm. Perhaps I was misremembering based on the conversation with Canderous. Edit: Regarding spawn positions, it looks like these might be useful starting points. Upper City: 60.00, 95.00, 0.0 Undercity: 318.00, 250.00, 2.5 You'll have to experiment with the rotation angle, as it will depend on how you oriented the mesh.

The issue I've had in the past with collision is that placeables respect collision the same as a player would, so trying to spawn one in right on top of some collision will result in it shifting to one side. It's probably not a big issue for the Upper City one, as it's just a static bit of scenery, so it doesn't matter if it moves a bit. Bastila's though I seem to recall has a cutscene that shows the capsule is empty. I could be mistaken, but if that is the case then it could be more problematic. Edit: OK, it turns out Bastila's pod wasn't too difficult to check. Loading a save right before Mission joins was sufficient. I didn't get a cutscene or even any journal update on approaching it though, so maybe I was imagining things? It seems like this is purely set dressing as well. Here's the hex edited level model: https://www.darthparametric.com/files/kotor/k1/[K1]_m04aa_04f_Invisible_Capsule.7z

I played around with removing the original capsule from the level for a while. I tried a few different mesh alterations, bashing my head against all the usual MDLOps issues, and not fairing any better with KAurora or Taina's Replacer. Then I hit on a much simpler solution. Simply change the capsule mesh's render flag from 1 to 0. It's a simple single byte hex edit. Observe: Now you see it. Now you don't. Here's the edited level model if you want to check it out for yourself: https://www.darthparametric.com/files/kotor/k1/[K1]_m02ac_02b_Invisible_Capsule.7z Note you'll need a save before entering the area for the first time. If needs be, check out ChAiNz.2da's collection of Taris saves for one right outside the door before the first transition to that area (Tar-UpperCity1st). I haven't edited the model for the Undercity level with Bastila's capsule yet, as that is way more of a pain in the ass to test. Also, I suspect that the collision mesh may prove problematic when trying to spawn in the new capsule as a placeable. I've had problems with that before.

Interesting. That camera issue sounds pretty much exactly like the problem I encountered (one of several anyway) with a custom astromech model. When combat was initiated, the camera would zoom into the middle of the mesh. Curiously, that model was compiled with KAurora, and was set as a character model (plus on Windows, so presumably no case issues).

Looks like the player's escape pod in Upper City and Bastila's pod in Undercity both use the same mesh, albeit both are part of their respective level models. Screwing with level models is kind of dicey IMO, to be avoided unless absolutely necessary. You could try editing the original texture and use the alpha to make it transparent, then spawn your new model as a placeable over the top of it. I'm not sure how well that would work out, but it would probably be advisable to start with that at least, and only contemplate physically altering the level model if that fails.

I posted OBJs of the 3 freighter models from the battle above Onderon for someone else a few months back. That included the KT-400 it would seem: https://www.darthparametric.com/files/kotor/misc/Onderon_Freighters.7z

Most ships are meshes within various level models.

The verpine headband visor mesh has a trimesh alpha value of 0.7. Here are the changes, going left to right, from a texture alpha channel colour of black, mid-grey (127,127,127), and white (diffuse colour was changed from red to green to confirm it was the right texture): It seems to me like it is affecting the diffuse more than the actual level of transparency. All normal meshes have a trimesh alpha of 1. My understanding is that a saber's blade shenanigans is mostly from the texture semantics. Blending additive is presumably the culprit with black issues. Although the blade glow is presumably from a special shader. It doesn't use the trimesh self-illumination. For TSL at least, only two mask models have meshes with a non-1 alpha: I_Mask_005 (Bothan Sensory Visor) trimesh Object02 - alpha 0.920000016689301 I_Mask_011 (Verpine Headband) trimesh Mesh02 - alpha 0.699999988079071 I haven't decompiled the K1 models, but I don't think TSL made any changes to the masks/goggles. Notionally there shouldn't be any faked reflection if there is no TXI specifying an envmap. I wonder if it is being forced elsewhere? I couldn't see anything obvious in baseitems.2da. That would explain why they need to force transparency via the trimesh though. There is both a shininess and specular value. I don't know if anything actually uses them. Possibly water meshes?

Ahah, I see why. I've never noticed this before, but they set the alpha in the trimesh. Sneaky, sneaky. So in the case of something like the verpine haadband: node trimesh Mesh02 parent VerpineHeadBand position 0 0 0 orientation 0 0 0 0 scale 1 alpha 0.699999988079071 selfillumcolor 0 0 0 diffuse 1 1 1 ambient 1 1 1 render 1 shadow 0 specular 0.000000 0.000000 0.000000 shininess 0.000000 wirecolor 1 1 1 bitmap I_VerpHBndNotice the "alpha" value. So even if you remove the alpha channel of the texture altogether, the visor will still be transparent. I guess this means you can have both transparency and an envmap in a single texture, at least on a per-mesh chunk basis.