I may be able to offer a service towards this goal. I can help out converting existing texture packs to the standard format. Thing is I have access to Linux and its scripting language where its fairly easy to knock up scripts to systematically move files around and generate text files.

I think I demonstrated from recent attempts with the Audio packs that I'm incapable of actually typing the names in without typos 😁 , so I need some form of carefully written list to work from, but having said that, I may be able to use the standard maping file itself as input.

Anyway, let me know if anyone wants me to have a go at a conversion.

I just re-read JC's post in another thread about management:

JC wrote:

The Textures folder within Glidos could contain all the usual numbered folders plus a folder for each artist. The numbered fol […]
Show full quote

The Textures folder within Glidos could contain all the usual numbered folders plus a folder for each artist.

The numbered folders would contain .txt files which are substituted for each of the original textures, and named simply with the co-ordinates that designated each texture. i.e. (0--32)(32--64).txt.

The .txt files link to the actual textures in the artist's folders and these can be organised any which way the artist wants. Changing texture packs would be a simple matter of overwriting the .txt files in the numbered folders.

If this sounds like a reasonable idea it would be good to establish it a.s.a.p so that we can all get on with designing textures without the worry of extra work later caused by compatibility issues. Thoughts?

I see now why you want to do it this way. I'm undecided about it. I like not having the weird named folders anywhere in my setup, because you have to look in each folder to find out what was there. If the folder names are more sensible and indicate their contents, this is much better in my opinion.

Paul, not sure if your suggestion is worthwhile at the moment. Maybe I don't fully understand what you're offering, but I would have thought any reorgansing of existing texture packs would be pretty much a manual exercise. This is one of the disadvantages of applying a standard after a lot of work has already been done.

I don't feel I understand all the issues either, but two points.

1) I also like the idea of not having any strangely named folders, and I suspect the mapping files give us a way.

2) I don't like the idea of overwriting a large number of files. One of the purposes of of the BASE and ROOT in a mapping file is so that a change of mapping file can determine which author's textures are used.

If I remember rightly, Glidos will pick up multiple mapping files, so if author's used a mapping file per level, users could have several author's work installed but determine who's to use on a level by level basis, by picking the right combination of mapping files. Perhaps author's could provide the mapping files in a subfolder where Glidos wont pick them up, and users can activate chosen levels by moving the appropriate mapping files to the main folder. A systematic naming of such mapping files would prevent multiple mapping files for a single level.

... maybe.

Agreed with 1) and 2).

I have spent the afternoon playing the two egypt levels of Unfinished Business to make capture folders for each. I've got in to a bit of a mess! There appear to be several folders that have the same name for both levels, but I can't be sure due to one level running into the next during playing.

Paul, are the weird named folders generated from the 256x256 complete tile, or from the level data? If the latter, there should be no way for me to have duplicated folder names.

I'm still looking for a way of ensuring that 100% of a level's textures are captured. It's incredibly time consuming to play a level all the way through, capture maybe 90% of it, and then have to work out all the little bits that weren't captured. To completely capture an entire level, you also have to put the weapons cheats on, then back into a coroner, face the camera and switch between all weapons in both firing and holstered states, otherwise you don't get all the little bits and pieces captured. It's possible to manually work out coordinates for missing bits by looking at the complete.bmp, but that is time consuming and fiddly.

Is there really no other way of doing this? I'd rather be spending my time doing the texturing, but currently too much of my time is going on management and structuring.

If it would be any help I have already mapped ALL of the textures for the first four levels from the alphanumeric folders into sensibly named folders following the format I have used in Qualopec. I have done most of the Folly and Colosseum as well. If you were to adopt the system I am using then most of the work is already done - you simply have to use a mapping file to divert to another folder rather than JC. Of course, you would need to rename the individual textures, but I have all the link files ready to go....
An advantage to this is that all of the pieces of a particular texture are grouped together in one folder and you don't have to go hopping between different folders to gather them up when working on them.

Gambit37 wrote:

Paul, are the weird named folders generated from the 256x256 complete tile, or from the level data? If the latter, there should be no way for me to have duplicated folder names.

Glidos is purely a render engine. It has no sight of the game itself, certainly not the level data. All it sees it Glide commands, which includes those that download the textures, so - as you say - derived from the 256x256 tile.

It's possible to manually work out coordinates for missing bits by looking at the complete.bmp, but that is time consuming and fiddly.

Is there really no other way of doing this? I'd rather be spending my time doing the texturing, but currently too much of my time is going on management and structuring.

Glidos can see only Glide commands, and the game generates Glids commands only for what you see on screen.

