[gernblan]

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:

else if(string("ter_hive.ter") == zone_name) {
	  //drachnidhive - not working yet
	  buffer = ter_orig + 0x2B36;
  }

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