Kesta

IIRC, when launched with this argument, the log generated is inside the "Edit Scripts" folder. the one right next to TES5Edit.exe is only updated when LODGen is run via "the inside" of xEdit. Don't take my word on that though, better wait for zilav's / sheson's confirmation.

The executable properties still show 0.9.9.9 indeed, but if you run LODGen (run TES5Edit with the -lodgen argument is the fastest way), and then check LODGEN_log.txt it'll give the actual version, which is indeed v1.0.0 beta.

Most common case of very small output folder is that you closed xEdit before LODGen.exe could finish. When you have this message It doesn't mean that you can exit xEdit. Doing so will shut down the lodgen process leading to a very small output. You have to keep xEdit open until it finish by itself.

You mean the original weather's imagespace or or modifiers applied via the MCM ? Manga still have to rework the seconds to prevent the dimming of lightsources, I think he expected the "target lum" settings to help with that. This was the only way we could achieve multiple night brightness settings without multiple plugins. That's a famous series of SweetFX preset (similar in functionment to enbseries without the memory management part, and with way less features and post-processing quality, but much better performances). The first 3 were designed for CoT, but the 4th edition should be for VW.

Afaik Manga isn't working on the Vividian ENB upgrade yet because there is a few more things we're trying to get into VW itself (new gloomy weather that appear on vampire attacks, sovngard weather, some climate adjustments for non-standard climates, ICBINE4 built-in compatibility, ...). But knowing manga's productivity when he start tinkering shaders, it'll only be a matter of days one he start working on the Vividian update to bring everything to a VW compatible version. Also, benhat (co-author of some of manga's enb) is going to release Northland ENB for VW in the upcoming days, which might be a great alternative.

Doubtful. This isn't about the performances, but more about getting "too far from vanilla" than what the STEP guide aim for. Individual manga's mods (vivid snow and vivid clouds and fogs) are better suited.

Second time we're having file corruption issue with the nexus in two updates... I'm still able to download and install v1.2 properly though, so it's worth trying to re-download.

Exoclyps : The actual problem is way different than that. And trying to find compare with real life situation with books or painting will hardly be accurate. Here are a bit more detail on what happened exactly. First, you need to understand that a weather is about the following data : Day/dawn/dusk/night colors (both ambiant and "sunglare" aka directional), and sky/star/aurora colors also. Clouds layers/textures/colors Fog effects, colors and distance Precipitation type Imagespace (in-engine post-processing). Manga first created vivid clouds, new clouds textures and revamped all of the clouds colors for vanilla weathers. He made patchs for most major weather mods for his new cloud setup, including CoT. Then he expanded vivid clouds for vivid clouds and fog, revamping fog as well. Again, patches for major weather mods, revamping all of the fog settings on any weathers. He took this opportunity to adjust several weather colors by this time, especially fixing CoT's night in the CoT patches long before CoT 5.0 was up. Then he made vivid snow, and revamped all of the precipitation types for snowy weathers. All this time, he also had been working on Vividian ENB, redoing the imagespaces in order to make them more suitable for Vividian ENB, and redoing all of the clear weathers so they'd look better with the ENB. Since his patch supported multiple weathers mods, he also offered completely redone (not even revamped, really redone) region settings (aka weather distribution) made by Unmeix in his patches, so CoT could be used alongside NLA for instance. What was left from the "patched version of CoT" which you can still find in the Vividian ENB installer was the following : Rain precipitations. Some colors he hadn't modified from CoT, and a few effects from the imagespaces. Sounds. Then CoT 5.0 came out, with a few sky colors adjustment (brightened blue) to adjust to the new skymeshes and the night sunglass effect fix. This is when I recall manga saying "Jeez, serisouly, 2 years and none of the actual colors oddities seen everywhere have been fixed. I'm done patching all of this so it doesn't look awfully weird, I should do my own weather mod". He had this idea some month before (last summer), but Hishutup convinced him it wasn't a good idea by the time, because there was already so much weather mods available. So he merged all of its changes into the original CoT along with his other weathers, listed what was left from the original, and redid all of it to prevent any re-using issue (new sounds, new rain precipitation and effects, revamped the visuals of the few weathers he hadn't completely redone already). He also scrapped all of the imagespaces and redid them to fulfill his unending passion for bloom settings. (I remember he streamed this part... that was... long, to say the least xD) I've been trying to figure out what felt "wrong" in this, and came up to the conclusion that the "weather creation process" had been extremely simplified compared to what had been done in CoT by the time it came out : The way CoT is designed suggest that JJC removed all of the weather for any region, and the went through each region by thinking "OK, in here, I need 3 different clear weather, 2 snowy ones, and one storm". Then designed them, and added them to the region, before moving to the next one. Instead, VW started from a pool of 580 available weathers that weren't assigned to anything, just looked nice and had a purpose (a foggy weather, a storm, a clear cost weather, ...), and assigned interesting weather to each region. The eternal question is "why didn't he just recreate the weather in a new plugin instead of merging them since nothing was left from the originals". This would have prevented all of its fuss. But weatherID assignation was already done for CoT weathers in hundreds of ENB Presets. By keeping the same purpose for each weatherID, ENB presets authors could just run their ENB with VW and adjust them to suit VWs settings, instead of having to rebuild the preset from scratch. But this really cost a lot of credibility to the work done.

DSR functionment is the following : 1) It detect which weapon is equipped in the left hand 2) It equip an "armor", which is actually invisible, but is the visual equivalent of the left-handed weapon. 3) When you draw your weapons, it unequip the fake armor, and equip an other one which is the visual equivalent of the scabbard of your left-hand weapon (without the weapon sheathed in). 4) When you sheathe your weapon, it re-equip the fake armor with the weapon model. Those "fake armors" are generated by the patcher, it create a fake armor for every playable weapons in your load order, and give it the model from the "mesh pack". It doesn't care if the mesh actually exist or not, it just tell the fake armor "your model is located at this path and have this name". So you need the mesh in order to really see your left-hand weapon,otherwise the fake armor is completely invisible. The trick is the same for right-hand staves and shields on back. To create DSR-specific mesh, you need to create the new meshes, with the proper name (the same as the original one, in the same path, but with the right prefix, because the patcher only append the prefix to the model path/name). There is a tutorial in the DSR optional download on how to edit a mesh to make a DSR-ready mesh. Side note : The DSR meshes doesn't modify the original one, they are brand new one. This means that you can actually install every mesh packs available, those needed will be used, the other not. Will save you a lot of time rather than checking for each option if you have or don't have the mod installed. Note that the "sword on back" option from DSR have for sole effect to give you new meshes for your weapons' scabbards that doesn't have the belt, in order to avoid that it look weird when the weapon is located on your back.

