eurolite

I couldn't follow that explanation unfortunately. You didn't really answer the first part about the ITMs (unless the manual was supposed to do that.) Are those entries going to be loaded still or delete due to the blank space in the merged patch? Why does the merged patch not add these entries? I don't understand what the flag does at all. Why are the entries separate even though they have the same LVLI? Care to explain? And if you have time, I was having another issue that I couldn't figure out: The RH WMK bridge deletes the first three entries from WMK since there are blank spaces there, right (or can the entry still get through despite the blanks)? Is this intentional, or do I have to merge both records together? I can't tell because some stuff is missing, but at the same time the bridge does copy over a few entries from WMK, meaning that if the bridge needed the other entries, it would have copied them over as well. It also doesn't help that I don't know what any of these records or entries mean. I should try to read up on that. The third plugin here has WMK as its master. The entire record is olive or grey, so that means it's a complete ITM. However, if I try to clean ITMs, FO3Edit will not find any.

I understand conflicts in general, I just need to understand the specific case I listed here. I have quiet a few like this that are not behaving the way I would expect them to.

I just made a merged patch and I don't understand why some things were excluded from the patch. Take a look: It is my understanding that the last plugin to load needs to have every other change in the record in order to not have conflicts. This picture contradicts this. Take a look at the first Leveled List Entry. The Merged Patch has it coloured yellow, which means it will overwrite without conflict. But how so? If it's blank for the merged patch, wouldn't that mean that it's deleting what WMK has put in? Why wouldn't the merged patch include that entry in the first place? Is it because it assumes that the ITM is unwanted because FWE deleted that entry (even though it's before WMK in the load order.) The same applies for the third entry. The fourth entry is confusing. It has the same exact values as the entry above except for the Level value. It seems that this is an entry for how much ammo this weapon will have. WMK had it at 16, but the FWE patch for WMK tones down the value to 8 for balancing purposes, correct? If so, why are the two entries considered different in FO3Edit? This also doesn't make sense because the previous entries we talked about have that blank spot for the merged patch and the colour is yellow, but the colour for this entry is red. What's going on here?

Post a load order please. A list of mods would help too.

No, you definitely helped! You said you just copied the mesh branch over to the original. I did that too and I think that is what fixed it.

Yeah, once I redo the texture I'll send it over. I was trying to do it but got annoyed at how bad it was turning out and annoyed at my lack of skill to make my own texture; it's difficult stretching a texture made for one UV map so that it can fit another. Edit: You can download it here. Included the 3DS Max, UVM, and diffuse PSD files in a folder named "mod resources". I fixed the glossiness by making a specular map. It probably isn't very great and I didn't really know what I was doing with it, but it fixed it.

Here you go. Simple edit in GECK to two values. I didn't bother testing it but there couldn't possibly be anything that could go wrong. Edit: I recommend you undo any changes you made to the master files. Reinstall them even.

This is great! I'd really really like to know exactly what you did to fix this. I know you said you don't know where I went wrong, but can you specify what you did in Nifskope? First, I had no idea that it's possible to interact between different instances of Nifskope. The only change I made to the model was the UV map coordinates/points (I can't recall the exact name right now, but I saw a section for it in Nifskope under one of the mesh branches.) If it's possible to just copy those new values over, that's all I'd need to do aside from changing the texture paths.' Also, what do you mean by changing the positioning? Do you mean the order of the branches, or you changed the origin of the mesh, etc.? I didn't think the latter would be necessary since, like I said, no changes to the model were made. You can use this for anything you'd like. However, this was made as request from someone on Reddit, and it'd be cool to give him/her credit for the idea. I can provide a psd for my (poorly made) diffuse/texture so you can change the logo to your favourite sports team/whatever. However, I do want to redo this because I think the way I did the UV Map seams was bad because there are visible seams for the texture on the sides of the hat. I just took the vanilla texture and stretched it. I couldn't figure out a good way to fix the seams; the stamp tool wasn't enough. I'd also like to fix the glossiness or make a proper specular. Maybe it wont be glossy in-game, but in GECK it was pretty shiny. After I fix all these things it'd be cool to release it on the Nexus and include a modder's resource with the PSD and whatever else so people can change the diffuse completely, change the cloth colour, or just change the logo. Edit: Since you didn't put the textures into the game, could it be that the game doesn't support 8.8.8.8 ARGB? I figured I'd make the texture high-quality since it's not really impactful on performance and DX1 looks awful. The textures do work in that format. Edit 2: I tried it out in a vanilla game on a new save and the game still crashes. I even tried changing the textures to DX1. I did rename your file, removing the 2 at the end because otherwise it won't replace anything. Was I supposed to keep the 2? How did you get it to work? Did you make a new plugin and change the model path for the hat in GECK? Edit 3: I remade everything. This time I imported the NIF directly into 3DS Max rather than exporting to OBJ via Nifskope. I then copied over the entire mesh branch to the original NIF, moved the shader and material properties over to the new branch, and deleted the old branch. The I gave things the right string names and sorted the branches the same way as the original NIF. I loaded it up and it doesn't crash! I just need to redo the diffuse since I redid the UV like I said I would. It's also shiny in-game like it was in GECK, so I'll be trying to fix that too.

