Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    Are you saying that all of the actual game files at .\Steam\steamapps\common\GameName can be deployed in this way? Many people would like this for maintaining 1.5.97 and 1.6.xxx, but this will only be useful until the modding community catches up over the next couple of months (hopefully). I do like the idea of using this for ENB. Then it would make more sense for me to use it for things like SKSE and SSE Engine Fixes (since I already use an ENB manager anyway).
  2. z929669
    Thanks for posting and the additional info. I think we will simply run some of these in our personal setups and see how it goes. The pitfalls I mention are in regards to updates to these MO plugins if/when MO updates are not backward compatible for said plugins. The default plugins bundled have no issues, since they are maintained my the MO devs, but third-party ones could create problems if creators go AFK. There are a number of potentially interesting plugins that I have hesitated to try (and become reliant upon) for this reason. I'm sure some of us will test drive and ask questions if we have them.
  3. z929669
    I can see how this would allow one to increase variety when applied to references or to circumvent patching for a given conflict. Seems very powerful, but I agree that it adds a significant layer of complexity to keeping track of things, but that wouldn't seem to be an issue if configured for a specific build (i.e., guide level) ... user customizations to a build would likely be at least as tricky to manage as plugin conflicts/dependencies. I wonder if it affects load times or if there are other drawbacks when hundreds (or more) of swaps exist in the setup.
  4. z929669
    You will need to generate your grass cache with your mods under 1.5.97 and then use that to gen LOD under 1.6.xxx against (nearly) same mod list. Otherwise, you must wait for .Net FW for NGIO under 1.6.xxx
  5. z929669
    It's here! For SSE 1.5.97 No Grass In Objects is required with grass cache, which depends upon .NET Scrip Framework, which is not yet updated to SSE 1.6.xxx DynDOLOD is not limiting grass LOD for SSE 1.6.xxx, NGIO is.
  6. z929669
    Yep, I agree you are replying within the understood context. I guess I am just suggesting that @anonymouselbow install SKSE, SSE Engine Fixes, and SSE Display Tweaks. These don't really mod the game per se with assets but rather with respects to some very basic script fixes for a more stable game. I would also recommend installing USSEP for a near-fully vanilla game with all baseline fixes applied.
  7. z929669
    Using SSE Display Tweaks resolves the 60 FPS soft cap on havok issues. You can run well over this limit when using this mod. Using only this mod with SSE Engine Fixes and SKSE over vanilla should resolve.
  8. z929669
    Nice follow-through @TechAngel85 and Mousetick. I think this may meet the bar now if the others agree.
  9. z929669
    Yes, that's what I had thought I implied just previous (and @Mousetick before me) ... book.swf from this mod is required to use this mod's fonts, and it doesn't seem to be decoupled from the softer text by overriding the FO Realistic Print option, because that feature is specifically being implemented by that mod's bood.swf. It looks like the rest of FO is implemented by books.swf.
  10. z929669
    AI followers are typically very annoying in all games I have played (certainly all Bethesda games). I avoid using them altogether unless I have to.
  11. z929669
    Letting book.swf override FO's by setting FO's to hidden produces exact same result as if not installing the "Realistic Print" option. This mod's INI is tied to book.swf. FO also includes books.swf, but that obviously is how FO is setting custom fonts. Installing the Realistic Print option is what provides book.swf from FO, which claims to do this:
  12. z929669
    Using the default DynDOLOD_SSE.ini, quality is not correlated with the numbers. In fact, sometimes higher quality is evidenced by lower numbers (Level0 vs Level1 for example). Billboard4 can be better than Billboard1, but it depends. Billboard1 and Billboard4 are probably better than Billboard2 in more situations for example, and all are probably better than Billboard6. Billboard4 theoretically costs more in FPS, but it really should not be detectable. The real gain is in using any Billboard in object LOD as opposed to Level0/1/2 LOD models. If using Billboards in LOD4/8, we recommend using Billboard4, but I'm fairly certain that sheson would say that Billboard1 will usually be just as good. I expect he may comment to set the record straight. Probably best to direct readers to my questions on this exact topic with sheson's responses. Begin reading at the post linked, and the follow-up questions/answers:
  13. z929669
    I will agree to disagree on this one. My eyes are worse than all of yours besides Greg, and I find it more pleasant to read with the 'softened' font. I really don't think it's softened enough to say it's blurry, and I don't think the ink looks smudged in the least. I still vote for this one, but if Tech and Greg disagree, then I am overruled.
  14. z929669
    So are you all for this one if we use the Realistic Print option from FO? This should fix the blur issue whilst maintaining the other features of this mod using the suggested settings I posted further back a bit.
  15. z929669
    Just wasted 30 minutes troubleshooting why I couldn't start a new game ... this is required to avoid CTD at startup on my rig. Instructions updated to clarify.
  16. z929669
    All of these Kezyma MO plugins are interesting, but the pitfalls seem huge if we came to rely on them.
  17. z929669
    No idea about the benefits (or pitfalls) of this one. I never noticed an issue either. If there is an issue, we may also want to consider DAR
  18. z929669
    I'm highly skeptical that this will be simpler for us to maintain. If someone cares to test it and discover any kinks or pitfalls (e.g. game updates or anything else that could obviate or otherwise break this method), I'd be willing to try it. I personally use "ENB and ReShade Manager" and have also tested "ENB Manager". The former is a bit harder to use and figure out, but it's more robust. I wouldn't want to support use of either tool in our guides though. Much simpler to use current manual instructions, IMO.
  19. z929669
    Yeah, that's what I mean. Both options seem desirable to me.
  20. z929669
    I hadn't noticed, but yes, it's fuzzier in my screens than it is in game (where it was a real improvement, IMO).
  21. z929669
    If you are using the latest version of RWT (5.x), there is nothing to fix. This is just a warning to verify you don't see artifacts of the large-reference bug in SSE and that it has been accounted for properly by this plugin (which it is). All such warnings are just that. Most other mod authors haven't made the changes as RWT has made in it's most recent version though. PS: I rarely see an issue in game for most of these situations, even if they are valid. Sometimes, there are visible issues in game, so having the warnings is a good thing.
  22. z929669
    I think if we use the Realistic Print option from FO, this might resolve for you guys. I personally prefer this mod's fuzzier text though, since it looks more like printed text.
  23. z929669
    Added to wiki, ModList, etc.
  24. z929669
    For LOD, the dead trees are just not working correctly, due to texture mips and possibly alpha. I have tried everything with no luck. Even with assistance from T4, sheson, and kojak747
  25. z929669
    Thanks. Tag changed. Added to wiki, ModList, etc.
×
×
  • Create New...

Important Information

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

  I accept