Sign in to follow this  
Followers 0
Khettienna

How To: Test a Mod

How To: Test a Mod

If you're interesting in testing mods, you're probably in one of these three situations:

  • You're a general mod user, and you want to test out a mod before adding it to your game permanently;
  • You're testing a mod for someone else, so you can provide them feedback about compatibility and potential bugs;
  • You are a modder, and testing your own mod, either as you develop or when you consider it to be otherwise finished.

Regardless of which of these you are, there are a lot of things you can do while testing to both protect your load order and saves and also generate more accurate and complete testing data. I will show you them! You may want to grab some munchies for the ride. :popcorn:

At the time this was written, nearly all of my experience with modding and testing is for Oblivion, therefore I will be writing from that perspective. I will update things for Skyrim as needed. I have done the best I can to generalize my language when possible so that this guide will work for both games, as well as Bethesda's Fallout games.

I. Multiple Game Installs

This has become, for me, one of the most time-saving testing strategies. For Oblivion, I have several installs, the first of which is almost unmodded - it contains only the latest official patch and the Unofficial Oblivion Patch.

:smarty:Smarty Says: Anyone using Oblivion mods at all should be using the UOP. If you are not using the UOP, you may think you have found bugs in the mod you are testing that actually originate from the vanilla game and are simply exposed by the mod's use of vanilla content. Modders also usually shouldn't fix vanilla bugs in their mods unless it is the purpose of the mod to do so, or they need to include UOP fixes in their mods to make sure both the fixes and the mod's edits work together, because that can lead to unnecessary conflicts. So play to the biggest audience, and let the UOP do its job. If you are testing for a different game, check for similarly-built and similarly-reputable Unofficial Patches for those games.

For my own convenience, I also keep a copy of some common mods (such as OBSE, Cobl, Unique Landscapes, the official DLCs, and a companion) in a nearby folder ready to drop right into this install in case the mod I'm testing has a dependency, needs a compatibility patch tested, or needs to be checked to see if a patch is required. This is a real time-saver for me since I also use this install to make my mods, and find myself contending with those mods quite a lot, but for most testers this is probably unnecessary.

The benefits of using a near-empty install for testing:

  • Makes installing mods to test, and uninstalling them when I'm finished, MUCH easier - even without BAIN or omod packaging.
  • I can test the mod by itself, and know that bugs I find are not related to compatibility issues.
  • I can see the mod without the effects of modded weather, water, models, or textures, which makes it easier to spot visual flaws.
  • The game runs smoother without my usual 12 gigs of stuff shoved into it, so I can test for performance issues with the current mod more accurately.

My second install is my actual for-play install. It's got all kinds of stuff in it, and I've pushed my machine's performance limits as far as I will within my own tolerance. I generally only test mods in this install if I think it will benefit in one of the following ways:

  • I can test for compatibility in the greater sense - does the mod play well with a fully-modded game?
  • Script-heavy mods might function more or less reliably depending on the game's performance and how many other scripts are running.
  • I have a few mods that just kind of permeate the world, testing with them allows me to see how the mod will interact with them.
  • I can see how replacers will affect the visual design of the mod I am working on.

:smarty:Smarty Says: If the mod you are testing has a lot of loose files, you may want to package it yourself in such a way that it can be automatically installed and uninstalled. Common methods are BAIN, omod/fomod, or just simply creating a .bsa of the resources. This way you won't risk leaving loose files behind.

So, how to you get multiple installs? I've explained this in a separate tutorial here. The short answer is that unless you want to do it by hand (which is not as bad as it sounds), grab a utility to do it for you if one is available for your game. InsanitySorrow's application, MOM, and mTES4 both handle multiple installs for Oblivion, and InsanitySorrow is currently busy working on a similar application for Skyrim.

II. Multiple Saves

You might be shocked at how much and what kind of data actually gets stored in your saved game. Given that most of my mods are interior overhauls or new interiors, one of the most common examples of "dirty save" data I encounter while testing is that since my character has already been to the cell I have modded, I find objects out of place. Or there when they shouldn't be. Or not there when they should be, etc... you get the idea. But if I test the same location with a brand new character who has been coc'd to the location straight from the tutorial dungeon, I will see that everything is A-OK. So, as you can see by this example, it is quite useful to test some mods with multiple saves!

