Sphered

Nifskope is handy for stuff like this. Here is a shot showing where you go to see that info Also there where its says BSLightingShaderProperty there is a flags section which says whether this model uses vertex colors or not More or less the same process for SSE mesh if its that, just the layout in skope is a little different. And honestly it might be just fine to disable vertex colors entirely. But either or, just make sure the color scheme is all white like in this shot and not all black if you do keep them enabled

Does it look black in-game too? Its most likely a vertex color setting causing this, but the game basically ignores that and usually renders it the expected way For tools to see it the way you expect, check your shader data and the shape data. There is a vertex colors section in each and if they dont agree with eachother, yeah black can happen. Check the actual color scheme too under the shape data. Your exporter or tool might have defaulted all to black. All white is the typical default for Skyrim

NiOverride is never mentioned with camera stuff and I have no idea why You can move nodes instead of your ref. Say.... NPC COM or NPC. Thats not the same as moving a ref, camera-wise. Clipping and a lot of annoyances wont happen when you do it this way. These node adjustments have a first person argument so if you try this route be sure to use the applicable arguments

Unless there is a magic effect parameter I am not thinking of, there is no direct way to natively do this. There are ways you could sweep a radius around you, and call the actor function HasLOS() which will give a good idea of at least can detect you. Beyond that it would take some out of the box conceptualizing and testing to narrow it further

Scaling doesnt increase collision scale Skin collision might be different but you pretty much need 3ds max or otherwise a program that offers collision support. You could try editing the boundary box around your race skeleton nif in skope, but I have no idea if that will help with your hitbox issue

Those are basics. You definitely want to learn how to write a script before diving into complex capabilities Example of an entire script ScriptName DemoABC Extends Book Event OnInit() Utility.Wait(2.0); Waits two seconds before continuing. Optional Debug.MessageBox("Lets go to... IDK how about Monument") Utility.Wait(0.1); The 0.1 delay ensures the message pops before moving you Game.GetPlayer().MoveTo(Game.GetForm(0xDED8F) as ObjectReference) EndEvent Thats an entire script. You need to declare what it is at the top. From there. Do whatever you want like register for keys (SKSE) or anything you like to use or do I extended Book. This means it this script, as is, will only work on Book Forms. Attach this to any book. Then load the game. You will port to Gjukar's Monument. If you attach this to say... an Actor. It wont do anything since you arent extending Actor. Pretty much all there is to it. You are telling the game what you wish to have it do for you

Overcomplication is the biggest obstacle Start simple String ByeHead = Debug.SendAnimationEvent(Game.GetForm(0x14) as ObjectReference,"KillMove1HMDecap") Thats it. But that in your Init or whatever function you are using. Your head lops right off Packages and all that jazz. Is about the immersion. Immersion is good. But it needs to take a backseat till you grasp the basics Now. After you see how easy decapping is. You then can dive into more steps. Like with NPCs, you might want to keep them from moving or running away. Running wont help them, but it might visually make the deed look awkward and wig out So you can do this to address such annoyances Whoever.SetDontMove() Utility.Wait(0.1) Debug.SendAnimationEvent(Whoever,"KillMove1HMDecap") Whoever.SetDontMove(False) And so on. You mentioned that dependent version the other day. That one is like fast-forwarding to the most tricky types of scenes in the game. You might find you can avoid that approach completely. Or you may still want that one, but it seems you are quite new to this and have some basics you need to get under your belt

I suspect this will help you out https://www.nexusmods.com/skyrim/mods/77135 Not my mod. It looks like it is right up your ally. Good luck

I reproduced this scene a long time ago and was annoyed with how finicky it was. Here is the part that matters Condemned.AddDependentAnimatedObjectReference(HeadAxer) Condemned.AddDependentAnimatedObjectReference(Guarding) Debug.SendAnimationEvent(Condemned,"IdleExecutionerChop") Utility.Wait(2.0) Condemned.RemoveDependentAnimatedObjectReference(HeadAxer) Condemned.RemoveDependentAnimatedObjectReference(Guarding)Above is after you have decided who is doing what, and have them assigned properly. The chopping block uses keywords. Those might or might not be negotiable I dont recall, but dependent animations arent done much I can suspect why I nailed this scene pretty good but cant locate it in my archives. As long as you can position them appropriately and they have the right keyword for their role, above should do it

Dependent-something animation whatever its called Those are quirky as hell. Distance matters. Keywords matter. Timing matters You might require three people. The scene as I recall, needs someone being chopped, someone doing the chopping, and a guard who either observes, or pushes them down onto the block. Been a while so going off memory, but to pull that off would be a trial and error deal. Try to commence it, with as little object interference between the actors and their standing spot as you can. Other actors will interrupt them, and again its just a really sensitive scene to pull off

There are a few places that texture gets looked at under the hood Race Level Headpart itself Preset can point to a head texture If you load a preset in racemenu, it too, has texture paths Seemed weird to me for there to be so many but anyway, my guess is you either dont have the desired tex set as default at the race level, or you overlooked the headpart or preset pointing to a different one

