I've been playing a bit with azone today, i'm not at home just on my linux laptop and don't have all the stuff to test these map files... but they should be okay i think.

barter.eqg : http://uncostockage.free.fr/EQEMU/barter.map
fhalls.eqg : http://uncostockage.free.fr/EQEMU/fhalls.map

These are 2 of the few zones i really want to use on my server.. next one is dreadspire but i can't seem to be able to find that opcode. So question to you fathernitwit, is it possible that azone just won't support a zone and always seg fault even if i'm sure i got the right opcode and all ?

dreadspire.eqg, to me the boundary is around here, i tried different value but it always crash... any idea ? :

Ok first stupid post...

I've had a lot of people ask me, and I cannot give them an answer as I haven't found it yet myself..

What are the map files for?

I've deleted the map files on our server as they seem to do nothing, and the server still works. I added them back of course later on *just in case* he he.

But again, I noticed no diffrence, as the info about the zones seems to be stored in the database and the client.

Am I wrong?

It's about los, load a zone with no map file and try to cast some kind of detrimental spell on a mob and you will get the "you cannot see your target" message for example. Mob won't be able to cast detrimental spell also i'm sure etc...

Ok and with looking at some of that it seems that the server would also translate terrain such as water for mobs too right? I think someone said once that water is purely client-side. I'm not sure about that, for your avatar sure, but not for mobs, the server controls where the mobs path, how they path, when they path etc. I'm sure there must be something missing in a map file that allows underwater mobs to leave the water =S. I mean using the client on live it works, on emu it doesn't... Something is missing there (meaning it worked when DoN/Titanium came out).

Dreadspire is actually a version 3 eqg, while the azone code was written to read version 2.. and it doesn't perfectly as shown =(

The version 3 eqgs are actually much more well behaved too sadly, but azone currently wont read them properly as the vertex data structure has changed from 32 bytes to 44 bytes in that version. Can get azone to support them soon though, I've been able to render them properly so I know I got the structure down.

Ok thank you KLS, it makes sense now. Almost every single DoD .eqg i tried crash azone, even when the opcode is really obvious.

Anyone tried these 2 .map files to see if they work ? I'm still not at home and can't do it.

Been playing with them and you're right... even when the offset is obvious, no dice.

SO... hopefully one can get azone to support this type of EQG also. I for one am willing to sit there and figure out offsets and work on anniversary zones even under these conditions, as long as there is a way that it CAN work.

I would think this is high priority because without this working in some way, any anniversary support in the future is pointless I would think.

So please, anyone capable (unfortunately I'm not THAT good with C++), please, let's work on this and make a real effort to getting the rest of the maps made not just for titanium but also for the zones going forward.

:)

Maybe I'm dumb but someone please explain to me what the "- 2" or "+ 19" mean in the offsets that were already hacked.

The wiki says that this offset will be on a 16 byte boundary but those do change that, no?

Examples:

} else if(string("ter_guildhall.ter") == zone_name) {
buffer = ter_orig + 0x3080 - 2;
} else if(string("ter_guildlobby.ter") == zone_name) {
buffer = ter_orig + 0x4190 + 19;

So if the offset for guildhall is 0x3080 as stated in the wiki example... why subtract 2 from it?

...and why add 19 to guildlobby's?

I at least need a basic understanding of these values and why they are the way they are (and different from the wiki) before I can really sit down and hack away at these zones for us.

If you look at the various example in the ter.cpp file it's not always on a 16 bit boundary.
About the guildhall example, 0x3080 - 2 is obviously the same as saying it's 0x307e (i tried and it works)... personnaly that's how i found the barter.eqg opcode (it's 0x56AD), i was sure it was around 0x56B0 but that one didn't worked so i tried 0x56B0 - 1 then 0x56B0 - 2 etc... till it worked. Probably an horrible way to find it but it worked. :)

I hope that's clear ? Sorry my english sucks.

VERY clear, thank you!

May I ask what fhalls was too?

As we find them, let's post the offsets so that we can all have them, please?

Ok, knowing what you just told me, I'll going to try to work on another zone.

For sure, let's do that, fhalls.eqg is 0x2230.

There's a handful of zones up to depths that I can't load and render properly atm, but it's just a matter of finding the offsets at this point. Should probably look for a more general solution, for version 2 EQGs but it's frustrating..

There's a freaking chunk of unknown data before the vertex data, somehow related to the material layers and a potential chunk of unknown data after the index data.. making finding the start of the vertex data pretty much impossible without offsets or identifying the unknown data before the vertex data.

Quite right KLS.

I'm working on it feverishly. I am thinking of a brute force method.. maybe writing a perl script to cycle the offsets, compile azone, execute it.

Would be ugly but it just may work...

That being said, my perl isn't up to par yet but I'm going to try anyway.

I'm having a hell of a time writing that script... my perl just isn't good enough yet.

Anyone up to taking a stab at this? It just may help get more zone maps made.

What the script needs to do:

(first you'd manually run azone on the zone you want to hack to get the .ter file name (since it's not always the same as the zone shortname), then you'd go into the ter.cpp file and add an offset line for that zone)

1) using a loop that increments the offset value you want to try (loop range of, say 0x0500 to EOF maybe?) ...load the ter.cpp file and at the offset location for the zone you want to hack, change it to the loop value, then save it back out.
2) compile azone
3) run azone on the zone you are hacking
4) trap the output to see if it gave a segfault. If it did, loop again. if it did NOT crash, double check for a .map file for that zone. If one exists, exit, reporting the offset found.

SO, part of this is manual and the script would have to be tweaked some each time because a new line like:

... would have to be added. The example above I added to try to hack drachnidhive.

Anyone up for banging out a perl script that can do this? I promise I'll hack the living heck out of it and then post the ter.cpp with the correct offsets for the zones I am able to make maps for (as well as the maps themselves) if you do.

So, the short of it is that the perl script would help change the offset in ter.cpp in a brute force way and be smart enough to know when it worked.

Then the user manually adds another line to ter.cpp like the above, changes the perl script to point to the offset location in ter.cpp (would be great if the script parsed that line and you could just tell it what line it was on!)... then the user runs the brute force script on the next zone... etc.

Is this idea stupid? Anyone think that it will not work? If not, why not?

Thank you.

Based on my EQG loader I got sidetracked last week with:

Not including any version 4 EQGs and just eqgs I found on my system. There are special conditions for version 1(fhalls) and version 3(anything in DoD) that don't let them load with the version 2 loader correctly (though you can get fhalls to work with an offset). I'll try to post my code once I clean it up a bit.