Name your god damn mod. Do not use your own name as part of the name.

• Darkconsole's Alchemy Updates
  
• Darkconsole's Huge Boobs Body Shape Preset
  

Be creative, for fucks sake. You are creating a mod, you are engaging in pure creation. Be creative. Christ. Don't be so vain, it is not about YOU, it is about the damn mod! When you make it about you, you just come off as a flaming toolbag.

"But your blog is, Darkconsole's Blog, hahah" duh, because the blog is about the things I say, not about the things I am making.

All object entries in CK should be prefixed - and prefixed with something meaningful. For example, all my mods are prefixed with my signature and the mod signature.

• Windrunner: dcc_wr_
  
• Windrunner's Expansion: dcc_wrr_
  
• Untamed: dcc_ut_
  
• Untamed Tattoo's dcc_uttat_
  

etc. When I redo Display Model this year, dcc_dm_.

Here is the thing. I don't give a fuck if its hard to type or read or find. Don't be stupid. If you prefix your things with aaa or _ or anything else, you are bad and should feel bad. Dear god, if you use that prefix (aaa/zzz/_) on your script files too, you more or less deserve to die in a fire.

The main thing is you need to pick a prefix that is descriptive, unique, and reusable in both CK and for filenames. Seriously, as a modder everything you have to deal with has a fucking filter box for you to easily dig up your objects and I suggest you make it your best friend.

There is another step to this though, the next step is to now include the TYPE of GAME object it is in the name. Lets say we created a magic effect that heals you. I would then name it, dcc_ut_EffectHeal. This is a nod towards how half the vanilla objects are created.

Now lets say I created the SPEL to use the MGEF.

• dcc_ut_SpellHeal will then use dcc_ut_EffectHeal as its magic effect.
  

Now lets say I created a spell that needs to have multiple magic effects. Lets namespace this further.

• SPEL dcc_ut_SpellSuperDuper
  
• uses MGEF dcc_ut_EffectSuperDuper_DamageResist
  
• uses MGEF dcc_ut_EffectSuperDuper_MagicResist
  
• uses MGEF dcc_ut_EffectSuperDuper_AttackDamageMult
  

And just by looking at those effects you know that all 3 are probably Value Modifiers that modify things like Damage Resist, Magic Resist, and Attack Damage Multiplier. Brilliant.

If you are wondering about a max name length... I am sure there is one, but I have not had any problems so far and you are seeing how descriptive these names are getting.

For a long time I refused to use the auto-fill feature of CK, and I actually still do refuse to use it for stock game objects - we haven't talked about code yet though. However, any items I added to CK I now use the auto-fill ability on.

In my script you will see things like:

• Shout Property dcc_ut_ShoutMateCall Auto
  
• Spell Property dcc_ut_SpellShiftCat Auto
  

Which means yes, I am referencing them as self.dcc_ut_ShoutMateCall in the code. I know that is a lot to to type and programmers are inherently lazy (unelss you are Java developer, in which case you are the master of clusterfucked obfuscation). But don't be retarded. Make your code easy to read and understand. Do not make your code a Perl shorthand pile of Dragur shit.

So because of what I said in the previous section, I created my spelled named dcc_ut_ShoutMateCall and now the Auto-fill button on the Script Property dialog will magically fill them all in with one click.

As I already mentioned, using the game as it exists as a template will result in very poor structure and organisation. Default things are named like "BearBlackRace" and "EnchFortifyHealth" - lets look at that. That is two completely different namespace systems.

• BearBlackRace, BearCaveRace, BearSnowRace - they have prefixed these races with the name of what kind animal it is. They stick with this (for the most part) with most of the races. WoodelfRace, WoodelfVampireRace, OrcRace, etc.
  

• EnchFortifyHealth, AlchFortifyHealth - here they have prefixed these objects with the actual type of game object it is. Completely different from the races. But this is actually the "right way!"
  

So here is what I suggest: when you are dealing with VANILLA objects, you completely disregard the rules I set for custom objects and even property binding. Also disregard what Bethesda did. Here, Prefix the shit with the TYPE of GAME object it is.

• RaceBearBlack, RaceBearBrown, RaceBearSnow
  
• which should look suspiciously like EnchFortifyHealth and AlchFortifyHealth.
  

This means now auto-fill will not work for vanilla objects - but oh well. That is the price we are going to pay to acknolege two things about the object: first that it is vanilla and not an object I made. Second being that we have learned how not to be bad by now.

