digitalpartisan

As others have said, no, sadly, there isn't. But I notice your example uses an alias as the property. Is that merely an example, or is it your actual intention? I ask because if you're going to point to an alias anyway, would it be possible to use a reference collection alias? Those, depending on your needs, can be populated automatically (since many quests do so) using criteria on the collection alias itself. If you could possibly go that route, you could have a single reference collection alias and iterate over the contents in it.

The input up to this point has been spot on, but I'd like to offer another perspective entirely. This problem could be solved by not declaring the function global. Sure, that's significantly less convenient from a coding / configuration standpoint, but it would offer a significant advantage from a flexibility standpoint. Yes, you would have to attach this script to an object and have other scripts accessing your logic, which in turn means adding a property to the scripts containing the fragment you're working on, but the option to change configuration (of variables, values, and all that stuff) in the editor without needing to change a script and recompile it is incredibly helpful. Just about every mod I've worked on where I've had important time / game time / math / etc. work going on has a configuration quest object in it that every other component ends up accessing. I've almost never seen fit to change any of the values from their defaults, but it's nice to know the option exists. This is doubly so post-release where a bug may have manifested itself that hasn't got anything to do with scripts and a fix merely requires changing a value in the editor. Fragments, as such, are on Quests, Terminals, Perks, Effects, etc. where there needs to be a customized response to an event of which the game engine informs the object in question. And yeah, that's a little bit obvious, but I say it to call attention to their real purpose. What does and doesn't belong in a fragment? Really, they're a pain to deal with (and yes, I know you all know that,) so they need to be as minimal as possible such that they only call other code (or perform the most basic of actions that isn't likely to change, such as closing out or activating quest objectives) that does real work. That way, the fragment doesn't need to be bothered with once it's written. Also, it's probably best to learn to interact with the scripts where fragments live. I had to deal with moving and changing them when I wanted to work on a mod that I had in version control. Moving the fragments into the namespace for the mod was a great choice. There have been a number of times I've had to fix a busted fragment script by hand since there was no chance of getting to compile correctly by editing the fragments. Do note that when you make these changes, it's best to do so after the mod has been saved in the CK and the object in question is closed. Edit, recompile, then reload the mod. This is especially helpful for mucking about with property changes on the fragment scripts.

There are multiple ways of going about this. The most basic is to place the object you want in the editor and then add to it the scripts DefaultBlockActivationOnLoad and defaultdisablehavokonload. On the scripts tab of that object reference, check the "Don't Havok Settle" checkbox. If you have your own object specific to your mod, you could add these scripts to its base form so that you don't have to add them on every single specific form you place. If the object is being placed by a script (or is otherwise available to be an ObjectReference in a script somewhere,) you could call BlockActivation() and SetMotionType() on that object with the appropriate parameters. If you're unsure how or why to do that, get a look at the scripts in the first method and see how they do it. The note on the first method about adding the script(s) involved on a base form applies here as well. Lastly, though quite possibly the least convenient unless you want to build complicated sets of static objects to be placed in the editor or as workshop objects, you could use the Creation Kit's static collection tools to combine objects placed in the editor into a single nif file and create a new static object in the editor which uses the new nif. This requires the objects assembled into the static collection must be static objects themselves. You may or may not need to create those static objects in the Creation Kit and point them at the models you want to use in the collection.

Sorry to have come into the conversation late, but I published a script that does this and I use it with all my mods. It's done quite well and it was intended as a modder's resource for those that need it and don't feel like bothering to program it themselves.

The primary focus of my mods is also Papyrus scripting. When I first started releasing mods almost a year ago, I, too ran in to the PS4 problem. To the best of my knowledge, no one has ever managed to slip something past Bethesda's packaging process and load it on to their platform. That said, I haven't read the material mentioned in this thread and I'm making it a point since it looks like good reading.

Don't be afraid to ask for scripting help if that's all that's standing in the way of what you want to do. Obviously, you can get the base ammo type and that's almost certainly going to cover you in most cases. There aren't too many other edge cases considering mods that can alter ammo types. I can think of a few ways I would go about this in terms of scripting and one of them is even open-ended so that plugins adding weapon mods that change ammo type can easily be incorporate to truly make your script generic. Granted, even without that feature your what you're looking to do might be more complicated that you expected, but that's not a huge deal-breaker, IMO. The underlying issue is that you need to associate a particular keyword with a particular ammo type. The way to go about that would be a struct. More precisely, you'll need an array of them and you'll need to iterate over it to check for each keyword that might alter the ammo type. If Papyrus didn't have certain restrictions on what can and cannot go in to structs and arrays, it would be possible to make this lookup process more efficient. Strictly speaking, it still is, but it would become convoluted to the point of impracticality. Regardless, that's what you'll need. If you intend to make your script something that third-party plugins can interact with (or better yet, you intend to write a plugin that will detect plugins that interest you and automatically pull in the appropriate data from them,) you'll want to add a function to the script you write that adds another of your structs to the array. Does that help any?

