keithinhanoi

I would not classify steveley's suggested merge as (very) "easy". Most of those patches include NavMesh overrides, and so after merging them, the NavMesh Info (NAVI) record needs to be deleted from the merged patch, and rebuilt in CK. But loading the merged patch in CK requires temporarily changing all of its masters into false-flagged .esp plugins (so set as a master, but still with the .esp file extension so the merged patch recognizes them.) This is because CK will only load one .esp plugin - everything else has to be a master. Once you've got that all set up, you load the merged plugin in CK, and then save it. To be on the safe side, I also add the .bsa files of any of those master plugins in CK's .ini file, but CJ has already said this is not necessary if you are only rebuilding the NAVI record. Not re-building the NavMesh will result in problems with NavMesh connections and "doors" from one cell to another. This has already be brought up in this thread (start reading from my post here.), and is highlighted in one of missjennabee's very informative forum thread stickies for ETaC. I don't want to scare people off, but if you're getting these patches to fix conflicting NavMeshes between mods, and then don't rebuild the NavMesh Info record, you're kind of shooting yourself in the foot.

Upscale, filters, change a thing or two is definitely NOT what the author of this retex has done. Fair enough if people don't like the color or material changes. If you're looking for something a little "sharper" but very very true to the HD-DLC originals, then I would take a look at Gamwich's Bethesda Performance Textures - Armor - Clothes - Weapons. Get the BPT_2K_ALL optional download, but it's just the armor variants for the DG set, not the boots, helmets or shield.

Um, that's the whole point to the mod, to improve the lighting as much as possible while still keeping the vanilla look. For those who want the lighting to be more "realistic" or "fantasy"-inspired, then RLO or ELFX are the first choices to try.

Well, I just got the message of the day, and if MO v1.3.x is still considered in beta testing, it should be stated directly and clearly, considering MO has a good number of non-English native speaking users. The idea that MO v1.3.x is only implied in the third section of the MO message of the day I've just received: That's enough for me to understand that I should no consider v1.3.2 a "stable release," but it could state this much more directly.

I seem to remember, back before I starting modding Skyrim and when I was still running it on a HDD, choosing a save in the Load Game menu being slow when I had lots of game saves. Now, even though I'm running on an SSD, I make a it a habit to move save files or delete them so that there are never more than 10 in the saves folder for that profile in MO. Honestly, I find it difficult to believe that the Flora Repawn Fix script could be solely responsible for slow downs in the Load Game menu, since all kinds of mods add to the size of the save files, as I mentioned already. Sounds like it's time for testing!

Note that USKP and even vanilla Skyrim itself employs a number of scripts that store lots and lots of data in your save game. Use either of the save game "cleaner" utilities on a game save some hundreds of hours in, and you will see this. Can you explain what you mean by "sluggish" in the main menu? Is it slow when you are choosing which game save to load, or is the initial loading screen when you choose the game save / hit "Continue game"? Anyhow, despite my previous cites of game save size and number of script instances, it would be much better to do testing with comparisons before deciding this script in particular adds "too much" data or slows down the main menu.

Sorry to continue steering this off-topic discussion, but I would recommend installing Mangaclub's mods using MO's built-in FOMOD installer, regardless of the version of MO. The external FOMOD installer has always had the issue of no displaying the option group headings (known as plugin groups in the XML code for the FOMOD), and that is also true for older versions of MO, including 1.2.18, and as far back as I can recall (more than 18 months.) So, I'd recommend going in to MO's setting menu, setting the internal FOMOD installer to be used, and the "preferred" way to install FOMOD-installer based mods.

