Re4 TexMod pack doesn't work. Couldn't open file error.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start OTM, add game.exe, e.t.c as described.
2. Play Resident Evil 4.
3. Use EFF-TPL textures replacement pack 1.1 by Albert (works fine with 
original TexMod).
4. Try to update the game (update button in OpenTexMod).
5. Nothing happens (nothing changes). :(

What is the expected output?
Working HD textures in menus, e.t.c. :)

What do you see instead?
Nothing changing.

What version of the product are you using? On what operating system?
v0.9 r8 with Re 4 multilang european release. (Win7)
EFF-TPL textures replacement pack 1.1 by Albert texmod pack.

Please provide any additional information below.
Hi ROTA! Thanks for working on an open-source TexMod-like tool,
that's greatly appreciated, deep respects to you!
However, I couldn't make it work in the above-described situation.
I've tried all methods available: Packing dds's into a ZIP, with texmod.def in 
the root of the zip, using TexMod-created TPF file, even loading textures one 
after another in the main window.
The results were as such:
1) Zip file - no errors, seems to be updating the game (lags as if it loads 
textures after pressing "update"), but nothing changes in game, except that the 
buttons for selecting which texture to save start to actually work.
2) TPF file - no errors, seems to update the game, however, nothing changes. 
(Must also mention, that TPF didn't work in the original TexMod either, I used 
def's in logging mode instead to make the pack work.)
3) Individual textures - gives error "Couldn't open file" when trying to update 
the game. Obviously, nothing changes. Tried r6 instead of r8 - no errors, but 
nothing changes.
Those same textures work fine with the original TexMod, so they should contain 
no file errors. Checked against your source code, it seems that the only place 
in it that seems to give the related error, is when the textures are being 
loaded into a buffer-like structure (tex->Textures[0]) within "int 
OTM_Sender::AddFile(...)" function.
Exactly, I'm suspicious about this fragment:
    unsigned int result = dat.Read( (void*) tex->Textures[0], len);
    dat.Close();

    if (result != len) { ...Here error goes... };
I haven't worked a lot with wxWidgets, which you seems to be using here, so I 
don't know what wxFile.Read returns, judging from your code it's the size of 
the data read, so it's possible that it somehow can't read the entire file, 
although I have no ideas why so.
I used the texture-saving tool within OTM (works perfectly, BTW) to check 
whether the textures hashes match (I thought they may have been different, and 
that's why textures don't work), but they match pretty perfectly, so that's not 
a reason.

Now, I know this is an alpha-version, so I don't except much, the fact it works 
at all (at least the feature to save the textures) is already promising a lot, 
but I'm looking forward to see it released, and if I can help somehow, I'll be 
glad to provide some assistance.

Best of luck to you!
Thanks again for working on an Open Source TexMod! :)
Alex

Original issue reported on code.google.com by evilgnos...@gmail.com on 1 Oct 2011 at 10:26

[GoogleCodeExporter]

what do you mean with HD? Are the textures greater than 16MB on diks?? If so 
the pipe buffer is to small and he does not send the textures to the game.

The next possible error could be the crc32 function, although it is the 
original function, I might calculate the size of some texture formats in an 
other way than the original TexMod. Maybe you have such an texture format. I 
will think about an easy way for you to detect if so...

Then I am a little bit confused about, what you have said about the tpf file. 
Does it work in the original TexMod in the normal mode or only in the loging 
mode??

Did you tried to save a texture, modified it and load it into the game again?

wxFile.Read returns the number of bytes which have been read. An error at this 
points means, he could not read out of the file. Somehow the wx2.9.1 seem to be 
buggy, I try to compile with wx2.9.2 now.

I am currently updating the features, e.g. a tool tip will po pup, when the 
mouse is over a package. But I have some bugs while unzipping. It seems it will 
take some days to debug :-(

But you can gather more informations, if you look into the OTM_log.txt in your 
Game directory. If textures has been send to the game, you could read something 
like:
MainLoop: run
MainLoop: read something (1311420) <- he reads 1311420 bytes
MainLoop: CONTROL_ADD_TEXTURE_DATA (0X1A92B5F2  262272,  12 1): 71904248 <- is 
the hash ok? the next number is the size of the file (in bytes)
OTM_TextureServer::AddFile( 146735148 262272, 0X1A92B5F2, 1): 71904248
End AddFile(0X1A92B5F2)
OTM_FileHandler::Add(71907312): 71905336
PropagateUpdate(0): 71904248
PrepareUpdate(146734916, 146734924): 71904248
AddUpdate( 71937656, 5): 71905960
MainLoop: run
MergeUpdate(): 71905960 <- this comes from the render thread while rendering 
the next frame

search in this file for the hash, do you find lines like this:
OTM_TextureClient::LookUpToMod( 71932512): hash: 0XF037EB98,  71905960 <- this 
is done for each texture loaded by the game, you should find at least once, 
such a line with your target hash, if not, I calculate the size wrong (see 
above)
LoadTexture( 71937752, 37745712): 71905960 <- hit
LoadTexture(): DONE <- load successfully

Original comment by c...@koerner-de.net on 2 Oct 2011 at 8:29

[GoogleCodeExporter]

Thanks for the reply! :)

> what do you mean with HD?
:) Lol, HD became such a cliche "word" nowadays, nobody cares to explain which 
meaning is being used. Unfortunately, me included. Pardon me. I meant "High 
Definition" in comparison to what the game originally offers. They're all less 
then 16Mb (most often even less then 1 Mb) in size and are standard 
DDS-textures.

> I will think about an easy way for you to detect if so... (crc32)
Would be nice! :)

