Carreau

That would be difficult to do with the BGS scripts that control item lists. The way the game fills in the inventory is that it sends an array of objects up and registers them with the inventory list. Inside each object is a list of values, which I've recently polled while working on an injector for the pipboy's inventory button bar. That's the entry block for the 10mm starter pistol from Vault 111. Each item is initiated with a filter flag, and that filter flag is what hides the item depending on the inventory tab you're looking at. What you could do, is write a script in AS3 that polls the ItemList entries and scans for identical formID (these should always be the same between different items of the same subclass). So in your hypothetical, the rifle without the silencer and the rifle with would both have the same fromID. The nodeID is tied to the persistent object reference which contains the actual information of mods on a weapon. Once you have arrays filled with groupings, you can add item to the entry list to grab the text off one of the rifles, and grab the filterFlag. Then you can change the filterFlags to the grouping to something that will screen out. I think where the hitch would be is in clicking the item entry. You could in theory add some parameter to your dummy entry, and use that as a test: if ItemList.selectedEntry.HasParameter("Foobar") And then swap filter flags around. All of that would have to be done as hard edits to the pipboy Inventory page menu as I think trying to do it as an injectable interface would ratchet the difficulty in doing this. And hard edits to this specific menu page would need compatibility patches for Def and VIS

That's the pinch point. Either you tie into a known function of BGSCodeObj, or you're forced into F4SE to get some form of AS3 callback or key polling

I've been toying with command injection to vanilla menus. It is possible. I'm using xSE to inject an extra SWF when the detected menu is open. Without xSE, you'd have to make hard edits to the menu And if you wanted to tie into calling commands from outside a vanilla function, you'd definitely need xSE to make that happen. As far as I know, there is no native vanilla method to make a papyrus call from scaleform. I had to write an xSE handler as middleware.

I bit of an update to this for anyone following. OnItemRemoved is a good workaround, although it would be nice to be able to resolve the inventory item in xSE since the workaround is VERY brute force. And thanks to the slow speed of papyrus versus the faster response time of native handling, I had to give a short delay between firing my xSE function to call papyrus and calling the EXE's dropitem function. Without a small delay in the AS3 side, papyrus takes too long to register the event and fill the item filter before the item is removed by the EXE. This was causing the item to drop as normal without moving it to my storage area, but a subsequent pickup and store function call would get caught since the event and filter were still in effect. I would still love to figure out how to resolve the pipboy item to an ObjectReference, but this workaround will be sufficient for now I suppose.

Thatâs my planned work around and already have it partially encoded in my test build. Being able to resolve an o-ref in my xSE plugin would be more ideal so i can be sure Iâm only grabbing what I need instead of grabbing items that may be truly dropped.

I'm trying to devise a way to remove items from the player's inventory via the pipboy and place them into another storage container. For the most part, this works with the exception of leveled items like weapons and armor. Since weapons and armor are kept as persistent object references, simply calling RemoveItem() will not correctly work. RemoveItem removes a random item of that base type from the inventory instead of the currently selected item. I tested this by adding 10 randomized laser guns to inventory and then parse them one at a time. A random laser gun would be removed instead of the selected one in the pipboy. Additionally, since I'm dealing in base forms, the laser guns are re-randomized. Basically, one needs the object reference used for persistence to be able to perform this function. In my injected ActionScript, I polled the currently selected item object to get all of the storage values. And this is what was returned favorite = true taggedForSearch = false isLegendary = false count = 1 nodeID = 19798 //0x4D56 filterFlag = 3 equipState = 0 text = 10mm Pistol clipIndex = 0 formID = 18466 //0x4822 canFavorite = true This was polling the starter 10mm pistol from Vault 111. Obviously, the ID fields are in decimal and not hex for the report. The one value of interest is 'nodeID'. If you drop the weapon and then retrieve it, 'nodeID' will change, so I'm assuming this is the value used as a persistent reference. The thing, though, is that it's internal to the pipboy. Rectifying this value either through xSE or papyrus results in no form or reference retrieved. I'm guessing this value is internal to the pipboy structure, which is unfortunately not very well exposed in xSE currently. When you use commands such as Drop in the pipboy, the entire object is sent back to the EXE, so I'm guessing the EXE uses the values listed in the entry list item to remove the persistent reference and drop it into the game world as a generated object reference. So I'm hoping someone here has some insight on how best to use the values available to create the correct ObjectReference so that I can more easily make my transfer. Thanks in advance!

