Jump to content

A Clear Map of Skyrim and Other Worlds (by DoubleYouC)


z929669

Recommended Posts

Discussion topic:

A Clear Map of Skyrim and Other Worlds by DoubleYouC

Wiki Link


Simple compare of A Quality World Map versus this mod:

Vanilla --> A Quality World Map --> A Clear Map of Skyrim and Other Worlds

vanilla.jpg AQWM.jpg ACMOS.jpg 


Vote to use this in 2.0.0 to replace A Quality World Map

Requires: Atlas Map Markers SE - Updated with MCM

Soft requirement: Unique Map Weathers Framework

Accepted for 2.0.0

Link to comment
Share on other sites

  • 2 weeks later...
40 minutes ago, DoubleYou said:

@z929669

A commenter mentioned having navigation issues with a controller. I believe you use a controller, so have/could you test this? 

I have had no issues, but I also have not loaded the map yet, since I haven't reached the LODGen phase of my setup. I will let you know though.

Link to comment
Share on other sites

  • 1 month later...

Forgive me for the stupid question: is this mod supposed to work correctly out of the box, without generating LOD Level 32 or using DynDOLOD, notwithstanding the complete lack of detail on the map?

I've been pulling my hair out trying to figure out the cause of a weird bug where low level LODs are superimposed with high level ones, resulting in a blurry flickering mess - in the world, not on the map (see screenshot below for an example). I never thought this mod could have anything to do with it, so I finally disabled it very late! After much troubleshooting and googling, I finally found the issue: uLockedObjectMapLOD=32 in 'A Clear Map of Skyrim.ini'.

Apparently there is a bug in the Skyrim engine that causes LODs not to be loaded/unloaded properly in the world when uLockedObjectMapLOD=32? As weird as it seems, this supposedly map-specific setting has nasty side-effects.

It's hard to find good information about it, I found these 2 reports which match exactly my experience:

I can reproduce it in vanilla Skyrim 1.5.97 by simply adding

[MapMenu]
uLockedObjectMapLOD=32

to Skyrim.ini.

It seems to happen more or less randomly after fast-travelling, using 'coc' in the console, and I think I encountered it too while travelling by foot or horse, but I may be misremembering. Setting uLockedObjectMapLOD to 16 (which is the default I think), or removing it from Skyrim.ini (in vanilla without the mod) or 'A Clear Map of Skyrim.ini' (with the mod) gets rid of the issue.

So my questions are:

  1. Are you aware of this issue caused by uLockedObjectMapLOD=32?
  2. Would generating LOD Level 32 and using DynDOLOD solve it?

By the way, there is a small typo on the description page on Nexus:

Quote

Maps don't look nearly as good without DynDOLOD. This can be improved by setting uLockedObjectLOD=4 in the A Clear Map of Skyrim.ini file;

uLockedObjectLOD should be uLockedObjectMapLOD. Also not sure why you're suggesting setting it to 4, wouldn't 16 work better? It works fine with 16 and adds quite a bit of detail in my experience.

Other than that, it's a great mod. Nice work :)

Thanks.

20211119171521_1.thumb.jpg.8f4aeaf18b3ec31a10f03d461966deb4.jpg

Edited by Mousetick
Link to comment
Share on other sites

Doh! I'm really stupid. :doh:

You see, I started a new modlist from scratch and I had installed 'A Clear Map of Skyrim' early as one of the first mods along with other UI and QoL mods. I wasn't intending to generate LODs and activate DynDOLOD until much later. A hundred mods or so later, I didn't remember that it installed as a FOMOD and I had chosen the DynDOLOD LOD32 option. Even though I added 'DynDOLOD LOD32' to the mod name in MO2, I couldn't remember why I put it there since there is only 1 variant of the mod to download on Nexus.

I went to read and re-read the mod instructions on the Nexus mod page, and didn't find any directly pertinent information.

Now I understand why uLockedObjectMapLOD=32. I just need confirmation that using DynDOLOD with Level32=1 will effectively eliminate the nasty engine side-effects in the world. Meanwhile I can just set uLockedObjectMapLOD=16 until I generate the appropriate LODs and activate DynDOLOD.

And if I may offer some suggestions, you may want to clarify, on the Nexus mod page, the importance of making the right choice during installation and the importance of actually using DynDOLOD LOD32 if that option was chosen during installation. Also you may want to add a warning in the FOMOD for the option 'With DynDOLOD LOD32'. And last, the warning in the FOMOD for the option 'No DynDOLOD LOD32' is a bit confusing: 'IF YOU DO NOT USE DYNDOLOD YOU MUST USE THIS FILE.' - what if I do use DynDOLOD, but without Level32=1, which option should be chosen?