> Then I am a little bit confused about, what you have said about the tpf file. 
Does it work in the original TexMod in the normal mode or only in the loging 
mode??
It only worked in logging mode for me, but this maybe due to the fact I used 
ENB mod (a modified d3d8.dll put into a game folder, essentially) with the game 
at the time. It may have interfered with the way textures were loaded into the 
game.
I removed this mod when I started to try out OTM, though, exactly with the 
thought to reduce any unnecessary interference in mind. I must admit, I haven't 
given the original TexMod a try in TPF mode after that yet.
As to the issue of whether this package actually works in TPF mode at all -- 
such a mode is suggested as "recommended" by the package authors in it's readme 
file. Since that package is available for a lot of years (starting 2007, 
maybe?) and hasn't been modified - it can be theorized it should work as TPF.
I'll give the original TexMod another try (without mods) and let you know how 
it turned out.

> Did you tried to save a texture, modified it and load it into the game again?
Not yet. Good idea. Will give it a try and report result afterwards.

> Somehow the wx2.9.1 seem to be buggy.
Tried it myself for a project of mine, couldn't get it to compile properly :( 

>But you can gather more informations, if you look into the OTM_log.txt in your 
Game directory...
I've attached my log to this message. This may not be the log used to save 
textures from the game, as I've removed the log at some point of testing to 
start it again. This is probably the log from my attempts to add the package as 
ZIP-file or as individual textures. Interestingly, I can't find and references 
to the LoadTexture() function in it. Most probably error happens before it can 
be called.

Original comment by evilgnos...@gmail.com on 3 Oct 2011 at 3:19

Attachments:

• OTM_log.txt

[GoogleCodeExporter]

Was this log created with any version before r8??
The texture was send as "remove" to the game. So you might not set the tick 
before the name of the package or you have used an earlier version. In r7 and 
maybe also earlier, if you have added a mod, you could not toggle the status 
(load or unload) of a mod. You needed to save it as default and run the game 
again, to be capable to mod or unmod a texture.

Do you really mean d3d8.dll-> DirectX8?? But since the log file exist, and 
texture were loaded, the game has used d3d9.dll
I don't know what could happen, if you have a second d3d9.dll in the games 
directory. I think many things can go wrong.

>> I will think about an easy way for you to detect if so... (crc32)
> Would be nice! :)
The simplest way would be: you save the target texture with my tool and compare 
the hash with your texmod.def files.

btw: The log file is overwritten each time you start the game.

Original comment by c...@koerner-de.net on 3 Oct 2011 at 7:17

[GoogleCodeExporter]

Sorry, was sleepy :) It's been 8 A.M. for me when I wrote the message above.
It was d3d9.dll (DX9) of course. I removed it when I started trying OTM out, so 
it's of no consequence.

1) R8 was used for all the steps below. No d3d9.dll mods were used. The game 
was captured by Add game menu within OTM.

2) The hashes for the textures match perfectly. a1.zip file was used as a 
package. texmod.def is in the root of it. This file is saved as default setting 
prematurely, as you described above.

3) No amount of clicking on "update" with just the ZIP-file produces any 
visible result.

4) I tried saving a texture, editing it (Photoshop CS2 with Nvidia DDS plugin) 
then loading it back to the game, but the OTM says "couldn't send to game \ 
couldn't open file", just like with the package textures. (Log file attached as 
OTM_log.txt)

4) I even tried to just save the texture (WITHOUT modifing it), and load it 
back... But guess what? The same error! (Couldn't open file.) The log it also 
attached as OTM_log2.txt This can not be a crc32 error OR the texture format 
error, since the texture had been saved by the OTM itself, was NOT modified, 
e.t.c

This leads me to believe that the problem happens on the stage where OTM loads 
textures. Most probably a wxWidgets issue.

Original comment by evilgnos...@gmail.com on 3 Oct 2011 at 12:57

Attachments:

• OTM_log.txt
• OTM_log2.txt

[GoogleCodeExporter]

Oh, and here's the texture I saved, for your reference in case that's helpful.

Original comment by evilgnos...@gmail.com on 3 Oct 2011 at 1:04

Attachments:

• game_0XD2BD45FA.dds

[GoogleCodeExporter]

In the first log file the game received a lot of texture, but they were all 
marked as remove. Which is strange, since you have used r8 and I am sure you 
have set in the GUI the tick before the package name.
According to second log file, no textures were send to the game.

So both should be a bug in the GUI. And I am even more concerned about, that it 
could not load the single texture file, since this means something went 
terrible wrong.

I have uploaded r9, which supports comments out of tpf and zip files (if a 
"Comment.txt" is in the zip file). For that I have coded a lot around the 
loading of files. Hopefully I have solved also the bug, you have found.

Thank you a lot for testing and writing this issue!

Original comment by c...@koerner-de.net on 4 Oct 2011 at 8:27

[GoogleCodeExporter]

Thank you, I'll test it right away! :)

Yes, I've tried both setting and removing ticks to no avail in r8.
We'll see what r9 brings.

Original comment by evilgnos...@gmail.com on 4 Oct 2011 at 9:31

[GoogleCodeExporter]

Okay, I've given r9 a try, and the bug with loading SINGLE textures is gone for 
good. I've managed to save a texture, modify it and put back to game, and it 
worked perfectly.

Loading a ZIP-file still has no effect however. I'll keep trying, and if it 
won't work I'll send you a log.

Original comment by evilgnos...@gmail.com on 4 Oct 2011 at 10:40

[GoogleCodeExporter]

Both TPF and ZIPs seem not to work, with RemoveTexture still being the case in 
the log.
I was able, however, to get all the textures working (in r9 of course) by 
adding all of them in the "OTM_GameSave_game.txt" file by writing the list of 
them preceding with "Add_true:".

I must admit, your program works extraordinary fast!
It took the original TexMod up to a minute to load all the textures from the 
pack, while OTM seems to load them on the fly.

The log with the attempt to load a ZIP-file is attached.

Original comment by evilgnos...@gmail.com on 4 Oct 2011 at 11:22

Attachments:

• OTM_log.txt

[GoogleCodeExporter]

As in some previous log-files, also in this one the game did not receive any 
texture from the GUI.

I try to sum up what you have done:

1) You have added zip and tpf files. Both seem to be loaded but send to the 
game as "remove".