Companion inventory isnât handled by leveled list. Their weapons are added directly. You can use papyrus scripting to remove their companion weapon and then have your new weapons added and equipped. Iâve done this in the past for changing Piperâs default weapon.

The door would be a bad place to attach the script. Primarily because input layers automatically clean up on script destruction. It would be better to attach the script as an alias script and have the door script fill a quest alias with the player once the walk through. Then on the way back through the door, have the door clear the alias.

The plugin itself has to be compiled with new addressing based on changes made in the EXE that impact run time addressing, which in turn affects F4SE addressing. The only way to recompile the plugin is to have the source code

Been keeping an eye on this thread, as itâs been very informative. What do yaâll suggest for a âhello worldâ style of plugin creation to get the basica down?

https://www.creationkit.com/fallout4/index.php?title=Enable_Loose_Files

Do you have loose files enabled? Are you installing them manually or via a mod manager? If the latter, are the teexture replacers loading after the original mod?

The only time a ModName.ini file should be generated is if the mod is coded to push settings changes or you created one manually to make custom ini settings. And with MO2, all ModName.ini files will get saved to /overwrite/MCM/Settings/

MCM issues were resolved in Mo2 release 2.1.0. So long as you have MCM installed in MO2, it will generate the correct ini files. Theyâll be stashed in the overwrite folder

A perk applied at the race level is exactly how I would do it. Then a magic effect that acts a listener to add the items. But instead of adding the inventory item OnEffectStart(), instead listen for the OnDying() event. Add the items then. That way, they don't show up in the actor's normal inventory and only show up after the actor has died. Scriptname XYZ extends ActiveMagiveEffect Actor DeadHuman LeveledItem Property MeatList Auto Event OnInit() DeadHuman = GetTargetActor() EndEvent Event OnDying(Actor akKiller) DeadHuman.AddItem(MeatList, abSilent = true) EndEvent This is how I've handled adding specific items based on death sequences, but it was never applied to a whole race.

Expired released an update the other day to looksmenu that had some test code in it that was enabling markers. He pulled it down and updated with a fkx that removed the code causing this. Hence. Update Looksmenu

Update looksmenu

I don't know if linked lists are really feasible. Papyrus has no implementation for pointers, so that's a problem with linked list implementation. Also, adding a struct to a struct is forbidden, so you can't directly implement. I attempted to add a struct to a struct and the compiler returned "D:\Steam\steamapps\common\Fallout 4\Papyrus Compiler\TestStruct.psc(6,9): struct variables cannot be structs themselves No output generated for TestStruct.psc, compilation failed." Where my struct was defined Struct TestOne int index string name testOne nextStruct EndStruct There are ways to cheese multidimensional arrays using formlists. https://www.creationkit.com/index.php?title=Arrays_(Papyrus) About halfway down, there's a discussion about ways to effectively create multidimensional arrays. My concern here is that they use activators to spawn instances of arrays. Given how the game cleans up activators, I don't know what the long term sustainability of this method would be. I was hoping it would be possible to make a formlist of structs, but that is throwing compiler errors as well D:\Steam\steamapps\common\Fallout 4\Papyrus Compiler\TestStruct.psc(19,19): type mismatch on parameter 1 - cannot pass a teststruct#testone to a form In this case, I'm trying to use AddForm on a formlist property to add a struct. So no dice in that front.

I make copies of the ESP and ise FO4Edit to change the header flag of the copy to ESM and then rename the file to ESM. The CK will load it if you have muktiple masters enabled. Once the mod is done, use FO4Edit to rename the dependency to ESP and youâre done. I make the copy so I donât have to monkey with the dependency file all the time

