DarthParametric

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.

It's all just transparency. All the envmap is doing is underlaying the diffuse. That's why you can only have one or the other. Either you have pure transparency, or you have an envmap. Like I said, if you want a transparent visor and the rest of the headgear shiny, that will require 2 separate textures. You cannot do both in a single texture.

The problem is that Bioware's envmap system is a piss-poor way to fake specular and reflections. It's never going to look good, especially in comparison to modern graphics, no matter how much you tweak it. It's cheap from a GPU/memory overhead standpoint, which is why they went with it. My suggestion would be to minimise the use of it wherever possible, and just accept that you will generally never get anything that looks remotely like a real reflective surface, outside of a few edge cases. One thing you could try is using some of the custom envmaps by Darth_Sapiens and/or try making your own. The vanilla ones are all pretty garbage. Regarding transparency and envmaps, you can't do both with a single map, seeing as both utilise the alpha channel. If you want shiny bits on your verpine visor, you'll need to break the visor out to its own separate texture (which could be tiny, like 64x64, seeing as it would just be a solid RGB colour and a solid alpha).

Save two copies of an RGB image out, one without RLE, the other with RLE, and attach them. Doesn't have to be anything fancy. Just some 256x256 images with blocks of a couple of colours is sufficient. Regarding alpha channels, what are you trying to do? A transparency mask should be fairly straightforward. Are you having trouble with an envmap mask?

PS doesn't handle DDS natively, but even with the nVidia DDS plugin it's of no use for KOTOR, as Bioware rolled their own custom implementation. You need this tool - http://deadlystream.com/forum/topic/3709-bioware-tga-to-dds-converter/ You need a TGA input for that, you just have to figure out how to get Gimp to export in the required format. Does the export/save dialogue for TGA in Gimp have any options for RLE compression? In that other thread I mentioned it seemed like the TGA in question was type 10, which has RLE. PS TGAs are type 2, with no compression.

It's quite possible to implement a wall trophy model in the EH as a placeable spawned by a script. In order to only get it to spawn after a quest though, you'd presumably have to use a plot flag or something. Someone more knowledgeable about scripts would have to chime in about the feasibility of that.

You don't require anything special for PS. It natively outputs in the correct format. There was some discussion of Gimp's odd ways with TGAs here - http://deadlystream.com/forum/topic/3726-help-installing-texture-mods

Open the UTI in the KOTOR Tools Item Editor, go to the Properties tab, add a new property, in the property editor window that pops up, choose a property type, for example bonus damage, set any other variables as appropriate (like subtype, value, etc.), then in the "upgrade required to activate" section, choose the appropriate weapon mod from the drop-down list.

A hat, with the XCOM logo on it, on a smiley face.

Yeah, and you did a great job on that. It probably doesn't warrant too much more attention to be honest, given what a minor element in the game it is. You'd be better off spending your time on something more prominent. Most particularly the big panels with giant cylinders in them on either side, but also the large red blocks on on the center console.

I was going to offer a better globe animation, like this: but it doesn't really work with an even number of frames. My 2c regarding the overall look of it is that I'm not super big on the giant Duplo button look. I guess that was kind of a necessity a decade ago dealing with tiny 256x256 textures and low poly counts to run on a console with less horsepower than a pocket calculator, but I don't see any need to be limited by that for mods today. Even if you want to go with a retro 70s vibe to keep it in the OT style, I'd still prefer to see a proper keyboard/keypad along with a more realistic array of switches and dials. Something along the lines of this kind of thing: http://image.shutterstock.com/z/stock-photo-thermo-electric-power-station-console-14977411.jpg http://www.smartinsights.com/wp-content/uploads/2013/01/Ishikawa-diagram-marketing.png http://www.projectfellowship.com/wp-content/uploads/2013/11/Fukushima-Daiichi-Nuclear-Power-Plant-Disaster-Reactor-Room.jpg http://www.mapps.l-3com.com/photo_gallery/pg_Fermi02.jpg

You shouldn't need an external app. The game can cap screenshots itself. Just add EnableScreenShot=1 under [Game Options] in swkotor2.ini, then use the PrtScrn button in-game. It should dump TGAs in the game directory. I'd suggest swapping the texture on the back of the lower section, with the rectangular grille looking bits, to the front side. It looks better IMO.

No. It's in the ASCII MDL. Just edit it in a text editor. In Max/GMax you can just edit it in the Aurora Trimesh modifier before exporting, but I gather there is no equivalent for Blender users.

Glow/emissive is defined in the trimesh semantics. In the ASCII MDL, use selfillumcolor to set the colour of the glow. For example: selfillumcolor 0.862745 0.0 0.729412is equivalent to a glow of RGB 220,0,186 (pinkish-purple). Typically though the way you do it is control colour entirely via the texture, and set the selfillumcolor to a greyscale value that just controls intensity. So somewhere between a 0.5 0.5 0.5 for a mid-grey to 1.0 1.0 1.0 for pure white.

Peeking under Quanon's skirt, the standalone helmet is just a standard mask. Only the full body model is a disguise.

KOTOR has no provision to remove/hide head models for a helmet (hence why there are no equipable helmets in the base game). You'll just have to live with the clipping. You could maybe try going the disguise route, but I don't know how that would play with the body models, or if you can even add that modifier to headgear. You'd need 6 variants of it, one for each race/sex combo.

Pff, not specific enough. How about "Coming Christmas 2023: Sleheyron". Lines up perfectly with K1's 20th anniversary.

The Override directory takes precedence. You obviously can't use it though for any resources that don't have a unique filename, which is a common problem in TSL especially. I think the MOD is required to have all the RIM's contents. I don't think it can just have selected elements.