2) If you add the zip and tpf file in the OTM_GameSave_*.txt and mark them as 
true, they will be loaded correctly into the game and you see the mod working.

What happens, if you add the files and click on "Save as default"? Are they 
marked correctly as true or false (either the thick is set or not) in 
OTM_GameSave_*.txt?

And if you have saved something in OTM_GameSave_*.txt (either by hand or 
clicking the "save as default" button), are the ticks of the packages correctly 
set, if the game starts?

I am sorry, for all these questions and the fact, that debugging took so long, 
although it should be a simple bug. But on my system everything work as it 
ought to be.

Original comment by c...@koerner-de.net on 5 Oct 2011 at 8:43

[GoogleCodeExporter]

> If you add the zip and tpf file in the OTM_GameSave_*.txt and mark them as 
true, they will be loaded correctly into the game and you see the mod working.

No :) Cause that' exactly what I did with the log above. Doesn't work.

> What happens, if you add the files and click on "Save as default"? Are they 
marked correctly as true or false (either the thick is set or not) in 
OTM_GameSave_*.txt?

Exactly what the log above shows. 
The exact line in the file states:
"Add_true:E:\Games\Resident Evil 4\A1.zip"

The contents of the "A1.zip" are as such:
Files like "GAME.EXE_0x0029B5FF.dds" and so forth.
And a file "texmod.def"
with strings like "0x0029B5FF|.\GAME.EXE_0x0029B5FF.dds" (that file works with 
the original TexMod).
I'm starting to get a feeling, that maybe "texmod.def" is somehow incompatible 
with OTM, but the fact that the textures are processed even trough "remove" 
shows that it at least tries to read them... Strange.

> are the ticks of the packages correctly set, if the game starts?
Yes, the ticks are set correctly.

I've attached both texmod.def from the ZIP and gamesave settings file used.

Original comment by evilgnos...@gmail.com on 5 Oct 2011 at 11:44

Attachments:

• OTM_GameSave_game.txt
• texmod.def

[GoogleCodeExporter]

> I must admit, your program works extraordinary fast!
> It took the original TexMod up to a minute to load all the textures from the 
pack, while OTM seems to load them on the fly.

I though it worked, cause you have stated this two lines^^
Well, if the GUI just want to remove files, it does not unzip each file, it 
unzips only the texmod.def file and extract the hash values. This should 
obviously be faster than extracting each file. If it would add the textures, it 
would unzip all of them. If it could not unzip certain textures, an error would 
be raised and this textures will not be send to the game (also not as "remove").

This OTM_GameSave_game.txt is not saved with the r9 version?? Because there is 
save single texture set to true, but no keys are set. This should not be 
possible in the r9 version.

Can you add more zip files (no matter if they contain textures or not) set some 
of them as true and others to false and save again and look, if all of them are 
set correctly to true or false in the save file?

Original comment by mar...@koerner-de.net on 5 Oct 2011 at 1:13

[GoogleCodeExporter]

> I though it worked, cause you have stated this two lines^^

Okay, I probably said something, that made you misunderstand me, I'm sorry!

Let me put as simple as possible: It did work.

Just NOT with ZIPs or TPFs. :)

Instead, I have manually added, using NOTEPAD, each of 1331 textures into 
"OTM_GameSave_****.txt". 
Like that:
Add_true:E:\Games\Resident Evil 4\TEXTURES\GAME.EXE_0x0029B5FF.dds
Add_true:E:\Games\Resident Evil 4\TEXTURES\GAME.EXE_0x00775A4D.dds
Add_true:E:\Games\Resident Evil 4\TEXTURES\GAME.EXE_0x007B48F4.dds
And so 1328 times forth. :)
And that (loading a lot of "SINGLE" textures, instead of one ZIP) made it work.
And it loaded all 1331 in no time, when it took original TexMod a minute and 
half. That's incredibly fast. :)
That's what I meant by those two lines :)

> This OTM_GameSave_game.txt is not saved with the r9 version??
No it is :) It's an r9 file. 100% guaranteed. In order to check everything, I 
deleted the previously saved file, and did it all again: set all settings again 
(with GUI), the resulting file having the same contents (as follows):

SaveAllTextures:0
SaveSingleTexture:0
FontColour:255,0,0
TextureColour:0,255,0
Add_true:E:\Games\Resident Evil 4\A1.zip

No other lines, symbols, e.t.c have appeared in the file. This is an r9 file.

==============================================
Okay, I... "made"... it work with my ZIP.
(Again, very fast :))

It seems, that my suspicion about "texmod.def" was 100% correct.
Presumably, the code that is supposed to read a zip with "def" inside has a bug.

Here's what I did (to make a ZIP work):

1) I took a ZIP containing a "texmod.def" and the textures (a1.zip) as above.
2) The I removed "texmod.def" from it.
3) This forced your code to use another method of loading ZIP-file, that reads 
it's entire contents, not just "texmod.def", and takes hashes from filenames.
4) This ZIP (with NO "texmod.def") DID work.

I have an idea, why it does work on your system (presumably with "texmod.def") 
and doesn't on mine.

Can you, please, attach any of your own "texmod.def"'s to a message here to 
prove or disprove my theory?

