pStyl3

Are you guys aware, that Cipscis ported his CASM - Cipscis' Automatic Save Manager mod over to Skyrim? Might be worth checking out, seeing as it is a valuable mod for the Fallout games.

wrinklyninja has uploaded LOOT 0.7.1 as the new official version! Bethsoft Forum Download - GitHub

- Source I am really looking forward to Fallout 4 and everything around it.

Alright. Just installed 1.3.7, found no major quirks so far. I think, there might be some oversights regarding the changes to the portrayal of the redundant flag, though. First, when MO 1.3.7 launches, it will look like this for the moment. That changes (at least it seems so to me) when the modlist.txt is saved, so it's no big deal, but it looks a bit funky nonetheless. Second, was it intentional, that mods that are disabled in the left pane are also getting flagged as 'redundant'? Aside from that, nothings going wrong for me so far, LOOT, xEdit and PatchusMaximus work. Thanks!

Alright, that is understandable. That said, the current behavior can lead to a certain, small confusion aswell. Let's say you have three mods. Mod A Mod B Mod C All three contain the same file, thus the file from Mod C wins. If I view the conflict tab of Mod C, I will see that the files of Mod A and Mod B will get overwritten. If I look at Mod A's and/or Mod B's conflict tab, I will see that the winning file is provided by Mod C. The thing is, the new conflict colors will always provide me with the information of all conflicting mods, if I click of Mod A, Mod B and Mod C will be highlighted red .. but if I then go into the conflict tab of Mod A, I will not necessarily be told, which file of Mod B conflicts with Mod A. I experienced that today. I was (finally) cleaning out all the redundant files between my different 'Optimized Textures' mods. Through the conflict colors I could see, that there was one pair of conflicting files left between 'Vanilla Optimized' and 'HRDLC1 Optimized', but neither checking the conflict tab of the one, nor of the other, revealed to me, which files were conflicting (since aMidianBorn was winning the conflict). Since both 'mods' contain a lot of files, it took me a couple of minutes to manually find the conflicting files. I managed it, but yeah. A possible way to handle this, could probably be to show all files that are winning over the currently viewed mod and making the actual winning mod bold (or something similar). But I understand your reasoning aswell Tannin (and thus you're desire to let it be as is), clearly pointed out conflict winners are very valuable information.

Screenshot #1 - Screenshot #2 Please have a look at the two screenshots above. Each of the following mods, which contain the two files .. cuirasslight.dds cuirasslight_n.dds .. are present in my left pane: test1 .. Unmanaged: HighResTexturePack01 HRDLC1 Optimized .. aMidianBorn Book of Silence - Armors .. test2 I noticed, that if I open the 'Conflicts' tab of 'test2' (screenshot #1) all mods above 'test2' are correctly being displayed in the 'The following conflicted files are provided by this mod' window. However, if I open the 'Conflicts' tab of 'test1' (screenshot #2), it is not the case that every mod under 'test1' is going to be displayed in the 'The following conflicted files are provided by other mods' window .. only the very last one. Was this a design choice, or would this rather be a bug?

In case you do not want to have the silently installed 'Windows 10 notifications', one thing to mention would be this: How to uninstall KB3035583 – The Windows 10 Downloader for Windows 7 and 8.1 If you uninstall the windows update KB3035583, this little new icon will be gone.

Thank you both for this awesome update! Small typo in the changelog: Appplied AOS' ...

I just installed the newest version of True Storms - Thunder and Rain Redone. It appears, that it still has the old version number attached to it (1.4, while it now should be 1.5), so I went ahead and opened it's information window in MO's left pane. The thing is, when I now select the 'Nexus Info' tab, MO stops working and it gives me the 'No Response' error. Can somebody else replicate that?

There are indeed messages displayed on screen. Have a look at this post from schlangster. I tested case #2 earlier this day for myself already, and it's working great. Edit: A bit further down he also said this:

