Reasons for this project

46 views
Skip to first unread message

poke

unread,
May 26, 2010, 12:22:54 PM5/26/10
to TexMod development
When I read this topic first on the wiki, I was really interested in
it. TexMod is a great tool, but it still misses some things, and there
is also the fear that it will be incompatible with future games. So
creating a new tool was a great idea.
The initial responses on that topic also showed that there are people
willing to help or at least are interested in such an application
being developed.

I, myself, don't have much experience with DirectX or related things,
but as you probably know, I'm a quite experienced software developer
and really interested in new things. So I see this project as a way to
learn even more, especially about DirectX (a topic which I have always
kind of ignored before). However, it's impossible for me to do this on
my own. I have created a DLL proxy before that was able to replace
textures with others, or to watch for certain events and do something
fancy (or something less fancy), so I have basic ideas on how to start
with this. But in the end, I won't _really_ know how to do it.
So basically by opening this project, I ask for people, who are
willing to help to get ideas and thoughts on the progress (yes, non-
coders are allowed to discuss too), and also especially for those
people, who are experienced with the stuff that is required here, or
are at least interested enough to learn about it quickly so they can
participate actively.

Again, this group is open to anyone who are interested in it. So if
you have ideas, suggestions, or are able to help in any possible way,
join and participate. Also, as soon as we have decided on the basics,
and have something to work on, I'll gladly invite every interested
programmer to the code project so they can participate.

Thanks for interest, and thanks in advance for your help.

poke

-----

The rest of this post is basically a response to Elephant's edit on
the wiki (http://wiki.guildwars.com/index.php?title=Talk
%3AGuide_to_modifying_in-game_graphics&diff=2032441&oldid=2032405).

» there are working opensource TPF unpackers on web, and soon a TPF
packer according to Kairu ;)
» You can make your own kind of packages (TPF is a non-readible
passworded zip + specific crypt) or extend it for other resources like
sounds, staying retro-compatible

Yes, but as of now, we can't say for sure if we can support the old
TPF file (or at least _I_ can't). We will see what our program evolves
to, and if we can, we will integrate as much of those things as we
can. It would be great if we would end up with a backwards compatible
tool.

As we also don't know (yet*) how TexMod worked exactly with all those
things, we might will need to come up with something new. Maybe that
new thing will be even more capable or more open (instead of a
protected zip file, we could easily just make a normal zip file with a
specific format inside. XPS does that for example, integrating both
binary ressources as well as XML based descriptions). And maybe we can
add something to use legacy TPF files (not create, but just use - or
repackage or whatever).

» Best would be direct RS author' accurate inputs about how he
identifies textures he wants to replace

I already contacted RS asking for support, by providing TexMod's
source and/or working with us together on the next version. I'm not
sure however if he will ever answer, but there is still hope.

» When you launch GW in Texmod, Texmod creates a binary module (in
your temp folder that is full of them... since they aren't
automatically deleted), it loads with GW.

» If you decide to reverse engineer signature/checksum computation :
do that on a DX sample application. It simplify things a lot...

I think that applies to the whole development of such a tool.

» There are artefacts in GW with Texmod : whole texture replaced by
red color. Is that a problem from Texmod interefering not perfectly
with DX, or is that a problem due to overlaping signatures ?

I'm not sure, but I think it might be because of filters being added
to the textures later. When working with my DX Proxy, I noticed very
often that the textures were altered on the fly; so your problem might
come from that.

» GW time life is ending soon ?

Ideally such a tool should not be create for just one application/
game. TexMod was created for Tomb Raider, but got used a lot for GW.
We should try to make our application generic enough to work with a
big set of games, so GW life is not an issue. (And I think all of us
are more thinking about GW2 after all)

» Texmod works for DX9, and it will be gw2 compatible, any clone you
make too.

TexMod is DX9 yes, but there are two newer versions; DirectX 10 exists
since Vista and DirectX 11 since Windows 7. It's unlikely that GW2
will be DX11, as that's quite new and won't be supported with Windows
XP; and as we know ArenaNet is trying to make the game work on a big
range of computers, so they won't leave XP out. But in the same way it
is very likely that Guild Wars 2 won't be DirectX 9; or at least it's
unlikely that DX9 will be default. ArenaNet is using Vista (or Win7)
computers in the office, so they might be focussing on DX10.
But similar how they did with DX8 in GW(1), they will probably add
some way to switch down to DX9 (I don't think 8 will be supported
though). However, and this is a big point for making a better
application, if such a switch involves a command line parameter,
TexMod won't be able to run it.
And in the end, it would be better, if we could support the highest
DirectX version a game offers natively without having the players to
miss better graphics just because they want to mod things. So we might
create multiple DX handlers in one application.

» Hope that RS author didn't just lose source code, yes, it happens
when you use less than 2 backups... Hope he didn't use 3rd party code
he can't release. ^^

I rather hope that he is willing to help us (and actually still checks
that mail account). Even if he doesn't have the code, it would be a
great help to have the person who created the original TexMod giving
us information on how he managed it to work etc.

Kairu

unread,
May 26, 2010, 3:44:39 PM5/26/10
to TexMod development
Yes, yes and yes. I agree with everything completely and you touched
on most if not all of the reasons I was also looking to start
production on a "new" texmod. It has been years now, and the original
just doesn't cut it anymore.

Though I'm not 100% sure that Texmod uses a proxy DLL (GW has been
killing external DLL access for a little while now with no ill effects
to texmod) I'm sure we can get it working.

