FEEDBACK v2.0.0 - Feedback & Bug Reports

[z929669]

On 5/20/2022 at 6:30 PM, Mousetick said:

In vanilla, horker tusk is a misc item (clutter junk) while in CACO it's an alchemy ingredient. You can't add vanilla horker tusk to your inventory even with console commands because it's automatically converted by CACO to CACO horker tusk.

From the sticky post at the top of the CACO compatibility page:

Standard Hearthfire workbenches produce vanilla objects from vanilla recipes with vanilla components which are patched by CACO, so they work transparently. Hearthfire Extended workbenches produce custom objects from custom recipes with vanilla components which are not patched by CACO, so they need the above workaround.

Yes, it should be easy to fix in the STEP CR patch so that HFE recipes use CACO components if applicable.

I have made the following change to the DEV patch to resolve this. Anything else?:

[Mousetick]

4 hours ago, z929669 said:

I have made the following change to the DEV patch to resolve this. Anything else?:

As far as I can see the Horker Tusk is the only component that needs patching, yes. But! If I'm counting right there are 4 HFE recipes using Horker Tusk:

KmodTrophyRecipeHorker
KmodBYOHHouse1BasementMainRecipeHorker
KmodBYOHHouse2BasementMainRecipeHorker
KmodBYOHHouse3BasementMainRecipeHorker

So much duplication!

It's strange that there is no HFE-CACO compatibility patch available on Nexus, not even an unofficial one. Both have been around for a while and HFE is pretty popular.

[DoubleYou]

Last I checked, the maintainers were hard to work with in regards to patching. 

[z929669]

7 hours ago, Mousetick said:

As far as I can see the Horker Tusk is the only component that needs patching, yes. But! If I'm counting right there are 4 HFE recipes using Horker Tusk:

KmodTrophyRecipeHorker
KmodBYOHHouse1BasementMainRecipeHorker
KmodBYOHHouse2BasementMainRecipeHorker
KmodBYOHHouse3BasementMainRecipeHorker

So much duplication!

It's strange that there is no HFE-CACO compatibility patch available on Nexus, not even an unofficial one. Both have been around for a while and HFE is pretty popular.

Thanks, I failed to search 'Horker' in xEdit so will address those as well.

[callmechewy]

Hey there, quick question because I managed to confuse myself when looking through the DynDOLOD_sse.ini file for fun...

When running BethINI and using the High setting, uGridsToLoad defaults to 5.
For the final step (in the Custom tab), we set uLargeRefLODGridSize to 11.

In the DynDOLOD_SSE.ini file, I noticed this section referring to both of those settings:

Quote

; Because Bethesda simply does not comprehend people are modding exterior worldspaces ...
; set to 1 if uLargeRefLODGridSize=5 (value of uGridsToLoad) in SkyrimPrefs.ini, do this if it is certain that the large references system will not be used, so that no DynDOLOD.esm is created
; set to 0 if uLargeRefLODGridSize>5 (value of uGridsToLoad) in SkyrimPrefs.ini
IgnoreLargeReferences=0

Does changing uLargeRefLODGridSize to 11 override the uGridsToLoad number from the previous tab, or are they separate?
The line seems to be saying that uLargeRefLODGridSize should be equal to the value of uGridsToLoad...right?

[Mousetick]

43 minutes ago, callmechewy said:

Does changing uLargeRefLODGridSize to 11 override the uGridsToLoad number from the previous tab, or are they separate?

No. They are separate. Each has its own value and function. uLargeRefLODGridSize must be greater or equal to uGridsToLoad, and must be an odd number. uGridsToLoad must be 5. So uLargeRefLODGridSize can be 5, 7, 9, 11, ... with 11 being recommended.

43 minutes ago, callmechewy said:

The line seems to be saying that uLargeRefLODGridSize should be equal to the value of uGridsToLoad...right?

No. It says if you set uLargeRefLODGridSize to the same value as uGridsToLoad, that is 5, then you should set IgnoreLargeReferences to 1, so that DynDOLOD doesn't need to process large references and generate a dedicated ESM plugin for them. Strongly advised against.

[callmechewy]

31 minutes ago, Mousetick said:

No. They are separate. Each has its own value and function. uLargeRefLODGridSize must be greater or equal to uGridsToLoad, and must be an odd number. uGridsToLoad must be 5. So uLargeRefLODGridSize can be 5, 7, 9, 11, ... with 11 being recommended.

No. It says if you set uLargeRefLODGridSize to the same value as uGridsToLoad, that is 5, then you should set IgnoreLargeReferences to 1, so that DynDOLOD doesn't need to process large references and generate a dedicated ESM plugin for them. Strongly advised against.

Great explanation. Thank you for clarifying that for me!

[FendisKhan]

Atlas Map Markers SE - Updated with MCM no longer has a "main file" called Atlas Map Marker - FISS Version. on NexusMods. There is such a file in the "old files" section, however.

[ButchDiavolo]

17 hours ago, FendisKhan said:

Atlas Map Markers SE - Updated with MCM no longer has a "main file" called Atlas Map Marker - FISS Version. on NexusMods. There is such a file in the "old files" section, however.

Yes, Kryptopyr is removing the FISS versions of all their mods for some reason. But they are in the old files section.

[Mousetick]

1 hour ago, ButchDiavolo said:

Yes, Kryptopyr is removing the FISS versions of all their mods for some reason.

Too many compatibility issues and crashes  Some mods bundle old versions of FISS scripts, causing conflicts and instability. Furthermore, it's been found that it can't cope with multiple mods accessing configuration files simultaneously (such as when starting or loading a game). Last but not least, it's not "officially" supported with AE (Skyrim 1.6.x).

It's the right move to dump it, in my view.

I recommend using the Settings Loader series to add the auto-load/save settings feature to MCMs lacking it. Many popular mods are covered.

The modern and reliable replacement of FISS is MCM Helper, on which the Settings Loader series is built.

[z929669]

I agree that we need to look into moving to this new system and away from FISSES as more and more mods support it.

[cpin1]

im using the 4k step guide, so all of my settings are what step recommends for 4k, i use all optional mods too. i do however use enb performance instead of heavy because even with my ryzen 5800x, 32gb ram and 6900xt i still get like 30-45fps on heavy whereas performance looks great with much better framerates.

embers xd comes with a couple of drawbacks. one is the look can be extremely inconsistent with the rest of the game, more noticable in helgen during the dragon attack and windhelm in the civil war questline. disabling embers xd has made the game look acceptable while retaining a more vanilla feel.

the other drawback is looking at some light sources can cause the game to go into slideshow framerates, which is why i had to uninstall it. i'm not sure what caused the frame dips, i didn't see anything in the guide that would fix it, but help on that would be nice. i'm still going to keep it uninstalled because it makes some scenery look really out of place.

while quickly speedrunning the main story to check if all that worked, i had to look up why irileth didn't appear for dragon rising, and realized the culrpit was "not so fast." it turns out that isn't so much a natural fix for the pacing of the main story, but more of a timegate. the problem i have with it is it doesn't let you know "hey come back in 6 days"

i guess if you have the mod you're expected to know it already, but i think for STEP that should be avoided since it can cause confusion and doesn't really change the quests to naturally have better pacing, but just adds an artificial timegate to stifle progress in that questline, making it inconsistent with the vast majority of the game.

[DoubleYou]

It's the Particle lights that cause the lights to go to slideshow framerates. 

[z929669]

For Helgen to look correct, check the options in Embers for "Disable Helgen glow" ... toggling this on/off will give you the look you want I think. As DY mentions, disabling particle lights and possibly using the "Optimized" setting in Embers FOMOD should give you better performance.

[TechAngel85]

On 6/8/2022 at 9:42 PM, cpin1 said:

while quickly speedrunning the main story to check if all that worked, i had to look up why irileth didn't appear for dragon rising, and realized the culrpit was "not so fast." it turns out that isn't so much a natural fix for the pacing of the main story, but more of a timegate. the problem i have with it is it doesn't let you know "hey come back in 6 days"

i guess if you have the mod you're expected to know it already, but i think for STEP that should be avoided since it can cause confusion and doesn't really change the quests to naturally have better pacing, but just adds an artificial timegate to stifle progress in that questline, making it inconsistent with the vast majority of the game.

You can find all the timing from that mod in its ReadMe. However this particular part is here:

Quote

  * Six days after giving Farengar the tablet the journal entry "I wonder if Farengar has made any progress on his Dragon research." will appear. Ireleth's scene about the first dragon sighting will start the next time the player visits Farengar.

See the mod's page on how to configure the mod's settings to change. I have no idea why they removed the MCM over this odd config setup, but they did.