ChuckYufarley

Very nice. Is the church a custom mesh?

I'm putting the finishing touches on my next mod, and I'll be including new versions of my 3 original vending machines. The Nuka machine from the video, a completely redesigned cigarette machine, and a mostly unchanged version of my original candy machine. All will be NPC usable. In the future, I will release new versions of some of the other machines I made for my earlier vending mod, and more than likely, some new designs.

Yeah, I've made a couple exploding vehicles for other projects, and of course I went all-in and made wrecked versions with all the doors and seats and anything else I figured would get blown off in an explosion, get blown off in the explosion. Imagine 100 45s getting thrown in every direction. Now that I said that, I kind of want to do in now. The zoom that happens with the terminals is an animated camera and it gets locked into place when the player enters the furniture. I tried several different configurations for the jukebox player animation, and none would allow for the zoom as well as give you the ability to look down and select the buttons. I haven't used any F4SE functions in any scripts as of yet and I believe it does give you the ability to register button strokes, but I don't know how far that extends. I first played the game on XBONE and got so used to using a controller that when I got the PC version and started modding, I stuck with it. So even though I've used a keyboard and mouse for other games, I'm totally lost when it comes to using them for FO4. It would really streamline the jukebox interaction to just be able to enter your selections on a keyboard, though. That way it wouldn't matter if the camera is locked into a zoomed view. My first jukebox mod only allowed for 23 songs, so when I started building the new one, I was determined to expand that. 200 songs is a huge jump, but it does create quite a hurdle for people who'd want to add their own music. I think there's plenty of people who would enjoy that kind of thing, but plenty more who'd have a hard time with it. It's a tall order either way. That's why I'm considering offering the customization thing as a service. Not sure how I'd implement that, but since I'd be hosting the mod elsewhere, I think there would be more flexibility. I wouldn't be providing the music, just helping to get things set up as much as I could. Edit> I just had a look at the key stroke functions for F4SE and it seems pretty simple, so that's something I'm going to have to look into implementing.

I will include all the information on how to add your own music with the mod. Basically it involves converting your sound files to .WAV format, renaming them to match the file names of the songs included with the mod, and dropping them into the correct folders. Converting a mesh to accept a snapped power line is pretty basic stuff, and adding a power on/off function to the script is feasible, but neither is something I plan on adding. To soothe the minds of anyone wondering how it seems to magically "work", I added a dummy fusion core slot to the back of the mesh to make it look like that's what's powering it.

Ha! I spend all that time developing the thing and you want me to let you blow it up? My first reaction is "Hell no!", but it is kind of a neat idea. It wouldn't have to be compatible with the other mod, it's just something I could build into it on it's own. But please don't hold your breath. If I start working on something like that, the old hamster wheel will start turning and then I'll start re-designing everything to blow up. As for the mp3 thing, at this point the menu cards are dependent on a texture for all that info. Short of writing a script for Photoshop that could import the metadata from each song and put it into each corresponding text slot, there's not much I could do with it. I'm barely a functional Papyrus scripter and there would be a whole new thing to learn in order to make something for Photoshop. And it would still fall to me in most cases to make the new texture file, regardless. However, the purpose of the menu cards is so that players can have a reference in order to know what combinations of button pushes play which songs, and at this point they're still rather difficult to read. I don't actually play the game enough to know if there's a way to zoom the camera for situations where you need to get a close-up look at something, other than enabling free cam, which would kind of break the immersion. They're much easier to see in the smaller jukebox but if I find a good solution for the bigger one, I might end up revamping the smaller one as well. I will not be implementing a pop-up menu, however. My main goal is to make these types of things as close to realistic as I can, and I've yet to find anything IRL that throws up a hovering menu in my face out of thin air. Potentially, I could implement something that could make them configurable with a holotape or by using MCM. and would work like a digital display rather than little paper cards. That way I wouldn't need to use a texture for that info. I'd eliminate the full 200 song menu and replace it with something that could be scrolled or flipped through, like with the diner jukebox. That way I could make the text larger and easier to read.

In fact, I have a couple jukebox models coming out in my next mod, but they are not wired. The script was complex enough without adding that function. However, like with my previous jukebox mod, the larger of my 2 new models spawns pre-arranged dance markers while songs are playing AND can be activated by your settlers. I'm wrapping up the last major part of the mod right now and I'd estimate that it will be ready for release by the end of the year, just not sure where I'll end up putting it. The larger one will play 200 songs. The smaller plays 100. Not sure if I'll end up leaving my selections in the mod. Not looking for any copyright hassles. However, it's simple enough to add your own music. The only difficulty would be in creating custom menu cards that would have the song names and artists for your own music. That's something I might offer as a service for people who want their own custom cards, but don't have the tools or ability to make their own. Also, I have in place the ability to add extra speakers to place around your space, with volume controls, so you can really crank out the tunes. The smaller one doesn't spawn dance markers though, as it's meant to be placed with my diner build set.

