z929669

Just wondering if crafting overhaul and weapon fixes would make sense to override Requiem. I am thinking so, but don't know enough about those mods to say for sure. You may want to read over the Requiem manual to see what that mod 'fixes' and if it meshes well with your philosophy. My guess is that you provide more thoughtful changes, since you are more specifically focused and Requiem takes a more general approach. Same goes for better stealth for followers, clothing fixes, etc. Requiem-type users are likely more drawn to your mods, so determining if they desirably modify Requiem along compatible directions may open up your mods for use with Requiem users. Requiem crafting is pretty basic, but allows for deconstruction of metallics into ingots in a balanced way (there is significant loss of material). Crafting anything in Requiem is not even possible without acquiring a crafting manual and the necessary skill to use the tools in the most basic way. More advanced smithing requires even more education. The details around making it harder to craft (and hence, enhancing the attractiveness of achievement) are well covered by Requiem, but the specifics of crafting would benefit from your mod I suspect. This is the general trend. Requiem fixes Skyrim by making it more rewarding to achieve, but it could benefit from a fine tuning that many of your mods could provide.

You must have not included something or something was corrupted. The DLC contain more than just textures, so if you unpack, you need to verify. Activate the BSAs and delete the extracted non-texture folders if those are extracted. The extracted textures will override the BSA textures.

No need to rush this either. A fair decision can only be made with plenty of in-game review of each overhaul. This takes hours. If we don't make a decision now, we can always accumulate data for a future release. Need testers and their input and reviews!

Problem is stylistic consistency though. Same texture artist usually has similar style and consistent results. Not always though. Anyone care to test texture mixing in game, picking best of each and showing the results?

AMB has great interior floors and good everywhere else. I also like SRO, particularly from a distance. I am ultimately very impressed with VL exteriors though. That is the only mod that has exterior stone that appears weathered and constructed from the endemic stone with weathered look/snow (not sure if this always applies though). Problem is that indoor stone walls should be same as outdoor (at least shape-wise). Need persons who have played in-game with each to comment.

https://www.nexusmods.com/skyrim/mods/43107/? Creating for MT forum.

d'oh! :facepalm:

As long as you follow the guide and properly create the Bashed Patch and have no mod issues, yes. Requirements: CellStabilizer (Stable uGrids)ENBoost (ONLY the following needed): d3d9.dllenbhost.exeenblocal.ini (ignore all other settings, they have no effect) UsePatchSpeedhackWithoutGraphics=trueFPSLimit=42.0 (optional)[*]sheson's patch (recommend Neo's version in the OP for now) Please report back how much RAM and VRAM you have (and CPU/GPU brand/architecture) as well as if there is any difference you notice during play. Load times (game startup, indoor/outdoor transitions) will be increased due to enbhost process memory manager and increased asset load time, but it is well worth it.

The 2k (complete) version is probably slight overkill, and the optimized version uses 2k textures for interiors but 1k for landscape. the torrent description details the diffs. I would recommend optimized version (it is linked in both the STEP Guide and SR:LE Guide.)

The log is under my docs > my games > skyrim > skse

Serious does the best job with the road texture ... better blending and resolution. A couple of other gems from that one, but that mod also does some strange things here and there.

hmmm i've got a decent rig with 32bit os,i5 2500k non-oc, 8gb ddr3 1600, msi gtx 660 2gb non-oc, and w7 32bit ( i patch the kernel so it can utilize my 8gb ram, but the application is still limited to 4gb max ) .. i use around 150mods, HD texture mix 1k and 2k, ugrid7, realvision enb lite.. with default setting of 512 block1 size and 256 block2 .. it ran smooth without safety load .. and i think my loading time between maps is faster now.. i'll report here if i found something new.. ;) 32-bit should be limited to more like 3 GB RAM per process; however, ENBoost obviates this restriction even on 32-bit I would think, since it offloads from TESV.exe as a separate process. As long as you have the system RAM, I thnk that 32-bit arch should benefit Someone that knows more about MM should confirm/deny though. Basically, if you can confirm any difference in your fully-modded gameplay (uGrids=5 [default]) between (create a save looking over the bay at Solitude, pan 360): No MM mods activeOnly ENBoost activeboth ENBoost and sheson's MM 3.0 activeas above but at uGrids=7 and Stable uGrids (CellStabilizer) activeJust report any CTDs or ILSs Based on shesons last response above, it would seem that whatever is allocated in the INI to the MemBlocks is still available, since this is not technically "Committed" under VMMap, but you should leave this at default (use the version in the OP attachment) or possibly reduce if you run out of memory (which you won't since you have enough. Are you using ENBoost?? That should prevent this. Sheson's method will prevent ILS and maybe some CTD, but not stutter.

