RoNin1971

Just did the work for my new vault door (a smaller version of the V111 doors) to go with my V33 pieces, amongst others. & I noticed ones more what I had forgotten: The vanilla pieces are way more complex as needed. They add each and every object to the object palette and stuff, which is an overkill. I have multiple meshes, like the original, but those are inside NiNodes. 1 for the upper part, 1 for the lower part & 1 for each "floorslat". Those are the ones I move/rotate. Everything inside the NiNode will move along. Whether mentioned with the object palette or not. Doing it like that makes it easy to replace the mesh(es) without the need to edit anything to create another door (with the same sequence) So, it looks like this: 3 NiControllerManager - 4 NiMultiTargetTransformController - - 0 NiNode RVP_V33Door01 [thats the "Target") - - 11 NiNode DoorLower [Extra Target 1] - - 29 NiNode DoorUpper [Extra Target 2] - - 36 NiNode floorslat01 [Extra Target 3] - - 40 NiNode floorslat02 [Extra Target 4] - 5 NiControllerSequence Open [4 controlled blocks. DoorLower, DoorUpper, floorslat01, floorslat02] - - 6 NiTextKeyExtraData - - - There are 3 text keys in this case: start (at 0.00), Sound: DRSVaultDoorVerticalOpen (at 0.16), end (at 1.8) - - 4 NiMultiTargetTransformController (the controller for the sequence) - - - 3 NiControllerManager (Manager for the sequence) - - 4x NiTransformInterpolator - - - NiTransformData [this one contains the Translations keys (LINEAR_KEY) setting each position in time, or the XYZ_ROTATION_KEY) Same for sequence Close - 16 NiDefaultAVObjectPalette - - 4x Objs [the 4 NiNodes: DoorLower, DoorUpper, floorslat01, floorslat02] As you can see, there are only NiNodes mentioned here. No BSTriShape's. So, I can put whatever shape I want inside those 4 NiNodes and they will move. (just make sure any collision data is an animated-static) edit: A quirk from Nifskope I guess, but after entering the number of 'controlled blocks' you need to hit "save". Before you can add those blocks to the list.

List of possible materials: (not all seem to work as expected) For a list of possible types and short explanation: https://geckwiki.com/index.php/Collision_layer Don't take anything there as absolute truth either. They are wrong about the water for example (but you need to do a bit more as just assign the type)

There are roughly 2 ways to create a "rigid-body". Which is what you need for Elric to finalize it as a true collision. Ether you use the 'mesh', which can be a plain. This method works nicely but the collision will be as complex as the mesh. Which at times might be overly complex and you might need to cut the mesh apart, to assign different materials. Or a 'convex-hull'. The later is the smallest box possible (with the least amount of vertices) encompassing the entire mesh. This too will work with a plain, but it might gain some small thickness. This doesn't work well with inward curves and holes. They get filled up. Both ways are more or less supported, somewhat, by nifskope. You should be able to set the material and type for the collision there as well. As long as you have the 'raw' data (with a visible rigid-body "collision" in Nifskope / pre-elric)

hmmm, I don't see how a more complex collision helps with textures. It is more likely the other way around. For example, I just did a few subwaytunnels. One 'part' or 'mesh' within those nifs is a piece of railroad. The texture covers the entire mesh. Both the wood and the steel beams. Using the mesh to create the collision you can however only assign either wood or metal. Not both. To do so you would need to split the mesh, to separate the wood from the metal. Many textures & meshes are like that. Although creating a big box with the size of the door will work just as good and hardly anyone will ever notice the metal sounds like wood. One of my first mods was the wide vault door, as a modders resource. That one works like any other vault door, with just a 'box' for the collision. It's almost fully metal, so that's ok, but it has a window too. It probably sounds like metal, but I never shot at it You could use that one as example. Although it is different from most normal doors, as it works (& looks) exactly like the Vault 111 doors. The most important thing I learned with that is that you need an 'animated-static' for the collision to be moveable. Using a regular static doesn't work, even though it looks like it does in CK, but no go in-game. These are typically purple of color in CK. BTW: if you look at the collision of a door with CK, you will notice the red (static) & purple (door) all together. Inside the nif you will however find multiple BhkCollisionObjects. Each of these refers to a part of it, but in the end there is only 1 piece of collision data containing it all. So, you can't delete and replace a part of it. Just delete and replace ALL of it. (you can use quite a lot of various copied collisions to 'construct' something.)

it depends on what you replaced. The doors usually have 'multiple' collisions. But it only looks like that. I think they use proxies or something. Anyway, you can't replace a part Just everything or you can add a new piece.