I assume this is in reference to your post in the pinned, Read This 1st thread? Without seeing the nif, I can't say for sure what the issue is. Is your light a workshop object that you're building in game? Did the vanilla light you used have a BSConnectPoint::Parents node with a P-WS-Autoplace point? It sounds as though there could be an issue with a) the mesh orientation with regard to the 0 NiNode, b) the orientation of any collision mesh that may be in place, or c) whether or not there's an autoplace connect point present. It could be that your nif doesn't have the connect node, and there might be a collision mesh out of alignment, which could keep you from positioning the light closer to the ceiling in game. The first thing I'd do is edit the mesh so that the spot where you want the light to attach to the ceiling is centered at 0,0,0. If you've included any custom collision meshes, make sure they're aligned properly. Then, in Nifskope, copy the BSConnectPoint::Parents node from the vanilla ceiling fan nif into your custom light nif. This should orient your light when placing it in game so that it automatically attaches to any ceiling with a collision mesh.

Well, nevermind all that about creating separate colored lights. Doing a little testing and gobos will project colors, but the trick would be to create a flat gobo texture that will project a spherical image that's not distorted. Trying out a gobo texture with a simple, two colored diamond pattern, and there is a lot of keystoning going on.

Is your mod installed via MO2 and not running as an unmanaged plug-in? If so, my guess would be you'd need to place your custom sound files into your mod folder in the MO2 install directory rather than the game's actual data folder. I've run into similar issues with textures in the past when I've installed my own mods via MO2, but left the textures in the game's data folder. That's why I leave my plug-ins as unmanaged until completion, then install the completed archives via MO2, so all my bits and pieces go where they should.

Yikes! That's a tall order. You can definitely get the lighted, multi-color glass effect for the globe part, but I don't think casting multi-color light onto surrounding surfaces is possible, at least not in a way that would work IRL. In my experience, in game light cast through a colored glass material doesn't take on the glass material color, but instead remains it's original color. One way that could work, however, is to create multiple custom lights in the CK, colored to represent each of the colors used in the glass globe, and assign a unique gobo to each of them that would block out everything except those corresponding colored areas of the globe. Think of it like shining a flashlight through a tin can that has several holes punched in the bottom. In this case, the gobo would be the tin can. Each light would be assigned to a custom addon node in the CK, and each value of these addon nodes would be assigned to a BSValueNode contained in your custom light nif. I must admit, as I'm thinking of a way to achieve this effect, I'm a bit intrigued by the idea of getting it to work. A couple things that give me pause are not knowing how many addon nodes can be placed at the same spot without creating conflict with one another, and whether or not light from one addon node would be visible when cast onto the blacked out portion of a gobo from another addon node. Like I said previously, I've never worked with gobos, and I can't say for certain if the "shadow" they create are simply areas where light does not shine through, or if they're more like textures projected onto nearby surfaces. I guess the way of going about this would be to start simple, with just two colored lights, and if it works, build from there. I've looked at the vanilla gobo textures, and they seem simple enough for me to figure out how to create something that might work in this instance. One thing that might not be possible is the refracted, kaleidoscope effect the light casts in the images from your link.

Try deleting 209. I don't know what type of effect it creates in the vanilla ceiling fan to have the 2 light sources placed close together like that. But, since 209 and 244 are non-shadow lights, they must not affect one another. On the other hand, having one non-shadow (209) and one shadow (60) in close proximity to one another, there might be some conflict going on. You did mention earlier that initially when you change the value of 244 to 60, the shadow you got was only pointing in one direction. Perhaps 209 was blocking the shadow that 60 was casting towards it. I don't know if you read the Creation Kit link I posted, but there's a lot of good information about lights in it.

I've used this Outfit Studio tutorial for converting helmets and masks and it worked for me. Where is your mesh positioned and centered? It's been a while since I've done this, but I'm pretty sure this tutorial assumes the mesh is positioned on the head, but centered to 0,0,0. If your mesh isn't configured this way, when you equip it, it could either be underground or up in the air, depending on where the mesh is positioned and centered when you export it.

