Kexikus

Yeah, that's most likely their self-illumination or lightmap, i.e. their environmental lighting affecting the way things look like ingame. On top of that, each renderer (e.g. KotOR or your texture editor) will show things slightly different anyway. You could get around that by changing the model but that's usually not a good idea as many objects/placeables are reused in different places where they have different environment lighting attached to blend in and if you removed that they'd stick out like a sore thumb in those areas that you didn't explicitly texture them for as they'd all use your one texture.

More progress: I finished modeling and texturing the backdrop buildings for Manaan that are seen from the hangar and in some parts of the city. I still need to render them properly, i.e. with a better alpha channel than the one seen on the following picture, but apart from that they're done. The sky in the background is taken straight from my original HD skybox release. That's not quite final but it will stay mostly the same apart from being rendered directly at the full resolution. As I mentioned before, I still need to render this with a proper alpha channel so that I don't have to add the alpha channel manually in Photoshop. That's easy when doing a standard render with one camera, but here I need to do a cylindrical render. For that I use the "Panorama Exporter" but that doesn't seem to generate an alpha channel. Even if I tick "Save Alpha channel" (or whatever the option is called) when saving the render to a texture, the alpha channel will just be full opacity. Any ideas on what I'm doing wrong here? Or any suggestions on how to get the alpha channel with a cylindrical render? Edit: Found the solution. Applying the "WarpAround" shader to the lens produces a spherical render that's close enough to a cylindrical render for me to use it. Also, another question. As was discussed before, the skybox textures in both KotOR games are cut off at their edges and also often don't have the horizon in the right place. For my original skyboxes, I just fixed that by stretching the texture but that obviously causes a loss in quality, so this time, I decided to edit the models instead. For the horizon, that's easy: I just moved the meshes up or down. I thought fixing the cut-off edges would be easy as well but that was due to an incorrect assumption. I had thought that the textures were cut off because the meshes overlap, but it turns out that this is not the case. Instead it's an issue with the UVW map that is slightly smaller than the texture. For the vanilla 512x512 textures only about half a pixel is missing at each edge so there's no visible seam (sometimes it's actually more than one pixel missing and for some reason still no seam), but with bigger textures, that half-pixel becomes about two pixels which is very much visible ingame. Now, I could of course manually adjust the UVW map for every mesh using an "Unwrap UVW" modifier but that sounds really tedious and boring. So I was hoping that someone here has a better idea about how I could fix this. Maybe it's possible to do these edits in the ASCII model? I don't know.

Using MDLOps 1.0 worked. Thanks for the suggestion. But I think I'll follow DPs suggestion as well. That should make life easier as well. Thanks!

Thanks. That's exactly what I was looking for. I just didn't expect it to be in the Area Tools section. Guess I need to do a more thorough search the next time I can't find something.

In the MDL Loading section of KotOR Max, there is the "Use Layout Position" option which I assume to place the model in the scene according to the .lyt file. Could someone tell me how to use that option? I tried having the .lyt in the same folder as the imported model, but that didn't work and I don't see an option to choose the .lyt file.

Question: Is it possible to use MDLedit with KotOR Tools batch exporting feature to export multiple models directly as ASCII with all of their textures? I know that I can just batch extract the .mdl and .mdx files and then batch convert them in MDLedit, but that leaves me without the extracted textures, so I was hoping there is a faster way.

You don't need these scripts. TSL already has scripts for changing booleans that can be used with the scripting parameters in TSLs dialog files. So you'd still add the global into globalcat.2da, but then use these vanilla scripts in the dialog. I can't remember their exact names, but the one for global setting should be a_global_set or for a boolean (like in your case) a_glob_bool_set. And then the first string parameter would be the tag of your global and the first number parameter would be the value, i.e. 1. The script to check for your global being set is c_glob_bool_set with the string parameter being your tag again. There are some more of these scripts for a global being equal to a certain number, or being smaller than a certain number, etc. They're very handy since you don't have to write each of these scripts yourself, but can just reuse these general ones.

Thanks. I just checked and the savegame works fine for me. I can enter the academy without issues. So it has to be some issue with your TSLRCM installation. I'd suggest a full reinstallation of the game and TSLRCM, making sure that you follow the installation instructions to the letter. Also, I think your game is in French (or at least not English), right? Make sure you also use TSLRCM in that same language.

Agreed. I don't see any other mods that could cause this either. So you could try and remove all the lev40 files as jc2 suggested and also lev_m40ad.mod from the modules folder (if it exists). Then load a savegame where you haven't entered the bridge module yet and see if the issue was fixed. If it was, you can search through your mods if any of them edited these files or if it really was only K1R that modified them, to see which mod is the cause of your issue.