A thought on that "already loaded" issue. Would it be possible to force that activity by way of script just to be sure? I've made a few mistakes with some of my mods that required an update which wouldn't take effect if the cells in question had already loaded and certain objects were fixed in place due to data in saves and I'm always looking out for issues like this. Most of the time, when I have to move something that isn't relatively unimportant, I can just delete it and place another (making sure to reset property values referring to the deleted reference when needed.) Just thought I'd ask since the issue came up.

Another thought: Many months back, I made a mod that used alias references for the first time. I made a few mistakes and learned a ton from them. Generally, when a quest has stopped (or is stopping, since many of these things happen at the same time in the engine) the quest's aliases are emptied, so copying a value from one of them at the wrong time will copy over nothing. If there's a particular stage in your main quest that indicates failure, then the script on that stage should load the value into the other quest and then actually stop (or fail, etc.) itself. Alternatively, if there is only one NPC this could possibly refer to, then is it not easier to just force the alias on the alternative quest to point to the (unique) actor in question.

Generally, the way to figure out what is (or, rather, what should be) the problem with this type of bug is to do a check like: if (None == yourVariableOrProperty) Debug.TraceStack("OMG it was null") ; because it's frequently helpful to know the execution path that resulted in this error else yourVariableOrProperty.yourFunction() endif Defensive coding where no action is taken if there's nothing in the variable pointing to the object you're trying to act on (with the associated debug output) is generally the best way to go. I say that as someone who has made plenty of mistakes in his Papyrus libraries and finally just gave up and forced myself to do detailed debug logging and defensive programming from the word "go" in my modding work. It saves a whole lot of time trying to sort out what didn't work. Good luck.

Ah ha! I've used the wrong word entirely. The word I was looking for was Persistence. And whatever else wait() behaviors do, they also force the engine to unnecessarily persist an object that uses them.

Whether or not someone has published some profiling is a good question. I can't find the "best practices" page on the FO4 Creation Kit website, but I do recall it having said something to the effect of "timer events are preferred." I suspect part of the preference may lie in the fact that timer events can be cancelled prior to termination. And it may be true that the script calling the Wait() behavior is actually freed up (and I confess it's been a while since I've reviewed the threading details of FO4's Papyrus implementation,) but this brings up the issue of exactly how the Wait() behaviors operate. Do they stick around in the name of the calling script? I admit I don't know off the top of my head, but I probably ought to figure it out since I'm in the process of rewriting some scripts from a mod of mind and extracting them as a modder's resource Papyrus library and much of the point is to actually force certain behaviors to execute serially despite threading being available in order to avoid hogging resources for things that really don't need to be threaded. In the mean time, I'll see if I can't tamp down exactly how the wait() behaviors work. Some mods have source code that frightens me - especially those dealing with timed workshop objects - because a single call to some wait() behavior can't really take in to account other events that may affect whether or not the timer should still process. It may be the best thing for the OP's mod that the wait() behavior is used if, at the time it is called, the next lines of could should absolutely always execute.

And now I'm off to learn more about PackIns. Thanks for the infinitely better solution!

This is a bit trick, but it's definitely do-able. Find the lights in Vault 111 and edit those object references. Using the tabs on the dialogue, find which other references they link to and which link to them. Hopefully, there will be some information in one of those tabs about the object which causes the lights to turn on. Find the scripts on those objects and see how, if at all, they interact with the lights. Should that tell you nothing, you could brute force it and delete one of the lights from the world. A warning should present itself indicating which object will be affected by that light being removed. That object is the thing you need to have a look at. I know the light object you're talking about, but I've never examined it closely in the editor. Are there any scripts on that light object? If so, is there any chance you could tick a box on a property (on the object reference you've placed for your mod) and just make the thing turn on? Admittedly, that's a long shot, but it's worth investigating. Good luck.

