z929669

It is also no longer available on Nexus. These sorts of mods have always been a bit hit/miss in terms of whether or not they work as expected for a given user, since OS settings can impact (and SKSE/controller configs). There are some old Reddit posts on this particular mod not behaving as expected.

'Installers' are needed to install mods. To me, they are a 7z archive containing a FOMOD or a folder structure conforming to Bethesda file-path standards. Do you mean BAIN installers? MO doesn't care as long as the mod's folder structure is standard. BAIN installer folder structures conform to standards. There is likely a MO plugin for BAIN Wizards, but I never saw the need. FOMOD is the current standard, and BAIN can be installed using MO's installer helper with drag/drop. Do you have an example of what you are trying to do? Wrye Bash should be run as an MO executable in order to properly generate the Bashed Patch based on your load order. This is a bit tricky to set up as I recall, since WB is launched via a Python launcher. Moved Topic into MO support forum

So you are running strictly vanilla with not a single mod? If that's true, then it's probably something to do with your display driver settings or INI settings. Use BethINI as we recommend and see our Display Settings guide. Directly from the description I linked: 1. You cannot overwrite mods that add bulbs with mods that add more bulbs because then you'll have an insane amount of bulbs and tons of flickering. 2. You can overwrite mods that add bulbs with mods that edit lighting colors. 3. You can overwrite mods that edit lighting colors with mods that only edit indirect lighting (for example, if you wanted to use a darker ambient lighting mod) Luminosity: edits lighting colors RS: adds bulbs, edits lighting colors ELE: edits lighting colors ELFX: adds bulbs, edits lighting colors, changes tons of objects to help reduce flickering created by excessive bulb placement NAT: edits lighting colors All other weather mods: edits weathers and will not conflict with interior lighting mods This likely addresses your problem.

I meant that if you check your level via settings, you can use that to subtract a past level from a current level ... but yes, the point is to not know or care. Just like you don't really measure experience in real life, even though you get better with practice.

Doh! I edited my previous.

No worries, I didn't realize you were attempting to help out. I thought you were trying to install your own hybrid of Step 1.0.0 and 2.0.0. This forum is open to the public, so best to add you to a forum role that will allow you access to more resources for helping out (including the dev forums for 2.0.0). Posting here only invites onlookers to want to use the dev guide ... and ask more questions. This is who I am talking to when I mention that we don't support the dev guide. We may wind up locking this topic to avert that if necessary.

I'm sure you can find mods that attempt to fix the bounty system in a number of different ways. Most fix obvious bugs, but some go further.

Your lighting configuration is not configured properly. Too many incompatible mods that mess with bulbs in the cell you are testing. This mod's description has some helpful notes.

Subtract? The following may be redundant advice. I missed that it pertains to Survival mode where not seeing leveling may be the point, as in Requiem (in which case, you are not supposed to know!): Pay attention to your 'level' progress indicator. Sleep as soon as it maxes/ Otherwise, you will not know unless you subtract from pre-sleep level.

LOL ... that article is pure "ad phishing". Scavengers/parasites create a bunch of useless and generic 'support' blog posts to trick search engines into propagating them via SEO in a sad and annoying attempt to capitalize on ad clicks.

I already mentioned in my last posts that NET FW does not work for 1.6.xxx ... We do not support questions on 2.0.0, because it's all under development, and that includes any version-specific mod instructions or patches. You can use the guide "as is" and figure it out for yourself. We welcome feedback in support of development but not the other way around. Yes, and this is why I really dislike it when MAs redundantly have the version in the file name. That's what the file description and changelog are for. I fixed this to be more agnostic of this pitfall.

Obviously, OS security isn't 'off'. A simple search would yield you the following topic. This topic is redundant:

You said SSE Engine Fixes was hidden ... it's available now. Yes, it should work, but my SAE build is dead, so there is some other SKSE plugin voodoo going on now with last SSE update. And another is coming. NET FW is needed for NGIO and grass LODGen. Not needed for anything else really though. It probably won't be ready for some time still. Also check that your game updated fully. I had this issue, but it didn't fix. I'm just taking a break until the dust settles. Working on meshes and mod updates as they come in the meantime.

Please look at the sticky in this very forum and search if that still doesn't tell you what you need to do.

