RoNin1971

Not that I'm aware of. I would definitely love to have it, since I've been working on way over 500 models (nifs) with an average 10 to 15 'parts' (TriShape data with a material) just for my Vault Pieces mod alone. (I've got at least one more mod (in development) with a similar amount.) Switching to 3DS isn't going to help you in any way for that matter. I only use it to create collisions, but there are ways to do without. As for the mesh part... pynifly doesn't do so bad, compared to the 'official plugin'. edit: I should add - The official plugin for 3DS can ONLY export a nif. To import one into 3DS you need another plugin (I believe I've got the niftools one currently). Those import plugins are never perfectly importing each and every detail from a nif. Since you can't get all the data in(put), its impossible to get it out(put).

Sounds good. You could just copy/paste the two NiNodes for the collision & helper to make it complete. (but only if the model still matches those. Otherwise you need to add something new.) As for the Wet Material. This is one of those things I dislike about pynifly. It is focused on clothing, like Outfit Studio. Not on general assets like walls. This gets worse with each update. Although it should not crash the game and you might hardly notice the difference, I do recommend swapping the OutfitTemplate with the original WoodTemplate.

Weird. There are 2 main differences visible here. 1: the copy does not have the "Wet Material" template assigned. I don't recall the lack of one could cause a CTD, but you could try adding that one. 2: Environment mapping has been added to the "Shader Flags 1" property, as well as a texture (cubemap). Why? this is only needed for shiny/reflective objects (glass, chrome, water) Adding the environment mapping to the nif could cause some trouble if the original material (bgsm) used does not. CTD? not sure, but you should definately remove that one as it has no use with a piece of wood. Imho. Its always best to keep the settings inside the material file & the nif exactly the same. (so, open up that BGSM and make sure the nif corresponds with that.) Not even Beth did that for all assets, so usually it should not cause (too much) trouble, but lets not use the poor handling of assets from Beth as an example of 'good practice'

It absolutely shouldn't. It's just a reference. Therefor the material itself can not give 2 different results. Did you compare the other settings for the BSLightingShaderProperty like Shader Flags 1 & 2 etc.? edit: & (if all is the same) what happens if you just delete the shaderProperty and copy/paste it from the original?

Well, actually, that is correct. Within Skyrim just pressing prt.scrn works just fine. Somehow it knows how to circumvent the snipping tool, or perhaps the key is set as default for screencaptures in Skyrim but not Fo4(? to lazy to check right now). This was not the case in the past. Anyway, to me it seems CTRL+Prt.Scrn should solve the "problem" for topic author.

Something changed in windows. I never got this 'snipping tool' before when hitting prt-scrn. It just created an image with my full desktop. (across 2 screens) Now the entire screen is darkened and a menu appears on top where I now need to choose what I want to do. (picture, video, rectangle, window, etc.), not just in FO4 but its default windows behavior now.