All random encounters are handled through the game's story manager. Adding one is pretty simple, and Bethesda streamlined their random encounter creation by including templates. The story manager will make sure certain encounters only appear at certain RE spawn points. Your idea would fall under REScene types. If you go into the CK, navigate to the quest tab, and type in RE to the filter box, you can review how the vanilla RE quests are done. There's already one with additional radstags under quest RESceneCT07. I would recommend looking this one over to see how the aliases are handled. To start a new quest, duplicate the template quest. There's one called RESceneTemplate. Duplicate that and then navigate to the alias tab. Do not mess with the TRIGGER alias or any of the Marker aliases. ActorAlias is the one you really care about. In the radstag RE, the ActorAlias alias was renamed to Radstag01 and then copied to Radstag02. In your quest, you can change the spawn type in "Create Ref to Object" from REFarmer to any kind of actor you want. Since you want wildlife, set it to wildlife. You can change the difficulty of the spawn as well. The last drop down is which marker in the RE spawn area the reference will be placed. The A and B are groupings. And there's a center marker. You can leave the default script in its default state. The last thing you'll need is an AI package to include. Most RE quests will have specific AI packages since the RE quest will be set as the owning quest in the Package editor. I would recommend copying package RESceneCT07_Radstags and setting your quest alias' packages to your copy. Then make sure the Owning Quest of the package is your RE quest. The last thing I would say to do is delete the RefCollection alias as I don't think you'll need it. Just have a couple of single aliases with whatever wildlife you want to spawn. The last thing you need to do is navigate to the Script tab and update script properties. Copy the same setup as RESceneCT07 and you should be good. In "SM Event Node", you'll find the Script Event manager. Open it up. Then expand these nodes: -Stacked Branch Node: REMainBranch -Stacked Branch Node: REBranch -Stacked Branch Node: REBranchNormalTriggers -Stacked Branch Node: RENonUrban -Random Quest Node: RESceneQuests Right click "Random Quest Node: RESceneQuests" and select " Add Quests" and then select your created quest(s). That will update the story manager to include your random event(s) into the queue. The last thing you need to do is give it some conditions. The Quest Node for RESceneCT07 has one conditional on it to make sure the radstag RE doesn't populate in a random event area that would best be suited for human types. So, it has a condition to check for a keyword to make sure the RE area doesn't prevent animal spawns. I would copy that condition and paste it into your conditions. And that should be it. It seems like a lot at first, but it's basically copying the template quest, updating a few aliases, and then populating the Story Manager. As for testing it, I haven't figured out a way to force specific random events to fire yet. For things like load screens, I would set a condition to point to a global called TrueGlobal and make sure it's equal to 1 (which it always is). That forces the load screens of my choosing to populate first so I can make sure they're working right, but it hasn't worked with random events yet. Anyways, good luck!

If you go into your fallout 4->data->script->base folder youâll see the DLC folders. Inside each will be a zipped file. Unzip that file so all scripts will be inside the dlc folder. So when youâre in fallout 4->data->script->base->dlc03 you should have all the PSC files after youâve unzipped them Script fragments are papyrus scripts, just generated by the CK. When you put a couple lines of code in a terminal, the CK generates all of the header and property information you normally would do yourself if you were coding from scratch.

Most times this is caused by a modified mesh i âve had cbbe/atomicB modified meshes create inmediate CTDs when opening their actors in the editor. My workaround is to temporarily place the meshes in a backup folder while working in the CK.

This mod has been on my radar to update for a while. I keep meaning to do it, and then I get distracted by life. The particular error there is happening on line 84, where the script is calling FindInIntArray(). It's a global function to the script, and shouldn't be called on self. Reg made the original mod when all we had were decompilers and XEdit. Most of the decompilers will add things like self in front of global scripts, so he probably thought at the time that since the decompiler was adding stuff like that to scripts that he should too. The simple fix, here, is to remove the call on self for that call and for the call a few lines down for SetHomeInternal()

Itâs click - wait - click. Every function in xEdit requires painfully slow double clicks.

There's not much to changing a dependency. I don't currently have any plugins that have ESPs as dependencies to load for a good tutorial, so I grabbed one that uses ESM masters just to show you where to navigate. -Open up the patch in FO4Edit (xEdit) -Navigate to the header section -Slowly double click on ModName.ESM to be changed (I have ArmorKeywords.esm highlighted in my example) -You'll get the typical "Are you REEEEAAAALLY sure?" prompt. Click "Yes! Let me get to work FFS" -Then you can edit the name, change ESM to ESP -Close and save -Your mod manager will now look for ModName.esp as the dependency.