When you read my code now you will see references to self.RaceBearBlack which is pointing at Skyrim's vanilla BearBlackRace, and self.dcc_ut_SpellShiftBear - by nature of the two different namespacing systems you know exactly which properties are default vanilla objects and which are custom objects without even opening CK. Plus, now all my Papyrus has constant structure for the variable names.

By default when you create a script fragment in CK, it ends up with a filename like TIF__G0FKURS3LF.PSC. Go ahead, open your Skyrim directory and look. You probably have a thousand of these TIF__ files laying around because of so many modders being bad.

The brilliant thing is that CK lets you rename these files and it takes almost no time. I already wrote a blog that details how and why you would want to do this. The TLDR version is that if you do not rename your fragment, both the Skyrim script directory and the players save is going to be a clusterfuck of hidden files that are near impossible to clean out easily. When you prefix your shit, save game editors and filesystem browsers can easily filter on things like "dcc_ut_" and show you only the things you need to take care of.

If you follow that blog post your TIF__D0NG54L1F3.PSC files will become things like "dcc_ut_DiagFrag_HandleAnimal_Follow.psc" - descriptive and very targetable. Now you know exactly which file you need to edit if you want to change how it works or recompile and you never have to even open CreationKit to do it.

Lets digest that script fragment name as though we are looking at the file lists in Windows Explorer: dcc_ut_DiagFrag_HandleAnimal_Follow.psc

• We know it is from the Mod Untamed by Darkconsole.
  
• We know it is a Dialogue Fragment.
  
• We know it is part of the Handle Animal Dialog Topics where all my animal commands are handled.
  
• We know this fragment is the fragment that tells animals to follow you.
  

Amazing. So much info.

You should follow the exact same rules as detailed under Creating Object Entries for making file names for your scripts. And you better not be forgetting about the Script Fragment Renaming section, either.

Resources are any files which are not scripts. Images, Meshes, Textures, whatever. Creation Kit will force you into a few low level conventions like "meshes have to be in meshes" and "textures have to be in textures" else you will get these "invalid directory" warnings.

But we need to take this a few steps further. You need to subfolder your shit.

• interface/untamed/splash.dds
  
• meshes/untamed/whatever.nif
  
• textures/untamed/whatever.dds
  

See what I did there? I made a subfolder using the name of my mod. Pure brilliance. Don't be afraid to subfolder even deeper in your own mod folder to do things like separating armor meshes and textures from eachother. This is a lesson in physical organisation.

Notice I used the MOD NAME and not MY NAME as the subfolder. If you look at my Pony Pack you will see where I fell into the trap of using MY NAME as the subfolders, and now it is clusterfuck of shared directories and overwrites because I did the same thing in SGO and I regret every moment of it.

BSA packing, contrary to any rants you may have seen me engage on IRC, is good. It will actually make your mod load a little faster because of computer science I am not going to get into.

However.

Are you making a Framework that other modders are going to use?

No? Ok. BSA that shit.

Yes? DON'T BSA THAT SHIT.

If you force a modder to extract your script files to compile, the next time you update all the modders are going to have to extract again. Or they will forget and wonder why their game is so fucked and not getting your bug fixes because the game values flat files over archived files.

Make a "SDK" which contains the source files (SkuUI, RaceMenu), or just distribute the mod as loose (SexLab, PapyrusUtil).

I'm looking at you, SexLab Aroused.

Taking for example this code:

Scriptname dcc_ut_QuestWhatever extends QuestActor Property dcc_ut_ActorSomebody AutoSpell Property dcc_ut_SpellSomething Auto;; ...

You can of course reference dcc_ut_ActorSomebody as is in that script. Now, when you bind this script to another script...

Scriptname dcc_ut_QuestAnother extends Questdcc_ut_QuestWhatever Property Whatever Auto;; ...

Now to access that actor we have to call Whatever.dcc_ut_ActorSomebody. But lets go back to the dcc_ut_QuestWhatever script. Because they are local properties you can just call them out, but I am suggesting you call all the properties with the self keyword included. E.g. self.dcc_ut_ActorSomebody.

This serves one purpose: it proves that you know where your shit is coming from. It's coming from right here. It also creates a consistent look across all the scripts for accessing properties. Plus looking at this code here...

Function DoSomeShit()    Int Counter = 0    Int Total = self.dcc_ut_ActorSomebody.GetNumItems()    Int Item    While(Counter < Total)        Item = self.dcc_ut_ActorSomebody.GetNthItem(Counter)        ;; ...        Counter += 1    EndWhileEndFunction

You now very easily can see which variables are actually properties and which variables are actual local variables (the ones without self).