Landscape textures are really tough to compare in screens (thanks SRB!). These are so big, that they really must be seen within the context of the larger environment. That said, I don't think that SRTO will work in most situations (a few seem quite applicable though). I like Serious and AMB in most situations and even one or two HRDLC win for me. I'll need to see in game before I say for sure though.

@SRB Thanks again for all the great compares! This one is very simple for me: Telvanni Reborn wins in almost all cases except for a few of the HRDLC versions. SRTO is way too much a deviation. I will venture that all of their textures will be too 'experimental' for STEP. TR it is I think. We may want to opt for keeping a few of the HRDLC though. SRB, do you want to pick which HRDLC should be retained over TR and we can add the notes to the mod page (if it even exists ... create it if you want and add your recommendations for excluding certain textures from the MO mods folder.

Nice work SRB! Thanks a TON for doing this. (agree that we need other contributors in this area) All in all, I think SRO stays the most true to vanilla; however, most of the AMB versions suit my taste. In particular, the interior floor is spot on. I also like the flatness of the AMB versions ... masonry rock should not have any shine or brightness in most cases. A tough call to be sure. May as well see the VL stuff as Neo says though.

I posted on the Nexus about a Requiem patch ... does that make sense?

WOW. uGrids 17 seems very stable. walking around outside of Windhelm and fast traveling back and forth to Solstheim, no issues at all. My frame rate is really not suffering either. This is quite playable! Private bytes to both MemBlocks still does not exceed 470/210 for me ... did I mention uGrids=17?? I really don't think that there is any need to bump up the default settings applied by sheson. This patch combined with ENBoost (which is really brilliant) and Stable uGrids mod are all together a viable solution to all the past two or more years of Skyrim bugs and glitches. Problems solved, IMO. @sheson You should post this patch on the Nexus or work with SKSE, ENBseries folks to package everything into a single solution (yeah, right ... that would make too much sense). @all else Need persons with lower-end rigs to test this for any buggy games. STEP needs to know if/how well this applies to 32-bit architecture or RAM/VRAM-limited 64-bit systems. This will all go into the STEP 2.2.8 guide, which will be released in the next couple of weeks.

@keithinhanoi I am no expert with VMMap, but I have played with it quite a bit. You can save the PID and reopen as long as the process continues to run. You can even look at the timeline of Committed (which is not very useful for our purposes, since it combines all allocations). I see no way to log anything. Unfortunately, Alt+Tabbing kills the process when I try to return. Probably something to do with ENBoost, but not sure. As I said though, I have been many places in game and have never had more than 450/200 allocated to the blocks in question. I am attempting higher uGrids (greater than 11) now, so will report back if I see any big increases in block allocation.

UPDATE: In continuing to test out a number of independently-patched versions of skse_steam_loader.dll, I am finding that they do not all work the same way (and some not as advertized). Also, in further testing the version that Neo uploaded, I have found that I actually can run Neo's version posted earlier on this thread with MemBlock settings higher than 512/256 using a different save game and mod setup (STEP:Core 2.2.8), so the patch may have save-game dependencies as well as mod dependencies ... or even Windows session dependencies in my case. Anyway, do not assume that the patch you are using is working as you think or intend: Launch VMMapLaunch Task ManagerLaunch Skyrim (skse_loader.exe) via MO or any other methodQuickly select the TESV.exe process in VMMap (Ctrl+p) before the game launchesLoad up an intensive savegameAlt+Tab back to VMMap and hit F5 to refreshClick on the "Committed" column header to sort descending (see above graphic)The first two Address nodes should correspond to MemBlocks 1 & 2, respectivelyNote the bit values under the "Private WS" column header (convert to KB by dividing by 1024^2)The skse MemBlock INI settings should be about 10-25 KB higher than indicated under "Private WS" (assuming that this is the max allocation)I will update the OP with this info for anyone that cares to test and report back ...

Are you using Neo's version or sheson's or your own? Also, the graphic following shows how to check how much memory should be allocated. I am running at uGrids=11, and the default of 512/256 is still more than necessary. My numbers reveal that 420/200 is all that is needed even at this demanding level.

STEP 2.2.8 release should be more clear and simple to follow ;)

This is true in my testing. Steps corresponding to standard KB blocks need not be used. I believe that this will work fine in 4 KB increments ... even 2 works, since we are ultimately dealing with bits (also see my previous post on this)