TESTING Icy Mesh Remaster (by Bionic)

[Mousetick]

1 hour ago, z929669 said:

Rules File - I would use IcyFixes.esp (ESL flagged ESPFE) and not the ESM (unless some of the records are fixing LR bugs, which IDK):

No, no and again no  It should be a master plugin (ESM). There is not any good reason to prefer a patch plugin (ESP) over a master plugin (ESM) when adding or overriding a large number of references, large or not. It can be provided in 2 variants: lite* (for all users except those upgrading from previous versions due to renumbered Form IDs) and full* (for users upgrading from previous non-lite version).

IcyFixes override a few large references. Being ESM avoids LR bugs. I know DynDOLOD has LR workarounds, but not everyone uses DynDOLOD or the workarounds. Being ESM also potentially allows it to declare new LRs for some of the references it adds, which would be nice - it currently doesn't AFAIK.

Sorry to be ranting and harping on about this, but we've already talked about these plugin differences at length already. Why exactly do you want ESP[-FE], what are the reasons that make it better than ESM? Following your (unknown) reasoning, Landscape and Water Fixes is wrong to be a master plugin (ESM) and should be released as as patch plugin (ESP) too? I'm sorry but that's nonsense

(*) lite = ESL-flagged and/or .esl extension, full = .esm extension, not ESL-flagged

[z929669]

5 minutes ago, Mousetick said:

No, no and again no  It should be a master plugin (ESM). There is not any good reason to prefer a patch plugin (ESP) over a master plugin (ESM) when adding or overriding a large number of references, large or not. It can be provided in 2 variants: lite* (for all users except VR users, or users upgrading from previous versions due to renumbered Form IDs) and full* (for VR users, and users upgrading from previous non-lite version).

IcyFixes override a few large references. Being ESM avoids LR bugs. I know DynDOLOD has LR workarounds, but not everyone uses DynDOLOD or the workarounds. Being ESM also potentially allows it to declare new LRs for some of the references it adds, which would be nice - it currently doesn't AFAIK.

No!  VR can't use lite plugins.

Sorry to be ranting and harping on about this, but we've already talked about these plugin differences at length already. Why exactly do you want ESP[-FE], what are the reasons that make it better than ESM? Following your (unknown) reasoning, Landscape and Water Fixes is wrong to be a master plugin (ESM) and should be released as as patch plugin (ESP) too? I'm sorry but that's nonsense

(*) lite = ESL-flagged and/or .esl extension, full = .esm extension, not ESL-flagged

As I understand it, VR supports ESPFE due to it's file extension even though it doesn't support the ESL flag itself, so it's a good compromise for plugins supporting SSE and SSE-VR.

Also, I did qualify my assertion. From my post:

Quote

I would use IcyFixes.esp (ESL flagged ESPFE) and not the ESM (unless some of the records are fixing LR bugs, which IDK)

... that's precicely why I qualified my statements. I wanted to double check if it really should be ESM. I got no issues with that, but what you're saying does imply that most mods should be ESM if they touch any outdoor landscapes ... most of them don't use ESM but rather ESP.

Reason to prefer ESP over ESM? Freedom to prioritize via plugins.txt rather than restricting to early in the LO. That's all.

That said, I'll modify my post accordingly.

[Mousetick]

54 minutes ago, z929669 said:

DynDOLOD can create the LOD textures from the full ones per standards, thereby obviating any need for the MA to provide the LOD variants and the user the error-prone task of selecting the correct ones in the FOMOD for their build.

You're assuming that all users of this mod are or should be using TexGen/DynDOLOD. That's not the case.

The MA would still need to provide LOD texture variants for users who don't. They could be simplified down to one texture (e.g. glacierslab) though that will require updating the LOD models. Currently the MA uses several LOD textures file names (e.g. glacierslab + glacierpillar + iceberglarge + ...) which are all the same texture.

[z929669]

3 minutes ago, Mousetick said:

You're assuming that all users of this mod are or should be using TexGen/DynDOLOD. That's not the case.

The MA would still need to provide LOD texture variants for users who don't. They could be simplified down to one texture (e.g. glacierslab) though that will require updating the LOD models. Currently the MA uses several LOD textures file names (e.g. glacierslab + glacierpillar + iceberglarge + ...) which are all the same texture.

That's a good point I hadn't considered. Simplifying to a single texture does make good sense, since textures bloat files more than other assets.

[Mousetick]

9 minutes ago, z929669 said:

As I understand it, VR supports ESPFE due to it's file extension even though it doesn't support the ESL flag itself, so it's a good compromise for plugins supporting SSE and SSE-VR.

You're right. I've corrected my post accordingly.

[Mousetick]

11 minutes ago, z929669 said:

Reason to prefer ESP over ESM? Freedom to prioritize via plugins.txt rather than restricting to early in the LO. That's all.

I get your point but loading this type of mod early is actually desirable, so that other mods (99% ESP) which need to move/resize/disable the same references are more likely to override it without special care. If it were an ESP the MA would need to advise users to load it early, to avoid issues with other mods.

In case of conflict, the best outcome is obtained by resolving with a patch anyway, in which case the relative order of mods or early/late position doesn't matter one bit.

[z929669]

8 minutes ago, Mousetick said:

I get your point but loading this type of mod early is actually desirable, so that other mods (99% ESP) which need to move/resize/disable the same references are more likely to override it without special care. If it were an ESP the MA would need to advise users to load it early, to avoid issues with other mods.

In case of conflict, the best outcome is obtained by resolving with a patch anyway, in which case the relative order of mods or early/late position doesn't matter one bit.

Yeah, I get it and see the value of ESM for anything at all touching landscapes or objects inherent to landscapes (like mountains/ice/glaciers but not so much plants/trees or most various other objects I'd speculate). Prioritizing later is usually not wanted. However, we traditionally solved this via LOOT masterlist submissions.

[CorneliusC]

Are there maybe any installation recommendations for using this mod within the STEP guide as an alternative to 'Glacier LOD Meshes'? Thank you.

[Mousetick]

1 hour ago, CorneliusC said:

Are there maybe any installation recommendations for using this mod within the STEP guide

This should be a good baseline:

On the optionals page, the only important choice is the BDS-compatibility 'Important plugin'. The other options are TBD. 

[CorneliusC]

4 hours ago, Mousetick said:

This should be a good baseline:

On the optionals page, the only important choice is the BDS-compatibility 'Important plugin'. The other options are TBD. 

Fantastic, thank you ...

Edited August 11, 2023 by CorneliusC

[z929669]

This got another significant update. FOMOD changed and no longer any Just Ice patch (not sure what it was patching in the first place).

We also have a cube map being overridden from this mod if it's installed alphabetically, so need to test with/wo hiding this file:

Wiki instructions updated

[Mousetick]

The Just Ice "patch" and other ice texture "patches" didn't patch anything, they were pre-made LOD textures for the LOD models provided by this mod. Now all LOD textures must be generated by TexGen and the LOD models of this mod have been updated to use those textures.

The cube map from this mod should win. Everything from this mod should overwrite everything else (except TexGen output) in order to look as it should.

[z929669]

This mod is still a confusing mess to install. Supposedly, IMR2 is coming, so I'm removing this from consideration until the MA can provide something clearer and less volatile. I've no doubt it's a good mod, but it's just too confusing and volatile for us to consider for 2.3.