I hope to be able to add to the project!

poke

unread,
May 27, 2010, 2:40:22 PM5/27/10
to TexMod development
> Though I'm not 100% sure that Texmod uses a proxy DLL (GW has been
> killing external DLL access for a little while now with no ill effects
> to texmod) I'm sure we can get it working.

They only removed that GW would automatically load an available
library in path (which would then replace the correct one); you can
still inject a library into a running process (something which
probably can't be prevented at all), so it might still work.

Kairu

unread,
May 27, 2010, 7:30:51 PM5/27/10
to TexMod development
Ah, one thing.

TexMod's TPF files are locked to prevent the everyday user from
opening it, changing things and putting it back in the wild under the
original authors name, or taking the credit of the original author by
just repackaging it.

I think it might be a good idea to keep this type of option in there,
but also allow unprotected versions.

CS Calli

unread,
May 28, 2010, 8:01:38 AM5/28/10
to TexMod development
We might want to be careful about .dll injections, I'm seeing a lot of
bans on the wiki from stuff that (supposedly) is client side only &
not a bot. I'm not saying we shouldn't do it, just to (very) be
careful.
Except I already have a program up that can convert a TPF in to a
ZIP...

Kairu

unread,
May 28, 2010, 11:13:19 AM5/28/10
to TexMod development
> Except I already have a program up that can convert a TPF in to a
> ZIP...

From what I saw it can't just repackage it, correct? I fiddled and
tried to merge two mods, but without the log file you can't do
anything. I realize you could create the log file by hand, but that's
still a lot of work. Most normal users wouldn't be able to handle it.

CS Calli

unread,
May 28, 2010, 3:38:36 PM5/28/10
to TexMod development
On May 28, 11:13 am, Kairu <kyle2...@gmail.com> wrote:
> From what I saw it can't just repackage it, correct? I fiddled and
> tried to merge two mods, but without the log file you can't do
> anything. I realize you could create the log file by hand, but that's
> still a lot of work. Most normal users wouldn't be able to handle it.

No, you can't just extract then re-pack, but it's a simple process to
fix the .def. You just add the path to where they are before the file-
name.
An example: The .dds is named "texture.dds"; It's in the "C:\mods\"
folder; Its .log line looks like "0xBCDB78DB|texture.dds". Just change
the line to "0xBCDB78DB|C:\mods\texture.dds", repeat for all other
lines, and rename the .def to .log.
That is assuming you have the .def file of the mod, which should
always be there.

And you can merge mods, I've done it multiple times. ;)
Reply all
Reply to author
Forward
0 new messages