I'm still here! Okay, so I've downloaded the variant of Conditional Combat Music that you're working with, aaltair, and re-installed Requiem 1.8.1.1 (sorry, my internet is just too slow to wait for 1.8.2 - and I figure it's probably nearly the same keyword-wise, anyhow.) First off aaltair, do yourself a favor and download and install at least the newest public release version of TES5Edit, which is 3.1.0, straight from its Nexus page here. Or better yet, download the latest developer release from the TES5Edit WIP thread on AFK Mods, using the link available in the OP of that thread, here (currently at svn1930). Yes, the developer releases could be considered potentially "dangerous", but zilav has had a really good track record on stable subversion releases. Now, back to your matter at hand. I matched your load order, and pulled it up in TES5Edit. The first thing I notice, even without applying a filter to show conflicts, is that all of Delaric's keywords are black text on white, as seen here: This means they are all unique - in other words, they are only supplied by the Conditional Combat Music plugin. Requiem doesn't have any Music Type or Music Track edits, so all we have to worry about are the 8 Race records that CCM edits. Let's take a look at one of those - the Dragon Priest Race. I don't often use the Hide no conflict rows feature, so I've just scrolled down a little to show all the relevant edits between CCM and Requiem that we need to worry about. Here it is, with the important bits circled: In this case, we want the override compatibility patch plugin to have both the keyword added by CCM and the keyword added by Requiem, plus the three original ones defined by Skyrim.esm. But there's that MagicNoReanimate keyword from USKP - what about that, right? Did Requiem intentionally remove it, or did USKP add it after this version of Requiem was released, or did the author of Requiem just no incorporate USKP fixes? We can do a bit of investigating by following the MagicNoReanimate keyword to see where it's used. To do that, hold down the control key and hover over the name of the keyword. You'll notice as you hold down the control key, any displayed entry with an associated FormID under your mouse cursor will be underlined. All you have to do is click on the entry, and you'll instantly be taken to the record of that FormID. So, control-click on MagicNoReanimate [KYWD:0006F6FB]. That takes us to view the MagicNoReanimate keyword record itself, which is pretty boring, but if you click the Referenced By tab under the right-hand pane, and then click on the File column header to list all records referencing the MagicNoReanimate by plugin name, we can check if Requiem is using the keyword elsewhere, as seen here: As I've pointed out, there's another Race using the MagicNoReanimate keyword which is edited by USKP, sol let's check if it's also edited by Requiem, to see if the keyword is removed or not. I double click DLC1UndeadDragonRace "Dragon Race" [RACE:03117DE] to go view the record, and here it is: Unfortunately, it doesn't tell us what we need to know, but we can see that Requiem isn't removing the MagicNoReanimate keyword from other races. So it's time to make a personal decision. The USKP decided that your player or other NPCs should not be able to reanimate Dragon Priests using magic. If you agree with that, then bring that keyword over as well. Once you've decided about that, then you start making your override (compatibility) patch plugin. You should have noticed in the second of the screenshots above that in addition to the added keywords, Requiem makes changes to the Starting Health / Magicka / Stamina, Base Mass, and Health Regen stats for the Dragon Priest Race. This means you'll want to select the record in Requiem.esp to make the override, and while viewing the record, the best way to do this is right-click on the name of the plugin at the top of the column with that plugin's edits to that record, and select Copy as override into... In this case, I'm right-clicking on [XX] Requiem.esp (XX being the load order number), and copying the override into my new plugin, and then drag over the two other added keywords from USKP and CCM. When you drag the CCM Keyword over, you'll get a message about adding CCM's .esp plugin as a master, which is fine so click OK. And here's the new override patch plugin with those three added keywords brought over into the patch plugin: A good thing to point out here is that although everything is showing up as grey text on light green background or green text on light yellow background, remember that seeing those supposedly "good" colors is NOT our goal. The goal is to get the right mix of edits in any record override in our patch so that all the mods have the correct / desired functionality. Essentially, for the other 7 race records that are edited by CCM, you need to do the same process. Decide what needs to go in the override plugin, copy override from Requiem.esp into the new plugin, and drag over the edits you want to be combined in the patch. Just from looking at them myself, I get the sense that there are some USKP fixes that either happened after the last release of Requiem, or the author of Requiem didn't worry about incorporating those USKP fixes. One example is the Uses Head Track Anims flag that USKP adds. This must have been done because Dremora do have the ability to do head tracking (they turn their heads to look at your character or other NPCs.) So in this case I would drag that edit into my patch. Also looking through those Race record edits, I'm pretty sure I found one mistake in the CCM - Most Epic plugin. There was no added keyword for the Frost Atronach race, so I added the same keyword to it that is used for the Storm Atronach race record, ActorTypeDaedraGreater. The way to do this yourself is to view the Storm Atronach race record, click on the ActorTypeDaedraGreater [KYWD:xx0012CA] entry in the column for CCM - Most Epic, and then press Control-C to copy that entry. Next, go to the Frost Atronach race record, copy override from Requiem.esp into your patch plugin, and then right-click on the KWDA - Keywords row in the column for your patch plugin, and select Add, like this: That will add a blank NULL - Null Reference keyword entry to the list. Finally to paste in the keyword that you copied, right click on the NULL entry, select Edit, and then type Control-v to paste in the correct keyword info. Hit OK and it's done. Besides all this, there's one Dawnguard added keyword for the Spriggan Race which Requiem doesn't use - DLC1WerewolfFeedExclude. The name of the keyword should make it clear what it's use is for, so you can decide whether you think Werewolves should be able to feed on Spriggans. Since Requiem.esp lists Dawnguard as a master, I have to assume that keyword is intentionally removed by Requiem. If you want to look at the override patch plugin I made based on my explanation above, you can download it from here. Some other final thoughts: I noticed that even though the Mammoth, Frostbite Spider and Spriggan races are edited in the CCM - Most Epic plugin, their added keywords are not used in any of the conditions that decide whether combat music is played. In other words, you won't hear combat music when you're fighting Mammoths or Spiders. In fact, the CCM - Most Epic plugin is set up only to play combat music for races tagged with one of five keywords: ActorTypeGiant, ActorTypeDragon, ActorTypeDaedraGreater, ActorTypeDwarvenCent, and ActorTypeDragonPriest. So, the truth is that the patch plugin doesn't need the Mammoth, Frostbite Spider, or Spriggan race records, as long as Requiem.esp is loading after CCM - Most Epic's plugin. I hope that all makes sense!