Can't be an incompatibility between vivid weathers and ASLAL. I just made a quick write-up on weather/lighting/post-processing interaction here : https://wiki.step-project.com/User:Kesta/LightingWeathersPostProcessing It lack a lot of polish, but hopefully anyone who already understand a bit about modding is able to understand the difference and most of the "compatibility issues" with Vivid Weathers and other mods.

Vivid Weathers doesn't touch interior lighting at all, the "interior darkness" feature work the same as if you casted a spell (like the orc racial power), except it last forever, but the effect is off when not on interior. Can you double check you don't have any scripts in your data folder (from the CK typically) that could alter the vanilla scripts for this effect (MagicImodBasicScript.pex), and provide a papyrus log in case something is wrong on this side ? While we're at it, if you only have VW, SKSE and OneTweak, I wouldn't mind a savegame with the bug in as well, could help figure out what the **** is going on with this feature. Edit : bah, nvm, took me longer to write this than for you to solve the issue >_

Try re-running nxmhandler.exe If not working, post the content of nxmhandlers.ini (all of this is in your mod organizer folder). And give the name of your browser, could help as well. Just for the notice, from MO2 download page :

In SkyrimPrefs.ini ; [Display] bFloatPointRenderTarget=1 This is true for any ENB. Think about posting screen next time you've got this kind of issues, not all are that obvious. As for the particle effect, I'm not sure why peoples are worrying about performances, it trade the regular effect for a particle-based one, so the performance impact is close to none. (for info, the "regular effect" is why skyrim performance plus have almost 20k endorsement by just down-sizing a dozen of textures.

Not sure why you can't. the "download with manager" feature is a "custom link" that must be opened in an app instead of a browser. When a browser fisrt encounter an nxm link, it will ask you with which application you want to open it. You should choose "nxmhandler.exe" (present in the same install folder as MO), this will take care of redirecting the download link to the mod manager you wish depending on the game the mod is designed for (in your case, MO for Skyrim I guess). This is the same concept as "magnet links" for torrent downloads. If your other browser already registered an other app for nxmlinks, you have to switch it to nxmhandler. You can usually do this in the configuration/options of your browser. Here is how it look in firefox : Google "how to change default program for magnet link in XXXX" with XXXX being your browser, and you should find the info you're looking for, you'll just have to follow the procedure for "nxm" instead of "magnet", and of course use the path to the nxmhandler instead of a torrent client ^^

How is this question related to tes5edit ? That's just a modding question. For your answer : this keyword is used to tell if you are allowed to disenchant an item to learn its enchantment or not. Typically used on unique items with unique enchantments such as the spellbreaker. So yes it's safe to remove it, that's how you create an "artifact disenchanting" mod.

Best / Simplest solution to check if your problem is MO related is to clean your esms outside of MO. Just launch TES5Edit normally, and clean your masters. Also, you should have a TES5Edit_log.txt in the folder where TES5Edit is installed. Copy its content to pastebin and send a link. If something is wrong in your cleaning process or with your masters, it'll be written in here.

Yes, thus what I wrote in the post I self-quoted. Currently the guide page have a "customization" with the text "List of guides." What I thought was replacing this simple text by a hand-crafter index. It'd keep the dynamically referenced guide in the category and its categories, but would allow a nicer display at "first sight". The issue being that it'd have to be maintained manually.

I guess that's the point we disagree on (and the one that led me to post this thread ^^) Sorting guides in alphabetical order just doesn't make any sense for me.

Discussion thread: Lucidity Sound FX by FoggyPath Wiki Link I just installed this and am about to test. The overall idea sound (see what I did here ? ) interesting. Those are remastered audio files from the original game, "cleaned" audio-wise in order to make their sound stand-out, clearer and more accurate/precise. The authors state that this improvement in quality is essentially aimed at users with headphones or computer-speaker, which tend to build up on the original bad-quality of a sound and make it even worse. The current version contains about 2000 remastered sound file (roughly 38% of the original files according to the authors). 212 of them are already covered by AOS, which should have the priority. Nice context STEP-wise I think, since someone recently brought up the fact that STEP needed a good review of its audio setup. Compares for STEP Bow Shooting Sounds: https://drive.google.com/file/d/0B1_Nlyy2ueu0bHF2a295dTA4N2s/view?usp=sharing List of oddities: When traveling between Whiterun and Riverwood at night there is a sound in the loop which sounds like a woman screaming.The fires in Inns have a low, bassy roar to them when the fires are nowhere near large enough to create such a roar (experienced in Riverwood Inn)

Some more questions : Statics have 4 level of LODs in the CK. Is the 4th one the LOD32 used for the map ? About lod textures atlas : LODGen have the following features (nexus description) While DynDOLOD have the following option : Max tile size : Lower values to reduce atlas texture size in exchange for quality. Which sound like it's just the atlas size from LODGen (which will result in a square-shaped atlas while you can set H/W distinctly with LODGen). Would using LODGen outside of dyndolod give more control over the texture atlas generation ? Or are the max texture size and the "in uv range" parameters in LODGen intended for dev-test/experimentation and not aimed at users ? Random "report" : (floating fire-embers) I guess just forcing the use of the full model of the brazero under them on LOD4 should be enough (I know the screen is actually behind whiterun's wall, but I'm more thinking about mods like ELFX-exterior which add this kind of brazier along roads). The question I'm asking myself is how the mesh-mask work. The full path for this brazier mesh is the following : Architecture\WhiteRun\WRClutter\WRBrazier01.nif Would just using "Brazier" as mesh filter would catch it, or the "WR" prefix would prevent it ? (the doc about the mesh-mask only state that the path is optional and that any suffix in the mesh can be caught whit the same rule, but don't say much about prefix).

What would happen if "we" just add text in the category page (where "List of Guides" is currently written) ? Wouldn't it behave just like a normal page, but with the full list at the bottom ? If so it's possible to design a nice hand-made index, but keep the exhaustive automated index at the bottom. Come to think of it, the Pack list could use a similar change.

What the title says, there is a few numbers of tools/utilities guides on STEP and I believe it make more sense to have them all gathered in a single sub-category. Relevant guides to be included into such category : https://wiki.step-project.com/Guide:DDSopt https://wiki.step-project.com/Guide:BAE https://wiki.step-project.com/Guide:BSA_Extraction_and_Optimization https://wiki.step-project.com/Guide:XEdit https://wiki.step-project.com/Guide:Wrye_Bash https://wiki.step-project.com/Guide:Skyrim_Launcher (maybe) https://wiki.step-project.com/Guide:Mod_Organizer https://wiki.step-project.com/Guide:NVIDIA_Inspector (maybe, not "just" a modding tool.) Potential future guide to be added to the list : NMM (mmh, "potential") Mator's Merge Plugins Mator Smash SpINI I'm opening the discussion here instead of jumping in as it'd imply moving several guides I haven't anything to do with, and I'm not even sure how to properly create a new sub-category :3 Also, I'd like to take this opportunity to say that the "guides" pages kinda suck imho (this one https://wiki.step-project.com/Category:Guides), in the way that it isn't really convenient for users to look for guides they'd be interested into.

All of the NPCs UNO edits are already present in the game if I'm not mistaken (it doesn't add any new one). So oyu can : 1) Merge UNO With all of its masters 2) Copy all of the NPCs records into a new plugin 3) Delete all the NPCs records from the original merge This way you'll have a plugin with everything but the NPCs changes, and and other one with just the NPCs changes. Not 100% of the reason why you would do this, but since it look lie this is what you're trying to do.

