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...
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...
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.
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.
I probably should change the field names now that they have a different meaning.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; }
Last edited by highvoltz; 05-26-2013 at 03:56 PM.
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.
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.
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*.
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 ); } // ...
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
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.
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
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:
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.
Are you using wowmapper @rens?
https://tanaris4.com
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.