[QUESTION] VMaps on Customized Maps

[stoneharry]

May you please check the type of exception thrown?
(catch (const std::exception& e) { std::cerr <<typeid (e).name() << ":" << e.what() ; }

The following exception is thrown:

Code: [Select]

class std::bad_alloc:bad allocation


[schlumpf]

So, new ModelInstance[97987] fails.

[stoneharry]

So, new ModelInstance[97987] fails.

That seems like a stupidly large array - why would it need to be that big?

[stoneharry]

I am printing every time it is called now:



It appears to be created for every map loaded. This makes sense as it must be a root tree file that points to all the WMO's on the map.

The odd thing is that it is allocating the arrays fine as seen here. It randomly fails every now and then which will lead to a server crash when it tries to index a invalid position in that array from where it failed to create.

I do not see why the allocation would fail either - there is plenty of memory free.

Also it does not fix vmaps and thus mmaps on some these WMO's placed in Noggit.

[stoneharry]

Here is a temporary hackfix that works while Noggit remains private source and nobody who wants to can even try to fix it:

• Generate movement maps (pathfinding) and upload this data to the server, along with map data.
• Convert the WMO you want collision for into a M2 - this is difficult and is easier to just rebuild as a low poly model.
• Placed said M2 where your WMO is, and then delete the WMO.
• Now generate vector map data using this version of the map with only the M2 version.
• Upload vector map data to server, restore your client to the original WMO version for distribution to players.

This is a horrible, horrible fix and takes many hours for a single WMO. But it is necessary for dungeons and such...

[Steff]

Here is a temporary hackfix that works while Noggit remains private source and nobody who wants to can even try to fix it:

Did I not chat with you and said I will have a look? I realy dont like the sound of this sentence.
It seams that I am an lazy idiot who don´t spend any time for this community. I should reconsider my engagement.

If you know an solution, tell me what to change. Save code did not change since sdl in repo.

[stoneharry]

Did I not chat with you and said I will have a look? I realy dont like the sound of this sentence.
It seams that I am an lazy idiot who don´t spend any time for this community. I should reconsider my engagement.

If you know an solution, tell me what to change. Save code did not change since sdl in repo.

As many others have said, there is no reason to be closed source. It is annoying that we discover a bug and then have to wait for 1-2 devs who work on it as a hobbie to get around to it on their huge to do list.

That sentence expresses my frustration as you can tell.

If the code for this part is the same then at least I can look at it.

[Steff]

And why not just tell me or Hanfer what you have found so we can fix it. As said no changes on save to open noggit repo.

For me the point is. Noggit is still open. The current version is out and everyone can look at it. And this was now for over one year so. No help, no bugtraker entrys. Nothing. Now as we dicide to start over on SDL everyone cry that we are so bad that it is closed.

The point is we want to clean up first before we open it again. Hanfer is also a big open source guy and it will again be open. But at the point we are happy with the codebase. QT development failed. We start over again with SDL. We forked it and at the point we are happy with our changes it will get again back to the public repo.

I also asked for help testing the 1.2 and 1.3 and expect Sergey NOONE answerd my posts.

The other point. I think there are only 3 till 5 guy now in the scene who would be realy helpfull, if they have access to the code. So if you want to help, just chat me on In irc or skype.

[larrylaffer]

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.

[larrylaffer]

Ok,

I found ot that noggit is not properly saving the MCRF and the MCNK.nDoodadRefs + MCNK.nMapObjRefs  variables, so the server doenst draw the damn objects and so, the vmaps doenst work.

MCRF sub-chunk

A list of with MCNK.nDoodadRefs + MCNK.nMapObjRefs indices into the file's MDDF and MODF chunks, saying which MCNK subchunk those particular doodads and objects are drawn within. This MCRF list contains duplicates for map doodads that overlap areas.
As both, WMOs and M2s are referenced here, they get doodad indices first, then WMOs. If you have a doodad and a WMO in the ADT as well as the MCNK, you will have a {0,0} in MCRF with nDoodadRefs and MCNK.nMapObjRefs being 1.
The client uses those MCRF-entries to calculate collision. Only objects which are referenced in the current chunk of the toon get checked against collision (this is only for MDX, WMO seem to have different collision). If a doodad entry from MDDF or MODF gets never referenced in a chunks MCRF it wont be drawn at all, WoW doesnt take the MDDF and MODF to draw the objects.

I tried to fix this saving the ADTs with an older version of noggit (rev 104) , and using the RefRep tool (both in the SDL an 104 version), but it doenst fix it...

The RefRep tool seems to screw the ADT structure, cuz when i tried to load the ADT in the Hex Editor using the template, i got an error and the ADT structure is not properly showed.

Hope that in the next version of noggit this would be fixed.

Regards

[Hlkz]

m2 work with the previous rev of vmap (vmap3)
(before this http ://github. com/TrinityCore/TrinityCore/commit/93d199f04382fe3c7f6f08f59fd2ad058568679a)

I am a very noob on c++, couldnt find where in this commit make it not work, but I think maybe we can downgrade some part of it?

[shilvasa]

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.

[MR. Farrare]

guys i figgured somthing might help if you need npc to fight on spawn wmo and not fall go to the creature template and change the npc movement type to 1 and inhabit type to 2 even if its 3 make it a 2 !!! and it do not work near ocean water only in land like when you spawn a necropolice up in doratar and spawn npc and make combat now they dont fall but when you spawn up ocean or water a ship or somthing they fal lol and in my custom map the wmo work fine even in ocean but only in my blizzlike map i have water wmo errors :lol:  hope it helped you  

and srry for my grammer hope you understand  :cry:

[Hlkz]

It seams so easy to some of you, please can someone just fix this? I pay you!
For fixing noggit, fixing the extractor, or just helping me fix the vmaps with hex editor...
I beg you!

I tried to compile noggit, but cant even open it.
I tried to find the pos with 010 editor but didnt find anything.
And didnt find where to get the pos2 and pos3 in the extractor.

[Steff]

In current closed test version of sdl 1.3 we did some changes to fix this.  But nonfeedback from testers in this point till now.