Mapping out Modding Standards

[VarsityPuppet 1,085]

 

This is an issue that has come to the forefront of my mind recently, as new techniques have surfaced for increasing the overall experience of the game.

 

Taking a card from the programmer's practices, I'd like to hopefully lay down some standards for modding to increase consistency across mods. This will hopefully help with easing compatibility between mods as new releases show up in the downloads section. I'm posting in here to gather input from the community as to what the best practices might be, though again, these ARE suggestions and we certainly can't force anyone to follow these practices. This would also be a good place to rehash our stance on porting, using others' assets and copyright issues.

 

These are my initial thoughts on standards.

 

1. Override Subfolders

 

I feel like there should be some subdivision of mod assets in the override. Either by asset or by mod, though I would be inclined to discourage by mod, because that introduces potential for increased incompatibility. By adding subfolders, we help organize installation files and add some ease of access to specific files that may need editing. The downside is of course that K1 doesn't support override subfolders.

 

An alternative to this then is applying naming standards to new mod files, but when most of the files being edited are vanilla and can't be edited, this is sort of a moot point.

 

Ultimately, I'm fine with using subfolders for K2, but not K1, since they are not supported, but it might be better to have the standards the same for both games.

 

2. Texture Formats

 

If you aren't aware, the Bioware DDS conversion tool has been released in the downloads section. It works great and really helps increase performance for massive reskins. However, converting existing mods is a bit of a mixed bag. Textures must have dimensions of a power of 2, must NOT have any compression applied and must have normal orientation. It's not much of a pain to ensure these while exporting textures, and not too much trouble to convert, but every once in awhile you'll get that random texture that's not within those standards and it won't convert correctly. I would even go as far to recommend including the textures in dds format in the mod. I can't imagine too many people will want to edit textures that go in the override, but if they do, I'm pretty sure there's a tool that will convert to tga for those people.

 

3. When to use scripts

 

