Find a way to fix this:

WMOs objects have three coordinates in the ADT.
The XYZ coordinates that set the position of the objects, and then some "upper" and "lower" xyz coordinates.
These coordinates must have a wide range of difference between the xyz position coords.
Problem is that noggit saves the upper and lower coordinates with very low values.

I had the vmaps problem with the stranglethon arena in a customized map, so i opened the blizz map where there is the arena in gurubashi, using the hex editor, and check the difference between the xyz position coordinates and the upper and lower coordinates.

I found that in the blizz map, the difference between the xyz coords and the upper and lower coords (for the strangleton arena) are aproximately:

x: +- 243
y: +- 190
z: +- 10

This means that if the x coord is 300, for example, the upper x must be aprox 543 and the lower 57.

Smaller wmos.. like walls or things like that, have an less range, like +-12 for X
(Noggits only set  +-1 difference for all the xyz coords)

Properly setting this with an hex editor or taliis (previously veryfing properly the correct differences of the wmo in an blizz map), we resolved the issue of vmaps in our wmo. Is a pain in the ass to fix every wmo in the map (specially if resave our map)... but at least we know how to do it now...

However, the vmaps doenst work with the m2... still i dont know how to fix that.

Regards.

i think this is the proplem and rather easy to fix.

there are 4 point info(vector3d) in each MODF entry, noggit handles the first 2 just fine, and the 3rd and 4th seems most likely the wmo's left-bottom-back and right-top-front boundary point(with north = back and south = front). with these 2 point it can draw a box, area out of boundary box means no collision at all.

i took a look into TC's wmo code, it doesn't generate collision outside this boundary box.