JC, I think maybe a combination of the two methods might be good. Your uses of link files is good if it is improving the grouping together of textures (have I understood correctly?). But still the link files themselves could be in more nicely named folders.

Don't be put off by the work that might be involved beause, as I mentioned before, I can probably automate conversion.

Maybe we should have at the top level two folders "links" and "textures". The links folder could have below it a hierarchy of folders that matches the way TR groups textures; these folders would contain the link files. The link files would map into the textures folder, which would have a hierarchy matching how we wish to group textures.

Thing is, I am happy to remap from the alphanumeric folders and once this job is done nobody need ever look at them again. If you want to locate a rock texture used in the Rome levels you will find it in a folder called "rock" inside a folder called "Rome" - no need to even cast a side glance at those nasty numbered folders - they will have been safely tucked away where no-one need go snooping!

I can't see any advantage to obfuscation. The more meaningful the names, the easier it is to maintain - like if something you count as a rock today, you one day would prefer to think of as a stone.

All it comes down to is your mapping files have lines like

00AE19B7C0B2D045AE54A1683C076786 00AE19B7C0B2D045AE54A1683C076786

where they could be

00AE19B7C0B2D045AE54A1683C076786 links\Caves\Text1

I can't think of any reason not to make use of that flexibility in the mapping files, other than you have already put so much work into it; but that is not a problem because the swap over can be automated, I think.

Gambit and JC, if you think its worth a go, maybe you can both give me your mapping files (plus, in the case of JC, all the link files) and I can see about generating one that uses the two techniques together.

When you put it that way, I guess that is fairly straightforward and simple enough to implement! What I don't understand, however, is the meaning of the word "obfuscation"?

Exactly, Paul. That's what I've been getting at. Have a look here, this is how I do mine currently.

Re: Request for better texture pack management

It's neater than JCs in terms of folder names, but I don't use ONLY link files in these named folders like JC, I mix and match tetxures with link files. I only create link files to textures that are used more than once throughout the game.

While I can see the benefits of your method JC, it's simply not useful during development of a level. One needs to know the weird named folder and the original PNG filename during replacement texture creation, to be able to then create a link file somewhere else. You clearly have way moe patience than me! Your method is only useful *after* all the work has been done and supposing someone else will be using it in the future.

Glidos is purely a render engine. It has no sight of the game itself, certainly not the level data. All it sees it Glide commands, which includes those that download the textures, so - as you say - derived from the 256x256 tile.

Yes, but the weird named folders must be created using some consistent algorithm based on the pixel data?

TR stores the texture sheets in one long panel. These panels are split into 256x256 chunks. The chunks equate to a weird folder name. I have seen that the same folder name can be generated from the same pixel data chunk when it's exactly the same in two different levels. I realised what you're saying about Glidos only being a render engine, but it must know *something* about the pixel data or it wouldn't be able to create folder names from it...?

Oh, and JC, to obfuscate means "to hide".

Sorry, I can't get the hang of this "quote" thing...

It probably just comes down to the preferred method of working.
Personally, after I have captured a level I like to go about identifying what all the various bits and pieces are. I start by creating subfolders in the alphanumeric ones with names like "lara" or "apes" and sort the textures into these. Following this it seems logical to then substitute a link file and move these subfolders off into an amalgamated folder elsewhere. It doesn't have anything to do with whether anyone else will make use of it in the future, it's just the way I like to organise things as I go.

JC wrote:

What I don't understand, however, is the meaning of the word "obfuscation"?

Hmmm, maybe I'm not sure. 😁 I think it means unnecessarily making something difficult to read.

Gambit37 wrote:

I only create link files to textures that are used more than once throughout the game.

That's the bit where I think a mixture of approaches would be good. By making all of the files in that heirarchy links to the textures in another folder heirarchy, you can collect the textures of each type together. Really rather neat I thought. Also get to give the textures nice names without any coords in them.

JC wrote:

It probably just comes down to the preferred method of working.

Possibly. But if you do find common ground then there'll be a lot of shared work.

Paul, did you see my query above?:

Gambit37 wrote:

Glidos is purely a render engine. It has no sight of the game itself, certainly not the level data. All it sees it Glide commands, which includes those that download the textures, so - as you say - derived from the 256x256 tile.

Yes, but the weird named folders must be created using some consistent algorithm based on the pixel data?

TR stores the texture sheets in one long panel. These panels are split into 256x256 chunks. The chunks equate to a weird folder name. I have seen that the same folder name can be generated from the same pixel data chunk when it's exactly the same in two different levels. I realised what you're saying about Glidos only being a render engine, but it must know *something* about the pixel data or it wouldn't be able to create folder names from it...?

Sorry, I obviously wasn't quite clear: you are right about it being derived from the 256x256 pixel data.