Re: Back on topic
 

There are enough people to do both actually. I personally think that content creation is going to be very limited. But even with the limitations there are things that we could learn from studying these formats.

I would have to agree with madborg on that one. I also think that in many cases it would be two completely different groups of people doing the different things. I for instance dont have very much experience with scripting, programming, etc. I do use photoshop a lot, have GM'd various games in the past so like creating adventures, and have some experience with using 3d tools. I think there are enough people working and using the emu that it would almost be different groups of people doing different things. Everyone could be doing their own thing while working togather and I think that you could make a sizable lump of old world style content. In some cases you could also modify existing zones if you wanted more content faster. East commons of west commons for instance. Fill in the tunnel like its collapsed with sand, punt the inns, and add some other stuff. It could pass for any outdoor area.

Thanks for the maya site btw madborg :)

Re: Re: Back on topic
 

Well good! I just wouldn't want to see the progress on the emulator itself be slowed due to world creation.

Either way, I think it's a very cool project.

-CB

I've been experimenting with creating my own zones, but I need some help. It seems that the game won't recognize what I create, so I performed a test and the result was unexpected. If you take all the files for a zone (e.g. everything beginning with "tox"), copy them, and rename them such that "tox" becomes "test", for example, putting a zone entry for "test" in the database and trying to go there in-game doesn't work. This seems strange to me, since the files are of course known to work. Can anyone try this, i.e. try to figure out how to run a valid zone under another name? It would go a long way toward getting our own .wld files to work.

WC

I'm no expert, in any way, shape or form, but it sounds to me like somewhere in the EQ files there is an entry as to what zones etc can be acessed by he EQ game... We would have to modify those entries to be able to create new content.

Let's start looking :) I've tried getting it to work on 0.2.0 and 0.2.1, but no success so far. Here's what I did on 0.2.1:

1. copied tox*.s3d to test*.s3d

2. added a zone entry in the db for zone "test", and specified "test" in the filename field as well.

3. copied tox.cfg to test.cfg and used a hex editor to change the text in the file to "Test" and "Another world", respectively. Any extra characters left over were replaced with nulls.

4. I set my character's zone to "test", and the xyz coordinates to 0,0,10.

When I try to enter the world, the client crashes.

WC

P.S. I've also updated my informal WLD spec on page 3.

Got a little more info. When I run in EQW 2.2 (which is REALLY slow, btw), I get the following pop-up message:



Unable to load World

EverQuest cannot load the zone file "test.s3d" in the directory that you are currently running EverQuest from. The file is present but it may be corrupt.

Please either reinstall or delete and re-patch this file.

For assistance with this problem, please call (858)-537-0898, or visit our website at http://www.everquest.com



When I click Ok, the client closes. It's interesting that this pop-up is only visible under EQW; before I was running eqgame patchme, and the pop-up wouldn't show up, but after I pressed enter the client would close. Presumably the popup was there but hidden by the game itself. There's QA for ya...

When I go to the eq folder, there are two new files there: test.chk and test_obj.chk. Maybe the game has a list of checksums or somesuch?

WC

Edit: I've been looking at the dbg.txt dump in the eq folder, and it says it was looking for test.wld. I used eqinside to rename tox.wld to test.wld, but it still didn't work. I then used eqinside to update the crc on that file, and still no-go...dbg.txt says that the client can't find test.wld, but I've verified that it's there. It looks like the client is complaining on all of the .wld files, but only the main wld file with the zone geometry is causing it to abort. This is potentially good news, since it implies that we can distribute files with only zone geometry and it might work (i.e. no chr, obj, etc. files), but we have to get the zone geometry files working first.

Edit: Another thing that's intetresting. In the character select screen, the zone shows up as "Unknown Zone". I've verified that there is an entry in the database for zone "test", and that there is a zone.cfg file in the cfg folder. So why doesn't the zone name show up? I suspect this is a related problem.

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

HELP!!!
 

Well, so far I haven't been able to figure out how to generate a proper checksum for my WLD files so the game will extract them from the S3D files without barfing. I super-optimized my crc32 routne and sic'ced a 1.7GHz PC at it, but no dice. So I'm officially yelling that I NEED HELP!!! :) I'm 99% confident that the checksum is somehow based on the actual name of the stored file, since I found four bitmaps in both global_chr.s3d and global_chr1.s3d that:

- are all byte-for-byte identical
- are all 72 bytes in size
- have DIFFERENT checksum values.
- have the SAME checksum value in each .S3D archive where the filenames match (e.g. elmhe0042.bmp has the same checksum in both files, but a different checksum than elmhe0052.bmp, even though the files are IDENTICAL).

The files I'm testing with are:

elmhe0042.bmp
elmhe0052.bmp
elmhe0062.bmp
elmhe0072.bmp

They are all 72 bytes in size and are byte-for-byte identical, but have different checksums in the S3D files:

40EF7F22
0FB81733
DE41AF00
9116C711

I did some poking around and noticed that there was a project called "nudeeq" that changed some character skins. NO, I'm not interested in nude character models, but I am VERY interested in HOW CHECKSUM VALUES WERE GENERATED. If anyone has any info on this, please post it or msg me; there is no way we can generate our own zones unless we can get the game loader to extract the files without thinking they are corrupted.

Windcatcher

Jeeze Windcatcher sure is a sick pup aint he? :P

lol, you don't know the half of it. he was looking for the nude Image the Gimp skin!

this comes from the skinFAQ

other information was the meaning of the texture file names for npcs such as human female chest piece.

I also have the nude wood elf female somewhere. Here is something from another file that I have:

Yep, EQInside handels all the .s3d stuff, i know i've replaced files in there before with np.

Interestingly enough, if you add files along the naming pattern it wont recognize them, meaning that the skin filenames, or maybe just which skins are valid/invalid, are stored somewhere.

The client reads the zone name at character select from it's local files, same with on the /who after you're in game. Also interesting, even the Verant s3d files "load" and "tutorial" display unknown zone. Only the "You have entered ZoneName" is read from the server.

The zones are hardwired in the client. There is a table that has some zone names and also a set of lists that have all the names. The list seems to had null pads of 2 or 3 chars but the table seems to have enough room to put some information in it -- from cfg files? The table does not have a complete zone list, but the list seems to be complete.

the zone "tutorial" was not in either the table or the lists of zones.