pra

Yeah, dynamically updating the navmesh door triangles isn't possible. Closest thing you can do is what Bethesda did for the VR workshops (and I stole for Not Just Basements): Place two invisible doors, one in your cell at the exit, the other in the wilderness somewhere (but still on the navmesh). Only finalize the navmesh in your interior, leave the exterior as it is (for compatibility reasons). Relocate the exterior invisble door when your moveto-activator relocates. This should make the quest markers work at least, pointing into/out of your interior. NPCs might be able to path out of the interior, but, they will then appear in the wilderness cell mentioned above. I don't think they can path into the interior. I tried circumventing some of the issues by giving the invisible doors in NJB an OnActivate event handler to relocate the NPC where I expect them to be. I don't think it really works, though.

To answer the original question: you can't. That said, Lighthouse Papyrus Extender seems to add a GetDoorDestination. I haven't tested it, though, and I don't know what it would even return, since a door's destination isn't an actual separate ObjectReference, but extra data in the door's ObjectReference.

The way I have been making custom sinks was by taking one of the working vanilla sink NIFs, pasting stuff from my custom NIF into it, and removing or repositioning some of the nodes to make the water stream align properly. Works without any placeAtNode, and it has a node which is getting rotated when you turn the sink on for the crank thingy. For this, I recommend using material swaps. If your custom NIF uses BGSM/BGEM files for texturing, you can create a material swap in the CK, where you put in the path to your original material under original, and another one under replacement. Then you can simply apply this material swap to your sinks to retexture them, without any need to modify the NIF.

Thread necromancy! I've been doing some testing yesterday, and, it seems, GameHour does NOT handle rollover properly. It works, if you want to advance the time by one day at most, but not more. This is what I did: debug.TraceUser(LOG_NAME, "Needed time "+timeToPass) debug.TraceUser(LOG_NAME, "GameHour before = "+GameHour.getValue()+", gametime before "+Utility.GetCurrentGameTime()) GameHour.mod(timeToPass) debug.TraceUser(LOG_NAME, "GameHour after = "+GameHour.getValue()+", gametime after "+Utility.GetCurrentGameTime()) And the output was: Needed time 759.229980 GameHour before = 14.640729, gametime before 0.610032 GameHour after = 773.870728, gametime after 1.244614 My code had a bug where it would calculate a way too large value for timeToPass. That number comes to about a month, not just one day. Doing some more math: 14.640729 / 24 = 0.610030375, which is close enough to the gametime before (probably some seconds missing or such) 773.870728 / 24 = 32.24461367. The decimals are similarily close enough to the decimals of gametime after, but the day itself got only advanced by 1, not by 32. What I think is going on is that the game is doing GameHour mod 24, and then, if the result ends up less than what it used to be before, it advances the game by one day.

I had a closer look at the nif yesterday. (In fact, this thread reminded me of this gear door, and prompted me do this) It seems there is indeed animation data in there, but in a weird way. All the moving pieces have controllers and not-manager-controlled interpolators. These actually do contain animation data. The On/Off (not Open/Close, my mistake) sequences simply have too short time durations to see that. What you can do is rename these sequence "On" to "Open", the "Off" to "Close", and then, for the "Open", set the start and end times to 3.466667 and 13, and for the "Close" to 16.166668 and 28.9. Set them in both the controller sequences, and the Sequences' Text Keys. This makes NifSkope display the animations at least (after a save, close, reopen). I have no idea inhowfar this will work in-game. Also, keep in mind, that if you turn this into an actual proper Door object, NPCs will be able to open it. Edit: I also adjusted the permissions on my nif fix mod, you can use that as the base, instead of the buggy vanilla mesh.

The gear door nif indeed has "Open" and "Close" sequences, but they don't seem to actually do anything. The entire animation seems to be governed by the HKT/HKX files. Making it work as a proper door will probably involve some serious nif hacking, pretty much rebuilding the animations from scratch by hand...

