Navigation-

Welcome

This page is a collection of tips that may be useful when modding with Morrowind.

Also, please note that these tips were not made by me. I have just hosted it here in order to make it more available to those who might need it. This has all been copied from a post on The Elder Scrolls Forums.

Play Before Modding - by Klinn

Play Morrowind quite a bit before even looking at the Construction Set. At least finish the main quest, and try advancing through a few of the many guilds/factions. There are three main reasons why I recommend this:

1. The Construction Set is addictive! Once you start modding, you may never find enough time to go back and play the game itself.

2. You'll have a better feeling for the 'Morrowind Universe'. When you release your mod, other players will initially expect it to fit into the world of Morrowind as they have experienced it. If your mod runs counter to the internal logic of the game world, it will be jarring and puzzling. That doesn't mean you shouldn't try doing new and original things, but be prepared to explain why all the Khajiits are now 32 feet tall and breath fire. By playing Morrowind extensively, you'll have experienced the same things as other users and can predict their expectations and reactions to the mini-world you've created.

3. You won't 'break' the game for other players. If you know what's involved in many of the quests, you won't accidentally do something that disrupts them. It doesn't have to be a literal 'break', i.e. killing some journal entries so the player can't advance in a quest, but other aspects of the adventure too. For example, late in the main quest the player comes across some very unique tools. It would seem strange to have a bunch of those suddenly turn up on some shopkeeper's counter, that would steal something away from the main quest.

Where To Begin? - by Klinn

When you first open the Construction Set, there's a whole pile of windows and buttons, but not much indication about how to proceed. And with all due respect to Bethesda, many people find the tutorials in the Help file are, ahhh, rather confusing. Rather than fighting with the Editor and getting frustrated, take advantage of other modders' experience. There are a number of good beginners tutorials out there. Although it's an older one, I still recommend Dragonsong's "My First Room". (link in pinned thread)

The "My First Room" tutorial starts right at the beginning, describing how to load the master ESM files so you can see the existing Morrowind world and its objects, and continues from there. It's great for explaining not just the 'how' of using the Construction Set, but the 'why' as well.

Two cautions: Dragonsong's tutorial was written back before the Tribunal and Bloodmoon expansions were released for Morrowind. As a result, it doesn't mention one issue that often puzzles new modders - a ton of error messages that appear when loading all three master ESM files. Or if only the Morrowind ESM master file is checkmarked, a bunch of weird 'GMST' entries appear in the mod's Details list. Please refer to one of the pinned threads for details about the problem. Secondly, I feel that Dragonsong did not emphasize the importance using grid snap to assemble interiors quickly and accurately. There's another post below addressing that aspect.

Start Small - by Klinn