I created a few in Blender. Just the model. exported to 3ds, made an animated-static as collision and did the animation with Gamebryo style [edit: With Nifskope]. (using vanilla vault doors as example). its a bit of work, but it does the trick. edit: Robotized is fairly correct. It is usually the quickest way to copy and replace an original door. It does depend on the animation sequence though. Just take a good look at a few 'vanilla' versions as example. (The ones with gamebryo animation (as that's defined inside the nif). It should be possible to export .hkx data from 3DS, but I never tried. I prefer the gamebryo method. From Blender it depends on what you are using as exporter. I would recommend PyNifly (https://github.com/BadDogSkyrim/PyNifly) It is the most useful plugin around for this kind of work. The latest versions even seem to support some animation, but as I'm sticking to an older version I have no idea how much and what kind. (I'm guessing gamebryo) Doors, however, are usually the same size as they need to fit the same hole. They frequently open/close in a similar fashion, leaving just the 'design' to be different. That makes the 'copy&replace mesh' method a very viable one.

Read: https://www.afkmods.com/index.php?/topic/5079-plugin-files-and-you-esmeslesp/ ...and forget about ESL.

I might have sounded a bit harsh, but fact is: I love you for creating pynifly and consider it a must have essential. Nothing comes without flaws though. Least of all me Anyway, the info might be old. For sure. Haven't updated for a long time as the older versions fit my needs better. Last time I tried updating (everything, not just pynifly) I couldn't produce a working collision for months. So, I'm definitely sticking to the old.

You should not adjust/change paths. Only make sute the texture+path are the same as inside the material file. second, make sure to use a .\Data\Meshes & .\Data\Textures (within the same folder structure) That way the nif & textures should work everywhere.

That's correct, as pynifly creates the "missing links", by adding a non-existent texture (path), without any checks. (...and using blenders path to textures instead, or ask the user, or have a setting to tell it where they are...) Your "workaround" is good. As long as you point it to the same texture as the material. You don't even have to look it up most of the time. The correct filename is usually there, you just need to adjust / point it to the right (relative) path. The only time you need to search for it, is when there is no textureset (or its empty). You should however not use this method to load a different/alternative/custom texture, as it will not show up anywhere else since the texture from the material is still used. Note: Purple in nifskope means the material is wrong/can not be found, -OR- if no material is set, it means the texture can't be found. When there is no material & no textureset, it shows up white. Nifskope, CK & the game all show the textures as supplied by the material, ignoring the textureset. UNLESS no material was set. (empty string) Pynifly ignores the material and ONLY looks at the textureset. (which is wrong, but alas, its the way it is) & it adds the relative path to a truncated version of the mesh path. So, when you have a mesh in: D:\FalloutExport\Data\Meshes\Mymesh.nif & a texture at: Textures\Mytexture.dds The texture is expected to be at: D:\FalloutExport\Data\Textures\Mytexture.dds If you have a mesh inside D:\Temp\WIP\mymesh.nif (note the lack of \Data\) it has no idea what to make of it. In case that would be: D:\Temp\WIP\Data\meshes\mymesh.nif, but the texture is actually at: D:\FalloutExport\Data\Textures\Mytexture.dds Niskope has no trouble with it, since you can supply a path for finding (texture)files (D:\FalloutExport\Data\) Pynifly is however hardcoded to look only at D:\Temp\WIP\Data\textures\mytexture.dds in this case. "Not there? Though luck".

I bet you are using pynifly. As nice as it is to have, it comes with flaws & a stubborn author. 1. It only looks at the texture set, ignoring the material. 2. it expects the textures\blah\blah.dds files to be relative to the path of the mesh, truncated at .\Data\ 3. it does not check if the texture is actually there, nor does it use the path set for textures in blender. Note: Only opaque textures turn black, anything with transparency turn completely invisible. I reported all of this long ago and told author the textures fail frequently, especially as I keep my own nifs separate while working on them, but still use vanilla materials & textures. But that's where textures should/must be according to the author. Afaik, a full path doesn't work any better. It cuts everything before & up to the \Data\ and replaces it with the one from the mesh. The game-engine does a similar thing. (Some vanilla nifs contain full paths and they still work, although the path does not exist) Re-linking the right dds files is a "working solution" within blender, BUT keep in mind that although the materials are not used/displayed it does store them on import and re-adds them on export. Changing the texture this way will be a "problem waiting to happen" as you will get to see the textures from the material everywhere, instead of the one you added to the texture set. I usually import a nif after making sure a material is present, preferably, and a texture set to correspond with it (mandatory). (which both is not always the case) In case of sets, I now put them inside my exported data folder (on a separate drive, not under fallout install) I import one. Make sure the textures are ok and rename the .mat to match the texture name. Then import the rest and set the texture .mats to the same ones. So they all use the same .mat for the same texture. Saves a lot of copies & clutter. Change one and you change all. Otherwise you'll have a truckload of *.mat.001 to *.mat.999. Sometimes (especially on individual nifs) I just replace the material node for a correct one using Nifskope afterwards. Keep in mind that nifskope, CK & the game will all ignore any textureset unless no material is set. This is the 'reverse' of what you get in Blender! Edit: BTW do not copy/paste but create duplicates. When you copy a mesh blender will also copy the material & texture. Leaving you with long lists of copies. When using duplicate, it uses the same as original. Saving you from the clutter.

The statement is a bit outdated, agreed. Haven't tested with my current setup (2x Samsung 990 Pro 2TB (7450 MB/s read)), but got nothing to compare it to anyway. It loads a lot faster as on my previous rig, which had SSD's as well, but a lot slower. Those definitely took longer to load as my PC before that, which still had HDD's. Let's just say it doesn't load as fast as it should be able to with SSD's. 7450 MB/s vs 286.8MB/s for the fastest seagate HDD, that's over 25 times faster, not 2 ...

Why would you? There is no reason for that. Start of on your own and try to learn what you need to do. Modding can be hard work. A big "DLC sized" mod especially so. It can be as stressful as it is rewarding and satisfying (when it finally works). It requires dedication & determination, for years. Especially when working with a group. You need lots of experience and knowledge before starting on something really big, or if working alone you can learn on the job, but be prepared to start over. More then once. Best to cut it all down to a few basics. Need custom characters? Create one (a mod with just that) Need assets? Learn to make 'm. Need 'm buildable? create a (small) workshop mod. Create a settlement mod. Etc. Yes, it will take time to do all that and your real work hasn't started yet, but you will have the knowledge to actually do it and a lot faster too. Meanwhile others get to see what you can do and who knows, they might want to join you.

Most of it doesn't have any. Not sure what's used for trees and stuff. edit: They (tree trunks) show up red with CK, so that might be regular statics. (should work in anycase, but they will be just that. Static. No swaying with the wind).

About what? "A DLC sized mod" should not be "THE" goal. "Oh, it doesn't matter, as long as its big" doesn't work. So you must have some kind of idea you wish to create and how, etc?

instead of trying to find a modern game which is similar in performance (that's going to be very hard), I believe it would be better to look at what FO4 actually needs, and more importantly, uses. A modern game will utilize my i9 14900K's 24 cores, FO4 will only use 4 out of those (afaik). So, a CPU with less but faster cores, will do better, but also makes any comparison moot. FO4 loads a lot faster from a good ol' harddrive instead of (much faster) SSD's. On the GPU front anything higher as the 'recommended' will do, unless you want to play around with 4K or even 8K textures. Your GPU's memory should be the decisive factor in that case. For using all kinds of shaders and/or ENB's you don't really have to look at anything, after fulfilling the above. Unless you wish to turn on "Godrays" (don't ) You really need to buy something very cheap, not to be able to play a 10 years old 3D game in ultra settings.

That might be right. I'm pretty sure the 3D models they use are way more complex as the FO4 ones, so don't worry about that. My 2070Super could handle FO4 on ultra without breaking a sweat. It's when you load it up with 4K textures and an ENB where it will fall short. I'm sure a 4080super will have no trouble with that AND a bunch of 8K textures, just like my 4090.

Yeah. That still got me 'shocked'. If anything, the NG version should have fixed the loading speeds/issues, but even that was to much to ask. In general one should keep in mind the game/engine was never designed or optimized for todays hardware and their capabilities, so its never going to utilize all of it (correctly).

That's because the older games can't handle all those cores. They only use a few. The faster each CPU-core the better the game performs, in those cases. & FO4 actually is pretty bad with SSD's. It can't handle the speed. Consequently loading can take forever.

You would be correct, IF resolution was all there is to it. But it isn't. I'm actually running FO4 on the latest i9 with a 4090 & some of the fastest RAM & SSD's. My screen is an ultra-wide 3440x1440. (45") - (I use it for 3D modeling and stuff too) Trust me, I'm using all the power they have to give. (although the CPU never gets fully utilized) Why? Because I'm using 4 & 8K textures and the highest possible settings on my ENB. In vanilla mode I can hit 10.000 fps, but I can still bring it down to below 60fps by going for the max. in quality. edit: I actually started playing FO4 on a 780M (2016/17), which was already sufficient to run it in (vanilla) ultra mode. Switched to the 2070Super in between, which couls easily hit 2300fps in vanilla ultra mode, but still could not handle my current settings & textures.

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.