GrantSP

Go back to this post and read the exchange SRB and I had on that. For some unknown reason my merge had invalid RGB values applied. Is your merge giving you the same result?

It would be good if you could tell us. Even if it is user-error, that's okay, we all make those.

Agreed, FNV is superior to FO3 but I'd still play both instead of FO4. FO3 can easily be played on current machines with no issue but if you do wish to try the TTW route, and you should, try this guide from @Adonis.

In the right-hand pane examine the 'Data' tab and see which mod is providing the INI. Whichever mod is shown providing that file is the one that the game is using. If no mod shows, then examine where you have the actual plugins loading.

MO's logs are in the folder called: logs. xEdit's logs are found in the same folder as the executable. Mator's Smash and Merge Plugins Standalone both have their logs in a folder called: logs. As for NPC Visual Transfer I have no idea.

You have to ensure that you drag not only the file, but the entire foldewr structure as well. This means inside the Fuz Ro D'oh mod you will have this folder structure, relative to your MO install: ... mods\Fuz Ro D-oh - Silent Voice\SKSE\\Plugins\Fuz Ro D'oh.dll\Plugins\Fuz Ro D'oh.ini... (other folders and files left out for clarity)

Doing a Google search of "RAPID mode" and reading the first response provides me with the same feeling. Just a different implementation of Windows' disk cache.

Any tool that is run from inside MO, that generates logs to show what it is doing, will be "tricked" in to seeing the plugins in the 'Data' folder. I have not used the NPC Visual Transfer Tool but if it is also setup correctly to be run from within MO it too should find everything it needs. You could, if you feel there is a problem, post your logs and INIs so we can examine what is happening.

... and yet it works without the switch. As an experiment I re-did my DynDOLOD to see what would happen. Here are some snippets of the log: Initial message from xEdit because the switch is missing: [00:03] Background Loader: finished Applying script... DynDOLOD Worlds 1.46 using TES5LODGen by Ehamloptiran, Sheson and Zilav, starting... [00:00:00.018] ******************************************************************** [00:00:00.026] d:\steam\steamapps\common\Skyrim\Data\ Not allowed! [00:00:00.031] Set the output path to a dedicated directory. [00:00:00.037] It should be outside of the game and MO virtual file structure. [00:00:00.043] ******************************************************************** [00:00:00.051] Current output path is not allowed, resetting it to D:\Games\Utils\xEdit\Edit Scripts\Output\ Then the script just kicks in as it should and away I went. Last lines of the log: [00:32:04.811] DynDOLOD Worlds completed successfully. [Apply Script done] Processed Records: 0, Elapsed Time: 32:37 [00:00] Saving: DynDOLOD.esp.save.2016_02_11_09_48_34 [00:01] Done saving. A little over half an hour for a "High" detail version of all Skyrim LOD. Everything appears as it should and the only hint I get of a problem is the reminder above and the redirection to my xEdit folder. Now I'll do the whole thing again with the switch re-instated. EDIT: Second run completed. Log output is: Applying script... DynDOLOD Worlds 1.46 using TES5LODGen by Ehamloptiran, Sheson and Zilav, starting... Here the script just starts without issue as MO had the switch in the arguments field like thus: -o:"E:\Games\TES5Edit-DynDOLOD\"Incidentally, this path is the one assigned to the second input field in the DynDOLOD UI for the output path. xEdit runs the script and about the same time as before it finishes with this message: [00:30:52.195] Waiting for LODGen.exe to finish ... [00:30:57.213] LODGen.exe still seems to be running. Giving up waiting for it. Let it finish on its own. Then proceed as normal. [00:30:57.256] DynDOLOD Worlds completed successfully. [Apply Script done] Processed Records: 0, Elapsed Time: 32:02 [00:00] Saving: DynDOLOD.esp.save.2016_02_11_10_42_37 [00:00] Done saving. Note: The output path in this second run was to a 2Tb HDD whereas the first run was to one of my SSDs. The LODGen.exe continued to run for several minutes after the actual script finished, as the log mentions. No doubt this is due to the slower drive. Conclusion: The switch applied to MO's argument field is the same as that assigned in DynDOLOD's UI so it can safely be omitted and then entered manually in the execution of the script. However, this doesn't address the issue of the OP. So it would be helpful if you could post the paths to all the tools used in this scenarioa as well as logs from MO and xEdit. Delete any from previous runs to avoid large files. Either post them here inside spoiler tags or on a hosting service like PasteBin. Additionally your MO INI will help us see the relative paths to each. The issue of permissions is still the primary culprit in my estimation. EDIT: Just had a lightbulb moment. Add a trailing backslash to the output field and see if it is recognised. Nope, makes no difference.

In theory you can simply omit the switch in the arguments field and just choose the output path in the DynDoLOD UI. It's the second field in the UI labelled: Output path.

Pfft, they're just flowers! Just kidding, me too.

Yeah I understand the concept and the reason for editing it, just bemused that I can't get the FPS drop. Sorry, only wanting to test it for you.

Must be a glitch, there's nothing in the logs to show a change of tag on this.

Sorry you posted as I edited. Yeah I have the original active and I can't see anything.

So do I actually need the crossbow in my inventory? Or is it just enough to have the mod active? EDIT: I see no FPS drop with the vanilla plugin. Drawn or holstered. What's the story with this thing, I see the posts say there are massive drops but I can't trigger them.

Is there any specific spot where the drop in FPS occurs because I get a constant 60FPS with that mod installed.

He didn't say that, just confirmed the weapon forms are not there.

Just watched that episode with the lizard/man transformation. Brilliant, that's the sort of stuff from the original series that made it a must watch show.

@Mator has stopped working on the script and has shifted focus to the tool. Any new records that we find that need to treated correctly will be added to the tool, not the script. On top of that it's just so easy to use, almost idiot proof.

Yep.

If the message says the directory is invalid then the directory is ... invalid. Check your spelling. The format of that switch you set in MO's 'Arguments' field must look like this: -o:"e:\Games\TES5LODGenOutput"

You should be at least getting error messages from Windows to say you're missing a .NET module or something. Having no messages at all and the code failing to run is just plain weird. I have a very similar system to you and I have never heard of or seen anything like this. The code changes from 1.2.x to 1.3.x are not that great as to render the entire UI useless. You have no AV software of other tools running that might be messing with the initialisation? Since the "hooking" code does look like malware to "less knowledgeable" software, MO sometimes gets treated like malware and either removed to the bin or just stopped.

The trick now is to find a good location that makes sense for everybody and have that information shown.

Yeah, your changes are much better. Too much info was confusing, now it has a much better flow.

There is a dedicated sub-forum for FNIS/MO matters and this very question is addressed in the OP.