Newb Question about JohnP's textures...

New Horizon on 7/9/2006 at 21:52

Quote Posted by Beleg Cúthalion

And I guess it would be too complicated to write a kind of organizer which allows to get the John-P-Textures into a(n) FM, right? :erm: In case of new textures used by the author, do they have a separate "space" or is it necessary to overwrite not-used textures (what would make it even more complicated)?

It would likely be complicated. T3 Fan Mission making is not easy. T3 Missions have the content literally 'baked' right into the .ibt mission files. Garrettloader has to strip anything that is 'not' custom material...out of the ibt and then reassemble it on the players computer from the original files. Fun stuff. :)

Beleg Cúthalion on 8/9/2006 at 07:31

What would happen if you installed the JP-package after installing an fm via GarrettLoader? That's why I asked if new textures etc. can only exist when an original file was overwritten. In this case JP would cause an optical fault, wouldn't it? But I guess that's too technical for me...:erg:

Crispy on 8/9/2006 at 10:18

I'm not sure where you got "optical fault" from. :)

But yeah, the installer for John P's textures will only patch OMs (since it works by modifying the OM's IBT file). It won't patch the IBT files of FMs.

In theory it could be rewritten for each individual FM (!), but that's a lot of work. I don't see anyone taking on that task, not when there's so many more important and interesting things to be doing. :)

Beleg Cúthalion on 9/9/2006 at 06:41

Quote Posted by Crispy

I'm not sure where you got "optical fault" from. :)

I just meant the wrong texture in the game; it "looks" wrong. Like grass placed on the wall.

Concerning the rest...it is kind of sad. :erm: Maybe we could agree to offer two versions of each FM? One normal and the other one with the Collective Texture Pack, copper highlight and the Thief-1-Garrett-Style? :sly: Just like I have? :rolleyes:

GlasWolf on 9/9/2006 at 09:27

Quote Posted by Crispy

In theory it could be rewritten for each individual FM (!), but that's a lot of work. I don't see anyone taking on that task, not when there's so many more important and interesting things to be doing. :)

No doubt I'm showing my ignorance (again) here, but does the installer scan the ibts looking for texture "signatures" which it then replaces with a link to John's own version of the texture file outwith the ibt? If so, then aren't the signatures for the standard textures going to be the same for OMs and FMs, meaning the patching process will be exactly the same?

Ziemanskye on 9/9/2006 at 10:09

Well, to join in the dumb questions I was going to ask if we could hijack the ibt-reinflation system for it, so it could be optional on compressed fms?

Crispy on 9/9/2006 at 10:36

Quote Posted by Beleg Cúthalion

Maybe we could agree to offer two versions of each FM? One normal and the other one with the Collective Texture Pack, copper highlight and the Thief-1-Garrett-Style? :sly: Just like I have? :rolleyes:

That'd be up to each FM author to put in the extra work to do that, but yeah, that's probably the easiest solution.

Quote Posted by GlasWolf

It works by mangling the names of the textures in the IBT. Since the game will then fail to find the textures in the IBT, it looks for them in the DynamicallyLoaded folder; and the versions in that folder have been replaced by John's textures.

I believe the installer mangles at pre-specified locations within the file, which are specific to each mission. I could be wrong though. If it does search for the names then in theory it could be made to work by modifying it to similarly mangle FM IBTs as well, but I don't believe it does. Currently it only looks at OM IBTs anyway, so it won't do FMs as it is.

GlasWolf on 9/9/2006 at 13:44

I did find a post from John P (http://www.ttlg.com/forums/showthread.php?p=1316585#post1316585) here that does make it sound as if it's a dynamic search procedure rather than pre-specified point (when he talks about renaming things he shouldn't have). Then again he could be talking about the initital stage of finding which parts need changing for the installer, rather than the installer doing it itself. So not conclusive.

I'm thinking along the same lines as Z too - during FM install/inflation, if John P's texures were installed then it could mimic the install method and rename all the default texture names that have enhanced versions installed. I'm curious where the texture names are held though. When John says:

Quote Posted by John P.

It doesn't really matter what you rename the texture to(inside the .ibt) - you could rename wall1.dds to donald_duck.dds, and put wall1.dds in the DynamicallyLoaded folder, and the game would then load wall1.dds from DynamicallyLoaded.

The texture name ("wall1.dds") must be specified somewhere else in some form. :confused:

nomad of the pacific on 9/9/2006 at 16:49

Quote:

Originally posted by Ziemanskye:
Well, to join in the dumb questions I was going to ask if we could hijack the ibt-reinflation system for it, so it could be optional on compressed fms?

There's a chance that might already work. Since the ibt stripper compares to OM ibt's and swaps data for placeholders, wouldn't the ibt reinflater replace those placeholders with the mangled texture file names, forcing the game to search for JohnP's textures? The only glitch might be if the file size of the OM ibt is changed by JohnP, in which case the ibt reinflater could totally screw up the reconstructed ibt. Maybe someone with JohnP textures installed could test that (as soon as we have an FM from GL 1.41.)

Crispy on 10/9/2006 at 02:39

Quote Posted by GlasWolf

I'm curious where the texture names are held though. [...] The texture name ("wall1.dds") must be specified somewhere else in some form. :confused:

The texture name is inside the IBT file. All John's installer does is change that name so that the game can no longer find, for example, wall1.dds. Then it puts John's own "wall1.dds" texture into the DynamicallyLoaded folder. Since the game can't find wall1.dds in the IBT, it looks for it in the DynamicallyLoaded folder; and there, it finds John's version.

Here's how it works without John's texture patch, in dramatised form:

Thief 3: Hmm, apparently I need "wall1.dds".
Thief 3: *searches for something called wall1.dds in the IBT file*
Thief 3: *finds it*
Thief 3: Yay, I now have wall1.dds! Celebrate!

And here's how it works with John's texture patch:

John's installer: *renames wall1.dds to donald_duck.dds in the IBT file*
(...later...)
Thief 3: Hmm, apparently I need "wall1.dds".
Thief 3: *searches for something called wall1.dds in the IBT file*
Thief 3: Huh, what's this donald_duck.dds nonsense? Oh well, it can't be relevant, since I'm looking for wall1.dds.
Thief 3: *doesn't find anything called wall1.dds*
Thief 3: Oh crap. :( Better check the DynamicallyLoaded folder...
Thief 3: *finds a file called wall1.dds in the DynamicallyLoaded folder* (but this copy of wall1.dds is actually John's changed version!)
Thief 3: Yay, I now have wall1.dds! Celebrate!

Of course, John's installer doesn't actually rename wall1.dds to donald_duck.dds. :) It just mangles the name, by, say, replacing it with zeroes. But the effect is the same.

Quote Posted by nomad of the pacific

That's true, I didn't think of that. That might actually work. :) Assuming that the stripper works by specifying locations in the file to be reconstructed (and that seems the most likely solution to me).

Quote:

The only glitch might be if the file size of the OM ibt is changed by JohnP

It isn't. The file size does not get changed; all the data is still there. It only gets renamed, not removed.

Quote:

Maybe someone with JohnP textures installed could test that (as soon as we have an FM from GL 1.41.)

Yeah, that would be great. Someone just needs to to take a stripped IBT that was made without JohnP's textures, re-inflate on an installation with JohnP's texture, and see if the inflated version causes JohnP's textures to load.