In short, what I think prevents OTM from working with this package's def is the 
way wxWidgets reads the "./" (or "this folder") symbol.
I think it probably wants to have "//" instead (fully being 
".//game_0xhash.dds"), a standard C++ system replacement tag for file paths, 
since "/" wants the next symbol as a sub-symbol for special symbols like "new 
line" ("/n") or "eof" and e.t.c.
Since TPFs are built using this same def (with "./"), it may also not work for 
that same reason.
When wxWidgets part of OTM sees "./texture.dds", it (probably) actually reads 
it like something like ".@exture.dds", and of course it cannot find such a 
file, as it doesn't exist, so it "removes" it as non-existing.

This all is just a theory, of course, but such bug is common amongst a lot of 
alpha-stage projects, I'll test this theory out and tell you the results! :)

Original comment by evilgnos...@gmail.com on 5 Oct 2011 at 6:44

[GoogleCodeExporter]

Okay.
My previous theory was HALF-correct. :)
While .// doesn't solve the issue,
the complete removal of ./ symbol does.

So a .def with this line WILL work all right:

0x47C5000B|GAME.EXE_0x47C5000B.dds

But a .def with this WON'T:
0x47C5000B|./GAME.EXE_0x47C5000B.dds

A .def whis this also WON'T:
0x47C5000B|.//GAME.EXE_0x47C5000B.dds

Now, the only question, is "why?" :)
I guess it has something to do with the ZIP's file structure...
Maybe by "./" it thinks to look in it's work folder, rather then in a ZIP...

Original comment by evilgnos...@gmail.com on 5 Oct 2011 at 6:54

[GoogleCodeExporter]

> And so 1328 times forth. :)
You have an endurance of max value +10 (because you are wearing a ring or 
something like this ^^)

> No it is :) It's an r9 file. 100% guaranteed. 
My fault. I thought I have added this feature but nope, I did not.

> Okay, I... "made"... it work with my ZIP.
> (Again, very fast :))
Strike, at least something works^^

> It seems, that my suspicion about "texmod.def" was 100% correct.
> Presumably, the code that is supposed to read a zip with "def" inside has a 
bug.
You are absolutely right. I assumed the file names in the def file to be 
without the leading ./
The tpf files I have generated with the original TexMod does not contain those 
symbols.
As you have said, this is the reason, why they are not found (btw I do not use 
wxWidgets for unziping, cause wxWidgets does not support passwords in zip 
files, which is needed for tpf files).

But as I stated, the GUI reads all textures out of the def file. Only if the 
textures are ought to be loaded into the game, it looks for the textures in the 
tpf file. If it looks for a texture and it can't find it, than an error message 
is prepared and this texture is not taken into account. The loop runs over the 
rest of the textures and each time a texture could not be unziped, a new error 
message is appended. After the loop an error is raised if the error message is 
not empty. If he really could not unzip the textures out of the tpf file, you 
should have get an overfull error message an nothing should be sent to the 
game. But you did not get a more than 2000 lines long error message and instead 
of sending nothing to the game, it sends all the textures as "remove". This is 
so strange...

I think the zip api has a bug and corrupts something, if a file could not be 
found in the zip file. Maybe I have to close and reopen the zip handle each 
time a search request failed. But how should the zip api corrupt 1) the local 
boolean for adding a texture and 2) the error message.
I am so confused about this zip api. It shows such a strange behaviour.

I though handling with a zip file should be one of the easiest things. But it 
took me more time to debug this zip file functionality (and I am still not 
finished) than coding (and debugging) the core functions of the d3d9 proxy dll. 
I am really pissed off...

I think, I should change to another zip api. I am currently using "zip utils". 
Can you advise an other to me?

Original comment by c...@koerner-de.net on 5 Oct 2011 at 7:29

Attachments:

• texmod.def

[GoogleCodeExporter]

As you I can only speculate why it does not find the files in the zip file. 
Maybe ./ does not point to the root of the zip file or it even does not not ./ 
as short cut to the current directory.

I remove now all leading "./" or ".\" or "/" or "\" to fix also the windows 
path style.

But I do not know why it removed the texture in your case instead of doing 
nothing.
btw: I stated, it would give you a huge error message and this was false, but 
in the current version it does.

Thank you very much to find this bug!

Original comment by c...@koerner-de.net on 6 Oct 2011 at 7:31

[GoogleCodeExporter]

I've tried this and that and there can be a "darker" end to that story.
Brighter for the "zip utils" though :)

As I've said before the TPF didn't work with the original TexMod for me too...
Well, I recently recompiled it with the new .def (the one without "./" s).

And guess what?

Started to work! With both TexMod and OTM. Yes, BOTH of them. :)
Both have a bug loading textures from the TPF (some of them (not all) appear 
white, instead of normal), but since both programs have this bug, not just OTM, 
and the file was packed with the original TexMod (the only common link for this 
bug), it must be something in the structure of the TPF file or a packing bug in 
the original TexMod, so it's not something you should worry about. I think the 
original TexMod might have messed somewhat with the textures (alpha layer, 
maybe) while packing them,... Just a theory, though.

What IS important in this, is that removing "./" made the TPFs work with both 
programs.
This leads me to believe that this bug isn't just a bug with "zip utils", but 
rather a common one for many zip extractors, since it's unlikely for both 
TexMod and OTM to use the same library.

Here's what I think happens:
1) The ZIP Library reads "texmod.def" and finds a file, like 
"./game_0x0000ffff.dds" in a TPF. Since, semantically, it is correct, and 
there's such a filename it doesn't fire off an error.
2) However, the "./" part may mess with how it searches for the file's index, 
and it may instead, return not some correct number or "-1" (as it is supposed 
to), but any random bullshit number, or even "-1", but with "ZR_OK", instead of 
an error condition. 
3) Next, when it tries to unzip some "-100500" index, it "unzips" random 
bullshit to the tex->'s data structure, instead of real file's data.
4) DirectX (or your DirectX overrider) than receives this bullshit, thinks 
something like "what the f*ck is that, that they try to pass to me in the guise 
of texture", and calls "remove" instead of "loadtexure".

