Category:About Modding Etiquette

Things to know when making a Mod

• Keep your mod clean. Information on cleaning mods can be found in the Mod Cleaning Tutorial.

• Keep any new dialogue clean. Information on unclean dialogue can be found in the Unclean Dialogue Tutorial.

• Don't create self-centered dialogue that adds topics or greetings to all NPCs in the world, without a means to avoid them. Another modder might want to create a NPC that knows absolutely nothing about current events or doesn't care about them. If you want to add generic topics to all NPCs, add them to the quest "Generic" or make your own quest and test for "GetIsPlayableRace == 1" and "GetInFaction ForgottenOnesFaction == 0".

• Don't click on Recompile All in the Script Edit window of the TES Construction Set. Doing so includes all of the scripts from currently open TES Files in your mod making it bigger in file size and possibly interfering with somebody else's mod.

• Include alterations to Worldspaces in the Summary window of your mod, in the description of the downloadable file, and on the Mod Worldspace Alterations page.

• Keep your scripting as efficient as possible. Scripts can very rapidly add up and kill performance if too many are running at once - ensure that your scripts are only running when they need to be. Avoid Global Scripts as much as possible, and avoid using PlaceAtMe to create new copies of an object when you could simply use MoveTo on an existing object.

• Keep game balance in mind when creating mods. Making an item that would normally need recharging use no charges or creating super spells with little or no magicka cost will severely alter the balance of game play.

• Include a detailed Readme file along with your mod. A good readme provides a description of the mod's features, any potential bugs or technical issues, a list of changes made to existing objects, possible sources of conflict with other mods, and some information on how to contact you in the event that a user encounters a problem with your plugin. Creating the readme as a plain text file (such as one written in Notepad) ensures that everyone will be able to read it. And to avoid overwriting another mod's readme, give it a unique name, such as "YourModName - Readme!"

Here's a sample readme template (modder's resource) that includes instructions for how to best deal with ArchiveInvalidation problems.

• Flag an unfinished mod as alpha or beta release. Unfinished mod include those that have known bugs you weren't able to fix yet as well as mods with missing or awkwardly substituted stuff (for example a pants-icon as placeholder-icon for a new skirt model)

• Make your release OMOD-ready by including OMOD conversion data for Oblivion Mod Manager. This avoids the need to release a separate OMOD version while still giving users an easier way to create their own OMOD. In an OMOD-ready archive, all the "omod conversion data" is pregenerated and included as a separate directory, including readme, install scripts (if any), screenshot, etc. This way, when the user goes to create an OMOD from the extracted download, OBMM finds that directory and asks if you want to import the conversion data.

You should probably include a very brief OMOD_or_Manual_Install.txt file explaining the steps. Feel free to use any of the files included in this small mod package as a guideline  (I'll post a separate modder's resource version as soon as possible).

The best thing about this approach is that it works just as well for users who like OMODs and those who don't (the only difference is the one extra directory in the archive).