Everybody wants to start modding by re-creating The Lord of the Rings in its entirety. Enthusiasm is great, but channel it into something you'll finish before the sun goes nova. Sure it's been done before, but there's nothing wrong with creating your own little house in Balmora, or re-skinning a claymore and adding enchantments, or scripting a teleport ring. Jump in and get an idea of what's involved in making mods before embarking on the mod to end all mods. (Disclaimer: I'm guilty of ignoring this one, big time!)

Making Clean Mods - by Klinn

So what's a 'dirty mod'? Is it even something we're allowed to talk about on this G-rated forum? Sure, the term refers to a mod that accidentally changes unrelated objects, often through the entire Morrowind universe. Dragonsong's tutorial discusses this problem, so I'll just hit the highlights here. The objects you see in the Editor's lists are 'master objects'. When you drag, say, a crate from the Containers list and drop it in a cell, you are creating a 'reference' to that master object. Now suppose you decide that you want to reward the player who looks in that crate by adding some more gold. You open up the crate's Properties by double-clicking on it and drag'n'drop some Gold_001 objects into the crate's list of contents. Oops. You'll probably be surprised to discover that you've accidentally added gold to every single crate of that type across all of Morrowind, even ones nowhere close to your mod! The problem is that you have modified the master object, not just the particular reference in a certain cell.

When you look at the Properties of an object reference, e.g. the crate you've dropped in a cell, you'll see a band through the middle labeled 'Reference Data'. Anything below that you can change freely and it will only affect that specific crate. Anything above it is part of the master object. One important note: even if you're only changing the reference data DO NOT CLICK 'SAVE'! This will mark the master object as changed, even if you didn't modify it. Note that the Save button is above the band through the middle and remember that we don't want to touch things up there. Just use the Close box [X] when you're finished with the Properties window.

But suppose you do want a crate with extra gold in it? How can you do that without accidentally making a dirty mod? The secret is to create a new 'master object'. There are few ways, but here's a simple one: Find a crate in the Editor's Containers list that has the appearance you want. Maybe the one called 'crate_01_empty'. Double-click on it to bring up the crate's Properties. Change the ID code to something different, e.g. 'My_Gold_Crate'. Click the 'Save' button. Yes, it's safe this time, because we're deliberately making a new master object. In fact, the Editor will ask if you are trying to create a new master or renaming the existing master. Be sure to click the 'Yes' button to create your own new unique master object. Now that you have a new master object of your own you can modify it freely without worrying about accidentally changing anything else. Add gold or fancy glass armor to its contents, whatever you like.

Free Intermediate to Advanced Tutorials! - by Klinn

You've been through some of the beginning tutorials mentioned in the pinned thread. Now you're bursting with cool ideas but can't quite figure out how to make them work. Well, you've got an absolutely excellent set of intermediate to advanced tutorials already installed on your system. They're called 'Morrowind'. Browse through the existing material that makes up the game. See how they arranged Bitter Coast cells so they look swampy and where they used vertex painting. Check how they made it possible for you to tag along after a galloping white guar. You want to have the player bring your NPC five jewels in exchange for something? Hmmm, remember the early quest where you gathered flower samples for Ajira in the Mages' Guild? Check out Ajira's dialogue ("flowers" topic mostly) to see how it can be done. This is also where having played the game a lot helps - you'll remember similar situations in the game that can help you with your mod.

Searching the Editor - by Klinn

The Construction Set has a built-in, semi-hidden search function. Under the Edit menu is the 'Find Text...' command. In the dialog box that pops up, enter the word you want to look for and click the Find Text button. You can find objects, scripts, and dialogue this way. In fact, that's how I just found the dialogue and scripts for Ajira mentioned above. You can also click on the column headings to sort the lists, e.g. to group all the static objects together, all the books, etc.

Making Rooms & Walls Line Up - Grid Snap - by Klinn

The interiors of buildings and caves are primarily composed of main sections or 'tiles' that assembled together, e.g. a corner followed by a straight piece, etc. Many people have problems getting these to line up. Either there are some small gaps, or the pieces overlap and the surfaces flicker in the game. To avoid this, it's important to line up the sections precisely. It's possible to manually enter the X,Y,Z coordinates of each piece, but that takes forever. Instead, try using the Grid Snap and Angle Snap features of the Editor.

First thing to do is to go into the Editor's Preferences and set the Grid Snap to a useful value. What value? Well, notice that almost every one the main sections or tiles is 256 units long by 256 units wide. There are some half-length pieces and double-wide ones, but most of them are that size. So to get one piece to line up with another, you could set the grid snap to 256 units. You could do this, but you'll probably find it difficult to move pieces around the Render window. Try something that divides evenly into 256. This is the 'power of two' rule of thumb you'll probably hear about. For the large room and cave sections, I recommend a value of 64, which is the Editor's default setting. It's small enough to see pieces moving as you drag them with the mouse, but large enough that you can be sure they're snapped together properly, even if you are zoomed quite far back.

OK, the Grid Snap is set to 64. Now make sure it's actually activated by clicking the little grid button on the toolbar. In addition, you must also turn on 'Angle Snap' by clicking the red pie-shaped button. Snapping room tiles together only works properly if you are building things 'square', that is, orthographically. I'll talk about building on an angle later.

Finally you can now drop the first piece of your room or cave into the Render window. At this point, the Editor throws you a curve ball. Even with grid snap turned on, simply dropping a room piece into the Render window does not make it snap to the grid! After dropping it, be sure to grab the section and move it slightly. You should see it jump to the nearest invisible grid point. Once that first section is in place, any others you bring in will line up perfectly.

That takes care of snapping the main room tiles. Once you begin to add other objects, e.g. doors or windows, you may find they won't snap to the right place. In Preferences, reduce the grid snap setting to 8 or 4 or even smaller. Remember, always use a power of two, i.e. 1, 2, 4, 8, 16, 32, 64, or 128.

Once you start adding all the 'clutter' that goes into a room or cave, e.g. furniture, dishes, rocks, posts, etc, then feel free to turn off the grid snap entirely. Angle snap too. Real world interiors are not so neatly arranged, at least my place sure isn't so try to introduce some randomness into the layout.

As I mentioned above, grid snap only works if the angle snap is on too. But what if you want to build something on an angle? If it's an interior, build it 'square' and leave it that way. Rotate the interior cell's North Arrow marker the other way instead. The direction it points will be 'up' on the player's Local Map, so it will look as if you built the interior on an angle. For exterior cells, e.g. if you're building some Imperial Fort walls or Hlaalu canal sections, assemble them 'square' with grid and angle snap turned on, then select all of the pieces and rotate them as a unit. Better make sure you won't want to make any changes or you'll have to rotate them back. It's a pain, believe me.

One final bit of advice about snapping. Suppose you want to move part of an interior you're working on over a bit, or maybe copy parts of an existing cell into your own and make it line up. If you select a whole bunch of stuff, i.e. not just the main room tiles but furnishings too, you'll probably discover that it doesn't end up in the right place, even with grid snap turned on. The problem is that the Editor is snapping to the origin of some random item within the group you've selected. Here's the trick: first select one of the main room tiles, then hold down the Ctrl key and select all the other items you want to move. This will force the Editor to snap that first item to the grid. Since the first item is a main room section, it will line up with any others already snapped in place.

Whew! This may seem like a lot to deal with, but it becomes second nature once you're used to it. And it pays off by being able to quickly and easily assemble interiors that you know are precisely aligned.

Debugging Scripts - by Srikandi

Debugging a script: incremental testing. You think you've figured out the scripting language, and you're ready to script your longsword that leaps out of your hand and tap-dances when an enemy is in sight, but only if the player has had a bit too much skooma and the moons are full. You pull out Scripting for Dummies, read it end to end, and then produce 200 lines of timeless code. You save your mod, start the game, give the sword to your character, wait for the right time of month, chug a few bottles and... nothing happens. Whoops! Where on earth did you slip up?

Don't ask us! Best thing to do is to avoid being in this situation in the first place. At the beginning, you should test your script at every point along the way where something should have happened that could be detectable in-game. First, get the longsword to drop to the ground when an enemy appears. Then get it to hop when dropped. Then choreograph the tap-dance. Then add the condition about skooma. Then check the moonphase. Make sure each phase works flawlessly before proceeding to the next.

Your testing can get even more fine-grained than this. For instance, if a variable X is supposed to get set, you can make sure that happened by starting the game, setting up the conditions for the script to run, opening the console, clicking the object the script is tied to, and typing "sv". Or, put a message-box in your script: messageBox "X is set to %g", X. You'll see a message in-game when the script runs. This will let you know not only the value of the variable, but whether that part of the code executed.

Don't be afraid to use the console while testing, to set the conditions for your script to execute... get your clean character to the right location, set the game day or the time, give yourself the items you need, spawn some enemies to test on, and avoid dying before you found out if your script worked. This can save a huge amount of testing time. You don't get any medals for feats of valor performed while testing mods.

Many more useful hints along these lines can be found in the Scripting for Dummies "Troubleshooting" section.

Incremental testing is tedious and time-consuming, but it is much better than the frustration of staring at a screenful of code and scratching your head... and when something doesn't work, you'll know exactly what it was, and it will be much more likely that you'll quickly find a solution, or get useful help on the forum. As you gain more experience, you'll be able to write longer sections between tests, and things will start to go faster.

The Render Window Is All Grey - by Klinn

If you can't see anything in the Render window, here are some things to try:

1) First, make sure you are actually loading a cell to look at. When starting the Editor, be sure to select (checkmark) at least one of the master ESM files such as Morrowind.esm by double-clicking on the filename. Once that is loaded, you'll see the game's cells listed in the 'Cell Name' list. Double-click on one of those to load it. Hopefully it will show up and the items in the cell will appear in the 'Cell Contents' list just to the right. If you still can't see anything, try double-clicking on an item in the cell contents list. This will position the camera very close to the object. If this fixes the problem, you have the Editor's viewing distance set too close. Under the Editor's Preferences, change the 'Clipping Distance' to so it's farther away. When first loading a cell, you start out quite far overhead. So you may need to adjust the clipping distance to see all the way down to the ground.

