EverQuest File Formats

[MOG]

What is known so far about the various file formats in EQ? How many ffs are documented so far? I would very much appreciate any info on that.

MOG

[jbb]

There isn't a lot of actual documentation that I'm aware of.

What there is seems to be in this forum and the tools::development forum where it was discussed earlier.

There is also openeq source code and my own renderer program work in progress (which is suffering from a lot of trial and error trying to figure things out but might be of some use).

It would be a good idea if some of it gor written up properly though

[daeken_bb]

Originally Posted by MOG

What is known so far about the various file formats in EQ? How many ffs are documented so far? I would very much appreciate any info on that.

MOG

The following file formats are entirely (or damn close to it) known:
PFS (used for s3d and eqg files)
.wld
.zon
.ter
.mod
.vpk (EQ2)
.voc (EQ2 -- partially known)

I have been thinking about writing formal documentation for a while now, but for now the docs on the forum will have to do. Perhaps over Christmas break I'll write up some real documentation.

[jbb]

I wrote something about the basic file format at
http://www.fx2100.com/eq1ff_1.txt

Please check it as it is from memory and may have fields in the wrong order or have detail wrong.

And this is just some very early thoughts. It needs a lot of tidying up and putting in a nicer format but I though it useful to at least get it down on "paper".

I'll add what detail I can on the static model format when I get the chance.

[MOG]

I would like to add a couple things that came to mind.

First of all, there would be a lot of legal hassles if you used EQ files directly. So my idea is, why not add a step, that while it might seem unnecessary to some, actually gives the OpenEQ team more protection? Instead of using EQ files, I suggest you completely research all EQ file formats and then create your own format for OpenEQ. Then you code a converter and it will import EQ files into your client. This actually covers your backs a lot more than you think.



MOG

[Mongrel]

First of all, you can use any file you want as long as you write the importer yourself. Second, they already created their own file format (it's posted about somewhere in the OpenEQ forums)

[daeken_bb]

Originally Posted by MOG

I would like to add a couple things that came to mind.

First of all, there would be a lot of legal hassles if you used EQ files directly. So my idea is, why not add a step, that while it might seem unnecessary to some, actually gives the OpenEQ team more protection? Instead of using EQ files, I suggest you completely research all EQ file formats and then create your own format for OpenEQ. Then you code a converter and it will import EQ files into your client. This actually covers your backs a lot more than you think.



MOG

Ok. Here's why we're not using importers.
1) We have a system in place where we can add support for new file formats without changing any code other than the primary file loader.
2) We know almost everything about the major EQ file formats and the majority of them are easy enough to use that it's not a problem.
3) Sony's legal team can't touch us when we're just using the files. The second we modify the files or release a tool to modify the files, we open ourselves up to a world of legal fury. Not only that, but we would most certainly have to distribute the already converted files because most people don't want two copies of each model file.

If someone wants to make convertors that's all fine and good, but there's no way we can stop supporting the EQ file formats if we want to use EQ's content. Also, the OpenEQ project won't condone the use of convertors... even the wld2ter convertor I wrote isn't supposed to be used for anything more than testing, and as soon as our WLD loader is coded, even that won't be neccesary.

If you have any further questions or input on the issue, please let me know

WC was asked about editing existing EQ zones, and quote the law on why it would never happen on that project.


Imagin people editing there air maps to have bridges to the diferent islands, or adding shortcuts through mountains, or a lot of other exploits.

[Windcatcher]

That's right. That's why I have no intention of releasing a version of OpenZone that can read .WLD. The last thing I want or need is a bunch of losers trying to use it to cheat on EQLive (and I have no doubt that someone would). I'm actually quite surprised that no one has tried adding an importer and recompiling, but I guess that the kids who would try aren't old enough to know Delphi/Pascal :P (and don't have $1,000 to buy the professional flavor of Delphi, which the program requires).

OpenZone's purpose is and always was to allow people to create their own original content, not to corrupt EQLive. If someone tried using it to do that I'd be tempted to exhort SOE myself to shut them down.

Though I've said all this, I should warn anyone who might try that OpenZone really doesn't have the architecture to fully support everything in a .WLD and if at all possible I'd like to keep it that way to discourage anyone from trying. I expect that anyone who tries to rig an importer onto OpenZone *will* be detected, and as far as I'm concerned, anyone who tries cheating EQLive deserves whatever punishment SOE dishes out.

[jbb]

I'm fairly suprised that they don't appear to digitally sign the resource files and exe files for eqlive and have the client check the signatures on startup. It's obviously not foolproof when the software is running on a potential cheat's own computer but it's really easy and would be a very good anti-cheating measure.

OpenEQ will suffer from that even more I suspect as being open source it will be a lot easier to cheat, and frankly a lot of the potential players are exactly the people I would expect to try to cheat Probably needs some thinking about.

[daeken_bb]

Originally Posted by jbb

I'm fairly suprised that they don't appear to digitally sign the resource files and exe files for eqlive and have the client check the signatures on startup. It's obviously not foolproof when the software is running on a potential cheat's own computer but it's really easy and would be a very good anti-cheating measure.

OpenEQ will suffer from that even more I suspect as being open source it will be a lot easier to cheat, and frankly a lot of the potential players are exactly the people I would expect to try to cheat Probably needs some thinking about.

Opensource games are no easier to cheat on than closed source games if you design the protocols properly. We can't use security through obscurity like SOE does to secure their games. Things like run speed and such will have to be serverside or there's no way we're going to be able to curb the cheating.

OpenEQ being Opensource will only force us to design a smarter protocol and server implementation that, if done properly, will not allow cheating.

[jbb]

Well I'm thinking of things like making a modified client which renders the walls slightly transparently so that you can see what mobs are around the next corner. It's not at all easy with EQlive but would be very easy indeed if you have the source code.

The server can obviously only send updates for nearby creatures but I think it's totally impractical to do complete visibility tests on every creature for every client on the server.

Also I think there are some things that you need to do client side simply through lack of cpu power on the server. I think that it's impractical to do all collision detection on the server for all players. Which mean that if people modifuy their maps locally they'll be able to walk through walls, and get to places they should be able to. I just don't think that any reasonable server is going to be able to spend the cycles to do full collision detection for all clients. Perhaps doing occaional random checks on the clients to catch cheaters would be enough

[a_Guest03]

Even if someone can see through walls, that doesn't help any more than ShowEQ. SEQ was very organized data - wall invisibility is opportunistic.