JonathanOstrus

Thanks for the explanation but where must the papyrus code go? When i copy it into my alias window where i created a new script it won't compile :/ Wow, talk about necroing an old thread. I'm not entirely sure I understand what you mean by you put it in the alias window where you created a new script. The specifics of what Papyrus you put in and where depends on how you're having things work. The example I provided can't be used "as-is". It would need to be modified to suit your specific quest use case. Usually you would do something like talk to an NPC and in the dialogue you have a fragment which then sets an objective. Or you would set a quest stage. Then in the quest stage fragment you would set the objective. The code snippet I provided as an example was for a totally different thing. I think it was on a debug book I made which had a series of menus that let you turn on and off different features. Assuming you're doing it from a quest stage fragment, which would probably be the most applicable for people. The simplest code is to just put in the relevant SetObjectiveDisplayed call. Since it is being called from within the fragment of the script who's objective you want to set you don't need to specify a quest. If you were trying to remotely set it then you would specify the quest similar to something like in the CK wiki example, or the code I had. A case for using a dialogue fragment instead of a quest stage, might be if you want to be able to granularly enable and disable the display of the objective. Possibly multiple times. So if you're doing it from a dialogue fragment, and the dialogue is part of the same quest that has the objective. Then you can use GetOwningQuest().SetObjectiveDisplayed(n, true/false) as appropriate. Barring either of those being an appropriate case for you, then the way you would do it is adding a property of quest type to a script (likely a fragment of some type). Then in the fragment you use the PropertyName.SetObjectiveDisplayed(n, true/false). Which is what my code example illustrates. Albeit not in a fragment format. Note that in a fragment you don't put functions, but rather what's inside of a function. My code example is from something a bit more advanced. https://www.creationkit.com/index.php?title=SetObjectiveDisplayed_-_Quest

Since this has been necro'd already, something I should have noticed and pointed out long ago. Make the global update thread safe. KillCountProperty.SetValue(KillCountProperty.GetValue() + 1) Should be written KillCountProperty.Mod(1)This will ensure that during the modification operation there's no chance that the script may be suspended and the global modified by someone else first.

I'm going to preface this with the fact I have not used VSCode yet. It's on my list of things to try but I just haven't had time. So some of my suggestions/needs/etc may already be supported. I presently/previously (been a while since I've done any coding) use Notepad++ the most. I tried using Atom which was nice and had better support for some features, but lacked others. The absolute #1 feature I could never live without is syntax highlighting. And I'm not talking just function name highlights, but also distinctive highlighting of declared variables and native types such as ints, floats, or strings. I realize somethings this makes code look like a christmas tree, but after using it it is something I can't live without. One big one that was missing from Atom, though added via an addon that wasn't really good, is block selection of text, then copying and pasting. For those not familiar that, it is being able to select a rectangular area within the text and manipulate it. Or paste into an area inserting such things. Notepad++ has a form of it that I still find lacking in some cases, and I use another generic text editor EmEdit when I need specific assistance with it. I know this is a bit of an edge case use, but hey you asked for other comments. I also utilize the functions list that Notepad++ supports extensively. I suspect VSCode may have this functionality already in some fashion. Something that I find missing is the inclusion of variable definitions underneath an expandable function list to show which variables are declared within the function. Not something that is absolutely necessary but it can be useful. This is something I'm used to from full out Visual Studio and other full featured programming IDEs.

Woohoo

Sweet. This looks cool.

Ok so it's kind of a mess. Couple things. You don't have connect points to enable this to be modular. Your nif hierarchy is messed up. You have a collision object outside the main NiNode. You're using offset translations. If you get the connect points working you want the connect point parent to be at the offset mount position. Then the child loads it's 0,0,0 at the parent position and rotation.The way this is normally done is your weapon record will point to a dummy nif which has a parent node for the receiver. Almost every FO4 gun uses one of a few dummy receiver nifs. Before you start trying to fix yours it would be worthwhile to go through a vanilla weapon and understand how the design is put together. My go to weapon is the 10mm pistol. Take a look at the vanilla one Weapons\10mmPistol\10mmRecieverDummy.nif. The important stuff is the BSConnectPoint:Parents. That has a P-Receiver node. The parent of the dummy is generally at 0,0,0 because it's a dummy. Just used to mount other stuff in its place. Now if you look at the receivers for the 10mm gun they point to Weapons\10mmPistol\10MMPistol.nif. Which has a BSConnectPoint:Children and a node called C-Receiver. See a pattern here? Parents have a variable named P-something, then the children have C-something. The same nif also has BSConnectPoint:Parents which adds the magazine, barrel, scope, and other nodes. Then when other OMODs are attached to the weapon, the nifs that are brought with them attach to an existing parent node. If you turn on the visibility of the connect points in NifSkope you'll see a bunch of the parent nodes, their position, and rotation. It may take some experimenting of your own to get them in the right places. I won't be able to get more in depth than that. I'd suggest searching for some youtube videos or tutorials for connect points. I'd probably stay away from the workshop building ones. The workshop furniture stuff isn't entirely relevant. They'll show at least how to copy and set up the parent nodes. But workshop item snapping is handled very differently than weapon modularity. One key thing to remember when you copy the parent/child node blocks around. Make sure their names remain the same. Parents are CPA, children are CPT. They also must be directly under the base NiNode, and listed in the properties under "Extra Data List". If you look at vanilla nif references you'll quickly understand.

