I also had more elaborate ideas for the long term and this is where that model limit I keep talking about comes into play. I'm not very good at 3D modeling, but I've been trying to learn, and I've thought about adding new hilts if I ever managed to make any decent ones. Maybe some modelers would be willing to donate models as well. I came up with a system for how I would implement them, given the limitations of the game's upgrade system.

A lightsaber would be composed of five parts: crystal, hilt, energy cell, emitter matrix, and lens. Mechanically, in the standard game the crystal performs the role of both the crystal and the hilt in my system - in that whatever crystal you put into the saber determines what model it gets. That's the crux of the problem.

The mod would add new hilt items. The workshop would let you put crystals into the hilts, or take them out, or whatever. In other words, you can change the hilt type and then proceed to upgrade it in the usual manner.

Hilts could be found or made. For example, if you find a rancor tooth, perhaps you could make a rancor tooth hilt.

The emitter matrix would determine the lightsaber type. There would be the standard type, which goes into all three upgradeable varieties. Then there would also be exotic ones such as dual-phase, crossguard, and curved. Depending on the models available, of course. Sabers made with exotic emitters could not be upgraded, due to the game limitations. This would possibly include the short lightsaber, if it were to be replaced by the longsaber in the upgrade system.

The big issue here is that with 10 colors and up to 3 variations of those colors, 30 total, there can only be about 8 hilts per saber type. 12 hilts if one style is dropped, 24 if two. There's a little wiggle room but not much. I don't know what if any hilt models will be added with this mod, so I could just use all the space I want for colors, but then it wouldn't be compatible with any hilt mods.

So the point of all this is I don't know what's the best idea, what someone using the mod would actually want. I'm looking for any general input, but more specifically:

Do people feel strongly about the short lightsaber? Either way - retaining it or replacing it with something else?

Is the longsaber worth adding? Even if it means getting rid of something else?

Are the new color options worth having at the expense of hilt options, or should extra room for hilts be prioritized?

I'd love to see that part implemented. I even intended to do so myself two years back but in the end I decided that using this would just be too impractical without a proper new GUI. I do think that the special hilts are only really needed for the "standard type" sabers, i.e. normal, double and short (and long, although I have to admit that I don't see the point of that one). Others, like the crossguard sabers could do with just one hilt just like in Sithspecters mod.

In any case, the most important question is this: How do you actually use these ingame if there's no GUI for it? With a dialog system? Will that work in a way that's not too annoying to use?

I've been working on the Telos surface skybox. It's not finished yet but I'm quite happy with how it's turning out. And since you don't actually see much of the terrain ingame ( ), here's a render.

The mountains are not quite finished, I'll add more sand on the coast (and brighten it up) for a better beach. The trees are just placeholders, the sun position might be tweaked and the clouds still need to extend further into the distance.

The clouds for the part behind the camera that's outside of the restoration zone are the one thing that I haven't worked on at all.

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.

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.)

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.

But the thing is, otherwise they won't work. I tried altering the .git then repacking the RIM file of Stoffe's Combat arena, but that didn't work. Only the override stuff worked.

On the other hand, TSLRCM modules do have their Git file packed.inside, but TSL patcher doesn't allow to inject it.

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.

So right now if I download M478 from the workshop it will break compatibility with TSLRCM? What about the various texture replacements and TSLRCM add-ons, those would be fine?

No, M478 won't break compability but pretty much any other mod that edits common files like appearance.2da could cause issues. Texture replacements are fine.

The problem is just that M478 patches some files that TSLRCM uses so you have to install your mods into the same folder that M478 is in if you want to keep these changes while installing your mods. But the M478 workshop folder doesn't contain all the files that TSLRCM edits so any edits to files that are in TSLRCM but not M478 will cause conflicts when installing mods to the M478 workshop folder.

Bottom line: Either be very, very careful or don't use M478 from the workshop with non-workshop mods.

That is a really good idea, though there'd have to be some sort of requirements for WIP Threads being nominated as I'm sure you'd know there have been many big promising mods with modders that don't even try to deliver.

Definitely. I think it would have to be a mod where "significant" process has been made this year. That's of course very vague but I'm sure that the MotY team could make that decision for the nominated mods.

One other thing I didn't say before is that I really like DPs idea of having badges as awards.

Really didn't expect to win this one. Thanks for the support guys and congratulations to all other winners!

Some suggestions from my end / replies to other suggestions:

I also prefered having K1 and TSL separated, but it's not really a big deal as long as the categories are good.

Have the option to not vote in a category right from the beginning so that one isn't forced to vote randomly.

About WIP mods: I like having that category, but I think it shouldn't be limited to Demo mods. In fact those should just be added to the standard categories, but for the WIP category one could just use the threads from the WIP section. It could be renamed to something like "Mod that most people look forward to" and really just be a vote on future mods that people are excited about.

I don't mean any disrespect but shouldn't we be voting for mods based on what the mod has to offer/how much effort went into the mod not how well we know the modder who made it. Though I can completely understand why you wouldn't want to play Demo mods.

That's exactly why I wanted to have the "No vote" option, as I haven't played the WIP mods and in this case didn't always follow your WIP thread, I couldn't tell what the mod has to offer. So I was forced to either vote randomly or not at all and the latter seemed like the fairest thing to do.

I spent the last days iterating over dozens of versions for the Onderonian sky. And here's the current result, also showing the updated lightmap for the palace, using the sun position provided by DarthParametric:

And here's another view down into the city:

And just for fun, here's an animation showing some of the iterations I went through:

The really dark ones in the middle were probably the closest to the vanilla skybox but in the end I decided to go with a brighter sky as that works better with the sun position and area lighting.

As always, I might still tweak that skybox but I think I'll let it rest for now while I work on one of the others.