BrettM

The last expression is redundant. "IF (A & B) OR (C & D)" will always be true when all four terms are true, so you don't need to test "(A & B & C & D)". Conversely, if either of the first two expressions is false, the third expression must also be false. For a simpler example, "IF A OR B" is true if A is true, if B is true, or if both are true. It gives you exactly the same results as "IF A OR B OR (A & B)".

There can be problems activating triggers that are aligned exactly, so it's generally a good idea to offset them just a bit to ensure this can't happen. Of course, it looks better if the physical bookcase is offset to match the offset applied to the triggers so the books align properly with the shelves.

The door animation isn't something you can control. It sounds like either your wall and door pieces are not properly aligned or you're using pieces that weren't designed to be used together.

Good start, but I would consider taking it one level deeper. Beneath (Modder's Name) add something like a (Mod Title) folder and put your furniture, rugs, etc. folders under that. After all, you may enjoy modding enough that you will make more than one mod, and it will be easier to package each one if the pieces aren't all mixed in with the others.

The yellow mountain flower will also grow in Castle Volkihar Courtyard after Valerica replants her garden, and samples are found on the Inner Sanctum altar in Forgotten Vale, so it must grow somewhere in the vicinity. I don't think even a strict lore stickler could fault you for placing it in sheltered or warm areas, such as Eldergleam Sanctuary, the hot-springs area, or the lusher caves (Bloated Man's Grotto, Moss Mother Cavern, Shadowgreen Cavern, etc.). I think that would let you put some just about anywhere in Skyrim while still keeping it fairly rare and ensuring lore-friendliness. Though, personally, I wouldn't object to seeing it wherever it pleases you to put it. I don't know of any lore that directly addresses the question. We only have whatever deductions we can draw from where we find it, which may have more to do with the devs wanting to add something new for the DLC rather than having lore implications.

What Arion said. And, by all means, read the "How To: Package Your Mod" tutorial here RIGHT NOW. Especially the section on folder structure. If I had read this before getting started with my first mod, it could have saved me a world of grief down the line when it came time to package it for distribution. You may someday decide to do additional mods, and starting off the first one on the right foot will leave you in a position to make that decision without unnecessary pain in revising folder hierarchies.

Looks fabulous! Regarding the lanterns, the retex/remesh is great, but you can also get some nice results using Funktasm's Morrowind Clutter textures on the vanilla mesh. I made some decent-looking brass lanterns for the FPI Gallery that way, though I didn't release the ID codes to users because I hadn't discussed repurposing the texture with him. (He's a generous guy and I think he'd go for it, but it slipped my mind to ask so I just used those lanterns as architectural elements.) There might also be some vanilla metallic textures that would work.

There are lots of modding instructional vids out there. I would recommend going to YouTube and looking up DarkFox127 for some outstanding examples.

Ah. I haven't had time lately to follow the scripting threads as closely as usual, but now I understand what level you're operating on. I did have the feeling that you might be tripping over your experience with real programming here, as I think most of us programmers do from time to time when dealing with the feeble thing that is Papyrus. One of the flaws of Papyrus is that it doesn't give you access to all of the data for an object. For example, you can't set the Model field or the intensity of a light via script, but can only do this in the CK. Thus, the CK must be used to pre-define all of the information that Papyrus can't touch, preventing you from instantiating anything free of CK connections. I am aware of a method for using the console to move a mannequin, but it requires the use of the CK to look up the RefIDs for the invisible bits, after which you can move the marker, physical model, etc. a piece at a time. If you can gather all the information with a script, that would be fantastic. I've not yet worked with aliases and dynamic attachment of scripts, so perhaps you've hit on a workable approach. I certainly hope so, because the generic ability to move functional collections such as mannequins at run time has been a holy grail for a lot of us. (Being able to instantiate them with a simple PlaceAtMe would be even more of a boon to console decorators, but I will settle for the ability to move them around. That would at least allow one to set up a warehouse cell from which pre-defined collections could be moved.) Good luck with the project!

No, I'm afraid it isn't a simple syntax issue, if I understand what you're trying to do. Excuse me if any of the following is too elementary for you. No slight or insult is intended. We can't create our script objects out of thin air by just referring to the script, as you seem to be attempting. We can only create objects that have been pre-defined in the Object Window of the CK with a base form ID. When we instantiate one of these forms in the game world, say by dragging a basket from the Object Window to the Render Window, we create a copy that is an instance of one of the native script types, such as ObjectReference in the case of a basket. If we wish to create an object that has extensions to its native type, we must add a base form ID of that type to the Object Window and then add our extension scripts as properties of that form. So, for example, we might whip up a model of a snark in a 3D modeling program, create a Static form that points to that model in the Object Window, and then add a script named Snark that extends ObjectReference in the data window for that form. We can then create copies of our snark object in the game world either at design time (drag-and-drop in the CK) or at run time through another script, which seems to be your goal here. Run-time instantiation can be done in two ways. One uses the PlaceAtMe function, which creates one or more copies of a given form at a given location. The location may be the player or may be some other target, such as a marker or another object. The second method is to place copies directly into the inventory of a player or container using AddItem. The second, instantiating script must also be attached to a base form. This form may be a trigger area or other activator placed at design time, so your object will appear when a character walks into a trap or pulls a lever. For example, see the Papyrus Basics tutorial here that adds gold to your inventory when a button is pressed. Or the form may be a Magic Effect that causes your object to be summoned. Or it might be something else, such as a quest stage. If your second script also needs to communicate with your object script -- to check or set properties, call functions, or trigger methods in MyExtendedClass or its parent ObjectReference -- then you're getting into slightly deeper waters. If this is the case, I would modestly suggest checking out the tutorial on Simple Inter-script Communication. This tutorial covers the basics of getting a handle on an object so that you can work with its scripts. Hope this helps.

Just off the top of my head, you might want to check the quest where you retrieve Potema's Skull from the catacombs. There is a room there with some dead draugr and vampires lying around that she resurrects. Or, for that matter, any dungeon where you find draugr in open crypts might show you the kind of script you need.

It really helps if you develop the habit of indenting your code properly. That makes it much easier to check that block start and end statements (if - endif, event - endevent, etc.) are properly paired, especially when your nesting starts getting deep. However, deep nesting is usually a sign that you need to break some code out into functions to simplify the structure of the script.