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.