Jump to content

z929669

Administrator
  • Posts

    13,028
  • Joined

  • Last visited

Everything posted by z929669

  1. Be sure you have a trailing slash for the path in the EXE config in MO for the "start in" line. Also check for spaces and enclose paths in quotes if there are any.
  2. There are potentially many things that can cause this, including presense of expected TexGen output, DynDOLOD Resources conflicts, disabled mods, on, and on. You will be asked to provide the log files mentioned in the OP and forum rules of this topic to resolve and avoid guessing.
  3. Special chars are almost always an issue in the programmatic dependency chain. I didn't know Windows allowed these chars (Although, I do know it allows ampersand, which is also a problem).
  4. DynDOLOD Version 3.00 Alpha 59 DynDOLOD.exe - unset some problematic flags on copied base records used for dynamic LOD DynDOLOD.exe - added dynamic flag to mesh mask rules DynDOLOD.exe - added principle support for base record swapping via _SWAP.INI DynDOLOD.exe - fixed a case of not creating an overwrite for material shader added by ESP DynDOLOD.exe - fixed a case of wrongly applying mesh mask rules without VWD flag and existing LOD model DynDOLOD Resources - updated/added meshes for better compatibility DynDOLOD Resources SE - updated/added meshes/textures for better compatibility
  5. Have you tried updating LOOT and rebooting? If you still get this, you may want to check your OS security, firewall, and AV logs.
  6. This sounds like a winner for my own game when I finally decide to play again for real (once Requiem is fully compatible). I love a good and deep quest line. Sounds like some plugin fixes or patching may be in order though.
  7. So the first issue of BOS breaking LOD Looks as if sheson is aware and making forthcoming changes to account for BOS
  8. I agree and have modified the instructions likewise for the time being. We had been skipping trees from this mod originally anyway, and I assumed it was for the LOD problem.
  9. I split the mesh LOD discussion topic from this to a new topic in the dev admin forums so taht we don't go OT here more than necessary.
  10. we shouldn't be using the 'Trees' fix. It will break the DynDOLOD for those trees unless I create models specifically for FML. Same is true for The MA should be made aware, so I will do that. Looks like EVT LOD will also be nullified. What exactly is this fixing anyway? The AA meshes have always looked fine to me. PS: We also need to keep this in mind for any DynDOLOD Resources and mention to sheson if any are affected by this or other mesh replacers.
  11. I will make a note about this on the FML page -- we shouldn't be using that fix. It will break the DynDOLOD for those trees.
  12. I updated the mod page accordingly. This is user preference, but 'Autumnal' is most vanilla friendly.
  13. Yes, I love Requiem and have been basically not playing the game until this overhaul is fully compatible with SSE. It changes SSE into a much richer and vastly more complex RPG that will add hundreds of ours to a given playthrough, IMO. I will definitely support a SSE guide around Requiem (probably would need to be unofficial though, as this completely breaks the Mandate). I'm aligned mostly with all of you on these predicted directions but don't want to spend an hour posting my own nonsense
  14. @DoubleYou has VR I think, so he may be interested in curating a VR guide that aligns mostly with our SSE guide at some point.
  15. Bumping this. I think we should be using both optional files. CACO Cleaned Textures - BC7 format textures instead of uncompressed DDS True Fortify Effects for Magic Skills - this make fortify magic effects consistent with other CACO fortify effects and should apply to Odin if I am interpreting that mod correctly (scales spell strength according to skill level)
  16. But this mod has an all-in-one option that applies to Step, which should be our guide requirement anyway (all DLC CC content required). This way, it's just like USSEP and what we've been saying applies.
  17. ... so it is written, and so it shall be done. I expect that this will be well maintained. If Garthand steps down, someone else on the USP team will probably pick it up again without delay. Krypto's patches could be more of a headache, but no more than updating each of the 20+ patches as they change (and guide instructions). I will begin doing this in the patches I'm working on and see where it goes.
  18. In looking more closely at the changes, I agree. We may need to look at the falmer temple chandelier and solcairn meshes though. I'd say to install the loose files rather than the FOMOD Updated instructions accordingly
  19. Agree. It's not a fix. It's an interface modification. It's also additionally an 'Extender' strictly speaking, but we have already agreed that any extender-format mod with a singular purpose that associates its impact with a given ModGroup should be placed into that ModGroup ... so again, 'Interface'.
  20. Yes, I agree that small patches for this that and the other thing are significantly burdensome for both us (creating mod pages and mods in the guide) and guide users (downloading/merging dozens of small patches). I would rather consume them into our patches. But this mod is different. It will ultimately patch all CC content for the USSE patches and any mods that are considered foundational by the community. I'd rather rely on all the USP patches and 'consume' the one-off patches into ours (e.g., kryptopyr's patches are a good example. That mod is a PITA to install and set up ... and it's instructions maintenance). Same goes for all of the other little patches we have accumulated thus far in the current iteration. I'd prefer to use this mod though and forego all related Step patching. I'm also inclined to place this one into Foundation for the same reason we do so for the USSEP (so that the guide can be tested early in the guide install with all relevant CC patching in place).
  21. I have been wanting to look at that one. Maybe we should consider it?
  22. Sorry, I'm still unclear: Do you want to use this mod or not? If we use it, you still want to replicate the USSEP patches from this mod into our patches? That's what doesn't make sense to me. I know they are already there, but I have been removing them in my current work. I can easily revert these changes, so I don't mind that and could use the extra work to become more familiar with these patches ... but I hate redundancy unless it's functionally necessary. May as well keep our patches as simple and light as possible. I assume that if this mod is doing all necessary CC patching (or will eventually, and will always patch USSEP), we don't need to forward any CC content at all into our patch. We only need to potentially forward some of this mod's patches into our patches.
  23. Do we agree that SS should override LFfGM? If so, then LOOT masterlist should be updated.
  24. We will probably need to test some of the changes to see if we still need to hide the same files or not (depending on the install method, since there is now both manual and FOMOD it looks like).
  25. Yes, thank you ... I keep forgetting this. So are you saying that that you prefer to only use this mod (USCCCP) to forward it's patches into ours and not actually use this mod in the guide lineup? This would be fine based on this mod's permissions. If we DO use this mod, then it doesn't make sense to use any of the records this mod forwards over the USSEP in the Step patches (unless they need to be forwarded past some other plugins in the guide).
×
×
  • Create New...

Important Information

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