MasterMagnus

Design a custom Package that tell's them to only sandbox in a given area? I haven't done this myself so I don't know really. But from what I can tell about creating sandboxing packages that would be my first approach.

I believe (last time I looked) the CK doesn't actually update correctly but it should work in game if you save and check it. That's all I remember about it, sorry I can't be more help.

-Select the thing your editing in the 'Face Tinting Layers' list. -Move the slider in 'Face Tinting Color' to 1 (it should be marked 'Face Tinting OPACITY' in my opinion) -If it's something that can be colored you can use the Red Green Blue boxes to change the color (or Select Color for the palette).

Yes it's possible. Copy the path of an existing one you want to use. Paste the path into the file browse box (making sure you're in the correct place in the folder structure). Although it's not on your hard drive to select you can just paste the path and it should show you the model if you got it right when you click ok.

Found documentation on CF() CallFunction() http://www.creationkit.com/fallout4/index.php?title=CallFunction **EDIT** Here's CGF() CallGlobalFunction() http://www.creationkit.com/fallout4/index.php?title=CallGlobalFunction Oh wow found this also. This may be super handy. CQF() CallQuestFunction() http://www.creationkit.com/fallout4/index.php?title=CallQuestFunction

Your image shows a line OnDeathSpell.Cast(Self,Self). Do you have a property for OnDeathSpell() set up correctly on the script? Is the OnDeathSpell() record set up correctly and you've verified the spell works? Does the OnDeathSpell() only work on a living actor? Even though you're capturing OnDying(), might they have died before the execution of the spell completed? What does OnDeathSpell() do? Perhaps that is code better moved right into the OnDying() event? I'm not 100% on how spawning from a leveled list works, but I think using the LeveledListTemplate is fine. You have the script attached to the base record, every Actor that spawns from that record should have that script.

Just thought of a possible helpful change: SetRace() will reset the actor to their base race. Scriptname FixScale extends ObjectReference Const {Repair scaled actor} Event OnInit() RegisterForRemoteEvent(Self,"OnExitFurniture") EndEvent Event OnExitFurniture(ObjectReference akActionRef) akActionRef.WaitFor3DLoad() (akActionRef as Actor).SetRace() akActionRef.SetScale(1) EndEvent

Oh and to the point. Unlimited Companion Framework (which is a fantastic mod from what I hear), is almost certainly the source of your problems. I would try to 'dismiss' them or get them to not follow through the mods functions if at all possible. There is one other thing you can try. It is quite drastic and I'd consider it a last resort. PRID or Click the Actor to select cf "Actor.Reset" OR to teleport the actor to you the player cf "Actor.Reset" Player I haven't tested those through the console, it may throw an error about "multiple scripts with the same function" or "No script found with that function" etc. You can also try cf "Reset" in that case. There is a way to do it, but you have to have the syntax just right. Chime back in here if that doesn't work and we can probably get a reset figured out. Some notes from the CK about Reset():

Shouldn't need any properties with the code I posted. I personally never use Debug statements. Debug code does not run on console at all, and has to have a special build. Or so I understand, as I say, never used Debug once. I like to craft my own message box if I need a feedback mechanism while testing. The more I think about this the more I'm starting to realize something that may be an issue. Furniture uses the 'Scale Actor to 1' keyword to force characters into 1.0 adult scale so that their animations line up with the furniture. Basically I'm starting to think Scale 1 to a Furniture item is different to an Actor's Base Record Scale 1. Furniture considers scale 1 to be Adult Human Standard Height (1). The Actor's record considers scale "The percent of my Race's full height". So your child runs around with 1 scale in relation to a child (all is well). Gets into furniture and gets set to 1 scale Adult height. The furniture's 'automatic reset of scale' puts them at 1 Adult Height when they exit (oops now the game's data for that actor thinks they are a 1 scale Adult). All just guess work, but back to the problem. Perhaps the SetScale(1) works just fine, but because the actor is 'in' the furniture 1 in this context is 1 Adult Scale. So how about you move the code execution to when they exit the furniture? Like so: Scriptname FixScale extends ObjectReference Const {Repair scaled actor} Event OnInit() RegisterForRemoteEvent(Self,"OnExitFurniture") EndEvent Event OnExitFurniture(ObjectReference akActionRef) akActionRef.WaitFor3DLoad() akActionRef.SetScale(1) EndEvent