As explained a great many times in this forum, it's your AV and windows OS 'protections'. You will need to perform the steps outlined in several posts in these forums. See sticky posts and/or search these DynDOLOD forums. The answers are littered all over the place multiple times.

You cannot run .NET FW in 1.6.xxx ... this is the big one that is taking the longest to update, since it must be rebuilt from scratch I think. SSE Engine Fixes is probably hidden while it is updated to latest 1.6.342 (or possibly waiting for the purported forthcoming 1.6.xxx). So you need to run without those two mods for now. No grass LOD in SAE for weeks or months still.

As I recall, I think @TechAngel85 made changes to such records in Realistic Water Two 5.0.0 to do just that (-90,000 I think) ... not sure about any necessary changes to the models though. I cannot check until later this evening, but if you have validated this or care to do so, please let us know if that's the case.

Tagged Accepted, added to ModList/changelog/etc.

Tagged Accepted, changed to Post-Processing, added to ModList/changelog, etc.

OK, now I understand. So to wrap this up for onlookers: DY's comment is accurate, but I was wrong about the reason why, because I hadn't considered the mesh rule for fxwaterfallbody and there being no LOD4 defined. Dynamic LOD, being a different LOD system will still show in Near/Far Grid overlapping with LOD4 but not as part of LOD4 ... so no NO waterfalls will be in the *.bto of LOD4 and will NOT show at all between approx. 43,008 gu and fBlock0distance value. In that case, I think we should simply be customizing our own fxwaterfallbody mesh rule to define static LOD4 and not lowering any of our Terrainmanager settings (which seems would be irrelevant). Waterfalls will then have Dynamic LOD that I must assume will override the Static LOD defined in LOD4 and allow the static LOD to render in between max Far Grid and fBlock0distance value if greater. Do correct me if I am still mistaken. Thanks

Yes, it's just odd that this MA would choose that format and place into the DDS container ... unless this is considered a modder's resource. Maybe the MA didn't want to risk degrading the source texture (or the source is also uncompressed, but I doubt that). Either way, this doesn't bother me or anyone with plenty of VRAM and drivers that manage it efficiently .... but I think it's bad practice, particularly for landscape textures.

So Dynamic LOD is only potentially active within the Near/Far Grid as shown, and this has nothing to do with display of Static object LOD or [Terrainmanager] distances. DY's comment above about NO waterfall LOD (Dynamic or Static) beyond Far Grid but within fBlock0distance is or is not true? If true, are you saying that this only applies to "the 3 waterfall types" in SSE and NOT all other object LOD (so *.bto meshes are shown, but somehow the waterfalls stitched into them aren't rendered?)?

If it's DDS, it's almost always compressed. I suppose it can be uncompressed, but that's just odd. BC7 is expected. Maybe it's not a square texture? I like this mod as a solution to these issues. I would question its permissions/validity were it not nearly two years old now, so I assume starac has given at least tacit permissions to the MA.

Tagged Accepted nd added to ModList

I have been churning this phrase over in my mind, and would like more clarification, especially in light of the below posts implicitly referencing this. For reference: So ... Far Grid / 2 * 4096 = distance of dynamic LOD in game units To clarify my understanding (or lack thereof): Distance from Player is assumed. Since player is in center, that is why we divide by 2. Cell width = 4096 gu. This measure assumes the perpendicular (a/b), and the oblique is c2 = a2 + b2 (according to Pythagoras) Dynamic LOD appears (starting) either in Near Grid or Far Grid, depending on mesh and any other rules governing. Does this mean that if defined in Near Grid, Dynamic LOD will only 'animate' (or otherwise behave dynamically) when the object is between approx. 2.5 and 5.5 cells away from Player, and if defined in Far Grid, between approx. 2.5 and 11.5 cells away from Player? Before the minimum of these respective ranges = animated (or otherwise dynamic) full model? After the maximum of these respective ranges = static LOD? Defining Dynamic LOD in Far Grid is better quality at cost of performance (due to larger potential range of Dynamic LOD)? IF so, then for an object with mesh rule defining Far Grid... because fBlockLevel0Distance = max of LOD4, then Dynamic LOD objects will render as such between 10,240 gu and 43,008 gu (but only if fBlockLevel0Distance ≥ 43,008)?