2) Still have a grey Render window? Check the Windows Desktop Properties and make sure it's set for 32-bit color. Sometimes when you update video drivers, this can be changed without you knowing about it.

3) If you have an nVidia TNT-based video card, there is known problem with recent Detonator drivers. You'll have to revert to earlier ones. Some people have reported success with the 30.82 version (thanks Shiva7663) while others made it work with 45.23 or 40.xx versions. (thanks Chia) Be sure to use a 'driver cleaner' type of utility to get rid of all traces of the previous driver before installing a different one.

My New Cell Is Choppy or Stutters - by Klinn

You may create a new interior cell and discover that when you test it in-game, it's really jerky or 'stutters'. Other cells will play with no problems. The problem: you probably have the music turned off. Yeah, it's a weird bug, but there yah go. Just turn the music up a touch, not even audible, and the cell should work fine. (Sorry, I don't recall who discovered this fix, but thanks and trophies to you!)

Objects or NPCs Are Missing or Duplicated - by Klinn

This is almost always caused by something called a 'dirty save'. Not to be confused with the 'dirty mod' issue discussed above. DinkumThinkum has written an excellent explanation of this common problem from a mod user's point of view over in the Mods Forum, and an even better one discussing how it applies to us mod authors, so hopefully he will join in this thread.

In the meantime, here's my brief take on it. When you save a game, all sorts of information about the Morrowind world is stored in it. Besides obvious things like the contents of a chest you've opened or the stock owned by an NPC merchant you've bartered with, there are things like the state of that door you opened, or the weather of a region you've passed through, or current values of script variables, etc, etc. Tons of stuff.

When Morrowind starts, it first loads the master ESM file(s), then any ESP mod files (in file date order), and finally you can load a save game. Since it is loaded last, the information about an object stored in a save game supercedes anything in a mod. Normally this is OK, but suppose you are testing a mod, decide to save your game right in the middle of it, then go back to the Editor and make changes? The information in the mod may have changed, but if the save game has different (earlier) info about the same object, the poor Morrowind game engine gets confused. So you end up with missing objects or NPCs, or often duplicates appear.

The rule of thumb to remember is "Never save while testing". Even more to the point, be sure the character you are using to test the mod has never been in the area, or interacted with NPCs there, and so on. Nothing that would result in data about those items being stored in the save game. Most modders create a special 'Test' character, fresh of the boat. Use that character to test a mod, but remember to never save over top of him or her. This way, you'll be sure that you're testing with a 'clean save'. If you need to pump up the character for testing purposes, use the Console to increase attributes, add equipment, teleport to the mod's cells, and so on.

Naming Your Unique New Objects - by Klinn

Way back in the first post, under 'Making Clean Mods', I mentioned the importance of creating your own unique-ID objects before modifying them. So what ID code should you call them? Here's a couple of things to watch out for:

1) Names with leading underscores can cause problems. Some modders add a leading underscore, e.g. "_My_Uber_Armor", so the object appears at the top of the Editor's lists and is easier to find. But there are some cases when this will cause bugs, and the error messages you get won't clearly indicate the problem. I recommend avoiding the practice.

