WLD Editor Suite

[Zaela_S]

...for Windows.

Currently comprising two small programs:

* Texture Adder - for adding new texture set data, allowing you to add custom mob model textures under new IDs rather than overwriting old ones.
* Transparentifier - for editing texture visibility flags, allowing you to e.g. tell the client to render arbitrary textures as semi-transparent, turn full transparency masking on/off, etc.

Link

Proof of concept:


gfaydark_chr.s3d normally has 3 golem (GOL / race 17) textures, IDs 0 to 2. Here the number of textures has been expanded to 7, IDs 0 to 6, using the Texture Adder. Two of the added textures were made semi-transparent using the Transparentifier.


Instructions for Texture Adder:

1. Pick your desired _chr.s3d file and make a backup copy of it.
2. Extract the internal .wld file using S3DSpy.
3. Run Texture Adder and select the .wld file from File > Load WLD. This will produce a list of model texture sets, like so:

4. Select a model texture set from the list.
5. Hit the "Add Texture Set" button. The texture set data entries for your current selection will be copied, and the newly copied data will be renamed under the next available ID. For example, if we selected FEM01 from the above list and copied it, we'd end up with a new entry for FEM with ID 02.
6. Using S3DSpy, note all the textures belonging to the model and ID you copied, e.g. FEMCH0101.bmp, FEMCH0102.bmp, FEMLG0101.bmp, etc, where the format is MDL__ID__.bmp. Create your new textures based on these and give them the new ID, e.g. FEMCH0201.bmp, FEMCH0202.bmp, FEMLG0201.bmp, etc.
7. Insert the your new textures and the edited .wld file into the _chr.s3d file using S3DSpy.
8. Voila!

Note that the texture set data in the .wld file is different from the texture files that go into the .s3d. Other than the visibility/transparency settings (and some unknowns, see below), they basically just tell the client "a texture with this name exists, and you should try to load it for this model and ID".


Instructions for Transparentifier:

1. Pick your desired _chr.s3d file and make a backup copy of it.
2. Extract the internal .wld file using S3DSpy.
3. Run Transparentifier and select the .wld file from File > Load WLD. This will produce a list of texture data, like so:

The names should line up with the names of .bmp files in the .s3d. Most of the data fields on the right have unknown functions (and are presented just in case anyone might want to try to figure someting out by looking for patterns), but the one we're interested in is the "Visibility Flag". Typical textures have values like 0x80000013 or 0x80000014. The "Visibility Flag binary" field represents the same value, but in binary (obviously). This field can be edited; each of the ones and zeros potentially corresponds to one setting being turned on or off for that texture. Which bits do what has not been thoroughly tested, but the user is free to experiment. On the other hand, if you just want to make something semi-transparent, a button is provided to do just that. Note that the button is not very smart -- it justs pastes 0x80000017 over the current value rather than setting specific bits (I'm too lazy to puzzle out exactly which bits are needed just yet). This should work fine for textures that have values of 0x80000013 or 0x80000014 beforehand, but may cause crashes on others.
4. When you've changed what you want, insert the .wld file back into the .s3d file using S3DSpy.
5. Done!


Note that neither of these programs have been very thoroughly tested, so they may well have bugs, and they obviously aren't super user-friendly as far as the information that is displayed goes. Furthermore, they've only been tested at all for mob model textures from _chr.s3d files; whether they would be able to do anything useful for equipment models or zone geometry is unknown, but you're welcome to try.

If there is any interest in all this, I could maybe make improvements/figure out more .wld data to edit and release later versions.

One last note, if anyone has any cool custom mob model textures or decides to make some using these programs, the folks at the Shards of Dalaya server would be happy to incorporate them into their world as brand new alternate textures.

[Akkadius]

This is cool as shit, nice job

[Dunge0nMastr]

Very awesome!

[Akkadius]

Zaela, posted on the Wiki: http://wiki.eqemulator.org/p?WLD_Editor_Suite

Let me know if you want access to make changes to Wiki documentation.

[moofta]

Looks groovy. Where can you get the current S3DSpy from? Whenever I search for it I either get 404's or Spy Kids 3D

[Zaela_S]

Originally Posted by moofta

Where can you get the current S3DSpy from?

I think the version I have is outdated (1.1)...

If anyone has the newest version I could arrange to have it hosted alongside these.

[Akkadius]

Originally Posted by Zaela_S

I think the version I have is outdated (1.1)...

If anyone has the newest version I could arrange to have it hosted alongside these.

The Wiki can host anything as far as files. Already has quite a few programs on there.

[ChaosSlayerZ]

RE: SoD

some of their achievements in this area:
https://shardsofdalaya.com/forum/thr...editing.28215/

