The mapping from the numbered folders to the paths specified in a master file should work fine. What information would be lost?

Oh, I just realised -- of course you still need the numbered folders to indetify tiles of different content but with the same coordinate filenames.

OK, so you just need an extra subfolder in the flat file then:

1BASE: trx\
2
3// level folders follow
4// Level 1: The Caves
5
6198EC2D38EF00FEA1653750E8B237D7F: levels\level01\tileset1
7203D6ED9632B742A2209637764C375F6: levels\level01\tileset2
854637C4BF0304439B63F51D3A5EEA382: levels\level01\tileset3

What I'm trying to do is avoid having any numbered folders off the textures folder at all. I estimate that after capturing the entire game, there will be around 170 folders in there which will be quite unmanageable.

Ok. Now that would work, and if I've gotten my class structure right, should be just a few lines of code change in one source file... but I bet I haven't. 😁

Ok here it is then. Now if you have any files in the Textures folder that start with the line "GLIDOS TEXTURE MAPPING" they are treated as mappings from strange folder names to nice ones. You can put the line

BASE: path

so as to not have to specify the whole thing on every mapping. Each time you put a "BASE:" line in it changes the base folder.

If different mapping files map the same funny-named folder, then the last mapping file Glidos reads in wins - difficult to predict which that will be, so its best if mapping files are disjoint.

I tested this by creating a trx folder inside Textures, and moving all the funny named folders below it (without name changes). Here's the mapping file I used.

1GLIDOS TEXTURE MAPPING
2
3BASE: trx\
4
500AE19B7C0B2D045AE54A1683C076786 00AE19B7C0B2D045AE54A1683C076786
60C4F02769AD92D3F8EF3653283C8DEB0 0C4F02769AD92D3F8EF3653283C8DEB0
711413E3940260824F64E393F5022B569 11413E3940260824F64E393F5022B569
8198EC2D38EF00FEA1653750E8B237D7F 198EC2D38EF00FEA1653750E8B237D7F
9203D6ED9632B742A2209637764C375F6 203D6ED9632B742A2209637764C375F6
102B9F6A059344DAE154DAE71FD6FAB95E 2B9F6A059344DAE154DAE71FD6FAB95E
113AC9023C45D0FFFA03D9F9FCBDBB37BE 3AC9023C45D0FFFA03D9F9FCBDBB37BE
12474C2C91326153751CC40C34817E6800 474C2C91326153751CC40C34817E6800
1354637C4BF0304439B63F51D3A5EEA382 54637C4BF0304439B63F51D3A5EEA382
145DC11F7D67BD718860E4A540983DCF1B 5DC11F7D67BD718860E4A540983DCF1B
156018E6431FA65017D0F703FC8E60D589 6018E6431FA65017D0F703FC8E60D589
1660812F71A9287004111BA82EF2404371 60812F71A9287004111BA82EF2404371
176374D96404C7A58754EFD0E7683320E8 6374D96404C7A58754EFD0E7683320E8
18643BFE0375AFFDF14E803305F215563B 643BFE0375AFFDF14E803305F215563B
196C7FE41E229619C7ACDED8A8538E3F4E 6C7FE41E229619C7ACDED8A8538E3F4E
20708171E626AA342A07B8567EA8A1A53D 708171E626AA342A07B8567EA8A1A53D
2170AC1176B4E7D571A7C6D159C8ECD318 70AC1176B4E7D571A7C6D159C8ECD318
227564D67E6E017EB1EDDC14F9BCC27F26 7564D67E6E017EB1EDDC14F9BCC27F26
2379B6CF7BC525BC3FC870723F2261A0C4 79B6CF7BC525BC3FC870723F2261A0C4
247E5129F80DD26B3F59CEA33D1BFC2AC2 7E5129F80DD26B3F59CEA33D1BFC2AC2
25817989A4FEBE4DBE4494634A58B66E12 817989A4FEBE4DBE4494634A58B66E12
26828A9C3EBE11915DDBA9536666948D79 828A9C3EBE11915DDBA9536666948D79
2783BFA65D61DEABF4306D9833758BEE8F 83BFA65D61DEABF4306D9833758BEE8F
288880FD9B651C257778549A7EE7A2E450 8880FD9B651C257778549A7EE7A2E450
298B4825478FAB43844E3D4CB077E97613 8B4825478FAB43844E3D4CB077E97613
308F2FA7061AB2E84279F2292FDD537C46 8F2FA7061AB2E84279F2292FDD537C46
3195F5F754FA4FEB35115917554FFBDD14 95F5F754FA4FEB35115917554FFBDD14
3299A9ECC11E164D754899E5F069ADA6AC 99A9ECC11E164D754899E5F069ADA6AC
339B40CDE58D672D1AB373E9D941C77522 9B40CDE58D672D1AB373E9D941C77522
349DB0846B3F90F68744D01237BFCE59CB 9DB0846B3F90F68744D01237BFCE59CB
35A1A7AB3474C72E950B1A5D738DD93B5C A1A7AB3474C72E950B1A5D738DD93B5C
36A479D9418DEB19361A846A878E51B1F4 A479D9418DEB19361A846A878E51B1F4
37BA8FAB4899D1F8E7FB4657D294FE1510 BA8FAB4899D1F8E7FB4657D294FE1510
38C0B3E0125D1A1A0FF5DBBCA296F8AD4F C0B3E0125D1A1A0FF5DBBCA296F8AD4F
39C1135A3AA842C8E3CDD2493E48CFAE7F C1135A3AA842C8E3CDD2493E48CFAE7F
40D9349B56109FDED872A007EFAB82BFB9 D9349B56109FDED872A007EFAB82BFB9
41E7504AFB7D3264410C74C2EA777AB1F3 E7504AFB7D3264410C74C2EA777AB1F3
42EBE5167861155DD1434BD6284ED73272 EBE5167861155DD1434BD6284ED73272
43EFE6179F82CA4471725D4532BC8AA60D EFE6179F82CA4471725D4532BC8AA60D
44F17F2EA5FCB70635738A07C173124945 F17F2EA5FCB70635738A07C173124945
45F3808399DA786C31CD69E5E4D1749957 F3808399DA786C31CD69E5E4D1749957
46F7DB5E988FF2AC261DF6FAE91E669CF4 F7DB5E988FF2AC261DF6FAE91E669CF4
47F7EB7D4BB45372D13AF34500AD82B217 F7EB7D4BB45372D13AF34500AD82B217

