MHDT - Max Height Data

[TechAngel85]

I've been running into this a lot and would like some more information. The MHDT - Max Height Data record seems to be a record that is in constant conflict. This record conflicts from each of the DLC and with several mods which have forwarded it from one of these sources.

1. What is this record?
2. Should it be forwarded?
3. If the the answer to the above is "yes", then from which DLC should it be forwarded when all three DLCs are listed as masters?

TIA!

[oqhansoloqo]

I heard that it typically has something to do with allowing dragons to fly high enough to not clip through objects, like buildings...  That's all I know about that.

[EssArrBee]

We didn't need to forward it until the last update to CRF. All the MDHT data was added so the dragons don't clip through any added houses by that mod.

[TechAngel85]

So with a mod that has no dragons in the added area...no need to forward. Thanks!

[oqhansoloqo]

Though remember that lots of people add mods that randomly can spawn dragons - Deadly Dragons or Dragon Combat Overhaul.  Might that have an affect?

[TechAngel85]

Well, I asked specifically for a player home mod that is in a location with no enemy spawns because it's located in a custom cell. So in my case it would not be needed.

[GrantSP]

There was a discussion about MHDT records in this Nexus thread. I remember the @Arthmoor quote being used here in STEP recently.

[Mator]

I've had to deal with this in the past in regards to Merged Plugins.  Awhile ago users were reporting merged plugins causing their map to freak out/be zoomed wrong/unusable.  I investigated and found it was because of conflicting edits to the MHDT subrecord on the Tamriel Worldspace.  The Merge Plugins script resets the MHDT subrecord to the Dragonborn defaults in all merged plugins.  See Lines 1379-1391

 

It should be noted that older versions of the Tamriel worldspace record will have different subrecord definitions for the MHDT subrecord, so in order to fix it you have to delete it and remake it (as is done in the script).

Edited July 6, 2015 by Mator

[zilav]

  On 7/6/2015 at 5:17 AM, Mator said:

I've had to deal with this in the past in regards to Merged Plugins.  Awhile ago users were reporting merged plugins causing their map to freak out/be zoomed wrong/unusable.  I investigated and found it was because of conflicting edits to the MHDT subrecord on the Tamriel Worldspace.  The Merge Plugins script resets the MHDT subrecord to the Dragonborn defaults in all merged plugins.  See Lines 1379-1391

 

It should be noted that older versions of the Tamriel worldspace record will have different subrecord definitions for the MHDT subrecord, so in order to fix it you have to delete it and remake it (as is done in the script).

This is not Max Height Data of individual cells, this is Camera Data of the whole worldspace

[TechAngel85]

So if a mod is in a specific worldspace, should it carry this data forward?

[GrantSP]

  On 7/6/2015 at 6:16 AM, TechAngel85 said:

So if a mod is in a specific worldspace, should it carry this data forward?

In the thread I linked to above @Arthmoor had this to say:

  Quote

With thousands of mods in the game not forwarding this data (because why would they - it requires DLC) there is no way that it being missing is going to matter. Every mod would break the game. Bethesda's own DLC would break the game, because Dragonborn's MHDT data will clearly not be taking Dawnguard into account, and vice-versa. So just the mere presence of Dragonborn in the game should cause Castle Volkihar to get blocked.

 

[hishutup]

Hmm, if it doesn't matter then why does it exist? Why would bethesda code that when for it to be wasted?

I don't think anyone can answer that.

 

I did however see that there is an option to generate the max hight data in the ck.

[DoubleYou]

I think it is like the majority of the INI settings I've been testing: no one really knows.

[richardo11]

Well, the thing is that Run for YOur Lives, from Arthmoor himself, does not forward MHDT from Skyrim and all DLC's .... and the mods works like a charm, why, who, how, shoulda-cuda ... bet that even Bethesda has a clue :)

[Katarsi]

I've noticed a bunch of conflicts in SSEEdit regarding this line and I also wondered what it actually does and if it has any impact on the game at all.

Some mods that influence worldspace (such as Plockton's Culling Data Glitch Fix - meant primarily for the huge square hole in the Sea of Ghosts), have this line empty. I left it empty on one setup and I didn't have any weird stuff going on. On the other hand, the mod Convenient Carriages for example has this data populated (with some sort of technical gibberish I don't understand), and when I did the setup with this data, there weren't any problems either.

 

I also noticed that DynDOLOD esm and DynDOLOD esp have different MHDT values; esm is the same as DLCs, but esp follows the value set by the load order. I really don't know what to make of it. I didn't notice any particular issues - although that might be because I don't know what I'm looking for.

[TechAngel85]

  On 3/31/2020 at 8:52 AM, Katarsi said:

I've noticed a bunch of conflicts in SSEEdit regarding this line and I also wondered what it actually does and if it has any impact on the game at all.

Some mods that influence worldspace (such as Plockton's Culling Data Glitch Fix - meant primarily for the huge square hole in the Sea of Ghosts), have this line empty. I left it empty on one setup and I didn't have any weird stuff going on. On the other hand, the mod Convenient Carriages for example has this data populated (with some sort of technical gibberish I don't understand), and when I did the setup with this data, there weren't any problems either.

 

I also noticed that DynDOLOD esm and DynDOLOD esp have different MHDT values; esm is the same as DLCs, but esp follows the value set by the load order. I really don't know what to make of it. I didn't notice any particular issues - although that might be because I don't know what I'm looking for.

Max height data is merged at runtime, therefore, leaving it blank will not have any impact if the mod is not drastically changing the heights for the cells it's editing (most mods don't). DynDOLOD updates this data, I think, to correct heights for cells that have objects in them that extended beyond the default heights (e.g. installing a mod that has taller trees vs vanilla trees). This height data is also used to updating the occlusion data using xLODGen or DynDOLOD.