Looks awesome. What about the whole per plugin include/skip record/subrecord type tags / settings thing? Will the checkbox tree settings global-only?

Hmm. I see the choices are limited. As much as I hate FB's Like button, I'd prefer the use of that here rather than the up/down vote system, if those are the only options. I'm not fond of the "Popular" star label for posts that have gone past the threshold. Can that image can be changed to say something else, yes?

Since we're being asked - I support the idea of a positive only system, as long as clearer definitions are given on what the "promotion" button means, and actually, if it can't be split into two kinds of positives - helpful and I agree, then I think the system should be removed completely. I'll just point out a few other examples and how promotion buttons for user posts work well or not to me: Reddit's Up/Down Vote: I really hate the up vote / down vote post system, because it just turns things into a popularity / personality contest. People may argue that over time / on the whole it works, but I disagree, and to me it often just becomes a reflection of the nasty nature of humans overall. Nexus Mod's Endorsement: I think Nexus' mod endorsement system is fundamentally flawed due to it being so open to interpretation. Some people hand them out like candy to kids, and others hold on to them bitterly, even telling mod authors no endorsement will be given if X is not done. An insane thing in my mind, treating an endorsement like currency. As a result some of the most amazing mods or mods with an incredible amount of work and love put into them receive a very small number of endorsements, and are sometimes as a result overlooked, as many users seem to use number of endorsements as a method for deciding what mods they should use. A very sad situation. Nexus Mods' Kudos: This system I actually quite appreciate, because they are tied to a single user, and you can either give it or take it away. I'm not sure how many people even realize there's a user kudos system on Nexus, but I honestly consider them to be some kind of measure of helpfulness or generosity of the user. I'm quite proud to have 50 of those, and do realize that people can decide to take the kudos away if they change their mind. I myself have considered doing this for one user who has started to become something of a real jerk, but for most people I've given a kudos, I really felt strongly about it before clicking that button. Facebook's Like: Ridiculous finger-twitching, worthless in its meaning and the way its used. Somebody posts about a persons' horrible death, and it receives Likes? But, for some reason, it's apparently a big part of FB's success, so they just won't get rid of / change it.Right now, STEP's up button does not have a clear definition of what it should be used for, so I really have no idea what my reputation points represent (despite my appreciation for having received them.) I also wish there was a way help users to know in general which posts in long threads are considered the most helpful, especially in threads where it wasn't a problem / solution situation (which would get a "best answer" selected, that most people would read first and maybe never get past reading to other helpful posts). So, I'll return to my two (positive) button suggestion, to give definitions, because as you could guess from my rants above, definitions are really important: Helpful button: click this if you strongly feel the post had genuinely helpful information, or you learned something new that will be helpful in future I agree button: basically, a button to replace those silly "+1" posts, already mentioned in this comments thread. But I don't think there should be a disagree button, because if people disagree, they should be typing a post to explain why they disagree, with their counterargument or different point of view.EDIT: I've reorganized my points above for easier reading, and below are some additional thoughts... I realized that I didn't mention why I don't think an unhelpful button would not be a good idea. As some people have already stated, the STEP moderators already do a very good job of addressing posts which are of an unconstructive or personally critical nature, so an unhelpful button would only be used to indicate a post with misinformation or incorrect information / conclusions. But like with my idea above about users expressing their disagreement in words rather than button clicks, I think the same is true of posts with incorrect information / conclusions. In sum, I think having an unhelpful or down vote button only serves to punish users for positing what they may have believed was correct information, or in the least make them feel bad for attempting to contribute. If a user makes a personal attack, posts spam, or otherwise violates the charter of the STEP forums, then we've already got the button for that: Report Lastly, I didn't say anything about whether I think users should be able to click the Helpful or I agree buttons I've suggested on posts made by STEP Moderators. If there are only these "positive" feedback buttons, then I think it would be fair to open up moderators to receiving that sort of feedback as well. If anyone has issues with a moderator or a particular exchange with a moderator, then they would need to take it up privately with Z. I think that about covers it. Apologies for a small wall of text.

