Introduction of OpenTexMod

[ROTA]

OpenTexMod (OTM) is the (state of the art)++ of modding texture ;)

First of all:

DON'T USE OpenTexMod WITH AN ONLINE GAME!!
The game can detect if they are modded, so your game account might be
banned!!
Just wait for a release, and maybe the game designer will endure
officially the release version of OTM.


OTM is separated in two parts a library and a GUI. The dll will be
explained more in detail in an extra post.

what I used to compile (and probably you will need):
- Visual Studio Express 2010 (compiling the dll)
- mingw32 (gcc) v 4.5.2 (compiling GUI and using makefiles for dll and
GUI)
- Windows SDK
- Microsoft DirectX SDK (June 2010)
- wxWidgets 2.9.1 (GUI)

I have tested it with:
- Win 7
- Battlefront II


how to compile:
OTM_DX9 (dll):
1) the dll will only work, if the name of the executable is saved in a
file (currently: D:\OTM.txt). If you want to change this file name,
you have to edit in OTM_DX9_dll.cpp the HookThisProgramm() function.
2) make (you will need to open the special command prompt of Visual
Studio)
OTM_GUI (GUI):
1) in the makefile: change the WX_DIR to your installation directory
of wxWidgets
2) make

how to run:
create D:\OTM.txt (or to you changed it) and simply write the name of
the executable you want to mod. One executable per line (without the
path and with .exe)
e.g:
Game1.exe
Game2.exe

Now start the OTM_GUI.exe in the bin directory.

The GUI is not developed so far, cause I don't know, if we will stay
at wxWidgets or not.

If you have started the GUI, you can simply start your game by your
self (you can't at the moment and you don't need to start it through
the GUI). If everything works, a new tab should open in the GUI (which
doesn't look great, but for testing purpose it is fine). The 3 Choices-
Handle will be in future to choose the keys for extracting the
textures. Currently they are:
back: Numpad /
save: Numpad *
next: Numpad -
You need to set a save directory, each time you start the game (only
if you want to save textures)
You can add a texture to mod by pressing the open button (if ticked,
the texture will be modded, else it will be unmodded)
And don't change the name of the saved texture, if you want to load
them as a mod (OTM extract the hash value out of the file name)
Submit each change by pressing the update button


Current features of OTM:
- load and remove textures on the fly
- save all textures (switch on/off on the fly)
- save single textures (switch on/off on the fly)
- command line support for the game is obsolete, cause you can start
the game by your own
- it can handle more than one game at the same time, even more than
one instance of the same game, each with different mods etc. (but I
have only tested with one game)


What should be done in future (GUI/dll):
- easy way of getting the user directory to store the OTM.txt. So the
GUI can modify this file and thus control on the fly which games
should be hooked or not.

What should be done in future (GUI):
- first of all: make the GUI more user-friendly and find errors ;)
- create and save standard scheme for each game, that will be loaded
at game start (see OTM_GameInfo)
- command line support for the GUI
- start the game with command line support also from the GUI
- intelligent update routine (now each ticked texture is reloaded and
each non ticked is removed, while pressing the update button, but the
dll can deal the difference to the old mod)
- zip-file support (if we stay at wxWidgets this should be easy)
- Onscreen display for save single textures
- add multi language support (first steps are done)

What should be done in future (dll):
- find errors
- speed up the OTM_TextureClient::MergeUpdate(), because this function
is called from the game-render-thread during rendering a frame!
- port the dll to dx8, dx10 and dx11. if dx10 and dx11 (hopefully this
will be a simple copy and paste with little changes, we can do this if
OTM works fine with dx9)


so far ROTA

[ROTA]

I forgot 3 things:

1) You may have to change the include directories of you windows SDK
as well as the directx SDK in the makefile of OTM_DX9

2) I uploaded the compiled code to the download section. All you have
to do, is creating D:\OTM.txt
but it might run only under win7, because I didn't pay attention
on including the windows.h downgrade compatible.

3) Probably we will not be able to use the mod-files *.tpf of the
original TexMod (even if we could read these files, we won't be able
to use them, because we don't know the hash function of the original
TexMod, see dll introduction part 3)

[CS Calli]

I can't speak about the Hash, as I haven't a clue about it either, but
reading and opening a tpf file is relatively simple; It's just a zip
file, with a un-typable password, and a XOR operation done on it. If
someone could figure out what the hashes mean, then we're set...

[ROTA]

As you can imagine, I didn't invent all the stuff by my self. The
trick with the inherited classes can be found in the internet.
Also a certain hash function is implemented (just search for
hkIDirect3DTexture9 or see below).

