I tried moving in the other direction, that is, taking the WLD file I made, renaming it to an existing one, and putting it in an existing s3d file. I got the same result; dbg.txt said that the client couldn't find the file. I suspect it's related to the checksum/crc in the s3d file. I noticed that eqinside doesn't recalculate the checksum when you put a new file in the archive. I think the loader in the client is calculating the crc/checksum and barfing when it doesn't match. If this is the case, I/we can't proceed until we know how to calculate the checksum that goes into the s3d file for any given file. I hacked together a quick eqinside clone that displays the checksum for a given file that is stored in an s3d file, and displays what it calculates using a standard crc32 algorithm. It doesn't match, so the client must do something different. Has anyone investigated this? I did a cursory look around the net and couldn't find any info.
Oh well. Time to head to that Super Bowl party...
WC
Edit: Wow that was a good game (unless you're a Rams fan I guess). Anyhow, here's my final thought for tonight: I found a small (72 byte) file in an s3d file and I've started an exhaustive search over all 32-bit seed values to see if any of them results in the checksum stored in the s3d file. I'll let it run overnight so if there are any keys that work, they should be found by tomorrow. Hopefully they used a straight crc32 algorithm...
|
Threaded Mode
