DocClox

I've never come across weapon racks like that in Fallout 4. Closest thing I can think of would be the magazine stands. You're going to need a nif with named nodes to attach the weapons, and a script to add and remove them when the shelf is activated. Look at the magazine racks for how to do that.

You could perhaps have ammunition that only existed while the weapon was equipped. So if they have the weapon drawn, they get an ammo count. Catch OnMenuOpenCloseEvent and you can remove it when they open the inventory or talk to a shopkeeper. Combine that with your idea of monetarily worthless ammo, and you should get more or less what you want.

accidental double post - please delete

How about an OnContainerChanged event? Detect when it's dropped and re-add it to the inventory?

Are you calling workshop_parent.BuildObjectPUBLIC on the generator ref? If not, if might help.

Doesn't seem to be. There's a CryoPod lever, but that turns out to be a door, and a AnimsLeverAction, but that's for lever action guns. There is an ActivatorLever keyword ... but nothing makes use of it. I admit, I'm quite surprised.

I haven't tried this in Fo4. but in Skyrim you could set the player's viewpoint to use another Actor's eyes. If that still works, you could: Switch player to AI drivenSwitch player to use invisible actor's eyesParalyze player actorWait for effect to wear offRestore player povRemove the invisible actorremove AI driven status from the player

Yeah, I thought about that. Depends on whether you want to place the terminal with a script, or set it up in the cell editor of the CK. @YouDoNotKnowMyName: There are also terminals in the Activator section that you will be able to attach. One of them is even for opening doors. Though from the sound of it, I'd probably go with the static substitution plan.

Take a look at the "Object Template" button on the Armor record. That lets you define different configurations of mods, and a default configuration as well.

I admit, I never tried attaching a script to the helper. I had a ring and a pivot and I put the script in the pivot. The rotation of the helper is absolute, so you don't need to query it's rotation, just have the script remember where you sent it last. Look at the one in Big John Salvage for an example

Useful to know. I would never have thought to check the materials

So you placed a rotation helper in a cellstuck a script on a the rotation helperand then tried to give the rotation marker script a property pointing at the rotation markerIs that about right? Because you wouldn't need a property in that case - just use "self"

Basically, use Game.GetFormFromFile to get the form safely from the esp file, then add it into the formlist. Repeat for each form you want to add. You can save a lot of trouble if the source mod has a quest or similar with a property array and then you just need to get the quest form and then iterate over the list. You'll probably want a quest in the destination mod so you can load up the forms in the OnInit method. I;m not sure if you need to do that each time the game loads or just the once. I'd try it just using OnInit myself and see what happens.

Are your earlier mods esm files? If not, how are you populating the lists? You can reference a non-esp non-esm mod's assets in the CK, but unless the source mod is an esm, the reference won't be resolved correctly when the load order changes. Or you can get around that by softloading the references you want to use and adding them to the lists with a script. [edit] "Non-esm", not "non-esp" :whistling:

What is it that you want to take the position of, exactly? Generally speaking, if it's not an object reference, or a subclass of objref, then it doesn't exist in-world and has no meaningful co-ordinates.

Scripts are effectively types in papyrus' OO model. Attaching one twice is like trying to declare a variable as an int, and also as an int.

Be a bit careful with that approach. They are like state machines, but they only go forward. If you do quest q = whatever q.setstage(20) ; do stuff q.setstage(10) Then when you come to test the quest stage, you'll find it still at 20. The difference is that stage 10 won't be marked as completed until after the second setstage call, but you can't actually put the quest back to stage 10. I know this because I tried using a quest as a formal finite state automata back in Skyrim. Took me ages to figure out why it wasn't working.

Yeah, you need an instance. If you want to call it from the class, the function needs to be marked global. If it's a good fit for the problem, then why not?

This: bool RegisterFuncs(VirtualMachine* vm) { vm->RegisterFunction( new NativeFunction0 <StaticFunctionTag, void>("Test", "TestClass", Example_Plugin_Functions::Test, vm)); return true; } Calls the papyrus virtual machine to create a new native function called "Test" attached to a class called TestClass. The TestClass.psc definition is in the git archive too. Mainly they're being passed to the engine so they can be called later when papyrus invokes the TestClass - Test method.

Yes, that's what I did before ...Having the buttons enable an invisible xmarker. And the "MasterControlScript" would then check the enable state of those markers, and after doing what it needs to do it would disable that xmarker again, so it could respond to another button push. Why not scriptname ButtonMcButtonFace extends Objectreference bool property is_pressed = false auto event OnActivate() is_pressed = !is_pressed master_script.button_handler() endevent And then: script master_script extends whatever ButtonMcButtonFace property button1 auto ButtonMcButtonFace property button2 auto function button_hander() if button1.is_pressed if button2.is_pressed do_something() return else do_something_else() endif else if button2.is_pressed do_some_third_thing() else release_the_hounds() endif endif endfunction No markers needed, and you can have as many buttons as you like

I made a light mesh. It's basically a concrete housing protecting a ground tracking light from the workshop, only I ripped out the light's animation and added my own. What I did works just fine in Nifskope, but crashes the CK when I try and use it. I know it's not the textures causing the crash, because I ripped out the animation (again) and the static version loads fine with the those same textures. I've been checking the fields against working ones from the game, and so far as I can tell, it ought to work, but clearly I'm missing something. Any ideas for how to find the problem?

You could make the buttons stateful. Maybe have them light up when pushed and unlight when pushed again. You give each light-up button the same script and maybe a bool property to say if the state is pushed or not. Then a master script that queries the states of all the buttons is references before deciding what to do. That's not all in a single script, but it's got it down to two.

There is an example plugin for f4Se which will probably go a long way to getting you started. Basically, it defines a papyrus class and a single function within that class, and implements code to print a message when that function is called. Which is basically your workflow, I guess: create entry point, write code to do <whatever>, package up results in a Papyrus type and return them the the engine. Le me know if you get the urge to write a generalized JSON reader, or similar doo-dad. That's the thing I keep flirting with making.

I think I might have a better solution. I made a composite object for my rotating ring. The composite places the ring mesh and the helper that rotates it at nodes in its own structure. The helper attaches to the composite, and the ring attaches to the helper. The ring can move, but it's still attached to the composite via the helper. Then I attach the composite to the overall frame, and when I pick up the machine, the whole thing moves as one.

Wow. Thanks for that. That would have taken a while to figure out by myself.