So, what I think might be done against it:
1) Line 340 of OTM_File.cpp reads:

file.Replace( "\r", "");

I think you might add something like

file.Replace( "./", "");

under it. This should solve the issue...
Guess that what you've meant by "I remove now all leading "./"..."

2)...but to further check it out, there's this next below somewhere:

if (rz!=ZR_OK && rz!=ZR_MORE){
...code what to do on error...
}

I think here's where the f--- up happens, so another condition like
&& index!=-1
might be added. Of course, the index of "-1" without some "ZR_ERROR"-like stuff 
is purely theoretical. It might be anything else, so there might exist a need 
to double-check it somehow else.

I haven't had much forays into the "world" of ZIP-libs, was searching for a 
good lib myself. I once used to use an IrrLicht graphics core for my game 
projects and it had a pretty decent built-in ZIP lib, but that obviously won't 
help.
Most people, it seems, recommend using ZLib with some additional API to allow 
file handling, like this minizip tool here:
http://www.winimage.com/zLibDll/minizip.html
I haven't had time to test it out myself, yet, so I don't know how well it 
works or how comfortable it is to use.

I also found that topic here:
http://stackoverflow.com/questions/262899/portable-zip-library-for-c-c-not-an-ap
plication
That might be of some help, people there recommend some other Zlib-based 
libraries.
A ZLib has a very famous license, known for it's over-the-top 
non-restrictiveness, allowing the user to do nearly anything with the code, BTW.

Original comment by evilgnos...@gmail.com on 7 Oct 2011 at 12:35

[GoogleCodeExporter]

Here's another bug that was semi-solved in the original TexMod.
It is completely unrelated, and may be worth starting another thread.

It's about in-game "cutscenes". But not those played in-game by the game's own 
engine. But rather the game playing pre-rendered ".avi" or ".mpg" movie files 
during it's intro or gameplay.

When used with OTM the movies are replaced with a blank black screen, on top of 
which the subtitles are displayed, and the sound of the movie being "played" 
can be heard, which is rather funny, but obviously not good at all :)
I've checked it, and the sound IS coming from a movie, not some game files, so 
the movie is actually being played somewhere in a memory, just is not being 
shown.

When used in "save single texture" mode, OTM shows an info bar on top of the 
game graphics, reading "Actual texture: 1 (0..N): some_hash" or the like, with 
"N" being the total amount of textures currently loaded.

I've noticed that when the movie is loaded and is being played, the N becomes 
N+1, as if the movie was actually a texture.
For example, it was...
"Actual texture: 1 (0..90): some_hash"
before the movie was played,
then it became
"Actual texture: 1 (0..91): some_hash"
when the movie was "actively" "being" "played", 
and then it became
"Actual texture: 1 (0..90): some_hash"
again, when the movie ended, and was unloaded from the memory, I presume.

Since the OTM interferes with the movie at all, and the movie is somehow a 
texture, my theory is that DirectX uses this texture as some kind of DirectShow 
Draw() surface. The OTM prevents it from being modified by that process somehow.

My suggested solution is to somehow detect if the texture is a DirectShow 
output surface (some flag in the texture's properties, maybe), and make OTM's 
d3d9 override simply ignore such textures (they're not of much use for modders, 
anyway).

:)

No need to thank me, b.t.w, I'm glad to be of help.
Instead, THANK *YOU* for both writing this program, and fixing all those 
annoying bugs, I know what it is like, was in such a position myself a great 
number of times :)

Original comment by evilgnos...@gmail.com on 7 Oct 2011 at 12:54

[GoogleCodeExporter]

> 2)...but to further check it out, there's this next below somewhere:
> 
> if (rz!=ZR_OK && rz!=ZR_MORE){
> ...code what to do on error...
> }
> 
> I think here's where the f--- up happens, so another condition like
> && index!=-1
> might be added. Of course, the index of "-1" without some "ZR_ERROR"-like 
stuff is > purely theoretical. It might be anything else, so there might exist 
a need to double-check it somehow else.

The following two lines
ZRESULT rz = UnzipItem( ZIP_Handle, index, tex->Textures[count], ze.unc_size);
if (rz!=ZR_OK && rz!=ZR_MORE)
is unzipping and check for errors. Therefore one already need to now the index 
of the texture file.

But this code is executed after the following two lines:
FindZipItem( ZIP_Handle, file.wc_str(), false, &index, &ze); // look for texture
if (index>=0)
and there is the check of index>=0.

The original TexMod might have also a bug in adding files to a zip file. Maybe 
thats the reason, why the textures are unpacked incorrectly. But the zip api 
should not care about alpha channels or something like this. Maybe it stores 
only 0xFF what means aplha, red, green, and blue to be of max value, and this 
is white. But as you have said, this is nothing we should worry about.

As far as I remember minizip can't load files from memory. But this is what I 
need for tpf files. I need to load them, do a xor operation over the file 
content and afterwards treat them as zip file. If using minizip, I must save 
the content before into a file on disk again, what seems to me to be senseless.

There are some zip api's I have found. The most of them do not support files in 
memory. Other do not support seeking in zip files or passwords. But this is 
what I need.

The next bug:
This is strange. Cause I don't modify any of the textures. I calculate the 
hash, but don't change anything. I test with Battlefront II and it uses also in 
game movies and they seem also to be pre rendered, but this works.

Did you try to watch the movie with "save single texture" switched off? Somehow 
I have the hope, that the method, how I draw text, removes the buffer in 
special cases. But atm I can't test the opposite with Battlefront (switching 
save single texture on and watch the movie).