OnEquip would do it in a pinch. That event gets triggered when you attempt to equip a misc item, aka when you click it in your inventory. It will give a notification you might deem unimmersive though. It says you cant equip, and will tell you every time An alternative could be OnRead() with a book. The book itself need not have text, but it wont give that message, and should open the menu. To open the in-game crafting menu you can point to a reference table in the game, and via script, activate that table. At least thats how you typically can activate things remotely. I am assuming crafting furniture is not an exception, but it well could be

Def check out https://www.creationkit.com/index.php?title=Category:Papyrus It was a common reference for me with AI packs and animation events but also has an excellent papyrus section with categories and would likely be useful to you Do know though there are things you will pick up that arent common knowledge or known possible These two blocks accomplish the exact same thing... If Nazeem.IsDisabled() Nazeem.Enable() EndIfVs... !Nazeem.IsDisabled() || Nazeem.Enable() One line vs three. For me, tidyness starts to really help when a script starts getting a bit busy. Lot easier to read one way vs another depending on preference. Point being, do you, and enjoy learning. Anyhow, good luck on your project

A template is meant to prevent the need to keep reinventing the wheel for a different package, as it can take a bit of time to sculpt one from scratch. You still have to make a new package for a new goal, in case I understand that you hope to create less packages To actually reduce packages, would entail building multiple stacks within one package, each with various conditions to perform them. Aka ifinfaction ABC, skip these stacks and do this one. Etc. This can be very efficient once you build a solid product, but getting there is prone to easily messing something up, and can be painful if you want to revisit something and update it

The sources themselves are invaluable. They literally tell you everything available in the game, and many functions are noted with detail of what they accomplish. They are in your data folder for immediate usefulness Self-teaching when motivated with a goal is imo the best method

Place hundreds of refs of assorted jewels and coins. Disabled initially and enabled as wealth gets added. Thats one way This kinda thing tends to lend to bloating if done the envisioned way. But if creative enough, a somewhat efficient way could likely be pulled off. Just a matter of putting in some time into a project

You could do it as you imagine, if you use a custom skeleton which requires its own race. Give the head node a 0.1 scale or so, and you could put some gore there at the neck area. As for a head being on the ground I suppose you could take a facegen mesh and remove the bones and just place it near the body. Dont see why that wouldnt work. Could give it collision too just like any other object, and tie them together with a scripted havok constraint A slight bit of effort imo but if you really want that theme you could go that route

Adding or changing a node on a skeleton.nif file is incredibly easy and may be the right move if mods arent doing what you want. In the end, its all based on node names. Your weapons have a NiData String pointing to a node. You can move that node anywhere you want, or even make a new node, and change the string data in your weapons to match Its so much easier than it might sound to do this stuff. Just open a nif in nifskope and check out the headers on the weapons, and look around your pelvis (or perhaps spine) area on the skeleton for the node you want to configure

*shepherd Guess we can blame mass effect for this tho

I think that color means its busy or already open or whatever elsewhere. Try closing the ck and reopening the plugin in the ck, then see if you can go right to it and move etc

If you already have a facegen nif, you dont need the ck at all if exactly seeking to replace the look of one npc head. Thats all handled in the nif. The nif has strings. Strings in this case are labels of the editor ids for the face parts You need only ensure the labels/strings of their face parts, match what the editor ids are in the ck. Even if you are using blue textures for eyes, if their eyes are called eyebrownfemalehuman or whatever its called in the ck, call them that in the nif too Caveat is if you are using high poly on just this npc. Those have different tri files, so if using something special here with this npc you will need to setup a record in the ck pointing to that This is much simpler than it likely sounds. Just a text matching text deal

My assumption, since not looking at it atm, is beth uses idle markers and furniture for ambushes like that. Those are race-based aka only that race is made to perform the animations used in those moments Humanoids, assuming your ghost would be human-based, could use idles to simulate an ambush with no collision worries. There are idles you can invoke with script. IdleNocturnalEnter and IdleNocturnal_Rise. Timing will need to be played with and perhaps alpha settings and such for immersive spawn, but those would accomplish what you want Got a chance to look real quick in the CK. NocturnalMarker FormID 101A75 might be a good route to explore. I have found when making custom scenes I tend to fare better just manually doing this stuff but markers could be helpful

There are mitigations available to ease unwanted side effects SetAlpha() so to where you cant see them. ATM dont recall if its 0 or 1 that hides them lol MoveTo() can be used to move them several units below or away before being sanitized Depending on needs and goals, stuff like EnableAI(False) and SetDontMove() etc can potentially help I always removeallitems() but I never got a concrete on how necessary that is to fully delete actors or containers

A conflict would be if you tried having two bannered mares in the same place, or two different actorbases trying to be the default innkeeper at the same time, etc References which are placed in the world, are their own. They are their own record, so no issue placing them in a common area. The game knows to move refs over a skosh automatically in-game, if more than one ref gets put in the same coordinates You're good. Place away

Not blindly picking ancient mods nearing a decade old just cuz they were first therefore "popular" What they said above plus actually ask yourself what you want in a game, knowing there are tradeoffs. You have a lot of excess equipment there and some of those will definitely cause you issues