I know sometimes it's easier to add a script to spawn a random container somewhere in a module, but in terms of compatibility, scripts are the biggest problem area. If possible, avoid using scripts, add it to the git instead. It probably doesn't make sense to enforce this standard until we have a good way to merge git files (though, I think TSLPatcher is able to do this, but we'd probably need to cover TSLPatcher a little better in tutorials). We also shouldn't be using scripts too heavily to alter global game behavior, but I don't know if I would contest this much because the use case for this is pretty limited.

 

4. TSLRCM Compatibility

 

I think this seems pretty obvious, but at this point, mods should made with TSLRCM compatibility in mind. There are few who still make mods without consideration for TSLRCM, which is completely fine but certainly cuts down on their downloads. It shouldn’t have to be up to the user to ensure compatibility, nor to some other modder.

 

 

That’s all I’ve got for now. Don’t mean to step on people’s toes, and a lot of this is up for debate, so please, any input is welcome and encouraged.

[Fair Strides 509]

This is an issue that has come to the forefront of my mind recently, as new techniques have surfaced for increasing the overall experience of the game.

 

Taking a card from the programmer's practices, I'd like to hopefully lay down some standards for modding to increase consistency across mods. This will hopefully help with easing compatibility between mods as new releases show up in the downloads section. I'm posting in here to gather input from the community as to what the best practices might be, though again, these ARE suggestions and we certainly can't force anyone to follow these practices. This would also be a good place to rehash our stance on porting, using others' assets and copyright issues.

 

These are my initial thoughts on standards.

 

1. Override Subfolders

 

I feel like there should be some subdivision of mod assets in the override. Either by asset or by mod, though I would be inclined to discourage by mod, because that introduces potential for increased incompatibility. By adding subfolders, we help organize installation files and add some ease of access to specific files that may need editing. The downside is of course that K1 doesn't support override subfolders.

 

An alternative to this then is applying naming standards to new mod files, but when most of the files being edited are vanilla and can't be edited, this is sort of a moot point.

 

Ultimately, I'm fine with using subfolders for K2, but not K1, since they are not supported, but it might be better to have the standards the same for both games.

 

2. Texture Formats

 

If you aren't aware, the Bioware DDS conversion tool has been released in the downloads section. It works great and really helps increase performance for massive reskins. However, converting existing mods is a bit of a mixed bag. Textures must have dimensions of a power of 2, must NOT have any compression applied and must have normal orientation. It's not much of a pain to ensure these while exporting textures, and not too much trouble to convert, but every once in awhile you'll get that random texture that's not within those standards and it won't convert correctly. I would even go as far to recommend including the textures in dds format in the mod. I can't imagine too many people will want to edit textures that go in the override, but if they do, I'm pretty sure there's a tool that will convert to tga for those people.

 

3. When to use scripts

 

I know sometimes it's easier to add a script to spawn a random container somewhere in a module, but in terms of compatibility, scripts are the biggest problem area. If possible, avoid using scripts, add it to the git instead. It probably doesn't make sense to enforce this standard until we have a good way to merge git files (though, I think TSLPatcher is able to do this, but we'd probably need to cover TSLPatcher a little better in tutorials). We also shouldn't be using scripts too heavily to alter global game behavior, but I don't know if I would contest this much because the use case for this is pretty limited.

 

4. TSLRCM Compatibility

 

I think this seems pretty obvious, but at this point, mods should made with TSLRCM compatibility in mind. There are few who still make mods without consideration for TSLRCM, which is completely fine but certainly cuts down on their downloads. It shouldn’t have to be up to the user to ensure compatibility, nor to some other modder.

 

 

That’s all I’ve got for now. Don’t mean to step on people’s toes, and a lot of this is up for debate, so please, any input is welcome and encouraged.

 

I agree wholeheartedly with this, VP! I'll work myself on fleshing out some guidelines and "best practices", but let's see what I can post here...

 

(I'm going to try focusing more on things that apply to both games)

5. Avoid Override Clutter

 

    This one is rather simple: if it doesn't need to be there, don't put it there. The list of files that need to be in the override folder (or optionally sub-folders in KotOR 2's case) is as follows:

 

    .2da, .mdl (and .mdx; the mdl and mdx files only need to be in the Override if they are not models that make up levels), tga*, dds*, and txi*

 

    *These files most modders will install to the Override folder for ease-of-access. It's easier to get at the files here than extracting them from the level files...

 

    Lastly on this rule, the only other time you should add a file of any type to the Override folder instead of the level file is when the file in question is or will be used in multiple levels without changes. Otherwise, the file should be added to the level itself.

 

6. If making new levels, make them friendly:

 

    The game prioritizes the .mod level format and so uses it before using the .rim level format. Because of this, if you intend to let others use your level files, it's a lot nicer to use the the .rim format originally so that others can throw changes in a .mod file. This allows users of the newer copy to quickly uninstall the new changes if they desire. It also works great for testing a level, as you can use the .rim thing to "backup" a level at a point that you want to keep it before trying something different and are not sure if the changes will stay...

[Guest R2-X2]

And I tried to rely on modifying scripts that are unlikely to be used by anyone (like the sith soldier shooting the Duros on Taris) to change stuff in order not to edit dlg/rim/mod files for more compatibility.

[VarsityPuppet 1,085]

And I tried to rely on modifying scripts that are unlikely to be used by anyone (like the sith soldier shooting the Duros on Taris) to change stuff in order not to edit dlg/rim/mod files for more compatibility.

 

See this is something I would contest. Sure, it makes sense for compatibility, but I'm not sure I'd agree with coupling together bits of unrelated code.

 

More on this later though. Theoretically, it should not be hard to add another field to a git file, or any of the necessary structures to accomplish whatever you're doing. Once we start tightly coupling  scripts, we're asking for trouble.

[Sithspecter 909]

7. More Polygons DOES NOT Equal a Good Model

 

Too often (at least in the old days), people will equate a large number of polygons with a better model. This is almost certainly not the case. A good modeler should be able to be efficient with the polygons that they use. Especially with KotOR and TSL, the smaller details will be better coming from a texture, not the model. I say that a good texture makes up for a poor model better than a good model makes up for a poor texture. Spend the extra time on the texture, and it will make a difference.

 

For instance, you do not need to model a 6,000 poly lightsaber. Nobody is going to see that detail. A 200-500 polygon lightsaber will be plenty detailed for KotOR and TSL. I'd say another general rule of thumb would be 500-1500 polygons for ranged weapons.

 

8. Larger Texture Resolution DOES NOT Equal a Good Texture

 

Don't overcompensate with the texture either!! You don't need a 2048 x 2048 texture for that lightsaber either!! Nobody will be able to tell that it's larger than a 512 x 512 one. For just about any item, 512 x 512 or 1024 x 1024 will be a plenty large texture. Don't create larger files that aren't going to make a difference. If you use a 512 x 512 texture instead of a 2048 x 2048 texture, you're file size will be ONE SIXTEENTH!! That's a huge difference, and it will save space for those who download.

 

9. Limit Unnecessary NPCs in Modules

 

Modules with scores of NPCs get really laggy real quick. If you're making a new module, please keep the number of NPCs to an acceptable level. This problem can be seen in several large mods, and it can be very frustrating. You don't need rows of dozens of droids that are all asleep. Sure, it's a nice touch, but the performance drag on many systems can be large. Please keep the number of unnecessary NPCs to a minimum. You don't need 50 commoners in one area to make it feel populated.

[VarsityPuppet 1,085]

7. More Polygons DOES NOT Equal a Good Model

 

Too often (at least in the old days), people will equate a large number of polygons with a better model. This is almost certainly not the case. A good modeler should be able to be efficient with the polygons that they use. Especially with KotOR and TSL, the smaller details will be better coming from a texture, not the model. I say that a good texture makes up for a poor model better than a good model makes up for a poor texture. Spend the extra time on the texture, and it will make a difference.

 

For instance, you do not need to model a 6,000 poly lightsaber. Nobody is going to see that detail. A 200-500 polygon lightsaber will be plenty detailed for KotOR and TSL. I'd say another general rule of thumb would be 500-1500 polygons for ranged weapons.

Good recommendation, but are there any recommendations on placeables? Obviously they're quite variable in size.

 

8. Larger Texture Resolution DOES NOT Equal a Good Texture

 

Don't overcompensate with the texture either!! You don't need a 2048 x 2048 texture for that lightsaber either!! Nobody will be able to tell that it's larger than a 512 x 512 one. For just about any item, 512 x 512 or 1024 x 1024 will be a plenty large texture. Don't create larger files that aren't going to make a difference. If you use a 512 x 512 texture instead of a 2048 x 2048 texture, you're file size will be ONE SIXTEENTH!! That's a huge difference, and it will save space for those who download.

I would also like to point out that when you modify any original image file, make sure you're grabbing it from the C pack. You always want to be editing the highest resolution version of the image.

 

Also a rule of thumb when it comes to texture sizes and what sizes to use:

 

Heads: 512x512

Weapons: 128x128 or 256x256 depending on the definition

Armors: 512x512

 

Placeables and Area Textures are the exception. These typically are really low resolution in-game and are in dire need of upscaling.

 

Obviously, never go smaller than the original size.

 

I would also recommend we start an index of the available retextures. We're coming to a point where higher definition is the standard and yet there are so many different retextures you need to download to optimize the most amount of textures. My own override includes combinations of Vurt Xarwarz, Malkior, Jorak Uln and many others (I apologize if I didn't mention anyone specifically!)

 

 

9. Limit Unnecessary NPCs in Modules

 

Modules with scores of NPCs get really laggy real quick. If you're making a new module, please keep the number of NPCs to an acceptable level. This problem can be seen in several large mods, and it can be very frustrating. You don't need rows of dozens of droids that are all asleep. Sure, it's a nice touch, but the performance drag on many systems can be large. Please keep the number of unnecessary NPCs to a minimum. You don't need 50 commoners in one area to make it feel populated.

Yes, they should be kept to a minimum.

[LiliArch 115]

I seem to be unable to quote for some reason, but maybe this works without it.

//Edit: of course I now can quote - probably a JavaScript glitch of sorts or something. So, edited the correct quote to the post...

 

I would also like to point out that when you modify any original image file, make sure you're grabbing it from the C pack. You always want to be editing the highest resolution version of the image.

Isn't the highest resolution in the pack A, and not C? Or have I completely messed everything again...

[Ninko 64]

I seem to be unable to quote for some reason, but maybe this works without it. Isn't the highest resolution in the pack A, and not C? Or have I completely messed everything again...

 

You are correct there lili.

[VarsityPuppet 1,085]

I can't remember which texture pack it is. Should probably revise that before I make this official.

[sELFiNDUCEDcOMA 98]

1. Override Subfolders

 

I feel like there should be some subdivision of mod assets in the override. Either by asset or by mod, though I would be inclined to discourage by mod, because that introduces potential for increased incompatibility. By adding subfolders, we help organize installation files and add some ease of access to specific files that may need editing. The downside is of course that K1 doesn't support override subfolders.

 

An alternative to this then is applying naming standards to new mod files, but when most of the files being edited are vanilla and can't be edited, this is sort of a moot point.

 

Ultimately, I'm fine with using subfolders for K2, but not K1, since they are not supported, but it might be better to have the standards the same for both games.

 

Just thought I'd mention that you are limited to how many levels (branches) there are to your override folder. From my experience, you can have a sub-folder, but, you can't have a sub-folder within that one. At least that is my experience from using them to organize my mod project work.

 

In way of standards for these folders, I would suggest that for base-game shared files that they go into the main override folder. For those specific to certain modules, they go into module subfolders. I would also suggest that if you are creating new assets, that if they are for a specific module, they go there, if they are "generic" and used across the game like weapon models / textures, then they go into a new subfolder for weapons, however, prefixed with an identifier for your mod. Alternatively for the last, you simply have a Weapons folder for all weapon file assets -- you'd do the same for armor, characters, etc.

 

I have a similar structure for my own mod WIP, mostly to make it easier for me to work with the assets and to separate mine from TSLRCM. However, if you want to ensure "compatibility" then you have this folder structure by default in use with TSLRCM. You would create the various folders even if you end up putting nothing in it -- so that other modders, would make use of them instead of creating their own with some idiotic naming convention .

 

2. Texture Formats

 

If you aren't aware, the Bioware DDS conversion tool has been released in the downloads section. It works great and really helps increase performance for massive reskins. However, converting existing mods is a bit of a mixed bag. Textures must have dimensions of a power of 2, must NOT have any compression applied and must have normal orientation. It's not much of a pain to ensure these while exporting textures, and not too much trouble to convert, but every once in awhile you'll get that random texture that's not within those standards and it won't convert correctly. I would even go as far to recommend including the textures in dds format in the mod. I can't imagine too many people will want to edit textures that go in the override, but if they do, I'm pretty sure there's a tool that will convert to tga for those people.

 

If this is the old NWN command prompt tool, I recall it did an ok job of it. But as long as it is doing a good job of converting TGA to (proper) DDS, then I think by default those that reskin should be using it; primarily for things like environment textures, as DDS will support mipmapping. May not be worth the trouble of any extra tweaking for one-offs or characters -- depends on the end quality, though.

 

 

3. When to use scripts

 

I know sometimes it's easier to add a script to spawn a random container somewhere in a module, but in terms of compatibility, scripts are the biggest problem area. If possible, avoid using scripts, add it to the git instead. It probably doesn't make sense to enforce this standard until we have a good way to merge git files (though, I think TSLPatcher is able to do this, but we'd probably need to cover TSLPatcher a little better in tutorials). We also shouldn't be using scripts too heavily to alter global game behavior, but I don't know if I would contest this much because the use case for this is pretty limited.

 

The issue with scripts is due to the OnEnter script injection process. It's problematic, if others use it as well, however, probably the better way to get "compatibility" with TSLRCM.

 

4. TSLRCM Compatibility

 

I think this seems pretty obvious, but at this point, mods should made with TSLRCM compatibility in mind. There are few who still make mods without consideration for TSLRCM, which is completely fine but certainly cuts down on their downloads. It shouldn’t have to be up to the user to ensure compatibility, nor to some other modder.

 

I think TSLRCM could actually do a better job of supporting compatibility with other mods. For example, by making it easier for others to OnEnter inject their scripts and not interfere with TSLRCM.

 

Basically, you set up a script call to another script that does nothing other than include other scripts. You set this up for every module, even if they don't have an OnEnter script for the module -- you create one in such cases. Then if anyone wants to inject anything, they add their script include to this script for the module, and then add the script to the Override folder.

 

I agree wholeheartedly with this, VP! I'll work myself on fleshing out some guidelines and "best practices", but let's see what I can post here...

 

(I'm going to try focusing more on things that apply to both games)

5. Avoid Override Clutter

 

    This one is rather simple: if it doesn't need to be there, don't put it there. The list of files that need to be in the override folder (or optionally sub-folders in KotOR 2's case) is as follows:

 

    .2da, .mdl (and .mdx; the mdl and mdx files only need to be in the Override if they are not models that make up levels), tga*, dds*, and txi*

 

    *These files most modders will install to the Override folder for ease-of-access. It's easier to get at the files here than extracting them from the level files...

 

    Lastly on this rule, the only other time you should add a file of any type to the Override folder instead of the level file is when the file in question is or will be used in multiple levels without changes. Otherwise, the file should be added to the level itself.

 

6. If making new levels, make them friendly:

 

    The game prioritizes the .mod level format and so uses it before using the .rim level format. Because of this, if you intend to let others use your level files, it's a lot nicer to use the the .rim format originally so that others can throw changes in a .mod file. This allows users of the newer copy to quickly uninstall the new changes if they desire. It also works great for testing a level, as you can use the .rim thing to "backup" a level at a point that you want to keep it before trying something different and are not sure if the changes will stay...

 

Some good points, however, not sure I entirely agree; especially where you should be putting certain files instead of the override. It's easy to make these rules if you've never worked on a large mod that deals with all sorts of models, textures and scripts -- among other things. This might make it easier for people to use a bunch of mods together -- kind of doubt it -- at the cost of making the modder's task far more difficult.

 

But, that is just my opinion.

 

 

7. More Polygons DOES NOT Equal a Good Model

 

Too often (at least in the old days), people will equate a large number of polygons with a better model. This is almost certainly not the case. A good modeler should be able to be efficient with the polygons that they use. Especially with KotOR and TSL, the smaller details will be better coming from a texture, not the model. I say that a good texture makes up for a poor model better than a good model makes up for a poor texture. Spend the extra time on the texture, and it will make a difference.

 

For instance, you do not need to model a 6,000 poly lightsaber. Nobody is going to see that detail. A 200-500 polygon lightsaber will be plenty detailed for KotOR and TSL. I'd say another general rule of thumb would be 500-1500 polygons for ranged weapons.

 

I agree. Can't remark on poly limits, as it really depends upon the model, however, it's clear that some folks need to spend more time learning the basics of low-poly modeling and UV mapping. But hey, from my experience, most mod users tend to not to even notice the difference.

 

 

8. Larger Texture Resolution DOES NOT Equal a Good Texture

 

Don't overcompensate with the texture either!! You don't need a 2048 x 2048 texture for that lightsaber either!! Nobody will be able to tell that it's larger than a 512 x 512 one. For just about any item, 512 x 512 or 1024 x 1024 will be a plenty large texture. Don't create larger files that aren't going to make a difference. If you use a 512 x 512 texture instead of a 2048 x 2048 texture, you're file size will be ONE SIXTEENTH!! That's a huge difference, and it will save space for those who download.

 

Very much agree. And I'm agreeing from a point of view regarding texture mods in general -- not just for KotOR / TSL. 

 

Having said that, in the right context, 2048x2048 isn't a bad choice. However, 4096x4096 -- or worse, larger than this -- for these games is utterly pointless due to the engine...

 

 

I would also like to point out that when you modify any original image file, make sure you're grabbing it from the C pack. You always want to be editing the highest resolution version of the image.

 

Also a rule of thumb when it comes to texture sizes and what sizes to use:

 

Heads: 512x512

Weapons: 128x128 or 256x256 depending on the definition

Armors: 512x512

 

Placeables and Area Textures are the exception. These typically are really low resolution in-game and are in dire need of upscaling.

 

Obviously, never go smaller than the original size.

 

I'm going to suggest something different here:

 

Heads: 1024x1024

Weaps: 256x256 -- or 512x512 for new weaps; yes, there is a difference if you know what you're doing

Armors: 1024x1024

Items/Head-gear: 256x256 -- or possibly 512x512 for new models.

Inventory pics: 128x128

Creature: 1024x1024

Skybox: 2048x2048

Environ: 512x512 -- 1024x1024 for special cases

 

It really depends upon the skill of the modder when it comes to texturing for some of these. For example heads, you may be better off with 512x if you don't have advanced skills and can't make use of specularity properly. However, even so, you will find that there is a noticeable difference between a head using a (decent) texture resized from 1024x down to 512x.

 

The same is the case for "armor" or any body texture, like those for aliens / robots.

 

I might suggest higher for the skybox, however, either the renderer fails to display the extra detail or the textures are down-sampled as there is a size cap for these. Largest I can get to work, is 2048x and yes, there is a noticeable difference between it and 1024x.

 

Environment textures are funny, in that if you compared it to the minimum size for later games, then you might argue that 1024x is the best option. If you can get DDS to work correctly, this might be the best option, however, I find that the main issue with environment textures it that they are used all over the place at scales they weren't meant to be used at. The better option here is better model tools so that you can switch textures or reset the scale of those that are used for certain parts of the mesh.

 

However, so far I have stuck with 512x as there are a lot of environment textures and there would likely be negligible improvement in way of the environment by using anything larger. You are better off hex editing environment models to replace textures used at horrible scales with something else instead.

 

Anyway, that's my opinion on "best practice."

[VarsityPuppet 1,085]

Forewarning: I wrote most of this on the fly a few days ago. So pardon my poor grammar. 

 

Just thought I'd mention that you are limited to how many levels (branches) there are to your override folder. From my experience, you can have a sub-folder, but, you can't have a sub-folder within that one. At least that is my experience from using them to organize my mod project work.

Subfolders might be a good place for source code. It's always a bit troublesome to try to find that exact rar or zip file that has the original files you were working with, especially if you're constantly tweaking and changing things like myself.

 

In way of standards for these folders, I would suggest that for base-game shared files that they go into the main override folder. For those specific to certain modules, they go into module subfolders. I would also suggest that if you are creating new assets, that if they are for a specific module, they go there, if they are "generic" and used across the game like weapon models / textures, then they go into a new subfolder for weapons, however, prefixed with an identifier for your mod. Alternatively for the last, you simply have a Weapons folder for all weapon file assets -- you'd do the same for armor, characters, etc.

Yes, this is exactly the sort of thing I want hashed out, although the main issue we'll run into is that Kotor 1 does not support subfolders (I think). Doesn't mean we can't still do this for KOTOR 2.

 

I have a similar structure for my own mod WIP, mostly to make it easier for me to work with the assets and to separate mine from TSLRCM. However, if you want to ensure "compatibility" then you have this folder structure by default in use with TSLRCM. You would create the various folders even if you end up putting nothing in it -- so that other modders, would make use of them instead of creating their own with some idiotic naming convention .

Could you clarify this a bit? Are you suggesting making subfolders specifically for compatibility? That sounds like a good idea. I'd like to hear more on it.
 
 

If this is the old NWN command prompt tool, I recall it did an ok job of it. But as long as it is doing a good job of converting TGA to (proper) DDS, then I think by default those that reskin should be using it; primarily for things like environment textures, as DDS will support mipmapping. May not be worth the trouble of any extra tweaking for one-offs or characters -- depends on the end quality, though.

I believe it is and yes, it has been really helpful with the massive environmental retextures. You raise a good point about the one-off skins and characters, though I would be inclined to convert them for consistency. The tool is so easy to use though that we might as well just convert everything possible.

The only downside is that we'd have to be stricter about tga formats: They do have to be Po2 and non-compressed.
 
 

The issue with scripts is due to the OnEnter script injection process. It's problematic, if others use it as well, however, probably the better way to get "compatibility" with TSLRCM.

I think TSLRCM could actually do a better job of supporting compatibility with other mods. For example, by making it easier for others to OnEnter inject their scripts and not interfere with TSLRCM.

Basically, you set up a script call to another script that does nothing other than include other scripts. You set this up for every module, even if they don't have an OnEnter script for the module -- you create one in such cases. Then if anyone wants to inject anything, they add their script include to this script for the module, and then add the script to the Override folder.

This sounds like a generally good idea. I would just hope that there's not too much script injecting going on. Perhaps it would be worth going over the specific process. Then we can coordinate with TSLRCM to increase the compatibility for future modders. Though scripting has proven itself to be extremely buggy in the past.

 

I agree. Can't remark on poly limits, as it really depends upon the model, however, it's clear that some folks need to spend more time learning the basics of low-poly modeling and UV mapping. But hey, from my experience, most mod users tend to not to even notice the difference.

 
Good point. It's not like we have to be real strict on these anyways. I can't imagine there will be too many people with 2000+ poly models that will kill the game

 

 

I'm going to suggest something different here:
 
Heads: 1024x1024
Weaps: 256x256 -- or 512x512 for new weaps; yes, there is a difference if you know what you're doing
Armors: 1024x1024
Items/Head-gear: 256x256 -- or possibly 512x512 for new models.
Inventory pics: 128x128
Creature: 1024x1024
Skybox: 2048x2048
Environ: 512x512 -- 1024x1024 for special cases
 
It really depends upon the skill of the modder when it comes to texturing for some of these. For example heads, you may be better off with 512x if you don't have advanced skills and can't make use of specularity properly. However, even so, you will find that there is a noticeable difference between a head using a (decent) texture resized from 1024x down to 512x.

The same is the case for "armor" or any body texture, like those for aliens / robots.

Fair point. I would say 512-1024 is acceptable depending on your skill level and what you're trying to accomplish. I can't imagine there are any instances where we should be recommending 256x256 for head textures though.

 

I might suggest higher for the skybox, however, either the renderer fails to display the extra detail or the textures are down-sampled as there is a size cap for these. Largest I can get to work, is 2048x and yes, there is a noticeable difference between it and 1024x.

2048 across the board would be heavenly. Some of that depends on what people can export at. Maybe set 1024 as acceptable, but 2048 preferred? These of course would benefit from the DDS tool.

 

Environment textures are funny, in that if you compared it to the minimum size for later games, then you might argue that 1024x is the best option. If you can get DDS to work correctly, this might be the best option, however, I find that the main issue with environment textures it that they are used all over the place at scales they weren't meant to be used at. The better option here is better model tools so that you can switch textures or reset the scale of those that are used for certain parts of the mesh.
 
However, so far I have stuck with 512x as there are a lot of environment textures and there would likely be negligible improvement in way of the environment by using anything larger. You are better off hex editing environment models to replace textures used at horrible scales with something else instead.

Good point on this here, but I don't know what we can do about the tools for that now (other than editing UV Mapping for area models...?). We'll have to come back to this at a later time probably.

[Sithspecter 909]

Forewarning: I wrote most of this on the fly a few days ago. So pardon my poor grammar. 

Good point on this here, but I don't know what we can do about the tools for that now (other than editing UV Mapping for area models...?). We'll have to come back to this at a later time probably.

 

There are several options for rescaling UV maps, though most are fairly tedious.

 

First, if a texture is scaled badly, you can obviously enlarge the texture by a factor of 4, which would fix the badly scaled portion. But, this unnecessarily makes the regularly scaled portion a bit too fine of a resolution.

 

You could find the object names of the portions that are scaled badly in 3DSMax and hex edit those portions to use the larger tiled texture. This process is going to be pretty tedious, but it would seem to have the best results.

 

You could also pull the whole model into 3DSMax and adjust the UV maps, and use the Replacer function to change only the maps and preserve other qualities like animations and lightmaps. I'm not 100% sure that would work though. Once again, this would be somewhat tedious, but probably a bit easier than hex editing.

[Hassat Hunter 571]

I think TSLRCM could actually do a better job of supporting compatibility with other mods. For example, by making it easier for others to OnEnter inject their scripts and not interfere with TSLRCM.

 

Basically, you set up a script call to another script that does nothing other than include other scripts. You set this up for every module, even if they don't have an OnEnter script for the module -- you create one in such cases. Then if anyone wants to inject anything, they add their script include to this script for the module, and then add the script to the Override folder.

I don't really see the benefit of this. Aside from being a lot of work to put up you:

 

* Basically shift incompatibility from one file to another, solving nothing.

* Risk increased errors if different mods modify the different file seperately and incompatable.

* Limit yourself in the options, for example to have something NOT happening outlined in the original enter script. Which I did a fair number of times with TSLRCM, like not having 201TEL remove a global that was supposed for 209TEL.

* Run increased risk the game will go "kabloem" with several potential mutually exclusive scripts running, and hiding the conflict source (say, script 1 unsetting a local, when script 2 checks for that global).

 

It's an interesting idea, but I don't see it adding value and compatibility rather than being a source of more trouble and hidden conflicts.

[sELFiNDUCEDcOMA 98]

Hey all, sorry for the (long) delay in reply; after a short break I started work again and it tends to be demanding for the first few weeks. Whenever I had the time I tended to be too tired to remember or motivated to write this.

 

 

Skybox tex comment: 2048 across the board would be heavenly. Some of that depends on what people can export at. Maybe set 1024 as acceptable, but 2048 preferred?

 

Sounds good to me.

 

Could you clarify this a bit? Are you suggesting making subfolders specifically for compatibility? That sounds like a good idea. I'd like to hear more on it.

 

Well, at the moment I have the following folder structure:

 

 

 

ARMOR

BUMP -- more so a temp folder for testing

COR

DROID

DXN

EBO

GEN_NEW

GUI

HAB

HEADGEAR

INVENTORY

K1_TEX

K2_TEX

K2TSLR

PER

PORTRAITS

ROBES

TEL

WEAPS

WScreen

 

 

 

As you can see it's already a long list along with not really having much of a naming convention or standards in way of what goes where. I can imagine that if I keep it as is and other modders use their own folder structure, that quite a bit of conflicts would arise.

 

 

 

This sounds like a generally good idea. I would just hope that there's not too much script injecting going on. Perhaps it would be worth going over the specific process. Then we can coordinate with TSLRCM to increase the compatibility for future modders. Though scripting has proven itself to be extremely buggy in the past.

 

It's pretty simple really, you either replace the OnEnter script for the module to point at something like: OE_PER202, probably found in an "OnEnter" subfolder -- for ease of modification. The last line of the script would have an include for the original OnEnter script if the module had one. An alternative -- depending if the uncompiled scripts are available -- is to edit the original OnEnter script to have an include for the new OE_PER202 script. Regardless, the script can be easily found within the new "OnEnter" subfolder and modified by modders or those using mods. Users should be able to resolve some conflicts by simply modifying the load order for the included scripts -- EDIT: via a script editor / compiler.

 

To be frank, I use an SSD drive so I don't notice any real "performance" issues to do with scripts, but I can see how scripts loading a lot of things will cause lag.

 

I don't really see the benefit of this. Aside from being a lot of work to put up you:

 

I didn't think you would agree with this, and to be frank once again, I don't expect you to do this at all. However, I will comment regardless:

 

* Basically shift incompatibility from one file to another, solving nothing.
* Risk increased errors if different mods modify the different file seperately and incompatable.

 

 

If users have power in that they can edit the new OnEnter script --  EDIT: via a script editor / compiler if the uncompiled version is packaged with the mod -- and modify load orders or even comment things out for debugging; well, I don't see how that is  shifting "incompatibility" (or problem) from one file to another.

 

Another option is that modders can provide multiple versions of this script to support compatibility for various mods.

 

 

I don't really see the benefit of this. Aside from being a lot of work to put up you:

* Limit yourself in the options, for example to have something NOT happening outlined in the original enter script. Which I did a fair number of times with TSLRCM, like not having 201TEL remove a global that was supposed for 209TEL.
* Run increased risk the game will go "kabloem" with several potential mutually exclusive scripts running, and hiding the conflict source (say, script 1 unsetting a local, when script 2 checks for that global).

 

 

I think we have a different view of what the OnEnter scripts would do and how they work. The original OnEnter script would still get called rather than being replaced. And if you are simply using it to add various things based on an initial check to see whether it is necessary, then I don't see how there is the conflict you are suggesting. My understanding and use of the OnEnter script is that they are called once and run once on entering the module, rather than this being a script that is called every so often by the game. Further, when a script is included, it is essentially run before the next included script is loaded and run. It's procedural not concurrent -- though, I could be assuming here.

 

 

It's an interesting idea, but I don't see it adding value and compatibility rather than being a source of more trouble and hidden conflicts.

 

 

I really don't agree, and think it is quite easy to take that point of view when your mod is TSLRCM and you don't have to make it compatible with any other mod, rather, every other mod has to make their's compatible with yours upon every single release.

 

OnEnter injection gets around this to a degree, in that I don't have to update anything other than the scripts if I even have to do that at all.

 

Any issues OnEnter injection has, is more to do with bad scripting and a lack of conventions for scripts and the usage of this type of script IMO, and I doubt that I won't make use of it in the future as it makes my life easier at the very least.

 

 

Good point on this here, but I don't know what we can do about the tools for that now (other than editing UV Mapping for area models...?). We'll have to come back to this at a later time probably.

 

There are several options for rescaling UV maps, though most are fairly tedious.

 

First, if a texture is scaled badly, you can obviously enlarge the texture by a factor of 4, which would fix the badly scaled portion. But, this unnecessarily makes the regularly scaled portion a bit too fine of a resolution.

 

You could find the object names of the portions that are scaled badly in 3DSMax and hex edit those portions to use the larger tiled texture. This process is going to be pretty tedious, but it would seem to have the best results.

 

You could also pull the whole model into 3DSMax and adjust the UV maps, and use the Replacer function to change only the maps and preserve other qualities like animations and lightmaps. I'm not 100% sure that would work though. Once again, this would be somewhat tedious, but probably a bit easier than hex editing.

 

Yeah, hex-editing along with up-scaling is the usual way to go; don't believe that the modifying of UV maps and the use of the Replacer function works that well if at all. Don't recall it doing so.

[InSidious 237]

This is an issue that has come to the forefront of my mind recently, as new techniques have surfaced for increasing the overall experience of the game.

 

Taking a card from the programmer's practices, I'd like to hopefully lay down some standards for modding to increase consistency across mods. This will hopefully help with easing compatibility between mods as new releases show up in the downloads section. I'm posting in here to gather input from the community as to what the best practices might be, though again, these ARE suggestions and we certainly can't force anyone to follow these practices. This would also be a good place to rehash our stance on porting, using others' assets and copyright issues.

 

These are my initial thoughts on standards.

 

Well, if I can play the curmudgeon and disagree with a few of these...

 

 

1. Override Subfolders

 

I feel like there should be some subdivision of mod assets in the override. Either by asset or by mod, though I would be inclined to discourage by mod, because that introduces potential for increased incompatibility. By adding subfolders, we help organize installation files and add some ease of access to specific files that may need editing. The downside is of course that K1 doesn't support override subfolders.

 

An alternative to this then is applying naming standards to new mod files, but when most of the files being edited are vanilla and can't be edited, this is sort of a moot point.

 

Ultimately, I'm fine with using subfolders for K2, but not K1, since they are not supported, but it might be better to have the standards the same for both games.

 

The downside of this is it takes slightly longer to  work out where an incompatibility lies, it doesn't apply to both games, it's another thing for newbie modders to learn (and another thing for users to work out with mods which install manually/for those who can't run tslpatcher...). I agree with standardising filenames as much as possible. Most of my custom files begin di_ in part because it makes it much easier to identify who made them (which if someone wants to redownload is useful), but also because it (hopefully) prevents identically-named assets for two different mods.

 

 

2. Texture Formats

 

If you aren't aware, the Bioware DDS conversion tool has been released in the downloads section. It works great and really helps increase performance for massive reskins. However, converting existing mods is a bit of a mixed bag. Textures must have dimensions of a power of 2, must NOT have any compression applied and must have normal orientation. It's not much of a pain to ensure these while exporting textures, and not too much trouble to convert, but every once in awhile you'll get that random texture that's not within those standards and it won't convert correctly. I would even go as far to recommend including the textures in dds format in the mod. I can't imagine too many people will want to edit textures that go in the override, but if they do, I'm pretty sure there's a tool that will convert to tga for those people.

 

This is one I'll be bearing in mind for the future.

 

 

3. When to use scripts

 

I know sometimes it's easier to add a script to spawn a random container somewhere in a module, but in terms of compatibility, scripts are the biggest problem area. If possible, avoid using scripts, add it to the git instead. It probably doesn't make sense to enforce this standard until we have a good way to merge git files (though, I think TSLPatcher is able to do this, but we'd probably need to cover TSLPatcher a little better in tutorials). We also shouldn't be using scripts too heavily to alter global game behavior, but I don't know if I would contest this much because the use case for this is pretty limited.

 

This is where I really have to disagree. Adding to the .git is creating a wealth of compatibility problems, and should be avoided as much as possible, IMO. That means more difficulties for the user, and more problems making mods play nice. Plus, there then need to be TSLRCM-only mods, for instance, which effectively turns most mods into TSLRCM addons, and so on.

 

 

4. TSLRCM Compatibility

 

I think this seems pretty obvious, but at this point, mods should made with TSLRCM compatibility in mind. There are few who still make mods without consideration for TSLRCM, which is completely fine but certainly cuts down on their downloads. It shouldn’t have to be up to the user to ensure compatibility, nor to some other modder.

 

 

That’s all I’ve got for now. Don’t mean to step on people’s toes, and a lot of this is up for debate, so please, any input is welcome and encouraged.

 

Again, I think this is a pretty solid principle.

 

 

 

See this is something I would contest. Sure, it makes sense for compatibility, but I'm not sure I'd agree with coupling together bits of unrelated code.

 

More on this later though. Theoretically, it should not be hard to add another field to a git file, or any of the necessary structures to accomplish whatever you're doing. Once we start tightly coupling  scripts, we're asking for trouble.

 

I suspect this is simpy a difference we're not going to agree on, but personally I'd rather have the mess of attaching unrelated bits of code than create greater compatibility problems and have everyone releasing .git files.

 

 

I'm going to add a few modding standards of my own, which mostly have nothing to do with releasing mods and file structure, and more to do with general conduct...

 

10. Label custom files clearly

 

As I said above, most of my custom files begin "di_" where possible. This (a) reduces conflicts, and ( makes it easier to spot what belongs to which mod, and, if you want to track the mod down again on the basis of your override, makes it easier to find. If you're not doing it, start doing it.

 

11. Release your source scripts

 

This is really just good manners. Chances are 80% of the time your source isn't all that exciting, but it might help out someoe trying out modding for the first time. It's also the only way, if you do make something really nifty, that knowledge is going to remain in the community after you disappear off elsewhere. It also makes it easier for others to make their mods compatible with yours.

 

12. Credit generously

 

In general, credit people more generously, not less. Almost no-one gets anywhere in modding without any help or feedback, so why not show people that it's appreciated?

 

13. Experiment before asking

 

Nearly contradicting my previous point, but as far as possible try things out first, then ask for help from someone else if you can't make it work. This (a) is the best way of exploring what's possible, ( is less annoying for the rest of us ( ), and © is going to make it easier when eithern nobody knows or there's nobody around and you need to work something out.

[VarsityPuppet 1,085]

Well, if I can play the curmudgeon and disagree with a few of these...

Ugh fine.

 

 

 

The downside of this is it takes slightly longer to  work out where an incompatibility lies, it doesn't apply to both games, it's another thing for newbie modders to learn (and another thing for users to work out with mods which install manually/for those who can't run tslpatcher...). I agree with standardising filenames as much as possible. Most of my custom files begin di_ in part because it makes it much easier to identify who made them (which if someone wants to redownload is useful), but also because it (hopefully) prevents identically-named assets for two different mods.

Standardizing file names sounds good. I'm still undecided on the subfolders, mainly because they aren't supported in K1 and I want the standards to be consistent across both games.

 

If we were to enforce a naming convention, what would that generally look like? Care to elaborate on that?

 

 

This is where I really have to disagree. Adding to the .git is creating a wealth of compatibility problems, and should be avoided as much as possible, IMO. That means more difficulties for the user, and more problems making mods play nice. Plus, there then need to be TSLRCM-only mods, for instance, which effectively turns most mods into TSLRCM addons, and so on.

As it is currently, yes. I maybe shouldn't push this too much until the tools I'm imagining come to fruition. It's not hard to edit git files, it's the merging that's hard.

 

 

I suspect this is simpy a difference we're not going to agree on, but personally I'd rather have the mess of attaching unrelated bits of code than create greater compatibility problems and have everyone releasing .git files.

I think I may not have explained myself real well on this end. More on that later, because I'm lazy

 

I'm going to add a few modding standards of my own, which mostly have nothing to do with releasing mods and file structure, and more to do with general conduct...

 

10. Label custom files clearly

 

As I said above, most of my custom files begin "di_" where possible. This (a) reduces conflicts, and ( makes it easier to spot what belongs to which mod, and, if you want to track the mod down again on the basis of your override, makes it easier to find. If you're not doing it, start doing it.

Again, get into specifics. Should it be two letter identifier, or three? Should it include a variation number always/never/sometimes?

 

11. Release your source scripts

 

This is really just good manners. Chances are 80% of the time your source isn't all that exciting, but it might help out someone trying out modding for the first time. It's also the only way, if you do make something really nifty, that knowledge is going to remain in the community after you disappear off elsewhere. It also makes it easier for others to make their mods compatible with yours.

Yes this. I also want to get a repository of TSLRCM and/or K1R scripts going. I know the source is available, but I want to put this on the wiki or a site like github where it's easier to access remotely.

 

12. Credit generously

 

In general, credit people more generously, not less. Almost no-one gets anywhere in modding without any help or feedback, so why not show people that it's appreciated?

 

13. Experiment before asking

 

Nearly contradicting my previous point, but as far as possible try things out first, then ask for help from someone else if you can't make it work. This (a) is the best way of exploring what's possible, ( is less annoying for the rest of us ( ), and © is going to make it easier when either nobody knows or there's nobody around and you need to work something out.

While good, these fall more into etiquette, which we could certainly have a subsection on.

[Guest R2-X2]

I have a question: How do you want to ensure compatibility between mods adding items using existing baseitems? The naming format of textures, models and icons seems quite vulnerable to compatibility issues. Of course anyone with Kotor Tool or any other GFF editor could just change the number of the tgas and the uti's model variation, but people without an idea of modding..? (Which I would suspect the broad majority of players to be.)

[Hassat Hunter 571]

TSLPatcher should be able to do that properly, AFAIK.

 

I personally love editing .git's, but true, I haven't really had to account for other mods at this point I think, rather than my own XD. Of course most mods do drop most stuff in the override, and .git cannot possibly EVER be there, so you need to insert them in the .rim (will be overwritten if TSLRCM) and/or .mod.

 

I'm pretty sure a repository of TSLRCM scripts' is impossible at this point, also slightly due to lack of organisation (our fault). But most files can be de-compiled with DeNCS, there are very few exclusions. And we had to work around stuff we couldn't decompile either (Handmaidens fight on Telos for example).

 

A TSLRCM respitory at this point would pretty much involve all scripts at this point, not much is excluded, so you might aswell take make it a respitory of all TSL files (using TSLRCM).

 

@ sELFiNDUCEDcOMA:

 

I'm not sure a tool exists to merge scripts automatically, so you still need to make enter scripts for all mods you want to be compatible with. And no, there's no way a file executing another file can "outcomment" something happening. That's simply not possible. As I stated before; I really think it's just adding another layer for incompatibility with the added effect of being less lenient on your options what to do. Nothing positive at all.

Also, why, if you can modify the onenter, would you want to execute another script rather than just doing it right there (unless of course engine crap demands it, as seen in the Telos Cantina for example IIRC). Adding more and more 'runs' just adds to being it more likely to have issues, not less.

 

Also the "I have to upload all my files with the next TSLRCM version" doesn't really hold much water after we're pretty much done, it's very unlikely that more is done and if so it's also unlikely to modify the onenter. They're really barely updated per version, big updates like 1.7,1.8 or 1.8.2 excluded.

1.8.3b it was just 207TEL (fixing issues with the Swoopstuff OE had set up) and 351NAR (fixing stuff we had set up inproperly).

 

Some of my own mods editing enter scripts (like My Dantooine Statue) has been as is since 29 janury 2012. Only the .dlg's got updated.

 

I personally see little harm in modmakers double checking if their mods work with the next TSLRCM rather than just "drop and forget" leading to potential issues later down the road. You can always ask me what's changed, and I happily cross-reference the changes to your modified files. And yes, I also do this every single of my own mods.

Rather safe than sorry after all.

 

And it's very likely for alternative onenters to cause issues, just try making one doing a cutscene on the EH, and then running the original onenter. It's going to work poorly.

[Guest R2-X2]

I personally dislike editing the rims, as it is intransparent and makes uninstallation more tedious. You don't edit the bifs either.

[sELFiNDUCEDcOMA 98]

@ sELFiNDUCEDcOMA:

I'm not sure a tool exists to merge scripts automatically, so you still need to make enter scripts for all mods you want to be compatible with. And no, there's no way a file executing another file can "outcomment" something happening. 

 

That's not what I meant. You have an OnEnter script that is made up of include calls, you can comment them in and out and switch load orders prior to compiling it and placing it into you override. Pretty simple really, even if this is something a mod author may end up doing as the average user has no clue when it comes to scripts. Basically creating a range of script variants supporting different mods.

 

 

 

@ sELFiNDUCEDcOMA:

Also, why, if you can modify the onenter, would you want to execute another script rather than just doing it right there (unless of course engine crap demands it, as seen in the Telos Cantina for example IIRC). Adding more and more 'runs' just adds to being it more likely to have issues, not less.

 

Ah, so as to have a LOAD ORDER that can be tweaked by other modders so as to make it more compatibility with other mods.

 

The OnEnter is nothing more than a container that calls other scripts, one that is exposed so as to make modding those modules easier without having to actually modify the modules themselves. If there is an issue, all you have to do is remove the OnEnter script in the Override and it reverts back to the original state TSLRCM safe version.

 

And more "runs" ain't your problem or even other modders' problem, it is the users who try and use this to have 100 mods running at once. Which may not be the case unless they are comfortable with modifying and compiling scripts.

 

 

@ sELFiNDUCEDcOMA:

Also the "I have to upload all my files with the next TSLRCM version" doesn't really hold much water after we're pretty much done, it's very unlikely that more is done and if so it's also unlikely to modify the onenter. They're really barely updated per version, big updates like 1.7,1.8 or 1.8.2 excluded.
1.8.3b it was just 207TEL (fixing issues with the Swoopstuff OE had set up) and 351NAR (fixing stuff we had set up inproperly).

Some of my own mods editing enter scripts (like My Dantooine Statue) has been as is since 29 janury 2012. Only the .dlg's got updated.

 

 

Yes, well it does happen and when it does people expect the mods to be checked for compatibility issues. Not everyone bothers -- because it was once off work or they just don't have the time/interest to do so-- which can lead to some mods not being used anymore due to being perceived as potentially resulting in bugs.

 

From my point of view, this becomes less relevant if OnEnter injecting is used.

 

 

@ sELFiNDUCEDcOMA:

And it's very likely for alternative onenters to cause issues, just try making one doing a cutscene on the EH, and then running the original onenter. It's going to work poorly.

 

 

That's why you have an OnEnter script that is doing nothing more than calling other scripts; some can be called prior to the original, some after.

 

Plus, I didn't say it was a cure all. Sure, OnEnter injecting isn't going to be a solution for every specific problem. But where it works...

 

 

 

But most files can be de-compiled with DeNCS, there are very few exclusions. 
 

 

Does anyone have an active download link for DeNCS..?