SKSE has been updated to version 1.7.3. Source Whatsnew: - added SpawnerTask for batch PlaceAtMe with positioning (see SpawnerTask.psc for details) - fixed chance of ModEvent/UICallback instances failing if the game was saved+loaded between their creation and execution - added Spell.GetEffectMagnitudes/GetEffectAreas/GetEffectDurations/GetMagicEffects - added ObjectReference.GetContainerForms/GetReferenceAliases - added WornObject.GetReferenceAliases - added Form.GetKeywords - added StringUtil.Split - added Utility.ResizeArray - added Actor.ResetAI (similar to console function) - fixed ActorBase.GetIndexOf* - fixed Utility.CreateArray initialization with empty Forms/Aliases - added support for skse.ExtendData(true) to enchanting/alchemy/smithing/crafting menus - added Ingredient/Potion/Scroll/Spell.GetIsNthEffectKnown/Magnitudes/Areas/Durations/MagicEffects - added Quest.GetAliasById/GetAliases - fixed Armor.ModArmorRating to disallow underflow - added FormList.ToArray/AddForms - added experimental GameData functions - TreeObject and Flora accept general forms as produce - added diagnostic messages that help detecting the cause of common crashes or problems. (1) Shows which masterfile is missing when the game CTDs on startup. (2) Lists the missing files in the removed content dialog when loading a save. Both are disabled by default; to enable them add this to \Data\SKSE\skse.ini: [General] EnableDiagnostics=1

Sorry for the late answers. Far too much to do in too little time. Good advice, unfortunately people often have stopped providing information, once they found out that the --single-process argument successfully bypassed their problem. But I will still try to gather information, as always. Thank you. So UAC is not a problem on your end and you are still getting the blank screen, even if you start MO the normal way. Hmm .. does the problem still occur for you, if Steam is not running in the background (so without Steam running, open MO and then try to run LOOT without the --single-process argument)? Do you automatically login to Nexus, if MO is started? And how many entries/plugins do you have in the left and right pane? Does the situation change, if you start LOOT from within MO with a vanilla profile (in MO)? If I recall correctly, I have verified the blank screen bug with all MO versions since 1.2.14 (and most of LOOT snapshot builds since Alpha 4 .. I believe). Regarding the --single-process argument, I recall wrinklyninja saying, that it has something to do with the quality of font rendering (but no guarantee on that).

Wrinklyninja couldn't fix the issue until now, nor is it the case that you 'are doing it wrong'. It is simply the fact, that the issue is pretty hard to come by. For example .. 95% of all the time, I am personally 100% able to trigger/reproduce the blank screen through starting MO via downloading a mod priorly. But then again, at certain times, I am no longer able to reproduce it with that routine, whatever I do the blank screen will not trigger (or with other words, suddenly my chance to trigger the issue is 0% all the time). To my knowledge, wrinklyninja has to this day not been able to reproduce the issue even once. But as said and laid out, GrantSP and me were (and are) able to reproduce the blank screen at will. What this simply means is, that there are still missing variables and factors regardings the exact reproduction steps for the issue. Even on my system something seems to change every now and then, something I am surprisingly not aware of even after all this time, which 'fixes' the issue temporarily for me and stops me from reproducing it. I've had that now a few times already (and believe me .. I tested a plethora of things). Right now, I am back to the state where I can reproduce it at will. @ TechAngel Great to here that adding the --single-process argument worked .. but to be honest, I expected nothing else. That argument has proven it's ability to bypass the blank screen over and over again. Just for the sake of it .. where do you have Skyrim/MO/LOOT installed to?

The blank screen bug is discussed in this issue on Tannin's bugtracker, and the replication steps for it (well, to some degree), were discovered by GrandSP and me here. In short, if you start MO through a download and then want to start LOOT from within MO, LOOT's UI is occasionally blank. It also seems that this sometimes happens to people, who have Steam/Skyrim/MO/LOOT within the C:\Program Files\ folder, which is, as we know, a through UAC rights-restriced folder. In any case, adding the --single-process argument to LOOT within MO's 'Modify Executable' window should stop the blank screen from happening (I did verify that here back in December 2014).

I have updated from 1.3.4 to 1.3.5 using the packaged archive and did not encounter this problem.

As sheson said, those Unknown: 15 lines are expected. In any case, I noticed that this particular windmill isn't displayed correctly, while looking outside from within Whiterun: https://abload.de/img/1ktqti.jpg https://abload.de/img/2afpz0.jpg The other two (screenshot #2) on the other hand are displayed correctly.

Updated to DynDOLOD 1.26, rechecked for errors. XEMI record errors are indeed gone. Thank you once again.

