Leaderboard

NWScript is closer to C than C#. You have a few issues there: ExecuteScript is for, as the name suggests, executing other, external, compiled scripts. Declare your sub-functions first, before the main. Seems you have some C# influence going on there. If you want to call a sub-function declared inside the same script, you just use its name, along with any requirements. So, for example, simply CombatOnDialogEnd(oBob, STANDARD_FACTION_HOSTILE_1). You don't need to declare constants like the factions, as they are already declared in nwscript.nss and will be converted as needed by the compiler. The order of your declarations is invalid, again due to C# influence. OBJECT_SELF refers to the script owner, not the PC. Since the script will be fired from a DLG, the owner will be whoever owns the DLG, presumably the hostile NPC (you also don't declare it). That is incorrect use of GetObjectByTag - "GetObjectByTag(string sTag, int nNth=0)". Knowing in advance that the Sandpeople Enclave has multiple instances of the same Jawa UTC that you have to account for, something like this should work: void main() { object oPC = GetFirstPC(); object oJawa; string sJawa = "tat20_06jawa"; // I assume you want a DS shift here AdjustAlignment(oPC, ALIGNMENT_DARK_SIDE, 15); oJawa = GetFirstObjectInArea(); while (GetIsObjectValid(oJawa) && GetStringLeft(GetTag(oJawa), 12) == sJawa && GetStandardFaction(oJawa) != STANDARD_FACTION_HOSTILE_1) { ChangeToStandardFaction(oJawa, STANDARD_FACTION_HOSTILE_1); oJawa = GetNextObjectInArea(); } } Although you may additionally need to give them some prompting to attack the PC, depending on how your initial testing turns out. I'd suggest perusing nwscript.nss, which there will likely be a copy of in your Override if you have used KTool. You should also extract the script source (NSS) available in scripts.bif (via KTool: BIFs -> scripts.bif -> Scripts, Source).

Well, if I can play the curmudgeon and disagree with a few of these... 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. This is one I'll be bearing in mind for the future. 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. Again, I think this is a pretty solid principle. 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.

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. Sounds good to me. Well, at the moment I have the following folder structure: 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. 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 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: 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 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. 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. 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.

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.

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

There's a way to do this, It's hard to differentiate between quads sometime. For example.. 30 degrees and 150 degees can't be told apart by their sin values. sin(30) = .5 sin(150) = .5 so we have to examine their cosine values. cos(30) = 0.866 cos(150) = -0.866 Therefore we can tell them apart by their cosine inverse values. arccos(0.866) = 30 arccos( -0.866) = 150 What we can use the sin value for is to differentiate quadrants using a comparison operator. if YOrientation < 0 then the degree is more than 180, if the XOrientation is also less than 0 then the degree is less than 270. Some psuedo code would be like.. float XOrientation; float YOrientation; float degrees; degrees = (arccos(XOrientation) * Pi/180); If (YOrientation < 0) degrees = degrees + 90; If (XOrientation > 0) degrees = degrees + 90; For reference, the unit circle: