Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    Read my previous post again. You need to Google how to do this if the following doesn't make sense. You need to set the file-type association with Windows. This is the simplest way to achieve that, IMO. (although, reinstalling 7z by running the installer as an admin may be even better). Alternatively, you can open 7z and choose Tools > Options > System tab to set the file associations. There's also many other ways to do it. Rebooting is also a possibility.
  2. z929669
    No, you said you downloaded 7-zip. You must install it to associate it with *.7z files. Once it is associated to the 7z file type, double clicking it will open the archive in 7z rather than what appears to be Windows Edge from your screenshot. If you know you have 7z installed, then Windows prevented it from associating with its own file type, so that's why I mentioned installing 7z. Alternatively, press Shift while right clicking on any *.7z file, and choose "Open with", and select 7-zip with 'Always' checked.
  3. z929669
    Install 7-zip.
  4. z929669
    This could be the reason for your mountain issues. The Step grass is GID, not CGID.
  5. z929669
    The issue is with the loaded mountain slabs it appears. Use More Informative Console to select one of those meshes. This will tell you the plugins and textures used. Then you can look at them in the MO data tab. Also test with a new game to rule out any savegame issues if you haven't already.
  6. z929669
    Backported ESL is only a redundancy, but it's a possibility it could interfere in some way as such. Root Builder is a convenience and will only add another variable to manage/troubleshoot, IMO. Candles have particle lights, so setting particles too high via BethINI will tank performance. Try 5000-6000 if 7500 is what you are using.
  7. z929669
    Thanks for this
  8. z929669
    Unless the FOMOD options have changed, use the existing instructions. Add checking these changes to the to-do list. Very low priority for us relative to just getting the patches updated to the more/less 2.2.0 build (first step). It doesn't sound like the base tree models have been changed, so existing LOD I made should still work, but I won't know until I do a diff.
  9. z929669
    Use BethINI to set proper TerrainManager distances, or the DynDOLOD MCM. Post for DynDOLOD support in the DynDOLOD support forums. Moved post to the relevant forum.
  10. z929669
    The Step SSE guide doesn't incorporate any seasonal mods, so seasonal performance variation seems n/a. I will look at adding better CCOR and CACO compatibility with CC content and other mods once I get to that point in the new patches. It's a ton of work to be done with all the vanilla-update changes and variable new-vanilla support from third-party mods. Your CTDs probably reflect issues with the patches and new conflicts (always test on a new game rather than a savegame from a previous build). Most existing mods (even updated ones) aren't completely accounting for 1.6.1170 vanilla and UP changes ... even some of the mods maintained by our staff.
  11. z929669
    To be clear, I posted compatibility of the Sky Reflection Fix followed by compatibility of Community Shaders, so it looks contradictory the way I did that I will edit it to be more explicit.
  12. z929669
    Please re-read my previous post. There's two sentences. You addressed only the first. There is no MO problem that I know of. You more likely have your environment or MO misconfigured. Have a look at the SSG for reference.
  13. z929669
    It sounds like you may be running SSE ≤ 1.6.40 without Backported Extended ESL Support mod. You have posted on Skyrim LE support, so want to be sure that's intended.
  14. z929669
    Yeah, I'm not going to forward the 'snow' flag unless there's good reason to do so. Thanks for the update.
  15. z929669
    So my guess is that the 'snow' flag probably obfuscates what BDS is doing for places that occlude snow like under rooves.
  16. z929669
    Did you ever learn more about this? I'm trying to guess what the 'Snow' flag does. BDS and Skyrim.esm don't use it, but Update.esm added this. Wondering if I should patch it. It impacts several records, but maybe nothing of concern (in which case, i will ignore using a modGroup):
  17. z929669
    I created an MO issue to ask the MO team if this is them or something else.
  18. z929669
    First, read Nexus mod Descriptions for relevant info. Post processing is irrelevant to this fix. It applies to the game engine itself: Sky Reflection Fix COMPATIBILITY Compatible with all game versions. Compatible with everything, including ENB and Community Shaders. ENB and CS are not compatible together: Community Shaders COMPATIBILITY Compatible with 1.5.97, 1.6.1130 and VR only. (Other versions may work but are unsupported) Not compatible with ENB. This mod disables all features if ENB is present, otherwise the game will crash. It can be used as a replacement for ENB for mods that require ENB/Particle Lights. Not compatible with Shader Tools (Parallax Fix, ShaderTools Updated). Delete SSEShaderTools.dll and ShaderTools.dll. This mod includes Shader Tools functionality.
  19. z929669
    I have this folder too and am not sure what creates it: \Documents\My Games\Skyrim.INI\SKSE It seems like an alternative location for logs of some SKSE-dependent mods. The traditional location is: \Documents\My Games\Skyrim Special Edition\SKSE Notes: I deleted both of these folders from \Documents\My Games\ (Skyrim.INI and Skyrim Special Edition\SKSE). Both locations are created on launch of the game via MO but not via Steam. Only the traditional location (Skyrim Special Edition\SKSE) is created when launching via skse64_loader.exe directly from my game folder. ... so \Documents\My Games\Skyrim.INI\SKSE is created either by MO or one of the SKSE-dependent runtime mods. Google tells me nothing. When run via MO .... Content of \Documents\My Games\Skyrim.INI\SKSE: Content of \Documents\My Games\Skyrim Special Edition\SKSE:
  20. z929669
    As sheson mentioned, you don't want to rename the HLT LOD trunks, because that will yield HLT aspen trunks for the RAT aspens. This won't match the full trees. I maintain EVT, and if you install the latest version, you should have the proper LOD models for the install options you choose. EVT 2.2.2 Lush/Custom trees provide treeaspen02_353A9A39passthru_lod.nif and treeaspen02_353A9A39_trunk.nif, so these are what get installed if you choose the large RAT aspens in the installer. I recommend you remove all tree mods and reinstall EVT. Then check that the LODs mentioned are in your installed EVT. If they aren't, it's a FOMOD problem I will need to address. Installing the RAT large option should install (among others): treeaspen02.nif (with CRC32 = 353A9A39) treeaspen02_353A9A39_trunk.nif (only needed for the TexGen Render option to create billboard textures for DynDOLOD Billboard#) treeaspen02_353A9A39passthru_lod.nif (the LOD model referencing trunk textures TexGen creates from treeaspen02_353A9A39_trunk.nif)
  21. z929669
    You must post the logs as instructed in the OP. treeaspen02 with CRC32 353a9a39 does not exist in HLT. HLT uses treeaspen02 with CRC32 055a9061. TexGen will create tree billboards for whatever LOD models it finds (with 'Render' option ticked). Your aspens are probably from whatever mod is providing treeaspen02 with CRC32 353a9a39, and you likely have no billboards for those LOD meshes, because TexGen didn't find the trunks to render for the billboards. It's all a guessing game without the logs.
  22. z929669
    But they don't perfectly match the full models. This is the problem you reported. You cannot compare far away trees to near ones. Only the transition difference matters, and that will be best if the LOD models have the same NiAlphaProperty as the full ones (unless you create your own optimized crowns that are not identical to the full ones). This isn't a DynDOLOD problem. It's a problem of the LOD models not being a good match to the full models anymore.
  23. z929669
    Did you make your own 3D models for this? If so, set NiAlphaProperty of the branches to 128. This will keep all of your other changes without messing up the alpha-to-coverage problem in LOD. If you also modified the base models to your own custom NiAlphaProperty, then just leave those as you like.
  24. z929669
    Yes, we can sort it out, but that will come later. At least we have the evidence here, so thanks for that.
  25. z929669
    There's nothing special about the texture on it's face. It's a 4k atlas. Another tree, treepineforestdead04 uses the same normal and a variant of the same diffuse. I wonder if this tree has the same problem as treepineforest03 and treepineforest05. It wasn't reported but possibly just never noticed. I just want to know if the difference in LOD brightness is due to the texture or the model and what to do to fix it at the source rather than require a DynDOLOD shape flag and a taxing workaround. I cannot reproduce it, because my modding environment isn't situated for testing Veydogolt/DynDOLOD. This is why I asked sheson if he was able to reproduce. I must assume so, but the question remains. Solving the brightness issue is of interest in the short term, producing better optimized LOD models is of interest in the longer term, but beside the point.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.

  I accept