So, besides interior decorating shenanigans, some other examples of mods you should test with multiple saves are:

  • Any mod that depends on vanilla/DLC/other mod quests or parts of quests being complete. Make sure the changes the mod brings about happen how they should regardless of if the mod is loaded with a save that has already completed that part of the quest, or if the character completes that part of the quest while the mod is already loaded. Good examples of this are mods that should not start until the player reached a certain level, has completed the main quest or other large quest chain, or should not start until the player completes the tutorial quest, and things of that nature.

  • Any mod with a known conflict with another mod, particularly if they edit or depend on vanilla/DLC scripts or quests. Sometimes the conflict is only true during certain quest stages from either mod or the vanilla game. For example, Mod A might lock a door that Mod B needs the player to be able to use freely - but perhaps only at certain times during each quest. Testing with a save where your character has already done one quest or the other might not show this conflict.

  • Any mod that handles character stats, leveling, etc. Test how that mod works when used with a new character, versus one that already has some levels and experience. When they both hit the same level, see if their stats are even, things like that, to make sure the mod works retroactively (if it is meant to).

  • Mods that are heavily dependent on faction or disposition. Is an evil character able to complete it as well as a good character? An unknown underdog as well as a lauded hero?

  • Particularly in the case of leveled dungeon mods, it is good to test with characters of varying levels to be sure the challenge is even enough across the board.

  • Also with dungeon mods, particularly gimmicky ones, test with all three class archetypes (warrior, rogue, mage). Some gimmicks may end up being impossible to complete for some classes, or trivial to the point of bugginess for others.

  • Sometimes you (or the modder you're testing for) will have fixed a bug in a new version, and want to be sure the fix applies retroactively, so it is good to test with a character who has never experienced the bug to make sure it doesn't happen in the first place, and a character who has experienced the bug to make sure it is now fixed.

  • Mods with gender-specific storylines, dialog and/or text. Try both a male and female character, and make sure your character is addressed/referred to appropriately. Check not just dialog, but also notes, letters, and quest journal entries.

As you can see, it's good to keep a few varying saves for testing! Some DOs and DON'Ts regarding multiple saves:

  • DO use the console to your advantage with a brand new save. You can coc right out of the tutorial dungeon to the in-game testing site; if you don't know its cell ID, just pick one you do know, and fast-travel/carriage ride/teleport/walk yer lazy bum to it.

  • DO make use of uploaded testing save packs! They can save you a ton of time when you need to have legitimately reached a certain level, skill, or quest stage without the console.

  • DON'T use test saves that were made with unknown or lots of mods loaded, because they might have all kinds of crazy bugs and bloat. The best saves to use are ones that were played mod-free and cheat free, with an exception for unofficial patches. Especially don't use any that were leveled/skilled/quested via console.

  • DO use your own well-played, well-loved, modded-to-heck character for testing to see how the mod will function in a more realistic setting, but verify bugs against clean test saves before reporting them. The clean test saves should be your "control variable".

Now, let's talk about things you can do in-game while actually testing!

III. Console Use

I cannot stress enough how much time the console can save. You can find a long list of Oblivion console commands at the wiki, so I won't list them, but I will suggest ways to use them you might not have considered.

The first is for note-taking. One of my favorite methods is to open the console, target something that is buggy so its form ID is printed on the screen, and type a note about it in the console. However, I do not press the ENTER key after typing the note - instead, I take a screenshot. Now I have the note, and the visual, and the form ID all in one file; at the end of the testing session, I can either transcribe my notes and offer screenshots where required, or just send the screenshots. You might also want to toggle on debug text to include that data in your shots.

Speaking of debug text (TDT in the console), if you have it running, try setting different debug text types (SDT 1, SDT 2, etc...) while you have something targeted in the console to see all the different kinds of data available in-game. FPS, current AI and/or combat procedure of your target, video memory used, current cell ID, etc... and that's just the beginning. This can be VERY useful data to see in-game, and to have on your screenshots for you or the modder you're testing for. More details here!

If you enter an area of a mod where performance seems particularly bad, use TBL to toggle on bright lights. Doing this maximizes ambient lighting, thereby voiding all node lighting (placed lights) and directional lighting (weather, etc...). This is a great way to test for OLS (Overlapping Lights Syndrome), which is one of the most common mod ailments. If your performance normalizes with the bright lights on, you have found the culprit! Eat a cookie.

Likewise, there are other commands you can use to test performance issues. TAI will toggle all AI - if toggling it off normalizes your performance, there may be too many NPCs crammed into the loaded area. If it prevents a recurring crash, it is quite likely that one or more NPCs in a location have either buggy or no defined AI, or buggy animations.

Does performance get chuggy when your character is facing a particular area, even with the bright lights on and AI off? Start using the console to disable objects one at a time, noting how the performance feels after each one, until you find the one that makes a huge difference. Sometimes a poorly-rigged model or even just a super high-poly model can cause this. The modder may want to know, so they can decide whether to use a different model or just accept the performance hit.

If an NPC isn't doing what they ought to be, use the EVP console command on them, and see if they right themselves. Whether they do or do not, report this to the modder, they need to know!

SAFE CONSOLE USE is important as a tester. Modders cannot expect other users to know how to use it or even have access to it, and you are testing to be sure the mod will work for as many users as possible! Here's some DOs and DON'Ts:

  • DON'T save the game or continue playing after console use (other than for note-taking). Exit & start over without console use so that your testing save won't be affected.

  • DON'T use the console to toggle collision, god mode, AI, or anything else while playing through a mod location unless you have completely exhausted all other means of finding a bug. These things can break scripts and quests in ways you might not see until much later, which will result in false bugs down the line. If you MUST use the console to proceed, make sure you inform the modder you're testing for of exactly what you did so they can take it into consideration. E.g., if you can't find a dungeon exit anywhere, so you toggled off collision to see if you could find an unintentionally hidden door, make sure the modder knows - your being unable to find a door normally is useful information. And make sure you reload your game to a save before you used the console!

  • DON'T use the console to advance quest stages, give yourself quest items, move yourself to quest targets, or muck with quest progression in any other way. Play them out the good old-fashioned way unless you get completely stuck, in which case ask the modder for help. When you know enough about the mod you're testing to break this rule, you will be quite certain of it.

  • DO use the console to give your character trivial vanilla items you need, as long as those items don't need to be acquired a certain way. For example, if you are testing a dungeon, feel free to give yourself lockpicks when you run out. Give your character the gold you need to buy the house, or the skill you need to join the guild, or a basic set of level-appropriate vanilla gear if you don't have one, things like that. It is usually also safe to give yourself a super high carryweight/set the encumbrance multiplier really high so you don't have to interrupt your testing to sell stuff. There might be times it's not okay to do this, such as a specific part of a quest where your stuff has all been taken away or your skills have been reduced as part of a quest - in those cases, just stick it out and play how it's meant to be played.

IV. Test EVERYTHING.

There are two ways to go about testing a mod, and the most dedicated tester will do BOTH.

The first is to play through a mod how most players will. Stick the path most traveled, go with the flow, look for the obvious solutions. Enjoy the experience of the mod from an end-user perspective. This is really important, because modders need to know if their puzzles are reasonably solvable, their enemies reasonably defeatable, and the overall experience altogether enjoyable. Their mods will get used by players with all level of gaming and mod-using experience, after all. So from installation to in-game start to in-game finish to uninstallation, do it like your only real understanding is how the base game works and your only reference is the documentation provided. Put your Soopar Seekrit Modder/Pro-Gamer Knowledge in a box until it's time to write up the bug report.

The second is to the play through the mod like the Mayhem guy in those car insurance commercials. Activate EVERYTHING, every lever, every door, every container. Talk to EVERY NPC. Loot EVERYTHING, and check how items appear in your inventory, and what happens when you try to drop them. Do things out of order, see if the quest still works. Try every response in dialog in every possible order, see if you can break a quest that way. Turn on bright lights or use light/night-eye spells in dimly lit or unlit areas, and nose around in every corner. Try to crawl/jump through openings that are obviously not meant to be traversed, see if you can go through, see if you get stuck. If there are in-game options, try them all in various combinations - do any not work together or at all? Try exploiting the environment (bunny-hopping up mountains, side-walking across mountains, things like that). Try to trivialize enemy encounters with kiting, ranged attacks, trapping large enemies in small spaces, etc... you get the idea. Do things that are obviously a bad idea for your character's safety, make sure they are actually dangerous, and see if you can save yourself from there or need to reload. Basically, be as nosy and destructive as possible within the confines of the game's rules and without the use of the console or mod-added cheats.

If you're Mayhem, like me, here are some particulars to check for (or, common bugs):

  • Make sure tileset pieces are aligned correctly, with forgiveness for the fact that even still there might be a 1-pixel seam (the vanilla models aren't perfect).

  • Many models aren't actually complete; for the sake of performance, they may not have a backing or a bottom, because those sides shouldn't be exposed to the player anyway. Check all objects from all angles. Common culprits are candles and wall fixtures resting placed sideways (as though stored or fallen), tileset or architecture pieces used in unconventional ways, and dungeon-related clutter and debris models.

  • Make sure placed objects are fully on the floor or other resting surface, but are not sinking too far in.

  • You should not be able to see the roots of placed trees or flora, with rare and obvious exceptions (like Nirnroot).

  • Candles with extra drippy pieces are difficult to place just right, so double-check those.

  • Because of the convex shape of barrels, double-check their sides aren't clipping into other objects.

  • Furniture with legs and rugs - if not all the legs are on the rug, make sure the other legs aren't floating off the floor.

  • If equipping or activating something starts a message box, try ALL the options in varying orders to see if you can break it.

  • Try telling a quest NPC "no" at first, and see if you can still say "yes" later.

  • Before running off to go do the quest, talk to the NPC again after saying "yes", and make sure he/she isn't still asking you to do the quest; likewise, make sure the quest doesn't complete early.

  • Try dropping or storing quest items both when they are needed/the quest is still in progress, and after the quest is complete.

  • Try turning in a quest without the required item(s) in your inventory, and see if the quest NPC notices.

  • Also make sure that the quest item(s) are, in fact, taken from you when you turn them in.

  • Lightly bump into shelves and tables, see how much stuff goes flying or what carefully-arranged displays get disrupted.

  • Double-check bookshelves to ensure objects aren't placed clipping into the shelves or the backing.

  • Randomly use vanilla containers and activators outside of the mod's location, as sometimes modders accidentally overwrite the vanilla versions of these when they meant to create their own unique ones.

  • Randomly talk to NPCs not related to the mod to make sure they don't have dialog related to the mod.

  • If there are multiple objects making up a light or flame fixture, bump them to be sure they are static (otherwise the object might move while the light remains still).

  • Read every book and note to check for grammar, spelling, and formatting.

  • Try mod-added spells on different objects - NPCs, containers, landscape, whatever, make sure the scripts work (or don't) as appropriate. Check to make sure that mean spells are hostile, and neutral/utility or nice spells don't start a fight.

  • Try mod-added gear on both male and female characters, with mer and man and beast races, and use it both third- and first-person, and under varying lighting conditions.

  • Use all mod-added weapons in actual combat, not just target dummies. Check scripted weapons to be sure their effects/counters work only on live targets.

  • Check mod-added items in the inventory menu to make sure they have appropriate icons, and drop them to be sure they have appropriate world/ground models.

  • For spells, enchanted items, ingredients, food, and potions, check their menu descriptions! For example, hover over a mod-added spell, and be sure its listed effect doesn't simply say "Script Effect".

  • Pick fights with important NPCs. See if they die, or if their new hatred of you breaks the quest.

  • Don't help while following NPCs during escort quests. See how long they can fend for themselves, and if that seems like a reasonable amount. Most modders will want you to have to help in these scenarios, but escort NPCs should at least be able to survive a hit or two, as the AI system will not automagically point all enemies at the player right off.

  • And likewise, be sure all NPCs function properly in combat. Some are meant to flee, some are meant to fight, some should be casters, some should be archers, etc. The modder might not have expected particular NPCs would ever be engaged in combat, but other mods (like overhauls) can make that happen pretty easily.

  • If an NPC is following you, try to ditch him or her, and see if/how long it takes them to catch up. See if quests that should depend on the follower being present progress without them.

  • Try skipping ahead in a quest without the console. E.g., if you already know you need to talk to an NPC and then go find an item, try skipping the dialog and just retrieving the item, and check both if the NPC still thinks you haven't got the item yet and if you can just turn the item in without having the conversation.

  • Check sideways/upside-down furniture in post-disaster scenes to be sure it can't be activated, as there are unusable static versions meant for this purpose.

  • The one and only exception I can think of to my no console rule: toggle off collision to venture outside the intended play area to check for placed objects that don't need to be there because the player can't access them. The game will still try to render them, thus they are eating performance for no good reason. One or two is not an issue, but for example, you might find a tiny dungeon cell is really huge when you pass through the walls, with 100 more tileset pieces and lights, enemies, and everything that the modder left behind. This kind of stuff should be cleaned up!

  • Try de-activating the mod's plugin(s) without playing all the way through it, at various random points. Is your character safe? Are your stats normal? Do you have any spell effects you shouldn't? Do you have all your stuff?

  • Whether or not the mod states it requires a script extender, try using it without, and see what happens. If it basically functions but only a few small things break, or you get the same problem every time, the modder might like to know. It can make troubleshooting for users much easier for later.

:smarty:Smarty Says: The hardcore Mayhem testers always bring a Wabbajack. Smarty is not kidding.

On the topic of checking text for errors, here are some common text/dialog errors:

  • Make sure the names of items, quest journals, NPCs, doors, containers, furniture, and activators have the first letter of each word capitalized to follow the vanilla capitalization convention.

  • Watch out for misuse of your/you're, its/it's, then/than, their/there/they're, etc...

  • One space should follow a comma.

  • Elipses should have a single space after them OR before them... depending on if the speech is trailing off or building from thought. ...See what I did there? :bagged:

  • Watch out for comma splices and run-on sentences. In dialog, comma splices and run-on sentences may be used deliberately to emulate natural speech patterns. Try reading the line aloud yourself to see if it sounds natural and makes sense.

  • Watch out for the use of "God" (singular) as a proper noun, likewise Earth, Heaven, Hell, and other such terms that have no meaning in Tamriel.

V. Companions

Followers can really throw a wrench into a modder's plan for any mod location. Do a test run with a companion, and check the following:

  • Can the companion use the objects in the area, if they should be able to?

  • Can the companion follow you comfortably through the whole area? Does their pathing seem natural, or do they walk/stand on tables or other places that aren't normal floor/ground space?

  • If the documentation asks you not to bring a follower with you, and you do anyway, what happens?

  • If the documentation doesn't specify whether you should bring one or not, does bringing one make it too easy?

  • While using the companion, do message boxes or other events happen at non-sequitur times? For example, a scripted door might have an OnActivate script so that something special happens when it gets used - but maybe that event should only occur when the player uses the door, and not any NPC.

  • Does the companion play nice with your mod-added allies? Does the companion fight with your enemies from the mod?

  • Will the companion equip the mod-added gear and use it, and does it look normal?

  • If you are silenced or have had all your stuff taken as part of a quest, and it has not been specified that you shouldn't bring a companion, are these effects also applied to your companion?

:smarty:Smarty Says: Remember that when testing with a companion, you are then using another mod in conjunction with the one you're testing, any bugs you encounter could be a bug in the companion mod! Try to use super simple companions for this reason, rather than very complex ones (sorry, Vilja, we still love you!). It might also be good to try to reproduce bugs you find with a very different companion, just in case.

VI. And when you're done...

You're not really done. XD

Now that you've installed, played, and uninstalled the mod, here are some points for you to consider and possibly report on:

  • Were you able to install the mod based purely on the instructions given in the documentation?

  • Other than bugs, were you able to play through the mod with just in-game cues or good old-fashioned problem solving? How often did you have to refer back to the documentation? Was there a high learning curve?

  • Were there points during gameplay where you had to do things that seemed really illogical to progress? I.e., your character must have been psychic to figure out the next step, or you had to use an item or object that seemed unrelated to the content to trigger an event?

  • Were all the locations reasonably easy to get to? Not in terms of map markers and fast-travel, but on foot - were the paths well-marked and easy to spot? Did the intended route take you through difficult, unrelated areas? Was it stuck up high in the mountains, and how much time did you spend fumbling around blind to find a path?

  • Did the effort and time spent seem balanced with the reward, excitement/suspense, and/or overall enjoyability? I.e., were there excessive amount of empty space/travel time for seemingly no good reason, was there an hour's worth of redundant enemies to get to the end boss, or did you enjoy the journey? Alternately, did it feel like the win was just handed to you? Note that this is pretty subjective, so remember to be respectful with your feedback.

  • How difficult was it to cleanly uninstall the mod? Did you have dig loose files out of a bunch of folders that were kind of everywhere, or was it packaged neatly enough to not be an issue? Note: Many mods still in beta will not be packaged any neater than they had to be to get them to you for testing, in these cases I'm sure you made an omod/fomod/BAIN/.bsa and won't be troubled about it. :D

  • Once the mod is uninstalled properly, go back in-game, and nose around. Make sure all vanilla locations and NPCs that were changed by the mod are back to how they were before you installed the mod. Make sure your character is how it should be; again, is your character safe? Are your stats normal? Do you have any spell effects you shouldn't? Do you have all your stuff?

  • Make sure you rebuild your Bashed Patch after you uninstall the mod, if you have one!

VII. Compatibility Testing

Not all modders or testers do compatibility testing. Not all mods need it, anyway - it just depends on the scope of the mod. But here are some common scenarios you might want to look into if you're willing to go above and beyond!

Landscape Mods - Unique Landscapes for Oblivion, for example. These guys take up a HUGE portion of Cyrodiil's backyard, so if the mod you're testing adds exterior locations, you might want to test with popular landscape mods for the game you're playing.

Large Quest Mods - Like landscape mods, these tend to add a lot of exterior locations. They are also prone to borrowing vanilla NPCs, so if the mod you're testing also does this, pay special attention.

Survival Mods - If you are testing a quest or dungeon mod, you may want to trying testing with a survival mod to be sure players who use them can keep their characters alive in your mod. Perhaps you just need to leave a few food barrels or a water source here and there, or add an option that allows them to bypass a long time lapse.

Tweak Everything Mods - Cobl is a good example of this for Oblivion, it has dozens of little game tweaks that might affect the mod you're testing. Off the bat, I will point you to its option to allow the player to move/drop quest items for consideration.

Overhauls - These can make the game much more challenging by adding extra enemy spaws to vanilla Leveled Lists. If you are testing a dungeon mod, see how much harder it is with an overhaul, and how that affects performance. Some overhauls also add a lot of small exterior locations, such as camps and hovels.

Interface Mods - These can affect how items appear in inventory, what books and notes look like, even how long of a name an object can have before it gets clipped. If any of this might affect any part of the mod you're testing, consider trying it with the vanilla interface, and then again with one of the popular interface mods.

Popular Replacers - A slight change in models or textures can sometimes have a huge impact on how an area looks, so if the mod you're testing has a lot of aesthetic components, try it with your favorite replacers and see how it takes.

Anything that is Super OMG Popular - If many thousands of people use it, and you have any reason to believe there could be a conflict, you will probably reduce the total man hours spent by all people on this earth if you find the conflict before the mod you're testing is released. Even if the modder cannot or chooses not to fix or patch the conflict, they can note it in their documentation and save a lot of people a lot of time.

IIX. Feedback

If you have gotten this far reading and have done or will be doing even a third of the stuff in this guide, I can only assume you are a modder testing your own stuff, or you are a tester giving a modder a helping hand. You now have some serious perspective on how much goes into making a mod and making sure it works for all kinds of users and players and characters. If your brain is still intact, I salute you! :salute:

...Mine sure isn't!
:woot:

As your final step of testing, please open your mouth and insert a cookie. If you are testing a mod for a modder, it's time for you to start aggregating all the data you've collected into some kind of readable format!

Some DOs and DON'Ts for feedback:

  • DO include as much detail as possible about each bug, including the steps to reproduce it if possible.

  • DON'T crit the modder with a huge wall of text, like I've just done to you! Use short paragraphs, bullet points/lists, linebreaks, and things like that to make it easy to digest the report one piece at a time. Use screenshots in lieu of super long visual descriptions, and link them directly in your report.

  • DO sort your information. If you are testing a quest mod, for example, list the bugs in the order they would be encountered in a normal play-through.

  • DON'T include any subjective feedback (your opinion, in other words) unless it was asked for. Just the facts, Ma'am. :police:

  • DO, however, note if anything seemed difficult to the point of bordering on impossible - things that would make the mod unusable for many people are worth reporting, subjective or not.

  • DO consider that if a modder has given you something to test, they have probably worked super hard on it and want it to work well, so be respectful!

  • DON'T report a bug that you aren't 100% sure about, without also saying that you're not sure about it, and why. These "maybe" reports can be very valuable, but will cause extra trouble if they are not marked as "maybe".

  • DO give the modder lots of information about your character and his/her game progression, your load order, and your hardware!

  • If your testing wasn't completed in one session, i.e. it's a long test where you'll make several reports, DO ask the modder to give you hints or help with anything you're having trouble with.

  • If you are a modder yourself and have a good rapport with the modder you're testing for, DON'T be afraid to poke around in the Construction Set/GECK/Creation Kit to see if you can find an easy solution to a bug. Not all modders will appreciate this, so it is wise to ask before you start testing if they want that kind of help, and respect the decision. The ones that do appreciate it will definitely show it.

  • DON'T be afraid to report small bugs, even if they seem nit-picky. Let the modder decide what is or isn't worth fixing.

  • DO break the rule about keeping your opinion to yourself every now and then to remark on something you genuinely like about the mod or give the modder some encouragement. Share the love & cookies, it will show in the finished mod. :wub:

Mod creation is somewhat a community effort. Even if the mod was conceptualized, designed, coded, recorded, modeled, scripted, and textured by the one person, that one person cannot test the mod under every possible set of conditions. Modders who don't have testers helping them have to wait until their creation has been released to the wild and subjected to the whims of the public before getting any feedback. However, modders who have testers helping them before release can better focus on making the improvements to the mod, and they can also be more confident about releasing and provide more accurate documentation, making the mod better for everyone all around, and making life exponentially easier for the modder.

If you're a modder and you're doing this all on your own, don't forget that we have in-house testers right here at TESA! The BTA Guild is, at the time of this writing, enjoying some quiet time as we gear up for the release of the Skyrim Creation Kit, but we'll be back open for business sooner than you can say "dirty edit"! We appreciate your commitment to your projects, your users, and the community.

So go on, have another. :cookie4u:

Disclaimer: This guide and its author are not responsible for calories consumed or weight gained due to instructions given in the guide.

0

Share this post


Link to post
Share on other sites

Oi! I haven't read through all that yet, but looking good so far. You've certainly covered a lot of material. I do have one comment. In this section:

...

:smarty:Smarty Says: Anyone using Oblivion mods at all should be using the UOP. If you are not using the UOP, you may think you have found bugs in the mod you are testing that actually originate from the vanilla game and are simply exposed by the mod's use of vanilla content. Modders also usually shouldn't fix vanilla bugs in their mods unless it is the purpose of the mod to do so, because that can lead to unnecessary conflicts. So play to the biggest audience, and let the UOP do its job. If you are testing for a different game, check for similarly-built and similarly-reputable Unofficial Patches for those games.

...

Very true, but there are times when you do want to copy the UOP changes into your mod. You certainly don't want to copy all of them, but if you are modifying something that the UOP fixes, you should copy the UOP's fix in as well. These fixes aren't the purpose of your mod, and as you say, you would normally leave the UOP to do its job, but if you don't replicate the fixes then your mod may wind up undoing the UOP's fixes.

We've got users who don't have a Bashed Patch and even if they do, some of the changes we make would override the UOP fixes anyway. For example, we needed to modify the script on the Dark Brotherhood Sanctuary door. When we did that change, we had to copy the UOP's fix to that script as well. You will find a similar thing if you modify a NPC. Let's say you add extra dialogue to an existing NPC. If that NPC has some fixes from the UOP, those changes should be replicated. Arthmoor recommends making these changes as well and has done the same thing with his mods, where required.

0

Share this post


Link to post
Share on other sites
Very true, but there are times when you do want to copy the UOP changes into your mod. You certainly don't want to copy all of them, but if you are modifying something that the UOP fixes, you should copy the UOP's fix in as well. These fixes aren't the purpose of your mod, and as you say, you would normally leave the UOP to do its job, but if you don't replicate the fixes then your mod may wind up undoing the UOP's fixes.

We've got users who don't have a Bashed Patch and even if they do, some of the changes we make would override the UOP fixes anyway. For example, we needed to modify the script on the Dark Brotherhood Sanctuary door. When we did that change, we had to copy the UOP's fix to that script as well. You will find a similar thing if you modify a NPC. Let's say you add extra dialogue to an existing NPC. If that NPC has some fixes from the UOP, those changes should be replicated. Arthmoor recommends making these changes as well and has done the same thing with his mods, where required.

That's all very true, because you're changing a record also changed by the UOP. I'll word that into the tutorial, thanks!

0

Share this post


Link to post
Share on other sites

Amazing write-up Khettienna. :bowdown: And you put this tut together so fast! The amount of useful info is huge and very well organized. Since my next planned mod is going to be very large compared to my previous ones, I will be using this info as much as possible and I will also be using testers as well. Thanks for all the time you put into this. :pints::jellytime::clap::cookie4u:

Come on CK!

0

Share this post


Link to post
Share on other sites

This should be required reading for people in the beta testers guild. It is very well done Khett.

0

Share this post


Link to post
Share on other sites

Good work Khett. I read through it all. Very thorough and I think you covered all the points.

If you're a modder getting your mod tested, don't discourage the nitpickers. Believe me, if you've worked for years on a mod, it is blinking bloody hard to see your masterpiece ripped apart by a tester. But if you are fortunate enough to have a nitpicker, encourage him or her. It will drive you crazy, but in the end, it's worth it. You can choose which bugs to fix and which ones are just too picky and so you ignore. We had a tester who actually complained about the number of spaces we had between sentences in the journal entries... But she helped us build a solid mod that had very few issues when released to the public. And she definitely used Khett's "mayhem" technique. Because of her, we had to put a check in to prevent players from running ahead of an escort at one point. We put a custom message in that scolded her for being impatient. Nobody has found that little Easter egg, yet.

Getting your mod tested isn't easy, but it will pay off in the end. Just take a deep breath and work through the bugs they find. You are creating a solid product - don't forget that.

0

Share this post


Link to post
Share on other sites

Great tutorial, Khett! :thumbup: I had to copy/paste it into a Wordpad file and save it in my Reference folder (yes, I have a folder full of modding tutorials :P ). A very welcome addition. Thanks! Have a :cookie4u:

0

Share this post


Link to post
Share on other sites

Thanks for the feedback, all! I've added a couple things to the tutorial, just in case it wasn't long enough already! I also went back through and cleaned up a lot of typos.

Mayhem Addendum:

  • Try turning in a quest without the required item(s) in your inventory, and see if the quest NPC notices.

  • Also make sure that the quest item(s) are, in fact, taken from you when you turn them in.

Feedback Addendum:

  • Don't be afraid to report small bugs, even if they seem nit-picky. Let the modder decide what is or isn't worth fixing.


AB's response reminded me of a whole other subsection I meant to add about common text errors:

  • Make sure the names of items, quest journals, NPCs, doors, containers, furniture, and activators have the first letter of each word capitalized to follow the vanilla capitalization convention.

  • Watch out for misuse of your/you're, its/it's, then/than, their/there/they're, etc...

  • One space should follow a comma.

  • Elipses should have a single space after them OR before them... depending on if the speech is trailing off or building from thought. ...See what I did there? :bagged:

  • Watch out for comma splices and run-on sentences. In dialog, comma splices and run-on sentences may be used deliberately to emulate natural speech patterns. Try reading the line aloud yourself to see if it sounds natural and makes sense.

  • Watch out for the use of "God" (singular) as a proper noun, likewise Earth, Heaven, Hell, and other such terms that have no meaning in Tamriel.

Regarding the number of spaces between sentences: Traditionally, two spaces are used between sentences in typed text; however, in vanilla Oblivion dialog and quest journal text, only one space separates one sentence from the next. Confusingly, two spaces separate sentences in some Oblivion book text, but not all. Which is correct, then, in the context of modding? I feel like the width of in-game fonts makes two spaces stick out as "wrong", but I've done it in my own mods anyway out of habit. Gosh darn the Interwebs, I blame HTML for this one-space trend. XD

I've also finished the tutorial for managing multiple game installs by hand. Actually, I finished it yesterday and forgot to update the link. But it's updated now. :D

0

Share this post


Link to post
Share on other sites

Yeah, it's supposed to be two spaces after a full stop, like periods and colons, but as you said, html strips those out. We've settled on one space for dialogue since you're pressed for the number of characters anyway. You can use one space or two spaces for journal entries, but the font the game uses for journal entries seems to make enough room with just one space. Whichever you pick, be consistent. That was our tester's complaint.

And yeah, the grammar and stuff is important. It really stands out, so take the time to get it right.

0

Share this post


Link to post
Share on other sites

Very nice! Thank you Khett for writing this up. :)

One thing I noticed being a Wrye Bash user is the wording here:

"* If the mod required you to rebuild your Bashed Patch after installation, make sure you rebuild it again after uninstalling the mod!"

If a mod user or tester uses Wrye Bash they need to rebuild their patch regardless of what a Mod Maker might suggest, both upon installing and removing any mods. Perhaps it might be better worded as "Remember to rebuild your Bashed Patch if you are a Wrye Bash User." (?)

In any case I think this is fantastic information for anyone who makes, tests or even just uses mods. :thumbup:

0

Share this post


Link to post
Share on other sites

Excellent guide. Especially the part about valuing a nit-picker if you happen to find one. It's all too easy to get tunnel vision with you're own work and overlook those nits because you know how to avoid them or because you don't even see them anymore.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0