Some New Map Files

[KLS]

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 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.

[uncommon]

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.

[gernblan]

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.

[gernblan]

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.

[uncommon]

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.

[gernblan]

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.

[uncommon]

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

[gernblan]

Originally Posted by KLS

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.

Is there a way to add v3 (and v4) support to azone, even if they still require manual offset hacking?

I'm willing to spend the time if I know that it's at all possible trying to find thse offsets.