That's really unfortunate. WB as in the Wrye Bash beta that Sharlikran is working on?

Okay, well, I get the same message that you do if I try installing from the DX9 runtime web-based installer. It was worth a try, anyhow. So, just for "fun", can you try this - Look in your Skyrim directory, in the /skyrim/DirectX10 folder, and run DXSETUP.exe You say that you've installed DX11, and I wonder where you got that? Anything after DX9 is covered in Windows updates, using the Windows Update control panel. I do know that DX11.1, the newest for Windows 7, is part of this Windows Platform Update (KB2670838). I don't know - it's possible the pirated install did something screwy with the DirectX drivers, and perhaps you need to uninstall (using the Uninstall Updates feature of the Programs and Features control panel) and then re-install them again fresh? I still find it very strange that both of the d3d9.dll based ENB and FXAA lead to the same crash, and it seems to point to a problem with the DX drivers that they hook into. If he's just trying to get ENBoost to work, with the UsePatchSpeedhackWithoutGraphics=true setting in enblocal.ini, then ENB preset is not of any concern. Even binary 0.266 should be fine.

The SKSE.ini settings are fine, and should not cause the crash on starting Skyrim in conjunction with the d3d9.dll of ENB being loaded. To be honest, I'm not sure about what traces a pirated copy would leave behind, because I never used one! However, I just noticed this from the YouTube comments: That tells me you've likely got some problem with your installed video drivers. Both FXAA and ENB hook into DirectX 9. Installing DX11 won't do any help, because you have to install each runtime version that you want your games to make use of. Somebody named thisisbleep posted about very similar problems to yours, and in the end, following my advice of re-installing DirectX 9 got everything working. Even if you've installed DX9, 10, & 11 before, you should get the DX 9.0c install package found here, and try installing it because it won't hurt anything. (If you prefer the standalone DX9 installer, it's here.) I'm crossing my fingers that this helps.... :)

LOL - OMG! I can't believe I never noticed that! Kudos to you this time, GrantSP! And thanks for the kind words.

If you know the EditorID for any record, then yes, you can search for it by typing the name in the EditorID search bar, as oqhansoloqo explained. That will just take you to view the exact record using that EditorID, like this: (For the above screen, I just installed an old copy of Requiem I had lying around, and didn't install Conditional Combat Music. A search for ActorTypeDeadraGreater didn't find anything, so it seems Requiem doesn't use that keyword at all. So I changed the example to ActorTypeNPC so you can see how searching can be done in TES5Edit.) Searching by EditorID can be a pretty slow method, depending on how many plugins you have loaded. So, another way to look for the record is to open up the Keyword records section in either Skyrim.esm or Requiem.esp, and sort the left-pane view alphabetically by EditorID - just click EditorID at the top of the left-pane column view, as seen here: Then to see a list of all records in every plugin except Skyrim.esm which refer to the record you're currently viewing, change to the Referenced by view in the right-hand pane, by clicking the Referenced by tab, right next to the View tab, as seen here: In the Referenced by view, just double-click on any entry in the list to view that record. There isn't any "back" button in TES5Edit, so EDIT: To go back to the previously viewed record, use the "back" button in the upper-right corner of the TES5Edit window (tip 'o the hat to GrantSP for pointing that out), but I would also recommend to make sure you note the FormID of the keyword, because using the search by FormID bar (at the top of the left pane) is WAY faster than searching by EditorID. If you don't see a Referenced by tab while viewing any record, that just means there are no records in any plugin besides Skyrim.esm which reference it. To also see Skyrim.esm records in the Referenced by view, you tell TES5Edit to build the list. Just right-click on one of the names of a plugin in the left-hand pane, go down to the Other... sub-menu, and select Build Reference Info as seen here: You will get a pop-up dialog named Build Reference Information for: and you should just click the box next to Skyrim.esm and then click [OK]. Building the reference information for Skyrim.esm takes a little time (54 seconds for me), because there are hundreds of thousands of records to process. That's why TES5Edit doesn't do this as a default every time you run it. So every time you want to look at cross references to Skyrim.esm, you need to build the reference information as I've explained. I hope that helps!