cf is CallFunction cgf is CallGlobalFunction They allow you to run functions defined in scripts from the console. I have no idea where or if they are documented and I can't remember where I got the info. You can use them to call functions from the CK documentation too, if you address it all correctly and have the correct objects selected.

Scriptname FixScale extends ObjectReference Const {Repair scaled actor} Event OnInit() RegisterForRemoteEvent(Self,"OnActivate") EndEvent Event OnActivate(ObjectReference akActionRef) akActionRef.SetScale(1) EndEvent Something like this placed on your furniture item?

You need to register the script to receive the event. Add this code to your script. Event OnInit() RegisterForRemoteEvent(Self,"OnDying")EndEvent This belongs on an Actor record, where in that context 'Self' will count as the Actor. *EDIT* oops changed that to OnDying()

Interesting, thanks for the research insights there. My current guess would be, they use the keyword to restrict synths from sandboxing on furniture that a synth would 'have no interest in' like sitting at a table and drinking or eating. As you note, they CAN animate that way, but perhaps devs didn't want them eating or working a scrap bench etc.

My guess would be, they use that keyword to mark only furniture that the synth race has animations for. You may assign the keyword to something, but if the synth doesn't have animations for that item it can't do anything (but fall back to sandboxing behavior). There are likely things hard coded about synths, and/or particular to synths. You should make your 'synth' a Human race, and give it a skin to look like a synth. Use a copied settler and keep everything the way it is. This way you have all the animations that humans can do, and normal 'settler' behavior, it just looks like a synth (you can assign a synth voice type too).

If you're just using it for yourself, I'd go with copying those items to your .esp. No scripting required. You might be able to make it as simple as copying the Armor Add-On and Armor records. They will likely still point to loose files in the other mod's folder, but should still work. Since you aren't redistributing this mod you don't have to worry about loose files in odd places. To be sure you're thorough, right click on a record (in the original .esp) and choose 'Use Info' to help you make sure you've copied everything you need. *EDIT* you may see NPC_ records in 'Use Info', for characters that are 'wearing' an armor, which you don't want to copy. I mentioned this really as a way to help you learn to 'reverse engineer' whats going on with the records, just an interesting thing to poke around in. Does that make sense enough to get you started? To answer your question, yes you would write and place that script on the NPC_ record. So that the script would only apply to actors that use the given form as their base.