I think this bug will take more time to solve :-(

Original comment by mar...@koerner-de.net on 7 Oct 2011 at 7:20

[GoogleCodeExporter]

Sorry haven't had time to read the source code more thoroughly.
But as I've said it can be some number above zero as well, simply an incorrect 
one.

A minizip API can theoretically be modified to keep the contents in memory, as 
can be most simple APIs, but this, of course, takes time and effort, and since 
"Zip utils" can simply be sent an already corrected file paths, and 
successfully work with them, there's no real need for this time-waste, I guess.

=================================================

> Did you try to watch the movie with "save single texture" switched off?
Yes, I did. Doesn't help. :(

> I test with Battlefront II...
Most probably it uses some other method of rendering a movie, maybe it buffers 
it within the game engine, and not with standard windows codecs. (Are the 
videos in Bink format?)
I was going to think Re4 used the most primitive method of rendering a movie, 
using windows libraries and drawing into generic front buffer, until I've 
noticed that N+1 texture amount increase when the movie is supposed to be 
played.

> But atm I can't test the opposite with Battlefront
Does this mean that when you switch it "on" the movie also disappears?

> I think this bug will take more time to solve :-(
Well, at least it's a related bug :), not a subsystem like Zip-utils :)

Original comment by evilgnos...@gmail.com on 7 Oct 2011 at 3:00

[GoogleCodeExporter]

Offtop:

I've tried to compile your version of d3d9.dll 
But I'm using Microsoft Visual C++ 2008 Express, and it doesn't read .vc 
makefiles.
So I had to remake a project file, it did compile, but I'm getting 0xc000007b 
error when trying to run a game with the compiled library. The size of the 
library is also smaller, then it should be (46,080 bytes instead of 122,328 it 
should be).
Some of it is probably because I used "release" config, but even when I used 
debug one, it was still some 20,000 bytes smaller in size and gave me the same 
error.

Most probably my project file misses something important from the makefile.vc 
settings. But I'm still guessing what it might be.
I've attached all the .lib files, and d3d SDK is correctly installed, so this 
is should not be an issue.

Original comment by evilgnos...@gmail.com on 7 Oct 2011 at 5:14

[GoogleCodeExporter]

I have tested OTM with Resident Evil 4 on WinXP and can confirm the bug. But 
instead of a black screen I see some garbage textures.

> Are the videos in Bink format?
Is there an easy way to test it?

> Does this mean that when you switch it "on" the movie also disappears?
no, I can turn it on, watch the movie and even switch trough the textures. But 
of course now texture is shown while rendering the movie.

> But I'm using Microsoft Visual C++ 2008 Express, and it doesn't read .vc 
makefiles.
I use: nmake -f makefile.vc
or you can also use: make -f makefile.gcc
If you have installed also the gcc. Both makefiles use the VC compiler and the 
same commands, so the resulting dll is identically. But with make -f 
makefile.gcc -j 4 you can compile with 4 threads.
Maybe the structure of the makefile has been changed from VS2008 to VS2010.

0xc000007b error: 
http://msoos.wordpress.com/2010/09/11/0xc000007b-error-solution/
Maybe you mixed 32bit an 64bit. The GUI as well as the dll is 32bit compiled. 
The GUI can't load 64bit dll. It could also be possible, that your 32bit dll 
tries to load a 64bit dll. But this should not happen, since I am using this 
pragma(lib...) style (except for the original d3d9.dll), which should check 
incompatibility during compilation.

Original comment by c...@koerner-de.net on 7 Oct 2011 at 5:59

[GoogleCodeExporter]

> I have tested OTM with Resident Evil 4 on WinXP and can confirm the bug. But 
instead of a black screen I see some garbage textures.

Yes, that should be it. I'm using Win7, so the screen's black, not garbage due 
to that, I think.

> I use: nmake -f makefile.vc
Yeah! That worked, thank you so much!

Original comment by evilgnos...@gmail.com on 8 Oct 2011 at 12:15

[GoogleCodeExporter]

> Is there an easy way to test it? (BINK)
Yes, actually there's nothing easier.
Check the game's folders, if there are files that have .bik or .smk extensions 
they're it. Most developers don't pack .bik -s into archives, that's not worth 
it.
The RAD GAME Tools (BINK-videos that is) is a rather popular video library used 
by a lot of games. If it's videos work fine with OTM it's a huge potential load 
off the shoulders.

Resident Evil 4, unfortunately, uses MPEG :(

Original comment by evilgnos...@gmail.com on 8 Oct 2011 at 12:23

[GoogleCodeExporter]

> Yeah! That worked, thank you so much!
That means it compiles now correctly and you can use the compiled dll?

> Check the game's folders, if there are files that have .bik or .smk 
extensions they're it. Most developers don't pack .bik -s into archives, that's 
not worth it.
There is no such file. But there are *.mvs files, but I did not get a hit with 
a quick google search.
The most stuff is packed in data cab, which I cannot open with 7z.

BTW: The bug is solved: When the Game passes texture to the DirectX device one 
has to take care to do not pass the OTM_IDirect3DTexture9 object to the 
original functions but the original IDirect3DTexture9 object. This was already 
done in the SetTexture function but not in the UpdateTexture function. 
Fortunately Resident Evil did not crash and only showed a black screen (or 
garbage). Now the movies work (at least on my WinXP machine).

Original comment by c...@koerner-de.net on 8 Oct 2011 at 6:23

[GoogleCodeExporter]

> That means it compiles now correctly and you can use the compiled dll?
Yes, not only compiles and runs, but also accepts a number of Resident Evil 
4-related changes. Nothing major, I simply wanted it to try and load ENB's 
d3d9.dll if such, renamed to "d3d9enb.dll", can be found in the game folder, 
and only if it's not there - the real "d3d9.dll". I also added a Re4 pack to be 
loaded without the need for GUI -- a personal preference. Re4 PC port's a crap, 
firing-up up to 10 tools with GUI before actually running the game just to make 
the game look like GameCube version (decent, that is) - a little too much for 
me :) Luckily, most "enchantment" tool developers made d3d9 override libraries. 
TexMod was the only weak spot. Thanks to you that's fixed now. :)
Works perfectly!

Here's what I needed (in terms of ENB mod):

void LoadOriginalDll(void)
{
  char buffer[MAX_PATH]; //Primary DLL path.
  char enb_path[MAX_PATH]; //Alternate DLL path.
    GetSystemDirectory(buffer,MAX_PATH); //get the system directory for d3d9.dll
    GetCurrentDirectory(MAX_PATH,enb_path); //get current directory for d3d9enb.

    // Append dll name
    strcat_s( buffer, MAX_PATH,"\\d3d9.dll"); //Primary DLL name.
    strcat_s( enb_path, MAX_PATH,"\\d3d9enb.dll"); //Alternate DLL name.

    // try to load the ENB's Alternate d3d9enb.dll, if pointer empty.
    if (!gl_hOriginalDll) gl_hOriginalDll = LoadLibrary(enb_path);

    // try to load the system's d3d9.dll, if pointer is still empty.
    if (!gl_hOriginalDll) gl_hOriginalDll = LoadLibrary(buffer);

    // Debug
    if (!gl_hOriginalDll)
    {
        ExitProcess(0); // exit the hard way
    }
}

I also modified InitInstance function not to "return", if the pipe hasn't been 
opened, and added "AddFile" (to load HUD fix mod) overrides there.
My version of the Lib is still compatible with the GUI to load any other mods, 
if the GUI is started before the game, which is required anyway.

====================================================================
I forgot to mention one very minor (but bad for end-user) bug:
When launched the very first time (or if the next mentioned file doesn't exist 
yet), OTM fails to load\create the
C:\Users\<User_Name>\AppData\Roaming\OpenTexMod\OTM_DX9.txt
file for some reason. It's not a big "problem", since nothing stops from 
creating such an empty file manually (which I did).

====================================================================
> BTW: The bug is solved...
COOL! :) It works!!! :)))

