Jump to content

[8620] extractor yet again...


Auntie Mangos
 Share

Recommended Posts

Well I haven't done client update yet, so I can only comment from experience of last milestone release.

And not very surprisingly, the interest quickly dies after everyone has gone through extracting stuff from latest client...I'm no different there ;)

The maps built with x64 binaries did indeed work, despite the ancient, non-64bit approved libmpq.

However i still do have the modified code from last milestone for newest (at that time) libmpq release somewhere, in case someone is interested now...but it probably needs an update now.

About vmaps, I didn't adapt the extractor, but the assembler as that one took by far the longest for me. I still think I just have some wine problem that causes almost 100% CPU time to be system time rather than user time, but couldn't find a cause yet.

Old patch:

http://getmangos.eu/community/showthread.php?10403-fix-vmap-assembly-on-64bit-systems

Link to comment
Share on other sites

  • 39 years later...

New client, same problem again, dbc/map extractor screws up on 64bit linux.

I would really appreciate if people accept that "long" IS NOT meant to be equivalent to 32bit since decades...

Since loadlib.h even includes stdint.h i beg to actually use it and finally end this mess:

diff --git a/contrib/extractor/ad b/contrib/extractor/ad
index 564ecea..ba86320 100755
Binary files a/contrib/extractor/ad and b/contrib/extractor/ad differ
diff --git a/contrib/extractor/loadlib/loadlib.h b/contrib/extractor/loadlib/loadlib.h
index 6acfd10..0bfa367 100644
--- a/contrib/extractor/loadlib/loadlib.h
+++ b/contrib/extractor/loadlib/loadlib.h
@@ -16,13 +16,13 @@ typedef unsigned char      uint8;
#include <linux/types.h> 
#endif
typedef int64_t            int64;
-typedef long               int32;
-typedef short              int16;
-typedef char               int8;
+typedef int32_t            int32;
+typedef int16_t            int16;
+typedef int8_t             int8;
typedef uint64_t           uint64;
-typedef unsigned long      uint32;
-typedef unsigned short     uint16;
-typedef unsigned char      uint8;
+typedef uint32_t           uint32;
+typedef uint16_t           uint16;
+typedef uint8_t            uint8;
#endif

#define FILE_FORMAT_VERSION    18

Link to comment
Share on other sites

So you mean it's kind of insecure anyway?

Hm how old are those libmq files in extractor sources?

Changelog of libmq 0.4.0 says:

"added support for 64-bit architectures and removed any stupid pointer to int arithmetics."

Might consider upgrading them, maybe i'll have a look at that too. Those vmaps probably still keep my 'puter occupied for some hours anyway...

-edit-

*rofl* you gotta read this:

MaNGOS is a free, Open Source implementation of a game server compatible with the original World of Warcraft client." It seems to use libmpq for a map extractor. The libmpq code is completely cloned inside of the mangos source repository. Maybe they will upgrade one day too ;)
Link to comment
Share on other sites

Since those vmaps took well over 12h (wonder if that's normal...or some wine penalty) i did try to port the extractor to the latest libmpq.

And i think i succeeded. Required many changes in mpq_libmpq.h/.cpp, but i could remove much more code than i had to write.

If someone is interested, i'll share it, but i only updated the cmake stuff, so someone would have to help with VS project files. And i don't know why the original author (who is that anyway?) changed libmpq to C++ sources, it's a C library.

Link to comment
Share on other sites

That it is safe to use on 64bit systems? Besides just being easier to use (less code) and probably better tested, especially with WoW .mpq files...

Not to mention, counter the mockery of the author :D

Btw. I still feel stupid now, because I should've rather invested a few minutes in compiling the vmap_assembler for linux first. Now takes ~12minutes instead of 12 hours with wine :eek:

I *knew* >90% system time usage was not a good sign...whatever the reason is.

- edit -

cheered too soon, apparently the vmaps it produced are rubbish, despite their file size looking fine. DBCs however work fine.

Link to comment
Share on other sites

  • 2 months later...

I just have compiled ad on Linux x64 with gcc 4.4.1. I had to add "#include <stdio.h>" into loadlib.cpp and mpq_libmpq.cpp to be able to do it. Probably this should be fixed in mangos sources as well for other users.

Linx3D, if you manage to adapt vmap extractor for gcc, please share you work.

Link to comment
Share on other sites

I just have compiled ad on Linux x64 with gcc 4.4.1. I had to add "#include <stdio.h>" into loadlib.cpp and mpq_libmpq.cpp to be able to do it. Probably this should be fixed in mangos sources as well for other users.

In [9158]. Thank you.

I temporary generate x64 support at windows for extractor and genenerate maps using x64 ad.exe version. Result files exactly same so as i understand it work correctly at x86 platforms.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use