I can't tell from the image what the complete structure of the light mesh is, or what part of it should be casting a shadow and where. The part up against the wall looks to be open, so there really wouldn't be anything to cast a shadow on the wall. Where in relation to the bulb portion is the BSValueNode situated? I typically center it in the middle of the bulb portion of a mesh. What you mentioned initially when you got it to work is placing it above, below or horizontally to the object, which should work with a value of 60, since that light is omnidirectional, but perhaps in the case of your wall lamp it's inside the mesh, or behind the wall? If it's inside or behind a mesh that has a two sided material, then that mesh would block out the light. If it's behind or inside a mesh with one sided material, then the mesh wouldn't cast a shadow. One sided material will only cast a shadow from if the light is coming from outside the visible portion of the mesh itself. In other words, if your mesh has one sided material, and the light is coming from inside or behind the visible portion of the mesh, it won't cast a shadow. Also, the light used in the addon node with value 60 has a radius of 256 units and a near clip value of 16. With a radius of 256, the shadow would project outwards to the length of a standard wall unit, but not all the way across a larger area. Not sure what the near clip value determines. This is from the Bethesda Creation Kit site: https://www.creationkit.com/fallout4/index.php?title=Light Near Clip: Controls the shadow bias of shadow-casting lights, the default value (7.2174) needs tweaking in most cases. If this value exceeds the Radius value, the light will disappear. If the default value is 7.2174, and addon node 60 has a value of 16, maybe that's causing the issue. Not sure though. You could try making a custom addon node in the CK and giving it a custom light with different values to see if that helps. One more thing to look into, with regard to position and rotation of the BSValueNode. Although it shouldn't matter when using an omnidirectional addon node (usually this applies more with spotlights) the default rotation of the light source is 90 degrees to the right, if you're looking at your mesh from the front. I know "front" view in Nifskope is actually from the rear of the mesh, but you want to be looking at it from the front as in how it looks in your 3D app or in game. In the attached screenshot, from the front of the mesh, the default rotation of a light placed in the middle of the mesh, points in the direction of the arrow. Like I said, I've only dealt with this when using spotlights, but maybe it applies to omnidirectional lights as well. Rotate the BSValueNode to change the direction the light will shine. Kind of hard to do in Nifskope without a visual representation of the light, but you can make a dummy object like an arrow that points to the right, rotate that, then copy the dummy's transform to your BSValueNode. I know my explanation gets rather convoluted. It's easier for me to do it rather than explain how to do it. Edit: Everything I said about the default rotation of the light is when the BSValueNode is set to a 0,0,0 rotation. If you copied the node from another nif, it might have some wild rotation already assigned to it and it's anybody's guess which way the light itself actually points. Hope this helps.

Glad it worked out for you.

Does your custom fan have a light, similar to the vanilla ceiling fan? If so, does it use the same BSValueNodes as the vanilla ceiling fan, specifically AddOnNode244? The vanilla ceiling fan light doesn't use shadow casting addon node lights, but AddOnNode244 uses a light with a gobo to project the blades' "shadow". I'm not certain how gobos work, but since the light itself is not a shadow casting light, I suspect there's some trickery at work where a texture that looks like a shadow is projected onto nearby surfaces, saving the game from having too many shadow casting lights in the same cell. With a non shadow casting light source, it wouldn't matter if you've ticked "cast shadows" in your material file. Lastly, if you're using the same BSValueNodes as the vanilla ceiling fan, have you ticked Bit 4 in the BSXFlags? This must be ticked in order for nifs to be able to utilize BSValueNodes. If your fan has blades that are different in shape, number or size from the vanilla ceiling fan, the gobo effect from AddOnNode244 might not look right since it's made to look like a shadow for the vanilla ceiling fan blades. In this case, if you want an actual shadow that matches your actual mesh, you could change the value of the BSValueNode in your nif to 60, which is the CK addon node index number for a shadow casting light. I could help you set this up if I could have a look at your fan nif. That way I can see how you have it set up and maybe determine why it's not working for you.

Is this something you're trying to accomplish with a CK build? If so here's a good tutorial for setting up lights to use enable/disable markers. Otherwise, if you're trying to make custom working light fixtures that can be placed in game, and controlled by a switched power source, I use the WorkshopIndCatLight.nif, found in Meshes\SetDressing\LightFixtures to build off of. The key is having the right BSBehaviorGraphExtraData block, in this case GenericBehaviors\WorkshopNoTransitions\WorkshopNoTransitions.hkx, which essentially tells the game "turn on when powered, turn off when not". I choose that nif because it has the fewest number of NiControllerSequences that might need to be edited out of all the light fixtures that use that particular BSBehaviorGraphExtraData block. It doesn't contain a BSValueNode (addon node), but it's simple enough to add one and set up in the NiControllerSequences. You need a fair bit of Nifskope experience to do this, but is one of the easier workflows for that application. If you have questions about building your custom fixture using this method, I'll be happy to walk you through it.

Nice. Watched the video and the first one gave me army flashbacks.

I made one ages ago and I'll be including it in my next mod. Right now I'm working on one last project to include in the collection, but I imagine I'll be ready to release the mod in the next several weeks. As far as the quonset itself goes, it's a prefab with no real add-on functionality other than a custom door which when attached, adds interior and exterior lights, which the player can turn on/off. It has plenty of room for adding furniture and whatnot. I've also included a vanilla bed and foot locker with added snap points which correspond to snap points built into the quonset nif, which makes placing them in neat, military fashion a LOT easier. A rough estimate on size is 2.5 generic floor units wide by about 4.5 units long and it's a little over one generic wall unit high.

