[8620] extractor yet again...

[Auntie Mangos]

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

[Lynx3d]

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

[XTZGZoReX]

Well, if we were to clean it up totally, we should've included it in main sources (instead of contrib) and use defines already in those sources (i.e. ACE_UINT32 -> uint32, etc).

[VladimirMangos]

But then extractor will linked with ACE...

[VladimirMangos]

In [8620]. Thank you.

One note: in any case extractor sources not writed in way for build at x64 platforms (libmpq code mostly)

[Lynx3d]

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

[Lynx3d]

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.

[The_Game_Master]

What are the advantages to switching to the latest libmpq?

[Lynx3d]

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

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.

[kyle1]

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.

[VladimirMangos]

maybe, but you sure that data generated by like buiild binary correct? Do you compare its with x86 binaries generated version?

As i remember extractor code hard based at x86 only code by used types and etc...

[VladimirMangos]

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.