====================================================================
I've noticed, OTM starts in German now, due to "last lang" file.
I can make a Russian translation file for you to include, if you want :)

If it keeps going that way, you'll be outta "alpha" soon :)

I've got a few suggestions:
1) The "File" menu really needs and "Exit" option, which, on exit will ask 
either:
1.1) "Do you want to quit?" if no game are running with OTM.
or
1.2) "Exiting now may crash any games currently connected to OTM. Are you 
sure?" if some games are running.
2) The aforementioned "OTM_DX9.txt" may make use of full file paths (or path 
hashes) like "C:\Games\Re4\game.exe", rather than simply "game.exe" (that is, 
any game executable name), since more the one game can here an executable named 
"game.exe" (or any other name). It's rare, but it can happen.
3) The "Add texture" can be renamed "Add Texture \ Pack", since I've been 
figuring out how to add packs, rather then single textures on my first run, 
before I figured out to look at the "file type" tab in that same load window. 
Unfortunately, It's not obvious.
4) I don't know if it's done already, but I think it'll be nice to call 
"update" automatically when a new texture and\or pack has been added, so the 
user won't need to click "update" to see his\her textures. If he\she wants the 
gone by clicking ticks - it's ok, but for the first add automatics will be cool.
5) At least on my machine "readme" window has a rendering bug when trying to 
scroll the text. It becomes a huge garbage of pixels :) Most probably a 
wxWidgets issue. Rather then solving it, I think it'll be nice to simply make 
readme an beautiful html file, and load it in the user's browser when clicked.
====================================================================
> The most stuff is packed in data cab, which I cannot open with 7z.

The cab files are sometimes an InstallShield format.
You can try InstallShield Cabinet File Viewer on them.
The filename for installer I've found was 
"InstallShield_Cabinet_File_Viewer.7z", you can Google it.
====================================================================
Once again thank you for developing this program!

Original comment by evilgnos...@gmail.com on 8 Oct 2011 at 9:51

[GoogleCodeExporter]

> 1.2) "Exiting now may crash any games currently connected to OTM. Are you 
sure?" if some games are running.
Oops! Forgot that this is done already. Anyway, the "exit" button in the main 
menu wouldn't hurt :)

Original comment by evilgnos...@gmail.com on 8 Oct 2011 at 9:59

[GoogleCodeExporter]

Here's a Russian language pack.
I'll translate the readme later.

Original comment by evilgnos...@gmail.com on 8 Oct 2011 at 10:12

Attachments:

• OTM_LanguagePack_Russian.txt

[GoogleCodeExporter]

Thank you for the Russian language pack, of course I will include it in future 
uploads.
Do you need UTF8 for a full Russian support?

> I forgot to mention one very minor (but bad for end-user) bug:
> When launched the very first time (or if the next mentioned file doesn't 
exist yet), OTM fails to load\create the
> C:\Users\<User_Name>\AppData\Roaming\OpenTexMod\OTM_DX9.txt
> file for some reason. It's not a big "problem", since nothing stops from 
creating > such an empty file manually (which I did).
I hope I solved this bug with r9.

> Oops! Forgot that this is done already. Anyway, the "exit" button in the main 
menu wouldn't hurt :)
In an early version I had such a menu entry. But it thought a single main menu 
with only one sub menu "exit" is a little bit desolate and so I removed it.

> 2) The aforementioned "OTM_DX9.txt" may make use of full file paths ...
I started also thinking about that, since more than one game label their 
executable as Game.exe. E.g. all the episode of half life 2 and portal label 
their executable hl2.exe.
I think I will write the whole path into the "OTM_DX9.txt" and allow multiple 
save in the OTM GUI for one game (game with path), and one of them can be set 
as default.