I finally got around lying down what I knew about basic record structure, which was the main thing that refrained me on going further into the xEdit guide. This is in a separate guide about plugins files : https://wiki.step-project.com/Guide:Plugins_Files Wouldn't mind a technical (zilav ?), visual (tech ? DY ? Hishy ?), and grammatical (Grant ?) review on this one. The third section is mostly containing placeholders right now, I'd just like to explain in here some specific things that have to be kept in mind when working on plugins/load order. I got a bit carried away when writing the thing about reference so it doesn't make much sense.

I think he want do make a list of every key with their id, so he'd like to copy the whole content of the key group in the left pane without having to go through individual records. @tecknomage : Right click on "Key" in the left pane and select "apply script", and choose the . In the script, locate this line : AddMessage('Processing: ' + FullPath(e));and replace it with this one : AddMessage(IntToHex(FormID(e), 8)+' '+GetElementEditValues(e, 'Full - Name')); Click OK (you'll be asked to save the new script, choose a name and save it). The list you want will be printed in the "Messages" tab, from there you can copy paste it. Edit : @Zilav, uh, FormID(e) no good actually, how do I cast IInterface to lwbMainRecord ? Edit2 : Ah, and FixedFormID instead of FormID would probably be better actually. Edit3 : Nevermind, fixed it, the cast error was about cardinal to string. Edit @Tecknomage : Keep in mind that the console isn't supposed to be a cheat engine but a developer tool (or it'd be available on console as well). I doubt you'll break anything with just adding keys to your inventory (however, using them to open quest-related door will probably screw the whole quest if done at the wrong time), however several "cheat codes" will just break your save on the long run, especially on FO4.