kinggath

Did some testing and found that Workshop items are handled special. If you place an item and select it in console mode you can see it doesn't have the persistent flag (looks like [PP] next to the form id). Also, if you leave the location you won't be able to run the prid command to select it, while anything, anywhere in the world you placed with PlaceAtMe can be selected with prid. So the next question is, what is the cost of persisting a static? I would assume it's just keeping the form id, position, and rotation - which shouldn't be very expensive.

I've tested it. It deletes it unless you set the last argument to true, or set the created objectreference as a script property or quest alias.

No, I mean that when you create an item in workshop mode, it will still be there when you come back. In order to have this same thing occur using PlaceAtMe in a script, you have to flag it as persistent. Which according to documentation of persistence, it remains in memory until you delete it. I want to know if workshop created items remain in memory the same way. If so, it would seem that the more objects you create, the slower your game would get over all, even when in a different location. Ultimately, I'm trying to determine how careful I have to be with Persistence. I'm creating workshop items that generate other items nearby via PlaceAtMe. If workshop items are persisted in the same way, than I'm actually going to be saving memory with what I'm working on. If not, then I may need to get a little more creative with my scripts.

Are items you create in the workshop (I'm talking everything from floors and walls, to workbenches and generators) persisted in the same way that items created with PlaceAtMe are persisted? Or are they handled in a special way that allows them to stick around without permanently sitting in memory? Or am I mis-understanding persistence in the game?

Changing existing scripts can be a pain, a lot of the data and functions end up stored in your save file (prevents your save from being corrupted and probably aids in optimization), which is why you sometimes have to wait a few in game days for the scripts to update. I'd first try editing a value you can test easily, for example, the vendor max income and multiplier. To test it, find one of your settlements that is creating the max caps before your change, save, exit, then change the script and sleep 24 hours so your workshop updates again and check if they created more caps this time or the same amount (you may have to find something to do after sleeping/waiting 24 hours as the workshop daily update may not complete immediately).

Are you editing the workshop script? Or extending it?

Is there any way to place texture sets (aka Decals) with papyrus? You can easily place them in the CK, but using PlaceAtMe/PlaceAtNode do not seem to work. Specifically, I'm placing a small building via script, and I'd like some of the walls to have blood and bullet impact decals on them.

They aren't always named in an obvious way, for example CookingMenu is any menu you can create things from scratch. PipboyMenu probably refers to something specific with the pipboy, not necessarily lifting it up and looking at it.

There's no easy way to modify the HUD, you have to do things with flash files. DEF UI is about the most anyone has figured out and release so far, here's some steps on what to edit to do things like that: http://www.nexusmods.com/fallout4/articles/10/? Adding new things would be a challenge, though absolutely possible if you have the patience to figure it out!

CookingMenu is the one for the chemistry station. Try setting a message for ! abOpening as well and see if that fires.

It's definitely something to do with the collision, but I can't figure out what, I ended swapping the static to a similar model temporarily so I could generate the navmesh, then swapped the model back. Tested OK in game so far!

I haven't used it with the lockpickingmenu yet, so I can't confirm, but there's always a chance the CK site has it incorrect. Try lockpickmenu without the ing, or try a different menu to make sure your code is good and firing in the right place (it looks good, but clearly you're having no luck so we've gotta test basic things).

Nothing else is completing or stopping the quest, correct? This event is auto unregistered when that happens.

Using the method I described above you can essentially create your own on/off state variable and use activate to control them. Though it would be excellent to have access to the power system instead of having to muck around like I did! One thing to watch for is items with a long power on animation, if you send activate to them before the power animation is over, you'll lose track of the sync because the activate command is ignored while the animations are playing, so you almost need to figure out the power on/off length of each thing you want to use and account for that in your scripts. It's a pain, but it works.

I've built several custom nifs and so far none have had this problem, when I open up the Navmesh Object tools the item falls forever - only happens with this one mesh so I don't think its an esp or settings issue. Here's a video so you can see what I mean: https://youtu.be/00MYSxSeQfQ Any ideas?

In case anyone else comes across this looking for the same thing. It appears that controlling power is not directly possible via script (at the time of this post, SKSE might change that in the future). While you can Activate generators, to turn on power, you can't actually bypass the power system directly. You can, however, call PlayAnimation("Reset") and then PlayAnimation("Powered"). This places the item into a state that acts as if it's powered, even though the workshop UI will still show it as unpowered. Future calls to Activate(Game.GetPlayer(), true) will then toggle the item on and off. This works for all powered workshop objects classified as Activators or Lights in the CK. The exception is certain lights, such as the hanginglightbulb. These lights have the "Off by default" option set in the CK, and it appears there is no way to turn this off with Papyrus. To bypass this for a mod I needed it on, I was forced to create duplicates of these lights with that option unchecked.

Add Const at the end of the global declaration line, the Const is just saying this property will always be this global, it won't prevent you from setting the value of the Global.

In your script you'll have something like: GlobalVariable Property SomeVariableName Auto Const Now in the CK object window, create a global variable, doesn't matter what you name it as you'll link it to the SomeVariableName you defined in your script next. Now that you have your script saved, and your global variable form created, go to the form you have your script attached and click on Properties. This will bring up a window with all of your properties defined in your script, select SomeVariableName and click Edit Value, you'll then find the global variable form you created in a drop down, select it and click OK on the properties menu.

Does anyone know if it's possible to change whether something is receiving power or not through a script? Once something has power, you can turn it on and off with calls to Activate, but I want to toggle power entirely. Here's specifically what I am trying to do in case there's a better way I'm not seeing: I'm using PlaceAtMe to create workshopLightbulbLight objects, and even if they are near a power radiating object they stay unpowered until I pick them up in workshop mode. I've made sure they have the workshop as a linked ref on the WorkshopItemKeyword. I can't figure out where the IsPowered function is pulling it's information. I've monitored for variable, keyword, and actor value changes before and after I pick up the light in workshop mode and can't find anything that's changing. Could it be using the model's animation graph data to store that kind of information?

Yep, turned out I needed to manually add a LinkedRef linking it to the workshop with the WorkshopItemKeyword.

I don't have a solution yet, but I'm closer to figuring out the exact cause. If I call GetWorkshopOwnedObjects in the OnWorkshopObjectGrabbed event for the spawned object, it comes back empty. When I also place it in the OnWorkshopObjectMoved event for that object, it comes back finding the reference. Something is preventing ownership from completing until after the object is placed in workshop mode. I've now tried calling SetActorRefOwner manually, and that doesn't fix it.

I have a script that spawns in a workshop object, let's say a Bar for example, and then assigns a settler to it. Everything works, the settler works the object, I can purchase things from him, etc. The one problem is that the settler's info card when you look at them in workshop mode shows Unassigned and the spawned object is not highlighted. If you pick up and move the spawned object, the info card updates and the highlighting works again. I can't figure out what I'm missing. The only thing I can think of is that it has to do with the Navmesh, which I've tried calling MoveToNearestNavmeshLocation with no success. Here is the function that does the work: Function Test() Debug.Notification("Running test...") ObjectReference playerRef = Game.GetPlayer() workshopscript thisWorkshop = WorkshopParent.GetWorkshopFromLocation(playerRef.GetCurrentLocation()) if(thisWorkshop) ObjectReference spawnTest = thisWorkshop.GetLinkedRef(WorkshopParent.WorkshopLinkSpawn).PlaceAtMe(SpawnMe) if(WorkshopParent.BuildObjectPUBLIC(spawnTest, thisWorkshop)) Debug.Notification("Spawned work object.") ObjectReference[] workshopActors = WorkshopParent.GetWorkshopActors(thisWorkshop) if(workshopActors) int j = 0 bool assignmentAttempted = false while(j < workshopActors.Length && ! assignmentAttempted) if( ! (workshopActors[j] as workshopnpcscript).bIsWorker) assignmentAttempted = true WorkshopParent.AssignActorToObjectPUBLIC(workshopActors[j] as workshopnpcscript, spawnTest as workshopobjectscript) Debug.Notification("Assigned actor.") endif j += 1 endwhile endif endif endif EndFunction

Imagine you want to make a mod that modifies the formula for how settlement attack outcomes are calculated off screen. While I want to make a mod that modifies the formula for happiness calculations. While we can both do so, a lot of the numbers for both are hard-coded in the WorkshopParentScript, so our mods are inherently incompatible as they would often both involve rewriting portions of the same script file. If instead we had a replacement community resource WorkshopParent script that tied the hard-coded numbers to globals, and added in function hooks to the points without events, we could each make our respective hypothetical mods, and both would work together beautifully. I'm speaking from experience programming in other languages, so perhaps this will end up causing too many speed issues, and the hard-coded values are a necessary evil. If someone else is working on something like this, or it already exists - great! If I just haven't delved deep enough into the scripts, and all this is possible already (and someone can tell me as much) - also great!

Is anyone working on or considered a series of wrappers for the workshop scripts? I ask because, while we can extend the scripts and add functionality that way, there are a lot of hard coded values and a very lackluster hook system. Would be nice to have a community resource so that we could all edit the workshop functionality without stepping on each other's toes and causing compatibility issues.

I found what I believe is a bug in the way Papyrus handles the GetDistance function. Let's say you have a RefCollectionAlias Property pointing to a Quest RefCollectionAlias filled with random ObjectReferences. If you loop through it with while grabbing each reference with GetAt and do a distance check to each on some other ObjectReference - the order matters, if you use the alias reference on the left, you'll get an impossibly huge number, while if you use it as the parameter, you'll get a correct distance. Here's some code to show what I mean: int i = 0 while(i < SomeRefCollection.GetCount()) ObjectReference thisRef = SomeRefCollection.GetAt(i) as ObjectReference float thisRefOnLeft = thisRef.GetDistance(someOtherReference) float thisRefOnRight = someOtherReference.GetDistance(thisRef) i += 1 endWhile Even though, those should come out to the same distance, thisRefOnLeft will have a crazy large number as if the two objects are in different worldspaces, and thisRefOnRight will have a correct distance. I still need to test this in a blank mod to confirm that this isn't just conflicts within my scripts, but I'm heading out right now, so I'll have to follow up later - thought I'd post this now in case someone can explain to me why this happens, or as a helper for anyone else who runs into the issue.