New/old Elemental Graphics

I've been tinkering with decoding s3d and wld files a bit myself lately. Not in any great depth and not with the intention to edit & repack anything, but enough that I could theoretically maybe help with the more programmy aspects (though I have doubts about how flexible EQ would be about e.g. loading more textures for a model than it normally would etc -- but who knows). Probably more know-how to be found on the EQEmu forums than I can provide, though.

As far as converting DDS to BMP not working, would probably need to know more about how you're doing the editing and converting and exactly what BMP format it's converting to (pallettized? 24bit? what happens to the alpha channel and mipmaps from the DDS? etc) before I could venture a guess. No idea how much the client's loaders are willing to recognize.
 
That gnome elemental makes me want to play a mage. Really like the other ones too Ill have to swap this in. Thanks for the post
 
These elementals look good enough to go in the game, but I ran into some trouble when testing them. Specifically, the long 'tails' which were first seen in this post by Grinkles do not appear on pets. I think the tail is key to this look! If you illusion a player it works, but only for the male gender.

To be more specific, elemental pets are race 2 and texture 0-3. This re-texture has a tail only in race 0, texture 1-4 from what I can tell. (Texture 4 doesn't exist, but it defaults to 0 and somehow gives the tail.) I may be able to resolve this, but I am working from the other side of the issue. So, if any of you has some insight for me that would be great!

I would happily use some of those other elemental models in the post I linked above, as they are great, except that it would 'break' player pets in those zones. For example, using the ore elemental in BQ would cause player's pets to appear like that as well. That would probably be interesting, but I cannot think of a lore reason why player pets would do that!
 
These elementals look good enough to go in the game, but I ran into some trouble when testing them. Specifically, the long 'tails' which were first seen in this post by Grinkles do not appear on pets. I think the tail is key to this look! If you illusion a player it works, but only for the male gender.

To be more specific, elemental pets are race 2 and texture 0-3. This re-texture has a tail only in race 0, texture 1-4 from what I can tell. (Texture 4 doesn't exist, but it defaults to 0 and somehow gives the tail.) I may be able to resolve this, but I am working from the other side of the issue. So, if any of you has some insight for me that would be great!

I would happily use some of those other elemental models in the post I linked above, as they are great, except that it would 'break' player pets in those zones. For example, using the ore elemental in BQ would cause player's pets to appear like that as well. That would probably be interesting, but I cannot think of a lore reason why player pets would do that!

Long time no chat, Olive. :) Believe it or not, the tail found on the Fire Elemental (which we can only assume was an intentional difference) is handled as a head texture, meaning it can be configured separately from the body. Its head texture number is 01, I believe. It is possible to "fake" the tail instantly on the remaining three Elementals with a little cleverness, as seen here on a Water Elemental:

WaterElementalTail_zps984f6c51.jpg

I achieve this on my own character by applying Illusionary Leather, which renders my whole body in texture 01 (Leather armor), including my head. I can then do one of two things to prepare the tail on an Elemental form that does not normally have one (Earth, Water, or Air):
  1. Click off the Illusionary Leather, which bugs out the head texture, leaving me appearing to wear a Leather cap while the rest of my body appears with my worn gear, OR
  2. Leave the Illusionary Leather in place.

After doing either of the above, I then choose an Elemental illusion, such as Illusion: Water Elemental, which I cast upon myself to take on the Water Elemental texture. However, because my head texture is set to 01 due to the previously-applied Illusionary Leather, and because Illusion: Water Elemental apparently does not have any component that modifies head texture (unlike Illusion: Fire Elemental), the result is that my character shifts to the Water Elemental form with the Water Elemental texture while retaining the Fire Elemental tail! I'm not sure if or how this method can be applied to NPCs, as I'm not sure universally modifying head textures for all Elementals is viable, but let me know what you make of all this, Olive...
 
Last edited:
Trivially. All NPCs have an independent field for head/helm textures settings. I could've answered that one for you Olive!

That's good to hear. I knew they had separate fields but wasn't sure if it would be problematic to modify them without breaking something else or having to do elaborate scripting (like having all Elementals henceforth spawn as humans for a split second, converting to head texture 01, then doing a racechange to Elemental). I say this because if I try my above method in reverse order, as in doing Illusion: Water Elemental first and then applying Illusionary Leather, no change occurs; the Leather texture must be applied to a humanoid form first when it comes to a player trying to mess with things like this, though I suppose this limitation wouldn't apply when you have access to GM commands.

Regarding .dds to .bmp conversion, I'll have to do some more testing with it. I think the problem probably is to do with alpha channels and such as you suggest. Perhaps if I convert to .bmp before doing any editing, the problem will not occur.

Also, any news on .wld files? I suspected for the longest time that adding custom textures alongside existing ones could possibly be done with a heavy-duty hex editor by finding the portions of a .wld that relate to textures, copying them at the end, and doing a few minor tweaks like changing eleua0301 to eleua0401 (for adding a fifth Elemental texture, for instance), but then I realized that there was the colossal task of having to update the .wld file's entire string table from the point where new entries were inserted so as not to corrupt the entire file. A clever script might be devised for such a task, but there's no telling if the client would even accept such changes. (You can probably tell I'm no coder, so forgive me if I misuse a term or two! :psyduck:)
 
Also, any news on .wld files? I suspected for the longest time that adding custom textures alongside existing ones could possibly be done with a heavy-duty hex editor by finding the portions of a .wld that relate to textures, copying them at the end, and doing a few minor tweaks like changing eleua0301 to eleua0401 (for adding a fifth Elemental texture, for instance), but then I realized that there was the colossal task of having to update the .wld file's entire string table from the point where new entries were inserted so as not to corrupt the entire file. A clever script might be devised for such a task, but there's no telling if the client would even accept such changes. (You can probably tell I'm no coder, so forgive me if I misuse a term or two! :psyduck:)

I was looking at .wlds a bit last week but got discouraged before getting to the point of testing anything. Just redoing things I'd already done with them before was surprisingly trying -- hard to keep things straight about them -- I think I'll try to look at it with fresh eyes tomorrow. I'd been hoping to find something that explicitly associates a model with its alternate textures (as there is for the base textures) but no such luck. Alternate textures *might* be discovered by partial names or by relative positions, but some little inconsistencies lead me to think hardcoding may be involved. Maybe not, though! I think I'll try to test by appending a texture set to the very end of the .wld to avoid the re-indexing issue to start with and see if that gets anywhere. (Actually getting around to re-coloring a set of textures to test with may be the hardest part ;p hopefully there won't be any issues if I use something with .bmp textures...) If it comes to it, re-indexing the whole .wld would probably be aggravating but likely doable, though there could be issues if any of the not-figured-out-by-EQEmu-people fields in the .wld are index references; failing to update them along with everything else would definitely wonk things up.

It's possible all of this has already been figured out and I'm just not patient enough at searching through the EQEmu forums. Most of the info I have was pieced together more than a decade ago...

tl;dr no news, really. Would make sense for .wld files to be relatively flexible and thus editable (I think people have made their own zone geometry within the .wld framework that the client understood; they aren't exactly the same as mob models, but c'mon) while on the other hand, things like LoadArmor17-22 and the associations of model names (used in the .wld) to race ID numbers (which is all we use) not seeming to be in the .wld itself suggests that there's a precedent for stuff related to models being hardcoded. Will try things out in the near future. It's all a bit tedious, is all.
 
Well, partial success. I got an alternate texture to show up on a model by simply appending things to the very end of the .wld ... on the other hand, the game slows to about 1 frame every 30 seconds the instant the texture set appears before giving up entirely.

I'm hoping I just overlooked something. Maybe it's just getting stuck in loading mode. Promising, in any case.
 
Well, partial success. I got an alternate texture to show up on a model by simply appending things to the very end of the .wld ... on the other hand, the game slows to about 1 frame every 30 seconds the instant the texture set appears before giving up entirely.

I'm hoping I just overlooked something. Maybe it's just getting stuck in loading mode. Promising, in any case.

:monocle: :toot: Keep on chugging along, Zaela! This would be such a great way for SoD or any server to set itself apart from the competition. Oh, the possibilities! :dance:

Btw, was there any problem at all with having to update string tables? And did you use a hex editor? How are you "opening" these files in the first place? I know they can be dumped into text for viewing in something like Word or Notepad, but a text dump presumably wouldn't help at all with editing entries to be put back into the .wld, and the resulting files are gigantic.
 
And did you use a hex editor? How are you "opening" these files in the first place?

Hex editing would be far too tedious. I just wrote a messy little program to read in the .wld data and split it up, which I modify on the fly to spit out whatever I want to see at the moment. Or to put the .wld back together with extra stuff added to the string block and whatnot. Ugly ad-hoc programmy stuff. Could be reworked into a more general and usable put-textures-into-wld program if I can get things working right, though.
 
*uses this*

Such a lovely take on the classic elementals. It was enough to get me to switch back to classic from the Luclin models for them. :D

Thank you! I heartily cheer on any further work in investigating texture modding and other such stuff. :)
 
Been too lazy to work on the adding texture sets to .wld thing (think I'll have to try putting things in the order they normally appear in the .wld, bit of a tedious bump of setting up to do before I can give that a go...). In the meantime I wanted to see if I could make some arbitrary things semi-transparent.

nPjvu2q.jpg

qUAZfcL.jpg

6LpBd9q.jpg

hfNLcda.jpg


Much easier, apparently. Probably not so interesting though.
 
Don't discount the usefulness of transparency, Zaela. You may have just opened up a whole new world of options for custom zone-building -- now there would be an easy way for any developer to create a "ghost" or undead version of any mob in the database without even having to do any palette swapping on the textures themselves! Making natively transparent models non-transparent might present some interesting options, too; I'm thinking of the ghosts used in Highkeep and North Freeport, for instance.

I'm also wondering about how your advances might be applied to armors and especially held items. For instance, if you could find it possible to insert multiple copies of, say, the model for Wand of the High Researcher, it might then be viable for yourself or another dev to color the textures in a totally different way (including particles, which I've demonstrated in this post), thereby vastly expanding the potential for diversifying the way our characters look. When a high-profile weapon model is shared by several pieces of raid loot, a dev could in theory clone the model a few times and colorize or retexture each one in a unique way that has never before been possible. Unique items could be given truly unique looks in order to differentiate them from other items using the same model, meaning we'd no longer have to "save" the coolest-looking weapon models purely for a single high-end drop or whatever the case may be. I'm not even sure if this is possible in the same way it is for adding new textures or transparency, though, because it would involve asking the database to load entirely "new" model IDs instead of a new texture within an already-present model....

I look forward to any other updates, even if the above isn't of interest to you. Also, feel free to take them to your own designated thread or to my own thread on texture editing if you feel the need, seeing as we've derailed this thread for several posts now. ;)
 
Back
Top Bottom