------------------------------------------------------------------------
Pearls of Wisdom
"EditorID's are not more than human-readable versions of the FormID's, that's it." - Xetrill

Are there any issues with flipping the TES4 entry and using an ESP as a Master?
"No issues. As long as you remember to flip the bit back, or all hell breaks lose." - SomeWelshGuy

------------------------------------------------------------------------
Useful Links
Mod Cleaning Tutorial: http://tesalliance.org/forums/index.php?/tutorials/article/45-mod-cleaning-faq/

------------------------------------------------------------------------

Ok chaps, I've been looking for a fundamental modding concepts tutorial and failed to find one.

What I'm looking for is advice on things like

• How should I name my EditorIDs?
  
• How do I make a clean mod?
  
• What's the problem with overlapping EditorIDs?
  
• Should I put all my mod ideas into one mod?

Many things like this are easily missed by us new-time modders - I kind of have a feeling for what makes a good/clean mod, but can't find anywhere that actually puts down these things in a simple fashion.

So - please give me pearls

I can tell you what I do regarding a couple of your questions.

For my IDs, I use an abbreviation of the name I upload with. I start with ElD_ the name of the mod I am editing, then the same basic naming they use in the CK. For example ElD_DeusLightBlueShadow
Makes it easy to find anything I've created.

Best way to make a clean mod is to not even look at other interior cells. Use the search window for placing your objects. Don't go rooting around in other cells. If you want to do this, do so with a different esp then the one you are going to make your work in.
If you do accidentally change something you can use the details under File>Data>YourMod.esp Just delete the cells you accidentally changed. A little 'I' will show up next to it. Or you can go the more advanced route and use a third party tool like TESVSnip. Just be careful and make a back up first in case you delete something you should not have.

Don't have any advice for your other two questions.

1.0 Editor IDs
Primarily, I construct my editor IDs to identify the author in some way, the group of mods to which they apply, the class of object, the type of reference and a name indicating the purpose of that object. For example, in one of my mods you'll find (if it is ever completed and released):
.
zqzzClSaddlebag
.
"zqzz" has my trademark (the 4-bit binary for the number eleven) embedded in a combination of letters whose selection refers to the group of plug-ins to which this object belongs; in this case "q" refers to Questfall Tower. This is followed by the capital, in this case "C" designating a container, and then a lowercase "l" designating base object identifier. If it was an object reference it would be a lower case r, for example. The remaining description need only be brief - in this case I think the word "Saddlebag" paints the picture quite nicely. At any time, this allows me to filter for all objects I've added or specific types of object that I've added.
.
2.0 Keeping it Clean
Firstly, it's how you go about keeping your edits clean which makes the biggest difference. It actually starts with your planning - before you open up the editor. Your journey through the creation of your mod will be a journey of baby-steps from one minor working function to another. So, every time you make a successful change that adds even the most minor degree of game-accessible working functionality, save your plug-in and, using Windows Explorer or some such, back it up to a separate file with its own date and time code in the filename. For example, in my version control directory you might find files named thusly:
.
1011_(Skyrim)_QuestfallTower_2012-0307-1735_Level-3-Atrium-Mannequins.esp
1011_(Skyrim)_QuestfallTower_2012-0307-1903_DaggerDisplayCaseFixed.esp
1011_(Skyrim)_QuestfallTower_2012-0307-1930_LibraryPropsLinked.esp
1011_(Skyrim)_QuestfallTower_2012-0307-2048_Atrium-Level-3.esp
1011_(Skyrim)_QuestfallTower_2012-0307-2130_Atrium-Level-3-Finalised.esp
1011_(Skyrim)_QuestfallTower_2012-0307-2318_Office.esp
1011_(Skyrim)_QuestfallTower_2012-0308-1331_Armoury-WeaponMounts.esp
.
That way, if something goes so wrong that the plug-in cannot be recovered, you can always role back to the last working version. That would include any dirty edits, because most of these updates take less time to repeat than rooting around for a dirty edit which may or may not be the only one.
.
Once you have procedures in place that keep your version history under control, the key is to avoid modifying existing base objects. Instead, create your own and modify those - by modifying the Base Object ID field with your own identifier and clicking yes when the Creation Kit asks you if you "want to create a new form". Finding desired objects with the search window is ideal, but if you have something specific in mind and cannot find it through the search window,

