kinggath

Necroing this thread because I just ran into this issue while experimenting with interior settlements. It's definitely due to Roombounds, and I have a nice simple scripted solution to at least make the items appear after they are placed (the invisible while holding them before building them problem will remain) Add another script to your custom workbench with this: Event OnWorkshopObjectPlaced(ObjectReference akReference) akReference.Disable(false) akReference.Enable(false) EndEvent Then, whenever the player builds anything in them, this will quickly disable/enable those items to get past the rendering issue.

I wanted to chime in on this and say that I absolutely love Vortex and it is absolutely moving the community in the right direction! If we want to continue to grow, we've got to be welcoming to new users. Modding is complicated, and for new users, Vortex simplifies the process greatly. I've actually learned a lot by reading all of the prompts and warnings it gives as I install more mods. It took a bit to get used to the sorting method, but just reading the on-screen stuff got me through it. I'm super excited for mod pack support, as I think that is going to be the ultimate invitation for new users to get more heavily into modding (we'll be like drug dealers - giving them a taste of what's possible with a shiny mod pack and then they'll be hooked!). Thanks for the commitment to this new software Nexus team! (PS. I voiced my preference on Elianora's post for drag-and-drop when I'm developing as a time-saver, but for playing, and for people who are new to modding - I think the Vortex method is a great way to be introduced to the concepts)

In response to post #72143393. #72144508, #72144708, #72144743, #72144783, #72144978, #72145133, #72145678, #72145908, #72146263, #72146413, #72146538, #72146543, #72147408, #72147963, #72149828, #72150433 are all replies on the same post. I agree with Elianora that having access to simple, drag-and-drop, manual ordering would be nice. I use Vortex for my gaming machine, but for development - it's too cumbersome. When doing things like upward-mod merging with XEdit, or trouble-shooting conflicts with mods, I can't have an auto-sorting system messing with the science. So I end up using NMM as a quick solution to updating my Plugins.txt file, particularly when I'm trying to do dev work.

Is there somewhere to read about the logic behind eliminating the easy to use method of manual mod order? As others have said, this ends up being a pretty useful feature when testing during development.

As some of you may know from my Builder's Toolkit for Sim Settlements, I really enjoy teaching new people how to mod. I'm looking for other people who enjoy writing tutorials, or recording video tutorials. If you are one of those people, could you message me? I have something in mind that I'd like to propose. Anyone else reading this - if you know of anyone who's into making tutorials for FO4 modding, could you post their info here and I'll try and reach out to them directly? -kinggath

Open the WorkshopParent quest, then open its script properties. The max work values are controlled under the WorkshopRatings property.

That worked flawlessly.

That might work, just check for all the terminal related animation keywords. Will give it a go - thanks for the suggestion!

I assumed that SomeObjectRef.GetBaseObject() as Terminal would tell me if an object reference was a Terminal type, but it doesn't seem to be working in my tests. Has anyone thought of a clever way to find out if an object reference is a Terminal?

Could you upload your save to google drive or something similar and PM me a link? I won't have time to look at it right away (about to leave for vacation), but I'm very interested to find out if this bug can be fixed. EDIT: And the sniped becomes the sniper. :bows to damanding:

Place the stairs in a worldspace and press F4 to reveal the collision mesh (you might be able to do this from the preview window of the object- uncertain). If a mesh shows up as a white frame, then it has stair helpers and it should be working. If not, then you'll need to create the stair helper(s) in 3ds and add them to the nif.

So with the settlers and workshop scripted objects I can always prid them even after save/quit/reload. Does that mean they are persistent? Also, do things like actor values reset if you drop persistence on an item? A lot of the information I'm finding is not just on the wiki but also from old skyrim posts, which obviously things have changed (by how much is unclear). In the skyrim explanations I'm finding, the difference between persistent and unpersistent is that a persistent ref basically keeps the ObjectReference around, whereas a non-peristent ref will just keep the coordinates/rotation data and the form ID and then when it's loaded a new ObjectReference is created there and then destroyed again on Unload. How that affects attached scripts, script changed actor values, and keywords - I have no idea. Since most of this information comes from Skyrim findings - I'm hoping someone can clarify how much of this is still accurate for FO4.

I guess that's not clear to me either then - what exactly is persistence? Is it just the 3D data? I seem to be able to access any properties on these objects remotely, I can move the objects around, I can even assign the actors to things, so far the only thing I haven't been able to do is rotate them without first loading the 3D.

Just found another clue that leads me to believe those things are persisted: GetWorkshopResourceObjects, which can be used to get settlers or resource objects based on an AV, it works no matter where you are even if the location is unloaded. For example, checkout this tidbit in the WorkshopParent script ObjectReference[] Function GetWorkshopActors(WorkshopScript workshopRef) return workshopRef.GetWorkshopResourceObjects(WorkshopRatings[WorkshopRatingPopulation].resourceValue) endFunction You can use that anywhere and it will return you references for all the actors that you can act on. Does that not require persistence? Again, these are the things I'm trying to understand so I can make informed decisions on how to proceed with part of a mod...

Thanks for the input - I actually didn't know about the forcepersistent command, could come in handy for testing. The WorkshopObjectScript only unlinks refs that are linked with a keyword set in properties for the workshop objects, it's actually only used for Guard Posts to make the NPC stay there during combat. Though that definitely gives some hints. Another hint I've found is that WorkshopParent uses SetPersistLoc on settlers that were spawned into the game. As far as I can tell, the point of SetPersistLoc is to automatically persist when that location is loaded, though that seems bizarre to me because any references in a loaded location would already be persisted. I guess it could be a way to prevent unloading until an entire location is unloaded, that way, for example, if one cell of Sanctuary is unloaded, the NPCs would remain. I guess there could be some engine level thing going on where certain objects, maybe those with scripts attached, are assigned unique IDs but aren't persisted. Which would make a lot of sense actually.