Edited by Mousetick
Link to comment
Share on other sites

4 hours ago, Mousetick said:

Doh! I'm really stupid. :doh:

You see, I started a new modlist from scratch and I had installed 'A Clear Map of Skyrim' early as one of the first mods along with other UI and QoL mods. I wasn't intending to generate LODs and activate DynDOLOD until much later. A hundred mods or so later, I didn't remember that it installed as a FOMOD and I had chosen the DynDOLOD LOD32 option. Even though I added 'DynDOLOD LOD32' to the mod name in MO2, I couldn't remember why I put it there since there is only 1 variant of the mod to download on Nexus.

I went to read and re-read the mod instructions on the Nexus mod page, and didn't find any directly pertinent information.

Now I understand why uLockedObjectMapLOD=32. I just need confirmation that using DynDOLOD with Level32=1 will effectively eliminate the nasty engine side-effects in the world. Meanwhile I can just set uLockedObjectMapLOD=16 until I generate the appropriate LODs and activate DynDOLOD.

And if I may offer some suggestions, you may want to clarify, on the Nexus mod page, the importance of making the right choice during installation and the importance of actually using DynDOLOD LOD32 if that option was chosen during installation. Also you may want to add a warning in the FOMOD for the option 'With DynDOLOD LOD32'. And last, the warning in the FOMOD for the option 'No DynDOLOD LOD32' is a bit confusing: 'IF YOU DO NOT USE DYNDOLOD YOU MUST USE THIS FILE.' - what if I do use DynDOLOD, but without Level32=1, which option should be chosen?

In my experience, I have had no such issues with uLockedObjectMapLOD=32. I have even forgotten to set Level32=1 in DynDOLOD_SSE.ini and haven't experienced this issue (this just causes the map to look drab with ACMoS).

You should point sheson to your post to provide the answer, because he will have the correct information and cause for this issue. I don't think it's the INI setting that causes this but rather some other behavior/setting (or lack thereof) in conjunction with this particular setting that is the cause. I just can't recall ATM. people deleting those settings are effectively setting uLockedObjectMapLOD=16 I think.

 

EDIT: sheson's response seems to be that this might only be a problem if there are no object LOD Level 32 files and uLockedObjectMapLOD=32 . Since we should have such files with this mod (if setting LOD32 for '\' to Level0 as instructed), there may be no issue for most/all of us that follow that instruction. I also set LOD32 for all trees that aren't covered by the INI of this mod.

 

Link to comment
Share on other sites

4 hours ago, Mousetick said:

Doh! I'm really stupid. :doh:

You see, I started a new modlist from scratch and I had installed 'A Clear Map of Skyrim' early as one of the first mods along with other UI and QoL mods. I wasn't intending to generate LODs and activate DynDOLOD until much later. A hundred mods or so later, I didn't remember that it installed as a FOMOD and I had chosen the DynDOLOD LOD32 option. Even though I added 'DynDOLOD LOD32' to the mod name in MO2, I couldn't remember why I put it there since there is only 1 variant of the mod to download on Nexus.

I went to read and re-read the mod instructions on the Nexus mod page, and didn't find any directly pertinent information.

Now I understand why uLockedObjectMapLOD=32. I just need confirmation that using DynDOLOD with Level32=1 will effectively eliminate the nasty engine side-effects in the world. Meanwhile I can just set uLockedObjectMapLOD=16 until I generate the appropriate LODs and activate DynDOLOD.

And if I may offer some suggestions, you may want to clarify, on the Nexus mod page, the importance of making the right choice during installation and the importance of actually using DynDOLOD LOD32 if that option was chosen during installation. Also you may want to add a warning in the FOMOD for the option 'With DynDOLOD LOD32'. And last, the warning in the FOMOD for the option 'No DynDOLOD LOD32' is a bit confusing: 'IF YOU DO NOT USE DYNDOLOD YOU MUST USE THIS FILE.' - what if I do use DynDOLOD, but without Level32=1, which option should be chosen?

I have tested using this for quite some time now, and I have yet to see stuck object LOD. I believe that the reason behind the bug you saw is merely because you didn't have any LOD32 object bto files. That being said, it is entirely possible that using uLockedObjectMapLOD=32 could cause stuck object LOD in loaded cells. However, since you could easily reproduce the bug when missing the LOD32 object LOD files, and I have never seen the issue while using it with proper LOD32 object LOD files, I believe I can safely say that there won't be any issues, provided you generate using the instructions provided.

