How do you ensure that you delete all the duplicates of this texture in all the other capture folders?

This is down to the methodical way that I choose to work. I described this elsewhere: To start work on a new level I scan through the capture folder and sort all the bits into sub-folders (i.e 'lara', 'rock', 'earth'...). Its a lot cleaner now because I can simply delete the bits that the equiv file has taken care of - e.g 'lara' - and I have a clearer picture of the work that will be involved.

I had to back-track to clean up the earlier levels. I generated an equiv file from just the Peru levels then pasted it into an excel spreadsheet. Using filters, this enabled me to locate all instances of duplicate textures and/or link files and delete all but those that I wanted to keep as the 'base'. It took a whole day (and much blaspheming...) but it was a job that only needed to be done once!

Paul wants to mix and match levels

We shouldn't let him do it!

I assume here that the equiv file you refer to would be a complete one for the entire game?

It could, but it doesn't need to be...It could just be updated to include each 'add on' pack that gets released. I think I have comitted a cardinal sin with my equiv file - but I'll raise this matter later....

OK... I'll confess now! In my packs for Folly, Colosseum and Midas there were six textures that got re-used in the original game which I wanted to replace with alternative textures. I whipped the duplicates out of the capture folders before I ran the equiv tool so that the file wouldn't list them. This allowed me to treat those six panels as if they were individual occurrences. I have made careful note of what they are so I would be able to repeat the trick should anyone want me to create an equiv file for a different version of the game. The only pitfall I can see though, is that my equiv file will not be interchangeable with anyone elses....

Yes I know. I subsituted an equiv file of my own with your pack, and noticed it messed up the MIDAS letters. I've been wishing to discuss this issue, but I thought I'd wait until the other discussions had died down. 😁

Its important that you can override some of the automatically generated equivalences, but it messes things up when you want to enhance a pack to work with other versions of TR. You'd like to build a Capture folder that had textures from all versions, and generate a new equiv file, but then you have these little tweaks to make.

I've been trying to think of a way you can right down the tweaks so that I can let you reapply them automatically, but I haven't figured out how.

I *could* be wrong, but I think there's only 2 actual versions of the PHD files on the various versions of the game.

I have what I consider version 1. I believe JC has version 2. We have both captured the entire game.

Should we share our captures and generate one big equiv file that we (all artists) use as a base? If we do this, then we're all starting from the same point and can make any tweaks we like to the equiv file for our own purposes.

Of course, no reason why we can't do this if there *are* more than 2 distinct versions of the PHDs... we just need to get hold of them.

Version 1 PHDs: 25/10/1996
Version 2 PHDs: 05/11/1996

Version 1 Listing:

11996-10-18  10:40           106,587 CRED1.PCX
21996-10-18  10:40           196,985 CRED2.PCX
31996-10-18  10:42           174,908 CRED3.PCX
41996-10-25  10:58           599,840 CUT1.PHD
51996-10-25  10:58           354,320 CUT2.PHD
61996-10-25  10:58           512,104 CUT3.PHD
71996-10-25  10:58           879,582 CUT4.PHD
81996-10-24  16:04            22,700 EIDOSPC.PCX
91996-10-18  10:42           102,512 END.PCX
101996-10-25  10:54         3,237,128 GYM.PHD
111996-10-18  12:32           168,100 INSTALL.PCX
121996-10-25  10:55         2,533,634 LEVEL1.PHD
131996-10-25  10:58         3,224,138 LEVEL10A.PHD
141996-10-25  10:58         3,094,342 LEVEL10B.PHD
151996-10-25  10:58         3,532,024 LEVEL10C.PHD
161996-10-25  10:55         2,873,450 LEVEL2.PHD
171996-10-25  10:55         2,934,730 LEVEL3A.PHD
181996-10-25  10:55         2,738,258 LEVEL3B.PHD
191996-10-25  10:56         3,030,872 LEVEL4.PHD
201996-10-25  10:56         2,718,540 LEVEL5.PHD
211996-10-25  10:56         3,074,376 LEVEL6.PHD
221996-10-25  10:56         2,817,612 LEVEL7A.PHD
231996-10-25  10:57         3,389,096 LEVEL7B.PHD
241996-10-25  10:57         2,880,564 LEVEL8A.PHD
251996-10-25  10:57         2,886,756 LEVEL8B.PHD
261996-10-25  10:57         3,105,450 LEVEL8C.PHD
271996-10-25  10:54           316,460 TITLE.PHD
281996-10-08  12:54           115,980 TITLEH.PCX
29              28 file(s)      51,621,048 bytes