You said that the other parts turn invisible? If you put back the original receiver do they show up again? It sounds like you may be either missing the connect point parents or children. Can you give a link to the files? Doing modular weapons is a very delicate thing. Your base weapon record will have a dummy receiver file typically. Then your object template will attach the real receiver, grip, and other bare minimum parts. Each of the object mods for the parts will reference a nif with the part. Each of those nifs of parts has to have an appropriate parent and/or child nodes for them to attach to others.

Did you mark the "Unique" box on the NPC record? You also need to set a persist location for the placed NPC reference. Otherwise it will cause the quest startup to fail filling the alias unless it's a start enabled quest. But even if it is, you should set a persist location for the NPC. It also should not be a vanilla location or it will cause an override of that location to be made in your mod.

I don't play nor do I mod FO4, but I assume it's the same as it is for SLE and SSE about converting an esp to an esm or converting an esm to an esp in Wrye Bash. Is that possible to do that before loading a mod in the CK for FO4 or does the OP need to make the another esp with the resources to be a master for that mod in FO4Edit? Unfortunately the Fallout4 ck version 1.10.15 does not accept ESM flagging .esp files like the SSE / SLE counterparts does. The previous version 1.8.10 does though. But you'd need to have made a backup of it.

If the mod you're trying to use assets from is a .esp, the Creation Kit will not let you use those in another .esp. This is called using a .esp master. The Creation Kit that is currently available (1.10.15) will strip all .esp files from the master list upon saving. Regardless if they have the ESM header that was previously supported. You would need to use an older CreationKit.exe file of 1.8.10 or earlier to use that method. The other option is to edit the mod the weapon comes from and set it as the active file. Then place it as desired and save. Repeat for each mod that has weapons you want to place somewhere in the world.

To dismiss the current follower you need to set a property for the DialogueFollower quest and call as such (DialogueFollower as DialogueFollowerScript).DismissFollower(0, 0) ; Function DismissFollower(Int iMessage = 0, Int iSayLine = 1) That will dismiss with the default dismissal message and skip the npc speaking the dismissal voice line. To then recruit a forced npc with (DialogueFollower as DialogueFollowerScript).SetFollower(akTheActor) ; Function SetFollower(ObjectReference FollowerRef)

First, in CK did you verify that the weapon is actually assigned to the property on the script for the armor record? Second, if you're using a save where the armor already has been spawned, delete the armor and spawn a new one. Preferably start with a new game, like coc to QASmoke and spawn the armor to test. Or at the very least a save where the mod has never been enabled when it was saved.

You cannot add an attach parent to an object unless it is via a mod that is being attached. Just adding the keyword doesn't work that way. It has to be assigned as an attach parent type not a general keyword. The only way to add extra slots to the object is to modify the record in the plugin at design time.

RE Tools. If you installed the Bethesda.net launcher then that's where you get the CreationKits for Fallout 4 and Skyrim Special Edition. Just make sure when you install them you target the game folder. It should automatically find it and offer the proper folder if you've started the Launcher at least once so it sets the proper registry keys. The only concern to be aware of in playing a normal game while having your modding tools installed, is that if you have any loose files or plugins (enabled) for your mod present then they will be in your game as well. If you don't have your plugin(s) enabled, and you do not overwrite vanilla or other mod added files, then there's no drawback to having the development stuff in your normal playthrough area. RE Vortex vs NMM. Personal preference really. I have and use both. NMM development is pretty much stopped at this point. There is some community patching and stuff going on but the releases of said patches is pretty sparse. Vortex on the other hand gets frequent updates as of late. Though it is still pretty fresh, so it has some bugs to work out. I do like the speed at which Vortex handles creating the hardlinks upon deployment of mods. And if you modify files in the data folder directly that are put in by a mod Vortex manages, it offers to save that change to the staging folder. This is nice in that, you can purge the game folder to quickly get a virgin state and then redeploy when ready and still have your changes. Do note though, that if you create any entirely new files, like a patch plugin, Vortex won't be aware of that.

No. This is why there are mods that transfer ingredients from a defined container when the player activates an alchemy table. Then when the player leaves they move the ingredients back to the container.