2) Names with embedded spaces, e.g. "My Uber Armor". Referring to an object name with embedded spaces requires enclosing it in quotes, which in turn requires very specific syntax when using that name as a reference in a script. Again, when the bug pops up, it's hard to track down. Try using capitals to distinguish the words, e.g. "MyUberArmor" or underscores within the name (but not a leading one!) such as "My_Uber_Armor".

3) Common names. If you create a global variable called something simple like "State", the odds are that somebody else might use the same name in their mod. Then when a user tries to play with both mods enabled at the same time, confusion reigns. Both mods will be trying to change the same variable. Use something distinctive, something unlikely to be duplicated. Many modders put their initials at the front, e.g. "KLN_Uber_Armor". (I seem to have a thing about armor, hmmm? )

Personally, I go even further than that and use an extension of a scheme suggested by Dragonsong years ago. It may be overkill for small mods, but for what it's worth, here's what I do: The first couple of letters are my initials, followed by the initials of the mod, then the class of object, and finally its name. Using armor as an example again, in a mod called "Berjon's Blade" I would call it "KLNBB_ARM_UberShield". Why put the object class in the middle of the name? Suppose I wanted a special script to be attached to the armor. I would name the script "KLNBB_SCR_UberShield". The pattern makes it very clear how things I've created are related to one another. And having the mod's initials in the name means I can create an uber shield in some other mod, and the names won't conflict. As I said, this may seem excessive for simple mods, so feel free to ignore this babbling of mine.