Yes, that still fits with my findings. But that additional 128MB allocated to block 2 will never actually get used (verify by taking a look at actual block 2 usage with the Memory Block Log tool.) However, you should be able to set block 1 = 1024 and block 2 = 256 and Skyrim won't crash on starting up if ExpandSystemMemoryX64=false. The big question then is whether as a result of changing the ExpandSystemMemoryX64 setting, you notice any difference in performance / smoothness of rendering while playing.

I notice in the screen cap that in enblocal.ini you've got: ForceBorderless=true ForceBorderlessFullscreen=true Which means in skyrimprefs.ini under [Display] you would want: bFull Screen=0 If that's right, then have you tried running with "native" full screen (so set the two enblocal.ini settings above to false and bFull Screen=1)? If that doesn't work, then after you've made sure there's no traces of the non-legal copy of Skyrim on your machine, then it would be very helpful to know what settings you've got in your skse.ini file. That said, with the crash and error message happening before TESV.exe has taken control of your screen, it's weird that it would be related to ENB, because it doesn't really kick in until after the screen goes black and after the Bethesda intro video has played.

That recommendation was based on my findings. With help from hishtup, I found that if ExpandSystemMemoryX64 is set to false then Block 1 of Sheson's memory fix can be set above 512MB (in other words, setting DefaultHeapInitialAllocMB= in SKSE.ini to more than 768) without having to set Block 2 to 512MB to avoid Skyrim crashing on startup. You can read more about the potential issues with ExpandSystemMemoryX64=true in the Memory Blocks Log by Sheson thread, maybe starting with my post explaining how Sheson's Memory Blocks fix works. I'd also recommend reading through the Common CTDs, Freezes, ILS and memory issues thread as well. Just note that at least one person has reported being able to set DefaultHeapInitialAllocMB= to more than 768 with ScrapHeapSizeMB=256 in SKSE.ini and did not see Skyrim crash, even though ExpandSystemMemoryX64 was set to true in enblocal.ini Anyhow, if you are seeing Skyrim crash at startup, and have set DefaultHeapInitialAllocMB= to more than 768 with ScrapHeapSizeMB=256 in SKSE.ini, I would recommend setting ExpandSystemMemoryX64 to false.

In short "spam" is a very appropriate term, because those missing "Property LinkCustom09/10" errors' only destructive capability are in their annoyance. Even with my level 53 char some hundreds of hours in, on a rather messy load order (it has seen many updates, removals, and reordering), I still only get very infrequent CTDs, and I have absolutely no reason to believe any of them are linked at all to the running of instances of the lvlpredator script. However, as I understand it, both the USKP and steve40's fix try to address issues with the original "vanilla" at the source, because it was originally implemented incorrectly, and at a minimum is possibly wasting processor cycles and definitely producing unwanted log spam. At worst, if you read forum posts back 2-3 years ago, there were claims the original "vanilla" lvlpredator script was also linked to CTDs, though this was never conclusively proven. So yes, from my personal experience and reading up on it, I think "red herring" is the correct way to think about the link you seemed to find between CTDs and those papyrus log errors. Either way, having USKP installed would be my default recommendation where the lvlpredator script is concerned, but if also using mods that add new predators, I'd consider it wise to use steve40's version of the script from the start of a play through.

That's a shame. I will always fondly remember one of my best random fight encounters which occurred when I and my follower happened upon that pagan magical creature bonfire gathering (can't recall W&C-H's name for it) at the same time as some goblins from SIC. Just one "friendly fire" arrow hit to an attendee of the gathering - and all hell broke loose as the entire posse turned on me and my hapless follower. Talk about lighting up the night skies....

