Jump to content

z929669

Administrator
  • Posts

    13,086
  • Joined

  • Last visited

Everything posted by z929669

  1. Thirded. I feel like this mod or some other will perform this function with compatibility for 1.6.xxx at some point, but not in the foreseeable future.
  2. True, it's more dynamic, but it places the burden on the user, who will often get this wrong and claim something isn't working (more support queries). It's great for people quickly testing things before making the 'static' changes via a plugin, but still six one way and half dozen the other.
  3. I tick the middle three boxes on that FOMOD page, but I have ticked them all before. I suspect that ticking them all might be best, but I haven't gotten around to comparing the results for all fires for each of those settings.
  4. I think XD has rounded the corner and is superior now, especially since it is ENB compatible out of the box. It works nicely for Step using the install instructions we recommend via the wiki link in the OP
  5. Well that's definitely interesting, IMO. I will need to play around with the possibilities. Seems very useful for guide curators, particularly when curating multiple guides within/among games.
  6. Yeah, increasing variety as the farmhouses example or by swapping several references with alternates for a single tree if that's possible seems interesting ... but as you mention, this can also be accomplished via plugin. ESL sort of takes care of plugin limits too. EDIT: I'll bet Arthmoor et al really hate this mod and the potential support headaches it will cause them ...
  7. 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).
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. Nice follow-through @TechAngel85 and Mousetick. I think this may meet the bar now if the others agree.
  15. 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.
  16. 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.
  17. 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:
  18. 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:
  19. 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.
  20. 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.
  21. 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.
  22. All of these Kezyma MO plugins are interesting, but the pitfalls seem huge if we came to rely on them.
  23. 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
  24. 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.
  25. Yeah, that's what I mean. Both options seem desirable to me.
×
×
  • Create New...

Important Information

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