Changing Existing Items In The Game - by Klinn

Be very careful about changing existing objects or NPCs in the game. Again, DinkumThinkum has some excellent words of wisdom about this, but here's a few points to consider.

1) If a player has already interacted with the existing object you are modifying, the info in their save game could supercede your changes. This is similar to the 'dirty save' issue described in the post above. The result is that they won't see the changes your mod is depending on.

2) You might accidentally break an existing quest, script, or dialogue that depends on the object or NPC.

3) Somebody else may change the same object in their mod, leading to conflicts between the two versions. For example, before Tribunal was released, a number of people edited the Main startup script to establish conditions needed by their mod. The trouble was that if another mod was loaded after theirs and it also modified the Main script, then that was the version which was used. The first mod was toast since its version of the Main script never ran. (Tribunal introduced the ability to have multiple startup scripts, so fortunately this particular practice is no longer needed.)

It is much safer to add new objects to Morrowind rather than try to modify existing ones. Try to do that to avoid potential conflicts.

General Tips - by Polycrates

First, go in-game and look around - a lot. The render window is good, but you don't really get a proper feel for how it's actually going to look to someone in the game. This is especially true for lighting levels, which are very different in render window. Also, you're more likely to see when things haven't lined up properly, or if they're floating in the air, etc. Also, if textures seem to be 'tearing', like there's two textures fighting over which one is going to be seen, you've probably got two items right on top of each other (mostly if you snap a couple of interior room pieces together and the edges are overlapping. And there's no harm in 'cheating' to get there when you're testing. Open the console and type: coc "the name of the cell" to get yourself there quick and easy.

Second, get Srikandi's Item List. It's a categorized list of just about every item in the construction set and it's beyond invaluable. Seriously, this will be your best friend.