My headcanon: ghouls can enter a state of hibernation, when left without oxygen, but still having access to radiation. Their ghoul physiology can still produce some energy from a radiosynthesis of sorts, but far less than regular cellular respiration would. Enough to prevent the cells from breaking down, but not enough for any movement or brain activity. Until the oxygen supply is restored. But yes, in the end, this is just bethesda being lazy.

Not sure what you're trying to accomplish, but, no, you aren't able to make this yellow crate be havok-able. This is the CollisionObject in the nif, which was never reverse-engineered. You can see it in the CK by pressing F4 in a render window. Red collisions are static, blue collisions are havok-enabled. The only way I can think of is to find a mesh with a blue collision of roughly he same shape and size, and transfer it into your version.

not quite. you need to call doScrap() from somewhere. Like, from the onClose: event onClose(ObjectReference akActionRef) if(akActionRef == Game.GetPlayer()) doScrap() endif endEvent This will make it so that as soon as you put anything into it and exit out of the menu, it will do the thing. You can also extract the script from my scrapping machine mod and look at that. I do some more things there, like, only work when powered, lock the container, play a rumbling sound while it works, and a "ding" when done, if you want to look up how to do that kind of stuff.

This is how it can be done in F4SE: function doScrap() Form[] inventory = GetInventoryItems() int i=0 while(i<inventory.length) processItem(inventory[i]) i += 1 endwhile endfunction function processItem(Form itemBase) MiscObject misc = itemBase as MiscObject if(!misc) return endif MiscObject:MiscComponent[] comps = misc.GetMiscComponents() if(comps.length == 0) return endif ; misc might be scrap already, check that if(comps.length == 1 && comps[0].Object.GetScrapItem() == misc) return endif int itemCount = getItemCount(itemBase) self.removeItem(itemBase, itemCount) int i=0 while(i<comps.length) MiscObject:MiscComponent cur = comps[i] MiscObject scrapItem = cur.Object.GetScrapItem() int amount = cur.Count * itemCount if(amount > 0) self.addItem(scrapItem, amount) endif i += 1 endwhile endfunction

edit: doublepost

I think you could. when the item is equipped, create an InputEnableLayer, where you disable abCamSwitch. Then, call Game.forceFirstPerson or .forceThirdPerson. You could also save the previous state, you can get it like this: (Game.GetPlayer() as Actor).GetAnimationVariableBool("IsFirstPerson") On unequip, delete that enablelayer, and potentially restore whatever the player had before. I think it would be the best to do this within a magic effect, which you put onto your weapon through an enchantment.

Could be done as an addon to VotW, I think. They solved the problem of actually playing clips on an in-game TV already, and have lots of actual videos, too. you would probably require a special version of their videoplayer script, which, instead of playing the video from one specific item, pulls one from a list somewhere (this list is then your "TV channel"), plays it, then goes to the next. I don't know, however, if you can start playback mid-video. Not just in the context of VotW, but in general. From what I understood, you would have to start a nif animation and a sound clip at a certain offset, and I think this just isn't possible in this engine.

It's this one: https://www.creationkit.com/fallout4/index.php?title=Precombined_References#LAND_Records_Notes Reads to me like: it is unknown how terrain is actually used in the precombines, but changing it breaks them.

The "restore precombines" script is pretty much finished. Seems to work so far. You can select masters, a target file, and it will then look if any files except these do any changes to the cells you run it on, and undoes them. It undoes the changes to the cell itself, to anything referenced within the precombined references, anything refenced within that physics area, landscape changes, and even the actual files, if any. It's the landscape part which makes me wonder, though: is that thing even used in previs or precombines? I have the feeling the precombines don't care about the terrain, and have no clue about previs. Does anyone know this? Edit: I published the script now: https://www.nexusmods.com/fallout4/mods/28898 The information about the landscape was mostly for the documentation, I just put in that I have no clue whenever it affects the previsibines for now.