Version 2 Listing:

11996-10-18  11:40           106,587 CRED1.PCX
21996-10-18  11:40           196,985 CRED2.PCX
31996-10-18  11:42           174,908 CRED3.PCX
41996-11-05  18:12           599,840 CUT1.PHD
51996-11-05  18:12           354,320 CUT2.PHD
61996-11-05  18:13           512,104 CUT3.PHD
71996-11-05  18:13           879,582 CUT4.PHD
81996-10-24  17:04            22,700 EIDOSPC.PCX
91996-10-18  11:42           102,512 END.PCX
101996-11-05  18:09         3,236,806 GYM.PHD
111996-10-18  13:32           168,100 INSTALL.PCX
121996-11-05  18:09         2,533,312 LEVEL1.PHD
131996-11-05  18:12         3,223,816 LEVEL10A.PHD
141996-11-05  18:12         3,094,020 LEVEL10B.PHD
151996-11-05  18:12         3,531,702 LEVEL10C.PHD
161996-11-05  18:09         2,873,128 LEVEL2.PHD
171996-11-05  18:09         2,934,408 LEVEL3A.PHD
181996-11-05  18:09         2,737,936 LEVEL3B.PHD
191996-11-05  18:10         3,030,550 LEVEL4.PHD
201996-11-05  18:10         2,718,218 LEVEL5.PHD
211996-11-05  18:10         3,139,590 LEVEL6.PHD
221996-11-05  18:10         2,817,290 LEVEL7A.PHD
231996-11-05  18:11         3,388,774 LEVEL7B.PHD
241996-11-05  18:11         2,880,242 LEVEL8A.PHD
251996-11-05  18:11         2,886,434 LEVEL8B.PHD
261996-11-05  18:11         3,105,128 LEVEL8C.PHD
271996-11-05  18:08           316,138 TITLE.PHD
281996-10-08  13:54           115,980 TITLEH.PCX
29              28 file(s)      51,681,110 bytes

Please note, I got the listing for version 2 from someone else, I don't actually own it. If I did, I could generate a master equiv file myself which obviously I'd share with everyone.

I think the more we can do ourselves to help users, the better this will turn out. I think it would be cool if we could get a master equiv file that simply "just works".

BTW, at the moment, the equiv file has to be placed in the Textures folder along with a root mapping file. I think this is a problem if users want to, for example, install JCs packs and mine at the same time

Wouldn't it be better if the equiv file went in a subfolder where all the images are stored, as specified by the root mapping file?

One big all-encompasing equiv file was how I imagined we'd do it, but I can see now that isn't going to work.

The trouble is if V1 and V2 use a texture twice then you get

BeginEquiv
V1A
V1B
V2A
V2B
EndEquiv

Then if someone wants to retexture the two occurences separately they have to change the equiv file to

BeginEquiv
V1A
V2A
EndEquiv

BeginEquiv
V1B
V2B
EndEquiv

The problem is that's very difficult to do when the names are the real 32 random char ones.

I think I can see a way around it though. Got to think about it a bit more, but I'll try to post something tomorrow... and release the new tool with the checking facility.

Oh - and that idea about putting the equiv file in the root might be a good one too. Needs some thought though.

OK, you think about it. 😀 I'm gonna try and avoid this bloody great stone ball in Ghana, again! Ihate weird camera angles and non-inverted controls....

Oh, that's Legend I'm talking about by the way...