also some of Vaion of THF achievements on custom particle effects:
http://www.thehiddenforest.org/viewt...hp?f=4&t=10557

[Akkadius]

Someone needs to take ownership of 3D modeling and the Wiki 3D modeling resources.

[Tyen05]

Originally Posted by Zaela_S

link

Thanks for contributing this, amazing work.

This really is such a great tool to have in the Everquest Developers arsenal. It's 1/3 of having the complete ability to customize Everquest npcs/pcs (textures, animations, models).

Can't thank you enough for providing this to everyone, and taking the time to create it.

[Zaela_S]

Added a couple more small things to the download link at the top:

* Weapon Copier - for copying (old) weapon models and textures under new IDs of your choosing, to allow alternate skins etc.
* Info - a mostly useless and woefully incomplete WLD data browser. Mainly for my own benefit; adding different data as it becomes relevant/confusing to me.

Important note about the Weapon Copier: right now it doesn't support weapon models with animation (i.e. particles and things with attack animations like whips and classic Cleric epic). Such models are excluded from the list when you load the .wld. Animation data is fairly complicated compared to simple texture stuff, not helped by the fact that, unlike with mob models, item models reuse data a lot, complicating making completely separate copies a bit. I might work on particles, but on the other hand it may not be worth the effort -- .s3d-based item models are not terribly impressive in the first place. Dunno.


Anyway, the instructions for Weapon Copier are pretty much the same as for Texture Adder, the main difference being that you get to input the new ID number you want your copy to have. (It's up to you to make sure you use a free ID.) Also, because the names of textures items use are not necessarily as consistent as for mob models, when you make a copy a .txt file will be made detailing the source texture files and the new names they will be expected under. For example:

it335_info.txt
IT174BLADE.BMP -> IT335BLADE.BMP
IT174METAL.BMP -> IT335METAL.BMP
IT174HANDLE.BMP -> IT335HANDLE.BMP
IT174GEM.BMP -> IT335GEM.BMP

Also, fixed a couple potential bugs in Texture Adder.

[Zaela_S]

S3DSpy kept crashing/hanging on me trying to insert anything at all into certain files (gequip.s3d, omensequip.eqg... inexplicably, since they're all structured identically as archives). Made a quick replacement just for importing and exporting files from .s3d/.eqg: EQGExport. It's a bit more ergonomic than S3DSpy as well if I say so myself. C++ source is included.

Also added another small thing to the WLD Editor Suite -- an editor for particle data for .s3d-based weapon particles. Most fields are unknowns, but I managed to find the ones for particle lifetime, delay between emissions, and how many of the same particle can be alive at once. Which is enough to make old weapons pump out absurd amounts of particles. With some trial and error and observation of a certain flag one can also change whether the particles stick around a weapon as it swings (animating stictly in weapon-space) or trailing behind it as it moves (animating in world-space around the point at which they were emitted).

The particle editor has EQGExport integrated into it so there's no need to export and import from the .s3d's as a separate step. If I make any other tools they'll also have this.

[sorvani]

This is good stuff.

[knowom]

Looks like a good tool and I imagine "Transparentifier" could be interesting if it works on zones also for say a semi transparent spectral ghost town sort of texture effect. I really wish there was like a SQL table that could be created to texture swap textures within .s3d files. That would be a ideal way around the copyright distribution dilemma of texture modding EQ s3d files while enjoying the zones we've grown fond of navigating. Open Zone was a good idea had the right intentions, but seems like it's been stagnant for awhile and could have benefited from being able to easily import Blender's 3D modeling file format.

[Zaela_S]

Yeah, I missed the early days when it seems legal issues were discussed here a lot. Don't know much about all that stuff; curious where exactly the line would be drawn. Can I modify my own files? (Well, not much they can do there.) If so, what's to stop me from making and distributing a program which modifies peoples' files for them in a pre-set way, e.g. inserting new textures into an .s3d and modifying a .wld, but not distributing any of the original data from those files? Probably too blatant a loophole... presumably "modify" does come right after "distribute" on the list of Things You May Not Do.

For mob models, at least, I would be interested to see if they would work split up. I.e., load the file containing base data for a certain model, then load a brand new custom-made file which only contains data for a new texture set for that model. Would depend how the client's loader is structured -- but it already surprised me with how permissive it is: the Texture Adder just shoves new .wld data at the very end of the file rather than following the internal ordering/structure, and it works. Being in separate files is only a step further than that. Maybe.

I'm kind of disappointed that people in the early days were only really interested in custom zones and not, say, item models (to the extent than stuff is only documented as far as it is relevant to zones). Item models seem like they might be pretty open to having brand new data loaded from new files. (Unlike mob models which as far as I can tell are dependent on the client for the translation from 3-letter model code to race id numbers that go in server packets.)

Blah blah blah...