[NavMesh][MPQ] Geometry parsing issues menu

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 41
  1. #16
    Bananenbrot's Avatar Contributor
    Reputation
    153
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/3
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually, CrystalMpq does that for me and that's where I think the problem lies. Kalimdor(29,13) is a patched file and I will look into it today...

    [NavMesh][MPQ] Geometry parsing issues
  2. #17
    highvoltz's Avatar Active Member
    Reputation
    47
    Join Date
    Dec 2009
    Posts
    29
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I came across cave at HawaiiMainLand(30,30) that should have had a hole in the terrain but all the 'Hole' values in the mapchunk headers are zero.
    One thing I've noticed is what is described as an offset to the MCNR(normals) chunk here is non-zero for only the map chunks that should have a hole. It also appears to not be an offset because some of the values are way to big and I believe it to actually be a bit-field that describes the hole cut out.

    Some example 'MCNR offset' values:

    Tile HawaiiMainLand(30, 30) Mapchunk (4,3) Value: 790030, Bits: 11000000111000001110
    Tile HawaiiMainLand(30, 30) Mapchunk (6,15) Value: 49344, Bits: 1100000011000000
    Tile HawaiiMainLand(30, 30) Mapchunk (7,15) Value: 771, Bits: 1100000011

    Tile Kalimdor(29,13) Mapchunk (4,1) Value: 3855, Bits: 111100001111

    Divide the bits in groups of 8 and you'll see a pattern.
    Last edited by highvoltz; 05-25-2013 at 10:54 PM.

  3. #18
    Bananenbrot's Avatar Contributor
    Reputation
    153
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/3
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by highvoltz View Post
    I came across cave at HawaiiMainLand(30,30) that should have had a hole in the terrain but all the 'Hole' values in the mapchunk headers are zero.
    One thing I've noticed is what is described as an offset to the MCNR(normals) chunk here is non-zero for only the map chunks that should have a hole. It also appears to not be an offset because some of the values are way to big and I believe it to actually be a bit-field that describes the hole cut out.

    Some example 'MCNR offset' values:

    Tile HawaiiMainLand(30, 30) Mapchunk (4,3) Value: 790030, Bits: 11000000111000001110
    Tile HawaiiMainLand(30, 30) Mapchunk (6,15) Value: 49344, Bits: 1100000011000000
    Tile HawaiiMainLand(30, 30) Mapchunk (7,15) Value: 771, Bits: 1100000011

    Tile Kalimdor(29,13) Mapchunk (4,1) Value: 3855, Bits: 111100001111

    Divide the bits in groups of 8 and you'll see a pattern.
    This sounds interesting, although I think it is unrelated to what I experience at chunks ([0,1], , because if I extract the adt with MPQEditor the data seems to be just fine.
    I don't have much time to invest into this at the moment, but will upload a pic of a diff today to show you what I mean.
    This may in fact fix the other hole bug in the same adt.

  4. #19
    highvoltz's Avatar Active Member
    Reputation
    47
    Join Date
    Dec 2009
    Posts
    29
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by Bananenbrot View Post
    This sounds interesting, although I think it is unrelated to what I experience at chunks ([0,1], , because if I extract the adt with MPQEditor the data seems to be just fine.
    I don't have much time to invest into this at the moment, but will upload a pic of a diff today to show you what I mean.
    This may in fact fix the other hole bug in the same adt.
    Whats are you experiencing at chunk ([0,1], 8 )? Chunk (4,1) is where the cave entrance is at, that is if you're referring to tile Kalimdor(29,13)

    anyways I figured out how the holes are now calculated. I guess they needed a 64 bit bitmap.
    Edit: Header.Holes is still being used if non-zero.
    Code:
    private bool Holy(int x, int y)
    {
    	if (Header.Holes != 0)
    	{
    		int holeX = x / 2;
    		int holeY = y / 2;
    		uint flag1 = 1u << (holeY * 4 + holeX);
    		return (Header.Holes & flag1) != 0;
    	}
    	ulong flag2 = 1ul << (y * 8 + x);
    	ulong bitmap = Header.OffsetMCNR;
    	bitmap <<= 32;
    	bitmap |= Header.OffsetMCVT;
    	return (bitmap & flag2) > 0;
    }
    I probably should change the field names now that they have a different meaning.
    Last edited by highvoltz; 05-26-2013 at 03:56 PM.

  5. #20
    Bananenbrot's Avatar Contributor
    Reputation
    153
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/3
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I mean the entrance to the barrow dens at said mapchunks. As you can see in my first post, it is missing holes (for me), as does the cave you mentioned (no pic, didn't mention it until now).
    Seems now they are missing for different reasons: The barrow dens are closed because CrystalMpq is applying too many patches to the file as I found out just recently.
    Up until today I thought a fixed CrystalMpq would fix the cave entrance you mentioned too, but your posts tell a different story. When I get CrystalMpq to extract the right version, I will definitely look into what you posted.

    Edit: Just to show you what actually differs:
    http://img703.imageshack.us/img703/1598/vbindiff.png
    There is an additional bit set in the flags of the mcnk header and subchunk offsets are zerod out. There were 2 additional patches applied to get this version, while the right file (empted's) is just the base file without any patches applied.

    Edit2: this makes me sad, but I think CrystalMpq's version is actually correct. I could find the first 0xa8 bytes of the file in wow's memory, while I could not find an even smaller subset of Empted's.
    Last edited by Bananenbrot; 05-26-2013 at 04:52 PM.

  6. #21
    highvoltz's Avatar Active Member
    Reputation
    47
    Join Date
    Dec 2009
    Posts
    29
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I had somehow missed the cave at chunk (1,8 ). Went back and found it and it's got a hole for me. I don't know whether it had a hole before my fix or not.

  7. #22
    Bananenbrot's Avatar Contributor
    Reputation
    153
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/3
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It probably did, like it was the case for Empted. But I suspect now that CrystalMpq's version is way to go, at least wow says so. See Edit2 in my previous post. Credits to CheatEngine.
    Of course this means that I have to reverse how WoW actually calculates hole locations *sigh*.

  8. #23
    Bananenbrot's Avatar Contributor
    Reputation
    153
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/3
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK, it was a pain to find CMapChunk::CreatePointers in the new idb, but I found it at wow.exe+0x5F5DB3 (16992).
    There is a new if branch, checking for flag 0x10000 in the header, if it is present, it uses the 8 bytes of McvtOffset and McnrOffset (chunkheader+0x14).
    Since they can now fill 8 bytes = 64 bit, they have finer control over which tile exactly isn't rendered. Not fyi, but for everyone else': The holes value is just 16 bit, so 4 tiles are handled uniformly.
    Similarly, the old 16 bit value is translated into an equivalent 64 bit value.

    This was a relatively recent change since it is not included in the 15662 mac build.
    Blizzard, I beg you to letting us leak another debug mac build. Or send it via email or sth.

    proof:
    Code:
    int __thiscall CMapChunk::CreatePointers(int this, int chunkHeader, BOOL isMainFile)
    {
      signed int col; // esi@1
      int this2; // edi@1
      int chunkbegin; // ebx@1
      signed int row; // ecx@4
      int v7; // edi@9
      int size; // [sp+18h] [bp+8h]@1
    
    
      col = 0;
      this2 = this;
      chunkbegin = chunkHeader + 8;
      size = *(_DWORD *)(chunkHeader + 4);
      if (isMainFile )
      {
        if ( *(_DWORD *)chunkbegin & 0x10000 )
        {
          memmove_0((void *)(this + 0x74), (const void *)(chunkbegin + 20), 8u);
        }
        else
        {
          do
          {
            row = 0;
            do
            {
              if ( *(_WORD *)(chunkbegin + 60) & CMap::s_holeMask[4 * (col >> 1) + (row >> 1)] )
                *(_BYTE *)(this2 + col + 116) |= 1 << row;
              ++row;
            }
            while ( row < 8 );
            ++col;
          }
          while ( col < 8 );
        }
        // ...

  9. #24
    Tanaris4's Avatar Contributor Authenticator enabled
    Reputation
    148
    Join Date
    Oct 2008
    Posts
    646
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Did you figure this out? I recently noticed when dumping the adts and trying to parse them I'm getting a mismatch using wowmapper. I did a bin diff of the old stormlib i'm using (which dumps an adt that wowmapper can process) and the new version on the site (where i get the chunk id mismatch), check it out: Screen Shot 2013-05-27 at 5.15.15 PM.png

    Quite strange... Not sure if the issue is with ADT parsing (did the structure change)? Or something with StormLib. Probably not with StormLib.
    https://tanaris4.com

  10. #25
    Bananenbrot's Avatar Contributor
    Reputation
    153
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/3
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah I did. See the post immediately above yours
    I also updated wowdev.

    Regarding your structure change:
    If your code still relies on those ofs* fields in the mcnkheader, it should be broken by this patch. Just read chunk after chunk, switch on the magic of the header and take what you need. This is how WoW does it for a long time now.
    Last edited by Bananenbrot; 05-31-2013 at 12:55 PM.

  11. #26
    Tanaris4's Avatar Contributor Authenticator enabled
    Reputation
    148
    Join Date
    Oct 2008
    Posts
    646
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by Bananenbrot View Post
    Regarding your structure change:
    If your code still relies on those ofs* fields in the mcnkheader, it should be broken by this patch. Just read chunk after chunk, switch on the magic of the header and take what you need. This is how WoW does it for a long time now.
    This is exactly the problem I was having. Thanks! I'll work on it + push to wowmapper.
    https://tanaris4.com

  12. #27
    Sednogmah's Avatar Contributor
    Reputation
    129
    Join Date
    Oct 2009
    Posts
    158
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What's the current repository of wowmapper?
    https://code.google.com/p/wowmapper/source/list hasn't been updated since 2011.
    Thanks.
    Last edited by Sednogmah; 06-17-2013 at 07:46 AM.
    951388dcb8e5be825c2c10a7f53c16fcd84fc6c8b76ff0483237eeff745eaeac

  13. #28
    rens's Avatar Sergeant
    Reputation
    36
    Join Date
    Sep 2012
    Posts
    38
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Bananenbrot, can you show me a screenshot of you GoldRushBG?

    I seem to be getting issues (I haven't look into the chnages in 5.3 yet though)


    EDIT:

    Originally Posted by Bananenbrot View Post
    Yeah I did. See the post immediately above yours
    I also updated wowdev.

    Regarding your structure change:
    If your code still relies on those ofs* fields in the mcnkheader, it should be broken by this patch. Just read chunk after chunk, switch on the magic of the header and take what you need. This is how WoW does it for a long time now.

    You right in my MCNKHeader I read OffsetMCVT and get 0. This seams to be the problem for me. Setting this to 0x88(previous value in a tile that will build: Azeroth_17_37.adt) doesn't fix my issue either as I get a bunch of "flat" tiles
    Last edited by rens; 06-28-2013 at 06:24 AM.

  14. #29
    Tanaris4's Avatar Contributor Authenticator enabled
    Reputation
    148
    Join Date
    Oct 2008
    Posts
    646
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Are you using wowmapper @rens?
    https://tanaris4.com

  15. #30
    Bananenbrot's Avatar Contributor
    Reputation
    153
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/3
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    See http://www.ownedcore.com/forums/worl...ml#post2757020 ([NavMesh][MPQ] Geometry parsing issues) and what I added at the end of the paragraph at ADT/v18 - WoWDev.
    If there is anything you didn't understand, re-PM me to get online at skype.

Page 2 of 3 FirstFirst 123 LastLast

Similar Threads

  1. Parsing mpq files for navmeshes
    By karnkore in forum Diablo 3 Memory Editing
    Replies: 1
    Last Post: 04-23-2014, 03:17 AM
  2. [Release] [Mpq][C#] Geometry parser/viewer
    By Bananenbrot in forum WoW Memory Editing
    Replies: 19
    Last Post: 03-11-2014, 05:35 AM
  3. [Question] MPQ compile issue
    By Aliv3 in forum WoW ME Questions and Requests
    Replies: 1
    Last Post: 10-14-2007, 04:44 AM
  4. patching issue
    By Marlo in forum World of Warcraft General
    Replies: 0
    Last Post: 07-22-2006, 07:35 PM
  5. [Patch 1.11] - Known Issues (6-20-06)
    By Cypher in forum World of Warcraft General
    Replies: 1
    Last Post: 06-24-2006, 12:42 AM
All times are GMT -5. The time now is 08:59 AM. Powered by vBulletin® Version 4.2.3
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. User Alert System provided by Advanced User Tagging (Pro) - vBulletin Mods & Addons Copyright © 2024 DragonByte Technologies Ltd.
Digital Point modules: Sphinx-based search