Never used F12. Because I have more then one screen, I always use CTRL+PrtScrn. Always worked just fine. The game reports the screenshot is taken on screen and even keeps track of the number of screen captures, so it is recognized as such. The game doesn't minimize or anything. You can keep going and make more captures, although if you do in close succession you will get the message too (unless you set UI to 100% transparent) edit: You can paste it from the clipboard, but also find it inside your Fallout 4's install. dir. edit2: Just tried. Hitting only prt-scrn will get me the same result as mentioned. It will minimize the game and such. CTRL+Prt-scrn works just fine. (but I knew that. As I've made thousands during the past 7-8 years.)

I can't find a version number, but the pynifly version I'm currently using is from march 2022 by the looks of it. So that would be something like v4.2. For me that one does all I need and the way I want. (I did change the order of games, so fallout 4 is on top and therefor always default) I usually import a nif to blender, do what I want to do & create a bunch of primitives to make up the collision. I then export the model & collision to 2 new nifs. The one with collision geometry I then import into 3DS, turn it into a BGS collision and export it. I then copy the niNode with the collision to the nif with the model and run it trough Elric. Since reverting to Blender 3.5 and the old pynifly (next to downgrading Fallout, CK & Plugin for 3DS to the old gen.) it has been working fine again.

The top NiNode (c_Cabn01NoFence) contains the main collision data (a bhkCollisionObject) The second one has a 'helper' for NPC's to find their path (a special type of "collision") or at least, it looks that way. The BSX flags tells something about the complexity. Not entirely sure about the BSX but the lack of those shouldn't make CK or the game CTD. It sounds a bit familiar to problems I had myself when I upgraded to Blender 4.0 & latest pynifly. Somehow it got the data corrupted in a way that only made the game CTD. Not Elric, Not Nifskope, not sure about CK anymore. Only reinstalling everything and downgrading to Blender 3.5 & an old pynifly solved it.

If the nif is not correctly structured (which mostly happens when copying things around) Elric will CTD too. I always sort by name, then reorder blocks & remove unused strings with nifskope before running nifs through Elric. When It does CTD, it is usually because I forgot and doing so fixes the CTD 9/10 times. You only really need Elric to finalize collision data. You don't have to do it for anything else. Also note that Elric will remove any copies of collision data. So, if you painstakingly copied collisions from other nifs to create something new... Do Not Pull It Trough Elric. or use a copy, and re-add the data afterwards.

By the looks of it the engine is pretty dumb in the way it handles this. One of my pieces is the 'wrecked wall'. Which has a bunch of bend plates on the floor. I assigned it the "Clutter NoNavcut" collision type, but that is completely ignored and the navmesh gets cut anyway. (so I just didn't add a collision for those parts in the finall version) ...Wonder what happens if the collision is something like 'smoke' ... It wouldn't surprise me by now if that too gets cut.

1871? He, I'm old, but not that old

I just received a reminder to claim a bunch of 'megascans' assets for free before the end of the year. (as they will not be free anymore at 1-1-2025) I already did some time ago, but it came to me that I should warn you guys/girls about it, as there is a ton of good stuff (3D models & textures) to be had, which you are free to use! I have a Quixel account and with that I now have access to the legacy Quixel megascans, as it all will be moved to epicgames fab.com. Where I got another library for free & unlimited access to the epic games assets, although the later may only be used with the Unreal Engine. So, if you are interested to have access (you do not need to download it all) to some 15.000+ textures & models ... go get 'm! (if possible, not sure any new account will get to claim those libraries ...)

It does look related, but not directly. The problem occurs everywhere. However: "It does so by taking the bounding box of the mesh*, and forcing the navmesh that intersects it to reform a new shape around that bounding box." sounds about right. I've tested inside V88, my own interior cell and down main street Sanctuary. The overhanging part will block any navmesh below, that isn't part of the same mesh/nif if it all is a single collision (data). It's as if the engine uses a convex-hull or bounding box around it. which would block that part of the passage way and as the top of the floor is above the meshes bottom (so, inside the "navcut"). Its the only way I can explain why it does work with 2 separate parts of collision data. * = instead of the mesh, it looks to me like it uses the collision data instead, in this case. edit: Yes. It explains a lot. Including why it appeared to work normal at first. As the pieces where just above ground (so, above the navmesh of the floor = no navcut) & without the floor piece in my initial test. So, it almost certainly uses a bounding box based on the collision data as a navcut. Which is not a bug but a feature. An annoying & buggy feature...

Here's something that's been bugging me for some time: This is one of my vault pieces, the red lines being the collision (a "compound rigid body" pre-elric). 2 of these gets you a "hall" with a (half) floor between. As you can see, the collision does not block the passage. As player you can walk right thru. NPC's however do not. The floor piece has a navmesh and works on its own, but they refuse to go there in combi with the above wall. If I navmesh the small strip of floor they will walk there. Combined within 1 mesh (add floor part to nif + collision) then it works just fine too. 2 separate objects (wall+ceiling & floor), no go. unless... I cut the collision up in 2 separate parts (2 bhkCollision objects inside nif) for the wall & ceiling. Any ideas on whats going on and possibly solve this issue? Am I missing something, a setting, a flag, or is it a bug? Note: For the image above I used the mesh to create the collision. Usually however I use a few boxes to keep it simple for the engine. No difference there.