Third, and this is for when you're starting to get the hang of the CS: most people are trying to mods that are supposed to "fit in" to the Morrowind world (if you're making a Final Fantasy mod, etc, ignore this). So have a look at how Bethesda has done things to try and make your places fit with that. The hallmark of a good mod is that you can't tell that you're not playing part of the original game. Look at how the 'unimportant items': bookshelves full of random items, items on tables, tapestries etc are placed and try to emulate that. Hell, you can even copy and paste whole shelves worth of stuff over from other cells. But this sort of background stuff really contributes to how well something fits in. Also, be really careful with your dialogue. It sounds really petty (and it is), but a lot of people will notice if you've made lots of spelling mistakes in your mod, and it does make it look a little unprofessional.

Fourth, good luck! The CS does look daunting at first, but you WILL get the hang of it in no time.

General Advice - by Kranas

A: If you're planning for a release of this mod and not just for yourself, then think about your audience. Just because you found Kwama Cuttle fascinating doesn't mean everyone is going to find Kwama Cuttle City an amazing experience.

B: The landscape sensitivity multiplier in the preferences can save you a lot of time when raising big landmasses.

C: Rise the landscape to where you want it as much as you can before putting stuff on it. Once you're satisfied with it, texture it, then put the statics like flora and rocks on first. Things like NPCs and Creatures should come last. Remember to always use wireframe and that A button to have a different view.

D: Use the scale function but don't overuse it. Remember, if you're scaling up something like a creature, they may end up looking like they're attacking at something above your character.

E: Alternate between doing interiors and exteriors. Working on one of them for too long can cause lapses in what might have been a nice landscape.

F: Learn to slope nicely. I.E: jagged, unclimbable cliffs = MINIMAL. Accessibility can be restricted somewhat, but you don't want to overdo it.

G: Scripting and quests should be saved for last, but it's okay to say, place a creature or an item somewhere as a reminder as long as you remember it.

H: All the above is for a more grand scale mod.

I: If you've got problems with overlapping objects (flickering) and really can't fix it, because it's too much trouble then shame on you! But rocks, pillars, carpets etc do nicely for covering up that sort of thing.

J: I'd say by around this stage to almost overdo landscape detail. Morrowind is quite a few years old now, and most people should have the computers to keep up with demanding landscape. However, you should always test and see for yourself, especially with a weather effect like the blizzards from Bloodmoon.

K: Check here for tutorials or ideas, the members here are almost always helpful.

L: Make a backup frequently, especially before and after cleaning with a tool like TESAME and TESTool.

M: Reward the player frequently, but don't overdo it.

N: Keep them interested. A well placed event script or even a simple reading of a journal entry or a well done quest can help a lot. Try not to give out too many quests that give not so great rewards.

O: Try to avoid cliché, unless you think it's to your advantage. It's nice to have some originality, but you don't have to be completely different.

P: In referral to O, that doesn't mean you have to go retexture some items (though it is fun.) or create some new animations or models. It simply means you could make a quest with a new approach or baby 0.5 scale cliff racers (One hopes not.) or something like that.

Q: Don't get too clogged down with other mods. Some people recommend it. I say, STAY AWAY. if you must, try to get the model or item or whatever, and integrate it into your own mod, so it doesn't require the parent mod, and then give credit where it's due if you release. Quite a few people really prefer if you ask permission before doing this.

R: No matter how great you think your unavoidable encounter with the Khajitt of Doom is, with his secret weakness, the player doesn't know the weakness, and so, is going to be SICK of trying to deal with this stupid thing.

S: This goes for stuff like dialogue in quests. Where's this cave? Your NPC says northwest of here...Really? Gee thanks for the vague directions! You might know where everything is, but the player knows nothing. That's part of the whole excitement for them.

T: Again, referring to R, don't mistake frustration for challenge. You might want to make something challenging, but there can be an extremely fine line between challenging and frustrating.

U: I must stress planning! It's soooooo important! Don't flail helplessly in the dark. The results usually aren't good. If you want to test something, make a separate plug-in.