> 3) The "Add texture" can be renamed "Add Texture \ Pack", ...
I hope you have already done in the Russian pack, I will change for German and 
English.

> 4) I don't know if it's done already, but I think it'll be nice to call 
"update" automatically when a new texture and\or pack has been added, so the 
user won't need to click "update" to see his\her textures.

Atm the update function for texture is not optimized at all (on the side of the 
GUI). It always send all texture to be reloaded and also each texture which is 
marked as unload. In future the GUI should only send differences. Therefore 
also a force to reload button must exist (if one has changed the texture and 
like to see the changes work). But atm I don't like to optimize this part of 
code, since it must be robust if the order of packages has changed (which might 
include textures targeting the same hash).
I will include such an automatic update, as soon as the update function is 
optimized.

> 5) At least on my machine "readme" window has a rendering bug when trying to 
scroll the text. It becomes a huge garbage of pixels :) Most probably a 
wxWidgets issue. Rather then solving it, I think it'll be nice to simply make 
readme an beautiful html file, and load it in the user's browser when clicked.

As you have said, it is a problem with wxWidgets, but on my machine it is 
solved since compiling with Visual Studio 2010 or against wxWidgets 2.9.2 I do 
not know which of both did the trick (probably wxWidgets 2.9.2). The uploads 
>=r9 should not have this bug any more.
I would not say hate but it comes very close if programs open other programs to 
show some text informations. I like to have a simple plain text as readme file. 
The help window is for users which do not look through the file content of the 
OTM directory and directly click onto the executable ;)

Original comment by c...@koerner-de.net on 9 Oct 2011 at 8:40

[GoogleCodeExporter]

BTW: under which pseudonym do you like to be mentioned?

Original comment by c...@koerner-de.net on 9 Oct 2011 at 11:25

[GoogleCodeExporter]

> Do you need UTF8 for a full Russian support?
Dunno :) Worked fine as is on my machine, haven't yet tested on WinXP.
I don't like UTF-8 actually... Most time, practically, it gave me nothing but 
troubles.
If, however, using it means Russian letters will stay Russian (and not 
"hieroglyphs") on a system with any other "primary" language, it may be worth a 
try.

> I hope I solved this bug with r9.
Yes. It appears you did :) I simply haven't tested it since r8 (until now) :)

> But it thought a single main menu with only one sub menu "exit" is a little 
bit desolate...
Well, since there no "main" menu anyway, the first menu is consciously 
recognized as being "main", the "Game" menu that is, and it has 2 entires 
already. I guess, a separator and then "Exit" won't "spoil" it much.
That is, if you're not planning on adding an actual "main" menu later-on.

>  ...and one of them can be set as default.
Cool! Your GUI uses "tabs" for opened games. I think an "always opened" "tab" 
for the game list can also be added, so there will be no need for any 
additional windows or menus, thus keeping it nice & simple.

> I hope you have already done in the Russian pack...
Yes I did :)

>...since it must be robust if the order of packages has changed...
 Yeah, I know that stuff, it's so frustrating to rewrite a nice & simple part of code that works well enough already, into a big ugly chunk of code, just to comfort the end-user, and then debugging that chunk of code a lot of time (so it can be "robust"), and feel like it's not really necessary, but hey, "It's not like I'm writing this (software) just for myself...". Actually, that's exactly what I'm dealing with now on a job... I need to make a price-list importer for a certain web-shop, and it works fine as it is, but is not comfortable for our customers to use, so I have to redo it, and it's so frustrating :(

>...but on my machine it is solved since compiling with Visual Studio 2010...
Unfortunately, it still bugs on mine... :( I've attached a screenshot. It's 
from r12.

>BTW: under which pseudonym do you like to be mentioned?H
Hmmm... :) I've always used "EvilAlex". I did drop the "Evil" part some time 
ago due to circumstances in my life (don't ask :)), but since "Alex" can be 
anyone, I guess "EvilAlex" will suffice ;) Especially being used for so long 
:)))

There's another (small) bug.
When the language is changed from within the program's menu, when then clicked 
on the "Help" menu, it'll display a readme in a previously used language (not 
the one currently set), until you quit the program and start it again (which 
fixes the bug).

Original comment by evilgnos...@gmail.com on 9 Oct 2011 at 12:45

Attachments:

• !bug.JPG

[GoogleCodeExporter]

BTW: The Goggle doesn't show "Issue controls" to me, presumably since I'm not a 
"member" of the project, but I guess we can set this "Issue" status as 
"Solved", since, well, it's solved and we're offtop-ing here on other bugs for 
a lot of time already, it can confuse any other potential viewers :)

Original comment by evilgnos...@gmail.com on 9 Oct 2011 at 12:52

[GoogleCodeExporter]

> > Do you need UTF8 for a full Russian support?
> Dunno :) Worked fine as is on my machine, haven't yet tested on WinXP.
But not on my, since the ascii encoding on my machine is german.
I have saved it for you in utf-16LE and will upload it the next update, so you 
can check for errors.

> Unfortunately, it still bugs on mine... :( I've attached a screenshot. It's 
from r12.
I will wait for a new version of wxWdigets 2.9.X

> Cool! Your GUI uses "tabs" for opened games. I think an "always opened" "tab" 
for the game list can also be added, so there will be no need for any 
additional windows or menus, thus keeping it nice & simple.
I think there is no need for a list of all games, since you can look up the 
games under "remove game" and the games, which runs at the moment, have all 
their own tab. If a game is running you can save and load different templates 
and also set one as default, which automaticaly loads on game start the next 
time. I think this is good enough for the first release. 

> There's another (small) bug.
In the version on my machine it is fixed, but thank you for the report.

Original comment by c...@koerner-de.net on 10 Oct 2011 at 9:23

• Changed state: Fixed