It doesn't have a new shape. The only difference is that the empty part between the front mandibles is now filled out with a freight container or something. (And the radar dish is different.)

I can't access the file like this. You need to add it to the post as well. That's the "Add to post" button on the right of the attached file after uploading it.

So yeah, that other skybox I worked on after Onderon turned out to be Onderon... But it's not the same skybox. Instead I worked on the skybox used down in the city, which obviously uses the same terrain but is rendered from a different point of view. At the same time, I added a better skyline to all Onderon city modules (including the civil war module). For that I rerendered the vanilla ond_skyline01 and ond_skyline02 textures in 3ds max and then modified the skybox models themselves to include the skyline. For the spaceport module I only had to scale and move the already existing model parts to bring them in line with the city seen on the skybox, but for all other modules, I added the new backdrop buildings. At the same time, I also moved the skybox itself downwards, as it was placed way too high (which resulted in the horizon being too high). Then I also had to move the sun in my renders, so that the shadows in the module match the sun position again, and I also had to move the clouds as the shift of perspective from the top of the mountain down into the city resulted in the sun being hidden behind clouds which I didn't want. But in the end it all worked out and I consider Onderon finished: (Disclaimer: I'll go over all skyboxes before rendering them in high quality and might tweak them, but don't expect any big changes.)

He asked for them to wear the standard robes anyway, so I guess it wouldn't actually be too hard to do except for the fact that there aren't really that many heads to use.

A savegame can be corrupted like this, yes, but I don't think that's the case here as your game crashes when you load a new area that shouldn't be in the savegame yet. I have no idea what else could be causing it though. Could you upload your savegame? Then I could try and see if it crashes for me too, which would suggest that it actually is the savegame that's causing all this. Or you could download one of the savegame collections from the download section and see if those crash as well when you go to the academy. That'd serve the same purpose.

Try setting K_XOR_AMBUSH to 2, but make a copy of your savegame. But it seems like you're having another issue. The globals seem fine for the second encounter, so I'd guess the dialog is screwed up or something like that.

Amazing work as always!

I highly doubt that as it's probably hardcoded for the game to use placeables.2da when looking for the apperance specified in an .utp file.

I'd suggest using MDLEdit instead of MDLOps. But I really don't know if that'll fix this specific issue.

You don't want to compile k_inc_force. The "inc" stands for "include", i.e. it's included when compiling other scripts, in this case force power scripts. As jc2 pointed out correctly, you need nwscript.nss in your Override folder to compile any scripts. And usually you do just what jc2 said, but since this is an include script, you need to put the UNCOMPILED k_inc_force.nss into your Override as well and then compile all scripts that include this script or at least all scripts that use the portion of k_inc_force that you modified. So go to spells.2da, find the scripts fired when using the force powers you want to be edited, then use KT to extract these scripts from the scripts.bif (hopefully you can find the uncompiled version, if you can't, try decompiling them with DeNCS but that might run into problems with the include script), and compile those while having nwscript.nss and your modified k_inc_force.nss in the Override. Once that's done, copy the compiled scripts to your Override and if you want to keep your Override clean, remove the k_inc_force.nss and nwscript.nss, but you don't have to. I wouldn't recommend removing the nwscript.nss as you need that to compile scripts and whether or not k_inc_force.nss is in your Override doesn't matter. As to the floating point values for alignment shifts. That's not possible. The alignment is saved as an integer value, so you can't use decimals here.

It's also in the installation log. Right after it says that it has skipped the file it should list all the edits it did to that 2da file.

That depends. Usually it's good as it will then just patch the existing 2da file instead of replacing it. (This is exactly the feature why TSLPatcher is useful). If for some very weird reason the mod author decided to not use TSLPatchers patching ability, but still decided not to replace an already existing 2da file, then you'll run into trouble. But I doubt that'll ever happen.

That's why I linked my tutorial on file priorities. The game will use the .git from the Override. If that doesn't exist, it'll use the one from the savegame. If that doesn't exist either, it will go to the .mod and finally to the .rim. That means that putting the .git into a .mod (or .rim) is necessary so that it doesn't screw up your savegame but it also means that the changes made to the .git in the .mod/.rim will only be seen ingame if you have never visited that module before (i.e. the .git doesn't exist in the savegame). Which is why putting the .gits into the Override is perfectly fine and useful for testing but NEVER for a finished mod. And TSLPatcher does allow you to edit .git files in the .rim/.mod files. Just put Modules\<module_name>.rim as the file destination. (Or maybe with / instead of \). It's all explained in the very handy TSLPatcher documentation pdf.

This is exactly what I was trying to tell you. The only reason why your .git edits reset the module is because you put them into the Override. That's fine as long as you're testing but DO NOT keep them there for the mod release. Instead put them into the corresponding .mod file.

Have a look at this. Especially the .git section.