When you open the CK with multiple plug-ins they are assigned a 'Temporary Form ID Prefix' (the first two digits of the Form ID). When you run the game, the plug-in your using things from will most likely have a different ID than it did in the CK. The game can't find those items because they're at a different ID. You will either need to copy those items from the other .esp into yours, and use the items from your .esp in the outfit record (which is a big NO-NO if you don't have permission from the author to copy their work). OR you will need to code a script to find those item IDs (hint: GetFormFromFile()), spawn them, and equip them on the NPC_. This isn't as hard as it may sound, just add a script to the NPC_ that runs OnInit(). You will in this case also have to note the other .esp as a 'Dependency' for your mod. If it were me I'd avoid using someone else's items unless this is just a mod for your own personal use.

The first two would probably be easily scripted. Capture the OnDeath() event, and lock or unlock the corpse based on your coded logic. Although adding this script to everything in the game may be somewhere between tricky and a huge chore. #3 Is most surely a ton of work to set that up on each NPC_ the way you want. But also very possible, just tedious.

PRID or click to select Companion cf "actor.setcompanion" false false

I chose to put it exclusively on Bethesda.net for personal reasons, and to get a larger audience. I chose to promote it here so anyone interested could grab it. Since it's not hosted here I thought it would help get the word out. Nobody is forced to do anything. If you want my mod, you could probably figure out a way to ask more nicely. You could also figure out how to use Beth mods alongside Nexus mods. As the author I decide where it belongs. You haven't convinced me to change my mind, in fact, if you read what you wrote from my perspective, you've reinforced that I made the right decision about where to host my mod.

In your Fallout4\Data\Scripts\Base folder will be a Base.ZIP file. Extract all those files into the Base folder. These are the .PSC base scripts. The CK takes .PSC source files and compiles to .PEX for run time. DLCs have their own folder and, if released, they will have a source .zip that needs extracted also (if you want to look at the source). You will put your externally written scripts in Data\Scripts\Source\User and subfolders for fragments. The CK automatically puts them in the correct folders, especially fragments, terminals, topic infos. In the CK each entry that can have a script attached will have a small window to attach the script, edit the Properties, edit the Source, and possibly a Compile button which is somewhat redundant with the compile menu option in the edit source window. Right click script for the full options. Once you have those extracted and re-open CK, you'll be able to look at how the built-in scripts work etc. It needs the .PSC file to present you with the edit options, it needs the .PEX file to be considered 'compiled' and be executed in-game. If that all makes sense. Happy hunting! **EDIT** I guess I should have mentioned. .PSC files are human readable plain text, so you can use various notepad editors to work with them.

Models just as static items isn't too hard. You could have a drum set and keyboards that the character sat down at without a ton of difficulty. Animations are the biggest road block though. They could only be 'held' using current animations. Having someone make new animations for even one instrument, never the less a minimal 3 piece band would be a monumental task. Being a musician myself I'm totally in to it. But it seems like too much work with little payoff to create new models that would just sit there without animations. And I don't see the point in putting an acoustic guitar in just to have people beat ghouls over the head with it. Singing at a microphone (and the mic) are done, although it's pretty clearly a female body posture. You could probably use Tinker Tom's 'working at a desk' animation for a keyboard player, although it's just fiddling with knobs mainly. You could maybe use the 'hammering' animation to have a upright chimes player. Maybe the sledge hammer animation for a gong or taiko drum player. Maybe the smoking animation for a harmonica player, that would be quite a stretch. I don't see it happening for a Guitar Bass Drums kind of situation without tons of work. I'd trim back the idea extensively, or think outside the box with using built-in animations and non-standard instrumentation. Ever see a 'one man band player piano?' An upright piano with all kinds of instruments inside, and very steam-punk rube-golderg look to it. Maybe in the wasteland they've created brand new instruments (that are played by shooting at them?) kidding, but you get the idea.

Possibly the object needs a Keyword to flag it as an assignable object? Just a guess.

My Hired Guns mods do that. You can spawn various companions from a holotape. When you spawn a new one your current companion (if it's a hired gun) dumps everything they are carrying in Sanctuary Workbench and vanishes. Links in my sig.

You're probably going to need to use DropFirstObject() and iterate over and over until all inventory is dropped. While it's easy to code this, and seemingly stupid why you can't get a container's entire inventory or drop it all on the ground, there is a huge 'gotcha' to consider. -DropFirstObject() drops singles from a stack until it's exhausted, not stacks. -I fully expect if I tried to drop my level 107 character's entire inventory on the ground at once the game would crash. It's such a nightmare to manage it from the pipboy, can you imagine every single item on the ground? My advice? Don't even try it. It's much easier to spawn a chest on the ground (most likely you'd want it to be persistent), remove all the stuff from wherever into the chest (the RemoveAllItems() works great). Making a function that drops someone's entire inventory on the ground is just asking for trouble, which is why there isn't a simple function to do that.

Interesting. I am currently working on triggering animations. Started after the patch you refer to. So I don't have any past behavior to compare to. Also having trouble triggering some animations that seem like they should work.