I'm not entirely sure what you're encountering. Would you be able to describe the message in more detail? Further, could you clarify what you mean by "when I go to edit the script I get the message in the title?" I'm familiar with a couple of error messages that might be the one you're referring to, but neither one of them have anything to do with editing the script, but rather assigning property values on the object the script is attached to. One of them might present itself when properties have been removed from the script and the editor detects existing property values are no longer needed for that script on that object. The other would present itself when properties marked "Mandatory" in the script's code have not been assigned a value, but you exit the property dialogue regardless. If I follow your last line correctly the activator's base object has the script attached, but no values in the properties because they cannot be known until they're assigned to a specific instance of that activator in the world. That makes plenty of sense given the nature of the mod you're working on, though I only spent a moment or two looking at the mods you linked. My suggestion: Find the base object of the activator you want to place in the object window, right click, and select "use info." From there, you'll be able to quickly locate cells where the activator is used and examine what's on one of them. I'd recommend checking at least two so that you can determine what the differences are between each setting. If there's not a whole lot of difference, or you believe them to be trivial in nature, then you can actually right-click on the property and copy it's value to place into the property on the activator you choose to place for your own purposes. If, on the other hand, turns out the values are not trivially replicated, then they likely reference other objects in the world which are uniquely placed along with the original mod's activators. You'll need to replicate those objects (and any settings on them) in order to add your activator. Does that help any?

I'll note that the Utility.Wait() and similar methods are generally not recommended unless there's a specific reason to use them. While it's a little bit more complicated, it's more recommended to use SetTimerGameTime() and to intercept that timer (using the ID you specify) with OnTimerGameTime(). This way, you're not forcing the game engine to keep a specific script running while that call to the Utility script completes. There are quite a few otherwise great mods floating around that make very bad use of timing-related features and it's best not to make your mod one of them.

I have this same error in multiple blender installations. Firstly, I used a 2.78 guide that others report to work with Skyrim nifs. Secondly, I used a mobile blender download from the Nexus which was a 2.49 setup following the recommended package / version instructions. I got the same error. And yes, I made sure that the other versions of Python, etc. were uninstalled just to make sure this wasn't due to a version mismatch issue (since the mobile blender package included everything it needed.) I'm forced to conclude the blender niftools may not work with Fallout 4 nifs. Has anyone used blender to complete a modelling project for FO4?

Have you tried this with FO4 nifs? I can get the dev version of the plugin running in the latest blender version with no issue, but other users are reporting a python error which I replicate as well. It's worth noting that I tried this in a mobile blender 2.49 off of the nexus and I got the same error despite that particular package being constructed according to the instructions others use successfully.

Ditto on the request for workflow and the like. I attempted this process with Blender 2.49 but nothing I did would allow the nif addon to install itself. I've got it installed easily enough, though as reported, import is busted and export seems just as wrecked.

Could you provide the specific contents of the EditorWarnings.txt file related to your content? I agree that warnings caused by your own files are to be dealt with. With the exception of a couple of incredibly obnoxious warnings which only come about as a result of merging one of my mods with its optional DLC-related plugins into an All-in-One package, I've dealt with every warning I've ever generated. At some point, I'm going to do the same with those other two just because I hate having to deal with those annoying messages. It's important to remember that we owe it to our users to make sure we're not messing with their save files (beyond what is needed to actually use the mod.) Odds are, you can perform a tweak or two in the CK (or in FO4Edit if you need to filter for dirty edits or the like) to fix the problem. If I had to venture a guess, based on what you've said here, the CK is just making a mess of something since dropping in a NPC should cause no issues whatsoever.

Ditto what Zzyxzz said. I wrote a Papyrus library that deals with injection into form lists, leveled items, and naming records. Sometimes, these are accessed remotely by using the name of the plugin required and the ID of the relevant record in that plugin. The plugin's position in the load order doesn't matter because the plugin and the rest of the ID are what really identify the record.

I'm semi-competent with Nifskope 2.0.0 in that I can perform basic block manipulation enough to add connect points to objects that don't have them and import meshes from other nifs (as well as make sure their texture data and related information is set correctly post-copy.) The issue I'm running in to now is that moving the collision information over doesn't seem to pan out inside nifskope itself. There's some reference data that I don't seem to be able to copy from one nif to another. Normally, this doesn't matter if you combined meshes such that you're using a large base and relatively small additional objects, but slapping together objects that you then just walk through is more than a little upsetting. Here's what I've tried: Straight-up copying the collision data (fails due to being unable to stitch up busted references in the new nif)Copying bits of things inside the collision block (no juice so far, but I'm going to try a few more things)Several difference searches both of the Nexus forums and other resources linked therein, but the instructions are clearly for older nif and nifskope versions (when they're not just broken links from almost ten years ago.)Is this possible in nifskope itself? If not, am I going to need to get Blender setup to export shapes as nifs? I'm on the verge of needing to do some actual modelling for another mod anyway, so I've taken a few stabs at making this work. Thanks.

Ditto on what others are saying. Double check where the source files you unpacked ended up and move them if needed.