• save your mod and back up the current version,
  
• look for the object in the cell where you've seen it before
  
• make a note of the object's "Base Object ID" (which appears in the search window)
  
• close the Creation Kit without saving
  
• restart the Creation Kit with your plug-in set to active
  
• get the desired object from the search window using the Base Object ID you copied out with pencil and paper about 10-20 minutes ago in step 3
  
• save your mod and run the game to see if the changes you just made either work, do not work, or totally mess things up

Of course, when TESVEdit comes out, there will be braces to go with the belt!
.
3.0 Reference Editor IDs
Reference editor IDs refer to a specific instance or, perhaps, "clone" of the Base Object as placed in the game. Before the scripting language was changed to produce Papyrus, the Reference Editor IDs were used in scripts to refer directly to objects in the game. It was quite the convenience too, I must say, and it's one of the features of the old scripting system I miss.
.
4.0 Nay! Horses for Courses: Fail to plan = plan to fail
Some of your modding ideas will depend on one-another - these should go in a single mod. Independent modding ideas are best kept separate until dependencies are formed with other ideas. Modding ideas which affect overall game-play should definitely stand alone as separate plug-ins
.
I'm currently working on a basic little player home with a few avatar comforts and, eventually, a brief campaign of little quests to make it just slightly more interesting. As I'd like to finish some time this millennium, the key is keeping things simple and avoiding, as far as possible, the limitations of the game engine. Having said this, the saddlebag bug (you can see them but they just don't activate) is an itch I feel compelled to scratch. So, in line with my systematized approach to things, I've set them up to have weight limits more appropriate to a horse than a human being and to be automatically accessed whenever the player mounts the horse. As you might well imagine, this may just annoy some people, who would therefore enjoy the game more if they used another system of accessing saddlebags and mounting horses. Now, if I combined this potentially irritating saddlebag system of mine with my player home plug-in, how do you think those people who prefer either no saddlebags or different saddlebags are going to feel about this player-home plug-in of mine?
.
So, it is always worth keeping an eye on the larger picture, especially seeing as each of us already has an overall concept in which each of our plug-ins is generally a component. One of the key ideas here is in making these components modular...

Depends on if you give a damn about the end user. If you do care, then no, you shouldn't put everything in a single mod. Some may like parts, others may like them all.

If not, then toss whatever you want into one file.

Thanks guys, now to clarify my 3rd question ... I am specifically trying to find the answer to this question: Why do we need to have unique EditorIDs?

Example
If I had 2 mods which both contained the same EditorID - let's say "ScarabFollowerDemon"... (with different FormIDs e.g. 0101000 and 0101abcf)...
What would happen if I loaded both mods? What if their FormIDs were also the same?

Nothing surprising, the EditorID's don't get loaded by the run-time (the game), so it will just work.

EditorID's are not more than human-readable versions of the FormID's, that's it.

FormID's cannot be the same, even if it looks like it, they have their own scope. The first two hexadecimal digits are reserved for load-order, so even if the last 6 digits match, the first 2 never can.

Late edit: That last part was really weird english?

.
Each of those Reference Editor IDs is supposed to be a unique reference and I think http://www.gamesas.com/user/448804-xetrill/ makes a good point about them being more human-readable. While I often find myself hunting for those hex IDs (e.g. '000068d74'; the engine's name for the player horse obtained from the Whiterun stables), when remotely picking the object out of a drop-down list, it is that much easier if there is a distinctive and unique descriptive word in the list. That's what those Editor Reference IDs do for us and, to date, I've found that their use is no longer mandatory - or even necessary depending on how we go about our scripting.
.
"Editor IDs", on the other hand, refer to the ID for the base object and, maybe I'm being remiss here, but I call them "Base Object IDs" because I find the current use of terminology just plain confusing. These refer, not to the instance of the object, but to the basic idea or concept of the object.
.
Now, if you have objects from different mods with the same Reference Editor ID and same Base Object ID the game sees these as something like, for example: mod A, object 3.8 and mod B, object 3.8 which, in the file structure is similar to having two files with the same name residing in different directories. So, in my mod '1011_(Skyrim)_TestingCaches.esp' I have the base object with Form ID '020012ca' and "EditorID" 'zqzzClJarCacheQuestfallTower'. The one instance of this object in the game is referred to as '0200182d'. Now, if I take the same jar model in another plug-in I am working on, '1011_(Skyrim)_QuestfallTower.esp', and rename the base object or "Editor ID" as 'zqzzClJarCacheQuestfallTower' it is assigned the Form ID '020138df' which, as you can see, different to the Form ID used in the '1011_(Skyrim)_TestingCaches.esp' we saw before. Once placed in the game environment of '1011_(Skyrim)_QuestfallTower.esp', it is referred to as '02013be0' - also quite different to the "same" object reference in '1011_(Skyrim)_TestingCaches.esp'.
.
To confirm, I just ran both Plug-ins concurrently with the overlapping editor IDs and there was no monkey-business to speak of. So, when I run these plug-ins together, there might be some overlaps in English usage (i.e. in the names, "EditorIDs" and even "Reference Editor IDs") but the game does things by the numbers and, unlike many Humans you will meet during your life, the game actually applies the limitations of context to usage - i.e. not confusing '0200396c' from mod A with '0200396c' from mod B. I hope this helps.
.
Good luck with your modding...

I once heard something about the game applying two digits preceing the formId when it references something based upon load order. So, the esm is always 00, first loaded mod is 01, etc. In this way it maintains a "dumb" (uses term laughably) system that doesn't need to make complex executive decisions about which to load.

Thanks for the clarification - so this means that I don;t need to worry about EditorID overlaps when I'm debugging mod incompatibilities - that's one less thing to worry about! (I was pretty sure I did need to worry about that, but probably from unenlightened Oblivion days!)

--
EDIT
Ok , more questions...

• If I look through update.esm is this a definitive way to determine what has changed in the various patches. i.e. if I look for COBJ records and find none, I can be sure that updates have not modified the recipes?
  
• When I use Script fragments, the filename is often something like QF____02000dfd.psc - I presume I ought to be renaming these with the modname in the centre e.g. QF__ScarabFollower__02000dfd.psc - otherwise this may conflict with other mods. Is this manual renaming necessary?

I'm looking at converting many mods to ESM in order to write Lorecraft plugins for them ... and I have noticed that you can actually set an ESP as a master and it seems to work.

• Do Master files need to be in ESM format?

(So I mean, do they need the flag set in their TES4 record).

If it follows that Skyrim loads ESMs first (in Load Order), followed by ESPs (in Load Order) this would ensure that the master is already loaded before the new mod, but presumably one can just require your mod to load after another ESP and it will work just fine?

ESMs allow the propagation of dependencies so that elements from the ESM plug-in can be invoked in other plug-ins. In the past they were also used to be handy for fixing some bugs, such as the mismatched complexion (between face and body).
.
It takes a little more than an extension change to make a master. There is also a bit change which, I think, can be done using a tool like TESnip
.
[EDIT]Spelling/Grammar[/Edit]

Some general advice I have is to ALWAYS plan and design modding projects before you go at them, and have a wholistic and realistic scope of said mod. Don't ever just go "Oh hey I'm gonna do this!" and jump in. You'll get discouraged, your mod will be unfocused and polished, and you'll probably never release it.

It's great to jump in when you are experiementing, researching, or just playing around with no real goal. But once you have an idea for a mod, and a real goal in mind, DEVELOP IT before you jump into it. Create a design doc, sketch out areas, write down ideas, etc. All of these things are the foundations of your mod, and references you can look back to in order to track your progress and think up a deadline.

The #1 reason why mods never get released has to do with this. The #2 reason is the mod is just too unrealistic or expansive in scope to reasonably pull off from the get-go. Usually you figure out #2, if you do #1 first

Thanks for this RealmEleven, but my question is whether we can use ESP files (without the bit change) as Masters...

Thanks!

You can change the bit of the ESP, load it in the CK as a master with your current plugin, save the current plugin and then re-flip the bit of the "master" esp file. You'll have two ESP files, one being a parent of the other. It's not possible without bit flipping, only Oblivion's CSE could do that.
Skyrim.esm is always 00
Update.esm is 01
Any following ESM and ESP files will then increase hexadecimally (00, 01, 02, 03, 04, 05, 06, 07, 08, 09, A, B, C, D, E, F, 10 etc.)
FF is reserved for items that are created in the save file (dropped items and such).

If two mods modify the same thing, the "bigger" hexadecimal order wins. So if ModB is loaded after ModA, and both change the stats of a horse, ModB's changes will overwrite ModA's changes as it's loaded later.

That means there's 255 "slots" available, three of those being taken up by the game. So essentially, excluding any DLCs, you can have 252 mods loaded at any one time. It's a decent system that works well.

Thanks SomeWelshGuy ...

I know how to do it - I just want to know if there are any issues with doing that.

No issues. As long as you remember to flip the bit back, or all hell breaks lose.

Thanks for that!

While I generally agree that you need a little direction, I've found out that jumping in there and building inspires me with more and more ideas as I go. I think that is generally true with writers and novelists in general. I doubt Steven King had the vision for "The Stand" in its entirety before he started writing. He (and other writers) likely had a beginning in mind and possibly a rough idea of how he wanted things to turn out in the end. But all the stuff in the middle came through hours and hours at the keyboard hashing the story out.

With my Bison Steve Hotel mod for Fallout NV, I had a rough idea of the beginning, and actually already had the end finished, then only after I really started building my quest, did I put all the pieces together as I went along. The more I worked, wrote dialog and plugged in quest objectives, the more ideas came to me, so I think one thing feeds off of the other.

It's less necessary to do depending on the scope of the mod and what the mod is. Large scale projects pretty much need planning or are doomed to fail. Something smaller can totally survive if you don't plan, it's just a risk to do unless you can remain focused and inspired long enough to see the project's completion. It also depends on what you plan on doing. Certain types of things work great with improv modding for the whole of the project while other things are at high risk to be flawed, unpolished or broken unless thought out some (such as complex level design).

On Project Management, there are two things that can kill a Plug-In:
.

• A poorly defined specification (or none at all) which, just like "extreme project management" can make the project drag on forever - which is how "extreme" project managers bleed their customers dry.
  
• A specification (even a well defined one) which fails to account for the limitations of the tools, the people using them and the environment in which the object under development is to operate.

.
It is most important to a have an overview of what you want to achieve at the forefront of your mind, but before you can actually get into the details of the specification, you need to be aware of the limitations you are facing. The game engine may not be capable of rendering dynamic object hierarchies, for example - and so it would be unrealistic to include a boat the character can pilot without a lot of outside help (e.g. from a script extender). If many of the punters are not using a script extender, including a dependency on one will alienate a significant chunk of your potential users. And so you will also run into many little "dilemma's" like this which only appear to be dilemmas because they suddenly present you with a limitation you did not consider. Often, working around a limitation is bigger than the project to which it applies. I've been there and done that - and the way the cookie crumbles is that the larger sub-project to bypass a given limitation monopolizes all your resources and you rarely finish this part before the deadline comes around or the the original project loses relevance.
.
So it pays to mess around and totally, utterly mess up in the Creation Kit, before committing yourself to a specification. If you have a general idea of what you want to do, allow the details to take form and for every detail which hasn't been done before:
.

• Plan how you will get by (i.e. more simply) without it
  
• Then put it to the test and see if it can be done before committing it to the specification

.
This way, you engineer for yourself the same advantages folks doing projects in other areas have at the outset of a project: a complete set of operating procedures. Generally, it has been my experience that a project will be executed three times faster when operating procedures are implemented, followed and, where necessary, adjusted to account for unforeseen factors.
.
But that's just my 2c (& I even forgot the 0.2c GST - shhh, don't tell anyone!)...
.
[EDIT]Spelling: dell to well[/EDIT]