Yes, I'm aware of that update; however, it wasn't actually a change to the script itself. Part of the method of the script fix was not only to change the script itself, but also to add some keywords to vanilla creature references as well as some worldspace edits. The fix in v2.0.6 address changes outside the script itself. What I've said about the pros and cons of the two scripts still stands, based on the best of my knowledge at the moment from everything I've read on this. TL; DR - Those USKP-added keywords are actually the reason for the unwanted papyrus log spam that occurs if you switch from the USKP version of the script to steve40's. My suggested changes to steve40's script will suppress that spam resulting from the switch. Despite this, the conditions that cause those warnings are still occurring in your game, but you just won't have to read about it, which is fine because they aren't causing your CTDs. EDIT: I tried contacting steve40 via PM on Nexus, and get an error message that he "cannot receive" PMs. Anybody know if he had an account elsewhere that I can contact him by?

The only thing problematic with that message is that it fills up your papyrus log with repeats of the warning, which makes it annoying when you need to read through the log. But it won't cause errors, or CTDs. All that message is telling you is that there is a bit of data associated with a particular object that was stored in your game save file by the lvlpredator script at some point, and now the version of the lvlpredator script you are using isn't asking for that data. So what you're getting is a complaint about that. The reason why you're getting that message is that the version of lvlpredator script you were using before was supplied by USKP, and you've since changed to Steve40's version of the script. Since the aim of both methods of fixing the lvlpredator script is to get rid of annoying papyrus log errors, a good question is what's the main difference between the USKP fix for the lvlpredator script and steve40's fix? The answer is that the USKP fix is designed to work with a 100% vanilla game, but won't help with mods that make changes to placed creatures or add new ones which employ the lvlpredator script, while steve40's implementation is designed to work with both vanilla and third-party placed creatures. I've already explained this quite clearly in a follow-up post here on the Nexus Forum's thread for steve40's fix for the lvlpredator script. A better question to ask here is whether you need to look through your papyrus logs or need to have papyrus logging turned on at all. Papyrus logging only shows debugging messages that the script authors have intentionally (or in some cases, unintentionally) left enabled. The truth is that with Papyrus logging turned on, the messages you see in the log file are just a tiny minute fraction of the actual number of errors occurring. In a good number of situations, what you might think is an error as displayed in the log is actually the author's method of the script gracefully exiting its process. Most mod authors use papyrus debug messages while they are developing the scripts for their mods, and then turn those off before releasing the mod to the public. Even then, some well-known mods, such as Convenient Horses, or any of isoku's mods, will intentionally print some error messages which the authors state can be safely ignored. Those messages are there just to be helpful in confirming things are working they way they should. If you understand that, and also the fact that the papyrus engine can't output log messages at the exact moment of a CTD, then it should become pretty clear why using the papyrus log is quite useless as a tool to find out why you're experiencing CTDs. I've just checked the USKP changelist web page, the last update to the lvlpredator script was in USKP v1.3.3. Just do a search for the text string "lvlpredator" and you'll see all other references after USKP release v1.3.3 have been redacted. So, my changes to steve40's script are still necessary to remove for those who started their play through with the USKP version of the lvlpredator script, and later changed to steve40's version of the fixed script, and are seeing messages like this: 08/02/2014 - 10:30:06PM] Warning: Property LinkCustom09 on script lvlpredatorscript attached to (00081CF9) cannot be initialized because the script no longer contains that property [08/02/2014 - 10:30:06PM] Warning: Property LinkCustom10 on script lvlpredatorscript attached to (00081CF9) cannot be initialized because the script no longer contains that property As for your wondering why a separate fix apart from the USKP solution would be needed, see my explanation above with regards to the USKP fix not working with some third-party mods. Postscript: I am adamant about not sharing a changed version of someone's work without getting their permission, which is the main reason why I haven't posted a link to a copy of steve40's script re-compiled with my suggested changes. However, I've seen him posting on the comments thread of his SkyBirds mod fairly recently, so I'm going to try contacting him to get permission to post an update to his script.

reindeer51 has just released a new version of his Windhelm expansion / overhaul mod, SNOW CITY, called SNOW CITY - The Great Expansion of Windhelm. which integrates Windhelm Exterior Altered by bjs_336. Looks very interesting. Initial comments from him are that it's compatible with Better Docks, but not compatible with JK's Windhelm - though one user is saying there's just minor clipping. He's spent over 500 hours on this, so I will be giving it a try sooner or later (I am not using all of the JK's overhauls, but I am using JK's Windhelm, so I'll see first-hand about any clipping, issues).

There are two mods in STEP Core & Extended which enhance the map graphics - High Quality 3D Map and A Quality World Map. Have you tried disabling both of these and then checking if opening the map still causes a CTD? Another thing to look at is your Skyrim.ini file, in the [MapMenu] section. Did you add/change any settings there?