Perhaps try setting one keyframe for the dummy before exporting. Although, I don't know if simply naming it BSValueNode will work. The only other thing I've exported from max (besides NiNode hierarchies, meshes and bones) that showed up in nifskope as it should are lights.

I haven't played either extensively, but they are two separate mods. The first is more bare bones and has most if not all the systems for building in place as soon as you install it. The second is more story driven and the building systems unlock as the story progresses. Both are great, it just depends on if you want the story content included or not.

I've had similar issues when trying to adapt vanilla meshes for use as anim objects for Fallout 4. I don't know if Skyrim skeletons are exactly like FO4, but I would imagine they are very close. The first problem with orienting a mesh is the bone Bethesda typically uses for the anim object root is positioned in the wrist and not the hand, like weapon bones. So not only do you have to calculate the AO orientation with regard to the player hand, but you also have to account for the offset from the AO bone TO the hand. Seems like a faulty system. So basically the AO mesh has to have the same offset from the 0 NiNode as the AO bone has from the hand, or wherever you want the AO mesh to appear. Second issue is rotation of the AO bone when the AO mesh is drawn. When the AO mesh is drawn during the character animation the 0 NiNode will align to whatever the AO bone position and rotation is at that particular frame. Realistically, the only way I know to find these transforms is to import the character animation into your 3D application and get the transform coordinates of the AO bone at whichever keyframe the AO mesh is drawn. Two work arounds I've come up with are to either find a vanilla AO nif that has the same size/function/grip...whatever, as the mesh you want to use. Import your mesh into the vanilla AO nif and align it to the vanilla mesh. Then delete the vanilla mesh and save it as your custom AO nif. This works fine for stuff like drinking glasses or bottles, but can be trickier for objects used for specific animations. The second work around I use involves creating custom character animations and using a different bone as the root node for the AO mesh. There are three AO bones parented to each hand bone and they cannot be moved independently, so you are stuck with the previously mentioned offset with those bones. However, there are also two additional AO bones that are not parented to any other bones and can be moved and animated wherever or however you'd like. First of all, when I create a custom AO mesh, I orient it so that the "grip" location is at 0,0,0, and make that the center of the mesh. When exported it will be centered to the 0 NiNode where the object will be grabbed by the player. When creating the character animation, I import the custom AO mesh into the scene, align the AO bone to the AO mesh, both for position and rotation, then parent the AO mesh to the AO bone. For FO4 skeletons, those bones are either AnimObjectA or AnimObjectB. Then I animate the AO bone to follow the character's hand, head, whatever. For this to work you must make sure that the custom AO nif has the correct AO bone indicated in the NiStringExtraData block. Hope this helps.

When I convert light nifs from a powered version to an "always on" version, I eliminate all the NiControllerSequences except the On sequence, then rename it to Idle. Then you need to change the sequence cycle type from Cycle_Clamp to Cycle_Loop. I also eliminate the BSBehaviorGraphExtraData block. No keywords needed in the CK. You can just use the converted nif to make a static object.

It looks as thought the only thing you changed from the vanilla construction light was to add a custom Addon Node which uses a custom light, is that correct? Otherwise, the nif itself has remained virtually unchanged from the original nif, except for the updated BSValueNode. The vanilla construction light activator also has the BlockPlayerActivation keyword, and I assume it works as it should in game. If that's the case, then there is no need to remove that keyword from your custom light. I've made many custom lights and when the objective is to have the light turn on/off via a connected power source, I always use the BlockPlayerActivation keyword. The only things I am seeing that might be causing an issue are the name of the BSValueNode not being changed in the NiDefaultObjectPalette, and perhaps the index number you're using for your custom addon node. The name in the object palette shouldn't be an issue, but it seems to me that in the past, not having the name and the AV Object match has caused a problem in one or two of my nifs. As for the addon node index number, you might have another mod installed that uses the same index number and that could be causing a conflict. I checked all the vanilla index numbers and 902 isn't used in the base game or any DLC packs, but since it's so close in sequential order to vanilla index numbers that are being used, I would venture to guess that it was generated by the CK when you created the addon node, and you left it unchanged. Chances are pretty good that another mod you've installed has the same, CK generated index number. Try changing the index number to something that would be a little harder to randomly duplicate in some other mod. Something with 4 digits. I use index numbers in the 5000s and have never had a conflict. Hope this helps.

Amazing stuff, as always.

No problem at all. Don't be hard on yourself. We all struggle with one thing or another. I look at some people's scripting and I might as well be trying to decode the Rosetta stone for all the complexities. My scripts tend to look like Rube Goldberg machines in code form.