Ok, I own up. I meant, pretend I'm thinking about it while playing Legend.

Great isn't it.

Hmmm... yes and no. I'll write up my thoughts once complete...

In looking at the structure of the site and aware that in the future I will be spending less time on the computer, I need to have a way that the site is fairly self-managing.

I therefore propose that I include an admin section of the site where artists can upload a complete texture pack with a little description -- this will allow people to manage their own page and saves me from having to get involved in every update.

I'm not yet sure if this is something that I'll code myself (I'm not a good coder and it doesn't really interest me to learn), or if I'll use a CMS. Either way, people will get a user-login for their own page or something similar. I'll also have a global master login so that in the future if someone wants to take over running the site (which I hope *will* happen as my very-long term plans don't include web-development or maintenance!) they can do.

Just keeping you up-to-date. I'll be investigating the best way of doing this.

I can help out probably. It would be quite nice if authors needed only FTP access to upload levels and descriptions. I could probably knock up a bit of PHP that would construct cooresponding web pages, based on an example one from you.

Also handy if admin simply had to create a new folder and give ftp access to it to provide support for each new author. I think that's possible.

The problem with FTP is that users all need some client software and the ability to use it -- while I'm sure everyone already making packs would have no problem with that, I'd like to have a system with as few barriers-to-entry as possible for any future artists wanting to get in on the action. I think a web-based system would be better from that point of view.

I've spent some of today looking at an open source CMS called e107, but it's engine structure and templating sucks. I'm going to tak another look at Mambo which didn't impress me a couple of years back but apparently now is a lot better.

I'm considering using a wiki for the site now as I really don't like the model that many of the other CMSs use and their templating is always, well, odd.

I'm looking at http://www.mediawiki.org/wiki/MediaWiki today -- while it's probably overkill for this project, all the works done and it includes file uploads. I'll see how easy it is to write a new front-end for it (I want a nice graphical site, not the basic templates). Will report back.

Stuff that, completely inappropriate!

Actually, a blog might be the best way to do it. We could have stand-alone pages for the help and background stuff, and the main part of the site is the blog where all the artists have write access and can update whenenver they want with their progress. I'm just not sure about upload capabilities... having another look...

Watch out for problems uploading large files. My new web host provides a web shell which allows upload, but for very large files it seems to time out. I end up using FTP.

Yes, this could be a serious problem, I had a similar issue when testing out large uploads on some of the open source CMSs.

Harummph. Maybe we *will* have to use FTP. I'd rather not though, it would be much more useful if it could all be done directly through the site.

Still investigating...

Well keep in mind the possibility of giving an example page to me and seeing if I can knock up something really simple. Also, there's the possibility of opening the site with FTP being the update method, but providing web based access later.

On the other hand, if you can find something that fits the job well, it certainly would save some trouble.

I've been looking at various CMSs, blogs and wikis and they are all too complicated or too weird in the way they manage uploads and/or themes/skins.

I'd like to just stick to my simple PHP driven pages for the site. The upload/download is the only issue and I now think FTP would be the simplest solution.

I propose something like this:

1) Each user has a unique username/password setup which logs their FTP client into a specific folder off a root downloads folder, for example /downloads/jc/

2) When JC wants to upload a new pack, he simply uses the FTP client to do so. I have a little script which will automatically build a directory listing of files in a folder, so all I need to do is incorporate that into the download page for each user to provide automated links

3) Assuming uploads are RAR,ZIP or EXE, if you also include a text file that is the same name as the uploaded pack, then this could contain the description which could be used as a little summary or the link title

I guess this is all that's needed?

Paul, does your hosting allow for specific FTP accounts be setup on a folder basis in this way?

Yes, it seems to allow for an an arbitrary number of ftp accounts each restricted to a folder. Its ideal, as far as I can see.

I was thinking of something much the same. You showed an example page, which had a drop down menu, with an item per author. That menu could be generated from an enumeration of the root folder, and then each author page could be another based on a template designed by you but pulling in the files and descriptions from the authors folders (and images aswell maybe).