Bump. You can also help by recommending some other places to ask this question; this sub-forum seems more about trouble with existing mods rather than trouble with creating one's own.

Yeah, I think SweetFX counts, right? It comes with the ENB preset mod I use.It is using the latest (0.267)You'd be surprised. I still can get drops down to 10 frames with ENB and 25 without in the Wasteland. Probably too many HD textures plus the engine being sucky at handling mods and in general. Also, I have 16GB of RAM, not 8.No, it's not dual GPU.I'm playing FO3 (this is the FO3 forums...) Yeah, I started with Skyrim and didn't have load order issues there. I don't think I have load order issues now. I know I goofed with my original load order but I figured out what I did wrong quickly once I took the time to look at it. Also, that forum post didn't have any useful information; why did you recommend it?Is it really worth the time to try to get that ENB option working? Could it be part of a bigger problem that will cause issues down the road? I haven't experience any out of memory crashes yet, but I have had 2 CTDs so far while playing.

No, I can't set it back to true. If I do it will just start the frame drops again. Disabling the memory manager on it's own and leaving system memory usage at the default, enabled, setting does not affect the issue. I was just saying that maybe if I disable the memory usage option without also disabling memory manager, I will still get frame drops. I doubt it, but I'm too lazy and there is no reason for me to test. I don't think memory manager on or off makes a huge difference if it's just a workaround for AMD cards anyway.

I found the problem. It was the ENB afterall. It was one of the memory settings, ReduceSystemMemoryUsage. I set it to false and it fixed everything. I also set DisableDriverMemoryManager to false. I don't know if both need to be set to false, but I know that the former for sure is the main problem causer.

I redid the UV Map for the Pre-war Baseball Cap. I needed to do this because the old UV Map was too small and the seams were in such a way that it wouldn't allow me to add a logo to the front of the cap. I remade the UV Map in 3DS Max, textured it in Photoshop using the original textures, and exported the NIF through 3DS Max. I edited the NIF with NifSkope and renamed things to what they were in the original mesh as well as added the texture paths. I exported the textures as 8.8.8.8 ARGB 1024x1024. The files consist of a single mesh, a diffuse, and a normal. I loaded up GECK and it looks fine in there (no crashes). However, if I try to equip it in-game, it crashes right away. Both male and female characters. What went wrong? My guess is I missed a step in NifSkope. Here are the files so that you all can inspect them for yourselves. Side question: the hat looks really shiny in Geck (goes away with the specular shader disabled.) I turned down the glossiness in NiMaterialPropery but that didn't help. Did I overdo the normal map, or is because of a lack of a specular map despite the specular map flag being checked? I saw a block in NifSkope for a specular shader specifically I think. Is this easily fixable, or should I make a specular map. Is it even worth making a specular map or having the specular shader enabled for a hat? I just copied what the original mesh had.

I was using LOOT to sort it for me. I see now that what I once thought was fine does have problems with the patches. New load order: Did not fix my issue. Edit: I was in a rush earlier. I now took the time make my load order according to the FWE page. It still has not fixed anything. I'm guessing it's either not related to my load order or I'd need to start a new save to fix it. Load order: Mod list (reverse the order, sorry):

Somehow the math looks wrong. It's just something I took from the INI files the author of the ENB I'm using posted. I used it because I was having constant crashes and thought I'd try it out. Turns out the crashes were because I have iNumHWThreads set to 4, not 2. Works for some people, but not for me. Anyway, removing those lines didn't help anything.