V: make sure your initials don't conflict too much as Klinn pointed out. Using three initials instead of one (like I shamelessly have) is a much better idea and has pretty much 0% chance of conflict.

W: Don't expect everyone to like your mod. That's the simple fact.

X: In reference to W, see what's "on the market" already. There's plenty of "my first house" type of mods out there. If that's what you want to do, great, but don't expect everyone to choose your mod over theirs.

Y: Again, referring to creating LotR, realize your own limitations, and your own dedication to it.

Z: If you're using NPCs in interiors, use the pathing button (some dots connected by lines on the toolbar) to stop them acting like idiots.

General Tips and Advice - by Patrograd2

Before you start, plan. Then, plan some more. Draw maps, characterize your NPCs, think about the scripts you will need to do the things you want and how you will implement them. Draw dialogue trees, think about how you will be introducing topics to the player. This plan doesn't have to be set in stone, the odds are that you'll change it as you go along, but its difficult to create a cohesive quest without it. Think about NPC motivations, their back-story, why they are there, why they are asking you to do things, what are their hopes, their fears, their concerns. Write out a quick storyboard that you intend to follow

Then, the first thing I always do in the CS is write the journal entries for the various quests, which I take form the storyboard I've written earlier. I have always viewed quest mods as me getting the player from journal entry A to journal entry B, and then onto C and so on. The journal is the most powerful tool at the disposal of the quest modder.

Speaking personally, I then build the mod in quest order, although I leave the details (furniture, tress and the like) until last, placing NPCs, creatures, quest related objects and scripted events as I go along through the story. If I get stuck on a script then I move on and come back that script later.

Testing. You cant do too much testing. Test everything, in every way you can think of. When testing, think not 'what will the player do here', think 'what are the possible things that the player can do', and account for it accordingly. Test dialogue under every condition you can think of. I have three test characters, a mage, a warrior and a stealth class. I make sure that all of these can get through.

Lastly, uber items. No-one wants them. Keep them out of your quest mod. It is better to under-reward the player than over-reward them. It is very, very easy to unbalance the game. Far too many otherwise perfectly good mods are ruined by giving the player the uber Sword of Killall at the end. Also be careful not to place any unique main quest items in your mod. I've seen Guards equipped with Trueflame before...killing those guards and taking the sword breaks the entire Tribunal quest series...

Hints on landscaping - by Miles_Acraeus

Q. How do I "erase" vertex color? Keep one mouse key as just plain white.

A. The color white in the editor doesn't register, but instead acts as an eraser.

Q. How do I go to an extreme coordinate off the map to begin my editing without having to scroll through 200 cells?

A. Edit your INI file under [general]

CODE:

Editor Starting Cell=wilderness
Editor Starting Pos=3076.085449,5801.512207,16321.179688
Editor Starting Dir 0=-0.970524,0.230054,0.071845
Editor Starting Dir 1=-0.241012,-0.926398,-0.289310
Editor Starting Dir 2=0.000000,-0.298097,0.954534

Edit those first two lines to the coordinates you wish to start at. Remember that the map is quadratic.

X,Y intersection = 0,0
Lower left = -x,-y
Upper Left = -x,y
Upper Right = x,y
Lower right = x,-y

Given that a game cell is roughly 8000 gu, use that as a coordinate multiplier. Let's say you want to start landscaping in the furthest reaches of the lower left quad at -100,-100 cells; set the starting cell as wilderness, and enter on the second line

Editor Starting Pos=-800000,-800000, 0