The problem is the size to pass to that function. I have read
somewhere size=width*hight/2. But I guess, one can also pass
width*hight. I think width*hight/4 is the minimal size of a packed
textures.

But as I have posted, I don't know if this hash-function is used, if
this calculation of the size is used, and if the hash is calculated
over the raw texture data or not.

At the moment an other hash function as well as size estimation is
implemented in OTM. But maybe we should give the following hash
function with size=width*hight a try.

DWORD QuickChecksum(DWORD *pData, int size)
{
if(!pData) { return 0x0; }

DWORD sum;
DWORD tmp;
sum = *pData;

for(int i = 1; i < (size/4); i++)
{
tmp = pData[i];
tmp = (DWORD)(sum >> 29) + tmp;
tmp = (DWORD)(sum >> 17) + tmp;
sum = (DWORD)(sum << 3) ^ tmp;
}

return sum;
}

[ROTA]

RS told me the hash function of the original TexMod and I have added
tpf support.
and for that also zip support. Just zip all the modded textures.

But at the moment there is no check if fake textures are loaded for
the same hash more than once, this will result in uncontrolled
behaviour.



I have seen there are at least 5 downloads of the r3-version. Are
there any comments about functionality, errors, crashes?

Did somebody try to compile the code for itself? errors/success?

Anybody out there, who want to help coding some stuff?

[CS Calli]

I've downloaded it and took a quick look. Running it on Guild Wars
(not loging in, just the title screen) works fine. Adding tpf's works
as expected (and much faster then TexMod). But, if I try to uncheck a
tpf then update, I get this:
"*--> Crash <--*
Exception: c0000005
Memory at address 00000000 could not be read
App: Gw.exe
ProgramId: 1
Build: 34247
When: 9/16/2011 09:22:05
Flags: 0". Saving dds files also worked fine.

I would try a compile, but I'm pretty tight on space on the moment and
can't install MSVS or the DX-SDK.
As for helping code, much of the stuff here is beyond what I can do;
But if I can help I'll try!

One question about the zip support and stand-alone dds, though. Does
they still need the texmod.def files? If not, how does it know what
files replace what?

[ROTA]

The crash is not good^^ It seems it deletes or try to accesses a NULL
pointer.

btw: the logging is turned on. In the game directory the file
OTM_log.txt holds a lot of information about the last run. If it
crashes again, this file would be helpful.

At the moment, the most thinks have to be done in the GUI, therefore
you need any compiler and wxwidgets, but this requires also 360MB
(depending on the version).

The zip file can hold a texmod.def, which is similar to the texmod.log
files (the same file but without the path). If a texmod.def file is
present only the texture out of this def file are loaded.
If no def-file is present it loads the crc32 value from the file name
(the same way it is done if you add a dds file directly). The file
name must match the wildcard *_hexnumber.dds. The name of the game is
not checked.
if a tpf file is loaded, the xor operation is done and afterwards it
is treated as regular zip file (with password).

Thinks to be done in the GUI:

The name of game (to be hooked) must stand in "D:\OTM.txt" which is
not user friendly. I didn't figure out a SHORT method on how to get
the C:\Users\xxx\Application Data directory. This method must be
compatible with WinXP. Afterwards a menu entry for adding an removing
an entry in to the C:\Users\xxx\Application\OpenTexMod
\HookedGames_DX9.txt should be added.

The GameInfo class serves as a storage for loaded textures, key-
values, paths etc (for each game which is running and hooked by the
dll). A save and load function should be added, afterwards we can load
the last saved settings on game start and send it immediately to the
game.

If the texture are send to the game following two thinks are not
supported yet:
1) crc32 value is not checked, that means several textures with the
same value can be loaded
2) atm each time you press the update button all the texture are send
again to the game. But the dll supports already to receive only the
difference to the old state. It even holds the the texture if they are
unloaded, if reloading it again, it do not need to receive the whole
texture again (but a transfer method without the content of the
texture is not implemented yet).

Atm the GUI looks awful. A concept must be created as well an
implementation done.

Key support: currently the keys for the one-file-logging mode are set
to Numpad/ Numpad* and Numpad- (through the GUI). In the language
class the names for the keys must be inserted into a wxArrayString and
the corresponding key values (int) must be stored in the same order
into an array. The correct values are commented out in the
OTM_Language.cpp file.

Language support: loading the messages from a file (English should
rest in the code itself, to ensure a stable run, if files are missing)