about wowmapper

[Megamike55]

//////////SelfIntroduction//////////
I have been reading these forums for a while now, and made my own private bot using all the information here. So thank you! to everyone here.

Up until now I have been using breadcrumbs and manual obstacle input (which is a pain!) to make my bot move around correctly.

I am getting very tired of inputting obstacles manually so I began looking into wowmapper - Project Hosting on Google Code


//////////OnTopic//////////
Unfortunately (correct me if I'm wrong) the format of the maps has changed a bit with wow 4.0.1 and it would seem wowmapper is no longer functioning. I have not Yet looked into fixing it myself, I first wanted to get some confirmation from you all. (I made sure to follow the forum rules and searched google before posting, but I see no information on updated wow map formatting.. not that I would expect there to be any, so soon, really)

Any information is greatly appreciated

Thanks


//////////Edit//////////
Edit: I went through and ran wowmapper in debug mode and looked at the call stack when the error occurs and.... I'm stumped. The error originates in the Vector class when the program calls the following line in chunk_c.h:
std::copy(buf.begin()+buf_off, buf.begin()+buf_off+(num*sizeof(T)), raw_iter);
Apparently, if I am reading this right, there seems to be a problem in the iterator, causing an out of range exception.

[RivaLfr]

Hello,

The map is now used in OldWorld.MPQ > "OldWorld\World\maps\Azeroth" for Azeroth.

After I'm not sure but the *.adt structure have changed I'm working on now for update ppather.

I post a message that I have more information.

[Flowerew]

Hi Megamike55, there can be several issues right now. I've not yet experimented with patch 4.x.x map data, but I will try to take a look at it when I come home from work. As stated on wowdev wiki a while ago, the map format changed with the new version, however I've no idea if the old map data is still there and what has to be done to update wowmapper. I will respond when I have more insight on this topic.

P.s.: the stack trace for the crash would be interessting

[RivaLfr]

     msvcr90d.dll!_crt_debugger_hook(int _Reserved=2)  Ligne 62    C
     msvcr90d.dll!_invalid_parameter(const wchar_t * pszExpression=0x00bf3a70, const wchar_t * pszFunction=0x00bf9a28, const wchar_t * pszFile=0x00bf3c60, unsigned int nLine=163, unsigned int pReserved=0)  Ligne 112 + 0x7 octets    C++
>    Sample_MeshExporter.exe!std::_Vector_const_iterator<unsigned char,std::allocator<unsigned char> >::operator+=(int _Off=134745192)  Ligne 163 + 0x1e octets    C++
     Sample_MeshExporter.exe!std::_Vector_const_iterator<unsigned char,std::allocator<unsigned char> >::operator+(int _Off=134745192)  Ligne 171 + 0xc octets    C++
     Sample_MeshExporter.exe!Chunk_c::CopyVector<signed char>(const std::vector<unsigned char,std::allocator<unsigned char> > & buf=[313436](82 'R',69 'E',86 'V',77 'M',4 '',0,0,0,18 '',0,0,0,82 'R',68 'D',72 'H',77 'M',64 '@',0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,64 '@',0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,79 'O',50 '2',72 'H',77 'M',0,36 '$',0,0,0,12 '',0,0,1 '
',0,0,0,0,0,0,0,24 '',12 '',0,0,1 '
',0,0,0,0,0,0,0,48 '0',12 '',0,0,1 '
',0,0,0,0,0,0,0,72 'H',12 '',...,...), unsigned int buf_off=134745192, unsigned int num=435, std::vector<signed char,std::allocator<signed char> > * dest=[435](0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,...,...), unsigned int dest_off=0)  Ligne 90 + 0x52 octets    C++
     Sample_MeshExporter.exe!McnrChunk_s::McnrChunk_s(Chunk_c * parent=0x08a69048, unsigned int off=134742016)  Ligne 37    C++
     Sample_MeshExporter.exe!McnkChunk_s::McnkChunk_s(Chunk_c * parent=0x0034eec8, unsigned int off=3168)  Ligne 80 + 0x24f octets    C++
     Sample_MeshExporter.exe!Adt_c::InitMcnks()  Ligne 36 + 0x36 octets    C++
     Sample_MeshExporter.exe!Adt_c::Adt_c(std::vector<unsigned char,std::allocator<unsigned char> > * buffer=[0](), std::vector<unsigned int,std::allocator<unsigned int> > * objUids=[0](), std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,Model_c *,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,Model_c *> > > * modelMap=[0]())  Ligne 23    C++
     Sample_MeshExporter.exe!LoadAdts(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & dir="E:\jeux\World of Warcraft\Data", const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & wdtDir="OldWorld\World\maps\Azeroth\Azeroth", Mesh_c * bigMesh=0x0034f8c4, std::list<AdtPos_s,std::allocator<AdtPos_s> > * adtPos=[687]({x=35 y=20 },{x=36 y=20 },{x=37 y=20 },{x=38 y=20 },{x=39 y=20 },{x=40 y=20 },{x=35 y=21 },{x=36 y=21 },{x=37 y=21 },{x=38 y=21 },{x=39 y=21 },{x=40 y=21 },{x=25 y=22 },{x=26 y=22 },{x=27 y=22 },{x=28 y=22 },{x=29 y=22 },{x=30 y=22 },{x=31 y=22 },{x=32 y=22 },{x=33 y=22 },{x=34 y=22 },{x=35 y=22 },{x=36 y=22 },{x=37 y=22 },{x=38 y=22 },{x=39 y=22 },{x=40 y=22 },{x=41 y=22 },{x=42 y=22 },...,...))  Ligne 134 + 0x20 octets    C++
     Sample_MeshExporter.exe!main(int argc=1, char * * argv=0x00895338)  Ligne 29 + 0x1b octets    C++
     Sample_MeshExporter.exe!__tmainCRTStartup()  Ligne 582 + 0x19 octets    C
     Sample_MeshExporter.exe!mainCRTStartup()  Ligne 399    C
     kernel32.dll!753d3677()     
     [Les frames ci-dessous sont peut-être incorrects et/ou manquants, aucun symbole chargé pour kernel32.dll]    
     ntdll.dll!77839d42()     
     ntdll.dll!77839d15()

[Flowerew]

Ok I see. I will try to fix this when I get home.

[RivaLfr]

The ADT structure have changed, for the moment have changed this:

 MhdrChunk_s(Chunk_c *parent, wm_off_t off)
      : Chunk_c(parent, off) {
    // OLD STRUCT
    //mcin_off = GetValue<wm_off_t>(0x04) + SUB_OFFSET;
    //mtex_off = GetValue<wm_off_t>(0x08) + SUB_OFFSET;
    //mmdx_off = GetValue<wm_off_t>(0x0c) + SUB_OFFSET;
    //mmid_off = GetValue<wm_off_t>(0x10) + SUB_OFFSET;
    //mwmo_off = GetValue<wm_off_t>(0x14) + SUB_OFFSET;
    //mwid_off = GetValue<wm_off_t>(0x18) + SUB_OFFSET;
    //mddf_off = GetValue<wm_off_t>(0x1c) + SUB_OFFSET;
    //modf_off = GetValue<wm_off_t>(0x20) + SUB_OFFSET;
    //mfbo_off = GetValue<wm_off_t>(0x24) ? GetValue<wm_off_t>(0x24) + SUB_OFFSET : 0;
    //mh2o_off = GetValue<wm_off_t>(0x28) ? GetValue<wm_off_t>(0x28) + SUB_OFFSET : 0;
    //mftx_off = GetValue<wm_off_t>(0x2c) ? GetValue<wm_off_t>(0x2c) + SUB_OFFSET : 0;
    
    // NEW STRUCT
    mcin_off = GetValue<wm_off_t>(0x04) + SUB_OFFSET;
    mtex_off = GetValue<wm_off_t>(0x08) + SUB_OFFSET;
    mmdx_off = GetValue<wm_off_t>(0x0c) + SUB_OFFSET;
    mmid_off = GetValue<wm_off_t>(0x10) + SUB_OFFSET;
    mwmo_off = GetValue<wm_off_t>(0x38) + SUB_OFFSET;
    mwid_off = GetValue<wm_off_t>(0x3C) + SUB_OFFSET;
    mddf_off = GetValue<wm_off_t>(0x??) + SUB_OFFSET; // ???
    modf_off = GetValue<wm_off_t>(0x??) + SUB_OFFSET; // ???
    mfbo_off = GetValue<wm_off_t>(0x??) ? GetValue<wm_off_t>(0x??) + SUB_OFFSET : 0; // ???
    mh2o_off = GetValue<wm_off_t>(0x??) ? GetValue<wm_off_t>(0x??) + SUB_OFFSET : 0; // ????
    mftx_off = GetValue<wm_off_t>(0x??) ? GetValue<wm_off_t>(0x??) + SUB_OFFSET : 0; // ????
  }

I continued to work.

EDIT: After offset 0x3C, the struct appears compressed or she is completely changed.

[Flowerew]

First of all, sry for the late response. As I see it right now wowmapper will not work with WoW 4.0 map data anytime soon. It seems like Blizz has removed all chunk offsets from the header chunk except for mh2o and mfbo (water & flight) -.-
As you can see this file is a valid zone (area_id=11 aka Wetlands). wowmapper parses chunks based on their offsets defined in chunks like the header and relies on these very offsets to step through a map file, thus it fails cause it simply can not see where it has to go next. I can't give any estimates on when I will rewrite it. So if you want to extract map information right now you have to downgrade to WoW 3.3.x.

http://i54.tinypic.com/23tfo9l.jpg

[rafalsk]

ADT/v23 - WoW.Dev Wiki
also working on making ppather work again..

[ostapus]

nice, good job!

[RivaLfr]

Thank, good job

[Megamike55]

Hi,

You all are amazingly talented. Thanks for your replies. I have my bot up and running with the geometry from Kalimdor and Azeroth and Outlands using the old data from 3.3.3. I have been researching all the file formats used here and it's confusing to say the least, being new to it.

My current goal is to extract various Dungeon geometry. I have gathered that WDT files contain a list of either ADT or WMO files, and that ADT or WMO files contain the actual geometry for any particular location in the game.

My question to you is simple. I am working on extracting Ragefire Chasm, and I know that its WMO files are contained here:
World\wmo\Dungeon\KL_OrgrimmarLavaDungeon\LavaDungeon.wmo (3.3.3 data)
But (1) I cannot find a WDT file for this instance. What am I missing? and (2) If I just went ahead and extracted information from the WMO files I found there, would the result actually be the instance geometry, as I think?


Edit: I answered number 2 myself, went ahead and used wowmapper to extract the wmo at
World\wmo\Dungeon\KL_OrgrimmarLavaDungeon\LavaDungeon.wmo
That particular wmo had LavaDungeon_000.wmo to LavaDungeon011.wmo listed in it, so wowmapper automatically extracted those 12 files and made the mesh. I output it to a file and put it in my bot. Turns out the coordinate system was flipped along x y and z in weird ways, but I'll fix that myself. I still wonder where the WDT went that was suppose to be there (according to my research). But it seems like that initial wmo is doing its job.

BTW. I love wowmapper. Awesome.

[Flowerew]

Nice to hear that. Hope you're using the latest revision from the svn of wowmapper, cause the download still has the scaling bug reported a while ago.

Oh and btw, the coordinates wowmapper outputs are different, because wow uses a different coordinate system (if I remember correctly a right handed with z-up http://mathworld.wolfram.com/Right-H...ateSystem.html) than recast. So first and foremost it's there to be used with recast, but the conversion is not difficult.

[Megamike55]

I'm not familiar with that, Thanks for the info. I was using the one in the download section: "wowmapper_v0.1.7z Official release, includes source, vc9 sample project, windows binary"

Found the bugfix you made in mesh_c and just updated it manually

[Megamike55]

I'm not sure if I should make a new thread or not, but I had a quick question to anyone who has run the output of wowmapper (the .mesh files) through Recast.

I took the demo recast project, stripped away the UI, converted the load function to load our .mesh files, and made it batch process all the .mesh files for Kalimdor,
using the Sample_StatMeshSimple class included in the demo. I just wanted to get some good navmeshes, for my own use (not going to use Detour, probably).
The problem is that the program keeps crashing... When m_vertsPerPoly is set to 3 it crashes on many of the bigger meshes, for example the central part of Darnassus.
I'd say the program crashed on average with 1 out of 20 of the meshes on that setting... However, when I set m_vertsPerPoly to 6 -the default- the program
crashes on 1 out of 200 or so.

I don't really understand this, does anyone have any insight from their own experiences? The crash happened (with m_vertsPerPoly = 3) quite consistently
inside recastmesh.cpp at function: rcBuildPolyMesh toward the end, when it attempts to free memory with delete [] indices;

[Cypher]

I don't know what version of recast you're using, but a quick look at the latest subversion revision for Recast indicates that they are now using RAII to free memory rather than doing it explicitly (hooray!). Without being able to see the code I can't really tell what may be causing the crash in your version, but I would guess that if you upgraded to the latest build the problem would most likely be gone.