Alright, thank you. One more thing, I checked my loadorder through with xEdit's 'Check for Error' function, this came up for DynDOLOD.esp. Is there something I can do about those? And I also found 5 ITMs within DynDOLOD.esp: Removing: SKHFApiary "Apiary" [CONT:190264D0] Removing: DBTortureVictimContainer3 "Hollowed-Out Rock" [CONT:00064922] Removing: DBTortureVictimContainer1 "Hollowed-Out Rock" [CONT:0006491F] Removing: DIntGate01 [ACTI:03003D68] Removing: DragonMoundBase [ACTI:000CAF75] [Removing "Identical to Master" records done] Processed Records: 37458, Removed Records: 5, Elapsed Time: 00:00https://abload.de/img/itm_1d3lgk.jpghttps://abload.de/img/itm_2rez31.jpg https://abload.de/img/itm_3lpxr4.jpg https://abload.de/img/itm_4muz46.jpg https://abload.de/img/itm_5u6bky.jpg

First time using DynDOLOD, thank you sheson and everyone else involved for this amazing project. I am using .. - MO 1.3.4 - xEdit 090515 - DynDOLOD 1.25 DynDOLOD.esp is last in my loadorder. My output folder for DynDOLOD is not inside an rights restricted folder, nor within MO's virtual file system or Steams folder, and I am using the High Preset setting. Overall the first results looks very promising. Take a look at the following images (first one is always with DynDOLOD activated, the second one with DynDOLOD deactivated): https://abload.de/img/1_1k2u71.jpg https://abload.de/img/1_2lwuoj.jpg https://abload.de/img/2_177unf.jpg https://abload.de/img/2_2xhuwx.jpg https://abload.de/img/3_1aouon.jpg https://abload.de/img/3_2l2ukq.jpg https://abload.de/img/4_1n4uaz.jpg https://abload.de/img/4_2f4umo.jpg https://abload.de/img/5_1pzuik.jpg https://abload.de/img/5_2utk9g.jpg That said though, I've got a few questions. Is it absolutely necessary, that DynDOLOD.esp should load last, and therefore even after a Bashed Patch? Or does that not matter? Furthermore, it seems that DynDOLOD has no entry in LOOT's masterlist.yaml file .. currently, the latest beta snapshot of LOOT, 0.7.0 Beta 4-65, places DynDOLOD (in my case) like this: ... - iNeed.esp - Prometheus_NSUTR Falskaar Dock.esp - Alternate Start - Live Another Life.esp - DynDOLOD.esp - Pre PaMa WAFR Patch.esp - Bashed Patch, 0.esp - PatchusMaximus.esp Do you see a problem in that sheson? And should LOOT's masterlist.yaml therefore get an update for DynDOLOD, according to your opinion? Then, running DynDOLOD using the High preset takes with my 106 plugins (DynDOLOD.esp manually put at the end of the loadorder, "Have MO manage archives" unticked within MO, plugins loaded via "Shift + OK" within TES5Edit) 24 minutes and 17 seconds. What about these messages in my TES5Edit_log.txt: Should I worry about those? TES5Edit_log.txt and LODGen_log.txt are here. Thank you once again.

You might want to read my small, german Was ist ein Bashed Patch tutorial. Everything should be outlined there aswell. :)

Regarding compatibility patches between free (e.g. AOS) and paid mods (e.g. Purity). How about adding a statement to the free mods' description/FAQ like this: "Q: Can you make a compatibility patch for this particular to-be-paid mod X (e.g. Purity)? A: That depends. If you want a compatibility patch between our mod and that particular to-be-paid mod (e.g. Purity) then please head over to Puritys Steam Workshop page and ask the author of said to-be-paid mod, to send us a free version of his/her mod. If he doesn't want to, there will be no compatibility patch, as we will not go around and buy mods to then create compatibility patches for them. It's all up to whether or not the author of the to-be-paid mod sends us a free example or not." Something like that would be a clear position and whether or not you will be able to create a compatbility patch (in case you want to in the first place, of course) all depends on the authors of to-be-paid mods.

Quote of behippo, author of SKSE Source

This is the first line.<br> And this the second line. Third and last line.

No problem, glad that I could remind you of this.

Did you create a SKSE.ini file in ..\Steam\SteamApps\common\Skyrim\Data\SKSE\.. ? Content of the SKSE.ini should be: [General] ClearInvalidRegistrations=1 [Memory] DefaultHeapInitialAllocMB=768 ScrapHeapSizeMB=256 [Display] iTintTextureResolution=2048