Wooty woot! Thanks very much for this -- I've just tried a quick test with my title graphics and your approach works -- very nice!

OK, here's the questions:

1) I understand that changing the BASE parameter anywhere in the file will point to a new folder. Any of these folders might contain TLNK files, which themselves have paths in them. Now clearly the paths in the TLNK files will be relative to the current base path. Currently my TLNKs start with TLNK: trx\folder\filename -- this now won't work. What is the best way for me to consistently name my TLNK paths so that I don't get all confused? 😉 --- Or alternatively, would starting with a root path work? ie: TLNK: \trx\folder\filename ---- does Glidos recognise the initial \ as meaning "The textures folder"? --- that would be the simplest solution I think.

2) As long as all mapping files start with GLIDOS TEXTURE MAPPING, does this mean I can have one map file per level? EG:

TRXmap_title.txt
TRXmap_level01.txt
TRXmap_level02.txt
etc...

3) Can I put comments in the mapping file? If so, what's the syntax?

I tried using a root (TLNK: \trx\etc.) and unsurprisingly it didn't work.

So I tried a relative path instead (TLNK: ..\letters\etc.) and that worked. Cool.

But I've just realised something important: the relative path in the TLNK file is relative to the current BASE *not* the current folder that the TLNK file resides in. I'm not sure this is logical -- maybe this should be changed?

OK, last comment for now:

I tried it with a fully qualified path (E:\projects\trx\etc...) and it works beautifully. No more copying of folders from one partition to another for testing! Great! One tiny problem -- if you forget the trailing slash in the BASE setting, it don't work -- could you check for that and append internally if it's forgotten?

You can have a mapping file per level as you suggest, and I would imagine that would be a very good approach, especially for people wishing to mix and match texture maps.

Anything after // in a line is thrown away - just following your suggestion.

Ah! TLINK paths! Hmmm, I hadn't thought about that.

It's funny, in my test with relative paths in TLNK files, I made a mistake and only put in one level up (..\), for example to find all the letters for the title. The base was set to trx\title, and my structure looks like this:

1trx\
2    \letters
3    \title\
4           \weirdnamedfolder1
5           \weirdnamedfolder2
6           \etc...

Now, using only one level up (..\letters) from wierdnamdefolder1 shouldn't have worked in terms of 'normal' relative paths -- I would need two levels up (..\..\letters). But of course, because the relative path is established using the base setting, which is currently trx\base, it works. Took me a while to realise what was going on.

I really don't know whether it's best for TLNKs to respect the BASE setting or not. There are pros and cons of each approach.

In some ways I would prefer for the content of TLNKS to be wholly independent of any external mapping file, so that a group of associated TLNKs and nested folders (as shown in my first sample on page 1) can find their graphics relative to each other.

I think maybe the ability to define some kind of ROOT variable would be useful as discussed above. What do you think?

It is all screwed up. I implemented link files using the hack of assuming that they would appear one level of folders below "Textures". I'm now not sure what the best behaviour would be.

It's not completely screwed -- they seem to respect the base path so that's a happy coincidence(?). But I agree, not sure of the best way forward.

No it doesn't it always look one folder up from where the link file is, which is sometimes the base. Its completely screwed. 😁

Ah, I see, so putting ..\ in my link files means it's actually looking two folders up? That makes sense and seems to be what happened in my test.

I'm thinking go with your ROOT: suggestion. You can use it only once. It should be the first thing in the file (after the signature). Anything before it is ignored. BASE: statements are taken relative to ROOT: and so are LINKs.

How would that be?

That sounds perfect! 😁

So to install texture packs into a folder called trx off the Textures folder, the root would be simply TRX\?

Will TLNK relative paths then be relative to the ROOT, the BASE, or their containing folder?

Ok that's done. You can now write

1ROOT: path

Should be the first thing after the header line. Anything before is ignored. Any later lines that say ROOT: are ignored. The path is relative to the Textures folder, unless it starts with a drive letter.

You can stick occurences of

1BASE: path

anywhere you like. The path is relative to the one specified by ROOT: unless it starts with a drive letter.

The actual mappings are relative to the path specified by BASE:

The contents of link files are relative to the path specified by ROOT:

You can still use multiple mapping files, with differing ROOT: statements. Should work.

Here's a new .exe. Please delete the previous one if you downloaded so we don't get confused about versions.

You, sir, are a genius wizard of the highest order. I will test this out later. Thank you very much! 😁

I couldn't wait -- have just tried it and it appears to work perfectly. This is going to make a massive difference to improving the testing time, managing the folders and deploying texture packs. I really appreciate the work that you've put in to this and promise to make the most of it by continuing to develop the texture packs.

I have a couple of days off this week so am going to try and grab some time to work on the weapons and finish off Lara. Although she was completed a while ago, she looks rather fake in places ( 😀 ), so needs some work...

Hey, you make it worth the effort.

Will there be an "official" release of 1.32 soon?