So, where exactly is the line drawn on using CC content within a regular, non-CC depending mod? The way I see it, we have 3 types of content here, where this question even makes sense: Assets within the CC BA2 archives, which are downloaded automatically, whenever you bought the mod or not. Assets within the base game's archive, which were added specifically for some CC mod. Like NIFs in the creationclub subfolder within Fallout4 - Meshes.ba2, or the scripts under Scripts\CreationClub within Fallout4 - Misc.ba2 Records within Fallout4.esm, which were added for some CC mod. Like the actual VR pod FURN, VRWorkshopShared_VRPod_Workshop.If I remember correctly, someone got bonked by Nexus for #1 before. But, where exactly is the line drawn? Are #2 and #3 fair game? #3 only? None of them? What if I copy a #3 record?

You give me too much credit :D I mostly find out stuff via trial&error, and am rarely sure about them... Another problem is, some of this stuff was literally years ago... In this particular case, I tried fixing precombines via ITMs a while ago, but failed. I probably have forgotten the version infos, missed one ref or another, or messed up in another way. I remember doing a script to copy over version info at least. Probably because someone asked me to. I am also thinking about making a "fix precombines for this cell" script, with the information I have now, it should be possible.

Both. I thought "previsibines" is the community term for this now. I definitely want to restore both. And for what the two of you wrote, it seems I can. Thank you! I'll post again after I tried doing this.

So basically, introduce ITMs of all vanilla records in the cell into B.esp? I was under the impression that ITMs still break precombines. Am I wrong? Additions from A.esp shouln't be an an issue, though, since AFAIK you can add refs as you please without breaking precombines, it's only deleting, moving, or otherwise changing, which breaks them.

So, there is a mod, which does a lot of changes to the exterior commonwealth worldspace, and breaks previsibines in the process. Let's call it A.esp. If A.esp is loaded, you have broken previsibines in the affected area. What I want to do is to create a B.esp, which, when loaded, undoes the changes done by A.esp in such a way, that vanilla previsibines take effect in the affected area once again. Is that possible? I have tried, but so far, failed. Regenerating previsibines for B.esp is not an option, because the whole point of the exercise is vanilla compatibility, to resolve conflicts. Editing A.esp is also not an option, because the mod author in question cannot be reached for permissions.

Wait what? I remember seeing that mod on Nexus, but disappearing at some point. What made it move, to LL, of all things? ... please don't tell me they added boobs to the eyebot ...

Open the nif with CreationKit.exe. It's able to view nif files. You might have to put the nif into Data/Meshes first, but not sure-

Interesting. Though you probably can't really pose the corpse then? The ghoul in my addon is placed on a gurney. But better than it being headless I guess. But wait, a propos gurney: it works in DLCRobot, in the mechanist's lair, doesn't it? Maybe whatever beth uses there can be replicated. Unless it's something beth-esm specific...

From what I understood, you have to sheathe and draw the weapon for the OMOD change to take effect. But I think I heard somewhere of some trick which supposedly works without? If all you want is do something to the target, then a scripted magic effect might be enough. But I'm wondering how complicated it would be to actually visually change the projectile, or even a part of the weapon, depending on what you load into it. Not 100% sure about the "fire" event. I think here the trick was, you must listen to the OnAnimationEvent, then use one of these: https://www.creationkit.com/fallout4/index.php?title=Animation_Event_List

Might be tied to it's animation, somehow... Implementing a custom-ammo weapon might still be feasible. You would have to react to the "reload" event, open a container from a hidden cell, then listen to the inventory events from there. Then try to to dynamically change OMODs on the weapon and give the player a dummy placeholder ammo? Though IIRC dynamically changing OMODs is somewhat wonky. Maybe investigate how other mods with ammo change/firing mode change are doing it. Or maybe just make the weapon fire an invisible dummy, which then moves the first ref from the ammo chest to itself? There might be different ways how this could work, with various levels of hackiness.