I suppose I could place more all caps explanations in the fomod saying that DynDOLOD users may want to use this file too if they do not set Level32=1. The map won't look as pretty, and Blackreach map will not be visible behind all the mountain LODs on the map.

Link to comment
Share on other sites

Thank you all for your responses. I'm going to generate the LODs with, and out of curiosity without, Level32=1. Will let you know the outcome, but based on your answers, I'm confident DynDOLOD + Level32=1 will solve the stuck LODs.

10 hours ago, DoubleYou said:

I suppose I could place more all caps explanations in the fomod saying that DynDOLOD users may want to use this file too if they do not set Level32=1.

May not be a good idea to PUT MORE ALL CAPS AS TOO MUCH ALL CAPS WOULD DIMINISH ITS IMPACT :)

The 'No DynDOLOD LOD32' option is the default choice, not optimal but it has no dependencies and it's safe, especially for dumb users like me who don't know what they're doing. It doesn't really need a warning, something like: "Installs INI file with object LOD pointing toward LOD16. Pick this option if you don't know what the other means."

The 'With DynDOLOD LOD32' option is for advanced users, it has a dependency on DynDOLOD and it requires special care, so it could afford a warning, something like: "Installs INI file with object LOD pointing toward LOD32. This is for users who use DynDOLOD Level32=1. DO NOT PICK THIS OPTION IF YOU'RE NOT USING OR ARE NOT PLANNING TO USE DynDOLOD Level32=1."

To be extra-safe, you could add a dependency condition on DynDOLOD's ESP in the FOMOD and disable the LOD32 option if it's not satisfied, but that may be overbearing.

And on the Nexus page, you may want to put more emphasis on those 2 installations options in the 'General Installation Instructions and Compatibility Notes' section, with a warning that using the LOD32 option without actually having any LOD32 files can have unintended undesirable side-effects.

That's just my very biased 2 cents, take them for what they're worth. I don't want to make a mountain out of a molehill, but I was really thrown off by the fact a seemingly innocuous map-specific configuration setting in a map mod can have such an effect on the overworld, which made it quite difficult to pinpoint. Without the LOD32 files, I had the fair expectation that the map would be "broken/incomplete", but I wasn't expecting at all the overworld to be broken in such a way.

 

 

Edited by Mousetick
Link to comment
Share on other sites

9 hours ago, Mousetick said:

Thank you all for your responses. I'm going to generate the LODs with, and out of curiosity without, Level32=1. Will let you know the outcome, but based on your answers, I'm confident DynDOLOD + Level32=1 will solve the stuck LODs.

May not be a good idea to PUT MORE ALL CAPS AS TOO MUCH ALL CAPS WOULD DIMINISH ITS IMPACT :)

The 'No DynDOLOD LOD32' option is the default choice, not optimal but it has no dependencies and it's safe, especially for dumb users like me who don't know what they're doing. It doesn't really need a warning, something like: "Installs INI file with object LOD pointing toward LOD16. Pick this option if you don't know what the other means."

The 'With DynDOLOD LOD32' option is for advanced users, it has a dependency on DynDOLOD and it requires special care, so it could afford a warning, something like: "Installs INI file with object LOD pointing toward LOD32. This is for users who use DynDOLOD Level32=1. DO NOT PICK THIS OPTION IF YOU'RE NOT USING OR ARE NOT PLANNING TO USE DynDOLOD Level32=1."

To be extra-safe, you could add a dependency condition on DynDOLOD's ESP in the FOMOD and disable the LOD32 option if it's not satisfied, but that may be overbearing.

And on the Nexus page, you may want to put more emphasis on those 2 installations options in the 'General Installation Instructions and Compatibility Notes' section, with a warning that using the LOD32 option without actually having any LOD32 files can have unintended undesirable side-effects.

That's just my very biased 2 cents, take them for what they're worth. I don't want to make a mountain out of a molehill, but I was really thrown off by the fact a seemingly innocuous map-specific configuration setting in a map mod can have such an effect on the overworld, which made it quite difficult to pinpoint. Without the LOD32 files, I had the fair expectation that the map would be "broken/incomplete", but I wasn't expecting at all the overworld to be broken in such a way.

We should distinguish between Level32=1 in DynDOLOD_SSE.ini and setting a value other than 'None' on the mesh rule for '\' (Level0 recommended). The latter I believe is what sheson means by "LOD Level 32 files". By default, all mesh rules are set to 'None', so you will need to set this. As mentioned, I also set 'Level0' for mushroom trees and 'Billboard6' for all other trees with 'None' at LOD32 in the mesh rule. ACMoS sets LOD32 for treeaspen and maybe others it customizes.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

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