Save that change to your INI (don't worry about a save "damaging" the INI, the INI will record your last cell in the editor.) Load up the CS, and there you are!

Q. How can I "mass" raise landscape?

A. Raise a bit of land at least 500 gu in elevation, in one cell. Now, check the box named, "flaten vertices". Move the cursor to the top of that raised land, left-click, hold, and drag, and drag, and drag.

Q. Why the heck does my comp lag so badly when I edit exteriors?

A. A lot depends on available RAM, both for memory and video memory. Try lowering the clipping distance as much as tolerable. Go to preferences on the menu bar (click on the hand holding the note -- next to the save icon), and look at the bottom of that window that pops up. You'll see a slider... Move that to the left. It should help.

General Tips - by SirLuther

Use the search function if you come upon a problem. Odds are, it's been answered at least once by someone, at some point, and so if you do a search, that answer will come up, and you'll have your solution without taking anyone else's time However, if you can't find an answer after searching, by all means, post your problem. Not only will it get an answer for you from all the great minds gathered together here, it will also provide something for other people with the same problem to come upon when they search.

Secondly, and this is related to modding, clutter, path grids, creative dialogue, and lighting! I can not over-emphasize how much better it will make your mod if you add those three things, as without them, it will be dull and lifeless. Clutter covers all the small things in life, which people > 60% of the time fail to add to interiors and exteriors. Bottles, plates, silverware, candles, you name it. Path grids, those are the paths that NPCs will walk if they are left to idle Gives your mod so much more life if, say, the innkeeper goes and checks the cellar occasionally, instead of just standing behind the counter looking dull Just be careful to test your pathing time and time again, as NPCs have the habit of mucking up even the simplest of paths. Specifically, avoid corners, and static objects, or other things with collision. Creative Dialogue. Do you know how annoying it is to load up a mod, and have the first modded NPC you meet say some recycled greeting? For goodness sake, if you can take the time to make a mod, then you can take the time to make greetings and dialogue for your NPCs. Unless of course there is a specific reason for the NPC to be just like everyone else... And last but not least, lighting. If you simply leave the light sliders to their defaults, it will result in, more often then not, a boring flood-filled interior with no life. Mess with the settings, make it darker, and add some candles your self. Makes for loads of character in an otherwise boring interior.

General Tips - by Iudas

Pathgrid your exteriors, when pathgridding, the granularity # represents the number of Game Units between two points on the grid. So a 128 granularity has many more points than a 4096 granularity.

Critters as well as NPC's use pathgrids but they use them differently, experiment. Want to restrict an NPC's movements, Manually disconnect his path grid from the rest of that cell's pathgrid.

For mental reference a game unit is .564 of an inch. An exterior cell is 385 feet on each side or 8192 gameunits.

Allow as many spelling errors in your dialogs as you allow in your scripts - 1.

Game settings are your friend if your desire is to change the overall way MW functions and have that change effect every mod the Player loads. MW Scripting for Dummies has a partially completed list of the GMSTs in the appendix.

Do include a proper readme with a unique name with your mod when you release it.

Do not waste your time trying to find the maximum compression utility... folks with flat rate always on connections could really care not at all what you compress with or how many MB you took out of the download, and if your download is that big to begin with, folks on pay per minute dialup are not going to download it anyhow. Yes it is really GeekBadge to use 7zip or some other esoteric program and if that is the route you are planning to go, then pack it with a self extractor because most folks will not have 7zip or winace but they will have built in FREE zip extraction courtesy of their OS.

You do not have to make your mod compatible with anything beyond MW, but if you want the hurrahs and accolades and the Big $$$ you will try to guarantee that you don't screw up the most popular mods with your creation.

Dialog: DO NOT place your dialog at the top of the dialog lists in any of the 9 greetings sections....DO NOT place your dialog at the very bottom of the dialog lists of any greetings section.....shuffle your dialog somewhere below the third or fourth entry in the greetings section you decide to modify.

Use File Export to get Comma Separated Values text files of the various object categories in the construction set. Import those files into Excel and you can sort and study and manipulate to your heart's content.
As long as you do not change the file type from CSV, after you have made all your changes in Excel, you can save those changes as a CSV and TESCS will import it. (not just excel, any real db or spreadsheet proggie can import CSV text files )