azone2 question

[Harcourt]

I'm not sure where to post this, since most of the discussion on it seems to be in the developer forums.

Hopping NPCs are getting under my skin, and I notice that one of the zones does not have a .map file. (I would like to use Blightfire Moors to test some things).

I built azone2 on a Linux box and ran it against the eqg file:

$ azone2 moors
AZONE2: EQEmu .MAP file generator with placeable object support.
Unable to open container file 'moors.eqg'

(The file opened OK, but the archiver couldn't read the zone data)


I obtained a Windows executable from
http://eqemumaps.googlecode.com/svn/trunk/azone_utils/

and ran that:

E:\underfoot>\Azone2.exe moors
AZONE2: EQEmu .MAP file generator with placeable object support.
Error reading ZON/TER from moors.eqg

The EQG version in Underfoot may be newer than azone2 can handle. Or I may be using azone2 wrong. Any suggestions?

[Derision]

I just tried it on Linux (32-bit) and Win7 (64 bit, although azone2 was compiled as 32 bit), and it works for me:

D:\EQClients\Underfoot>dir moors.eqg
 Volume in drive D is New Volume
 Volume Serial Number is E8FF-9784

 Directory of D:\EQClients\Underfoot

23/03/2010  19:33        26,670,635 moors.eqg
               1 File(s)     26,670,635 bytes
               0 Dir(s)  845,114,679,296 bytes free

D:\EQClients\Underfoot>azone2 moors
AZONE2: EQEmu .MAP file generator with placeable object support.
Attempting to load EQG moors
There are 3403632 vertices and 1134544 faces.
EQG V4 Placeable Zone Support
ObjectGroupCount = 2157
azone.ini not found in current directory. Including default models.
After processing placeable objects, there are 4909737 vertices and 1636579 faces
.
Bounding box: -3968.00 < x < 3968.00, -2560.00 < y < 3712.00
Building quadtree.
Done building quad tree...
Match counters: 9421821 easy in, 27934388 easy out, 167559 hard in, 0 hard out.
Writing map file.
Map header: Version: 0x01000000. 1636579 faces, 2666 nodes, 1813303 facelists
Done writing map (88.14MB).

D:\EQClients\Underfoot>

Don't know what to suggest, as no-one has reported a problem like this before.

[trevius]

Maybe that azone2 executable is from before the EQGv4 types were supported. I always compile my own azone2 straight from the source here:

http://code.google.com/p/projecteqem...utils%2Fazone2

And that always works fine for all zones currently available so far that I have tried.

[Harcourt]

Thanks for the responses. I am building on 64-bit Linux. I rebuilt azone2 as a 32-bit application and it runs fine.

And most importantly, the mobs in Moors follow the terrain now.

For any Fedora folks out there, you'll need:
zlib-devel-1.2.5-6.fc16.i686

I looked into building a working 64-bit version. There is some sort of sizing error, as the following is 20 bytes long rather than 12. Probably alignment.

struct struct_header {
  unsigned long offset;
  char magicCookie[4];
  unsigned long unknown;
} typedef struct_header;

PS: Reading the structure field-by-field may be the easiest solution

[lerxst2112]

It could be alignment or it could be that unsigned long is actually 64 bits.

The output from this would determine either or both cases:

#include <stdio.h>
#include <stddef.h>

struct struct_header {
	unsigned long offset;
	char magicCookie[4];
	unsigned long unknown;
} typedef struct_header;

int main()
{
	printf("sizeof %u %u \n", sizeof(struct_header), sizeof(unsigned long));
	printf("offset %u %u\n", offsetof(struct_header,magicCookie), offsetof(struct_header,unknown));
	return 0;
}

[Harcourt]

The output:
sizeof 24 8
offset 8 16

My understanding of the C++ standard was that unsigned long is always 32 bits. If you want a 64-bit integer use "long long" or "unsigned long long". But that does not appear to be the case anymore.

In any event, I'll change the headers to use uint32 and see if that helps. At best a nitpick since I can run it as a 32-bit application. But I spent enough time looking into this, so I might as well track down the source of the problem.

[lerxst2112]

The C, and consequentially C++ standard only requires that a type have a minimum size, not a maximum. An unsigned long is guaranteed to hold a value of 0 to 4294967295, which requires 32 bits. An unsigned int is guaranteed to hold a value of 0 to 65535, or 16 bits, but on most 32-bit platforms it is 32 bits as well because that is the fastest register size on that platform.

In your case, it's clear that unsigned long is 64-bits. As far as I know, on Linux, an unsigned int is 32 bits for both 32-bit and 64-bit programs. On Windows, unsigned long is also 32 bits for both.

C99 and C++ 11 define various guaranteed size types, but multiplatform support for both standards is a bit sketchy, so if you go down that road you may run into problems. I believe GCC has supported the C99 types for a while, but Visual Studio did not include the header until VC++ 10.

If you're really lucky, when you change that to unsigned int you'll get 12, 4, 4, 8 as the output from that program which is what you're looking for. If the offsets are different than that you'll need to add #pragma pack(push, 1), #pragma pack(pop) around the struct definition to force it.

[thepoetwarrior]

I got azone2 to work for old zone like guktop but can't get it to work for later expansion zone like oldcommons.

[NatedogEZ]

azone2 different than just regular azone? I compiled azone and it was able to do the newer zones just fine.

[thepoetwarrior]

Was exe downloaded, probably old version, couldn't handle the newer zone, only created map for older zones. I didn't compile my own azone.

[zenthrose]

hate to resurrect an old thread but using azone2 downloaded from the wiki i had 1 zone that failed to let me make and that is thuliasaur. any idea why that is? i have a copy of live and the rof2 for the emu, and im trying to get all the maps the way they are on live for my server and thuliasaur causes azone2 to crash.

and so you know when i do this command from the directory i have live in i run it like this azone2.exe thuliasaur then after 10 sec i get a pop up saying that azone2 as stopped working with 2 click boxes debug and close.

[demonstar55]

They do some really dumb shit with maps .. We haven't accounted for all of them and the dev hasn't had the free time to account for all their dumb shit.

[zenthrose]

lol i like the bluntness demonstar55, like i said it was the only zone i could not map, so ill have to deal until the dev can account for that zone. thanks for the reply