Getting Caught Up

[Fingernail]

Just to clarify: it appears some people thought I was suggesting making a campaign again.

 

Hold your horses there people, I was being sarcastic and irreverant!!!!

 

It's obviously still a rather sore wound or something.

[New Horizon]

The only real issue I see with this approach is, that it is easy to forget to upload a hires texture. If you upload the lowres to CVS, then you are already doing the CVS thing, and it is easy to remember to upload the hires version right after. IMO it's easier to forget this when you have to upload it to a totally different location with a different application.

 

That's not meant as need to debate.

 

Well, what I'm thinking of requesting from now on is that everyone upload only the hires version. I check for updates every day, so I'm always on top of it. I'll just copy the new hires textures to my hires backup and then bump a copy down to our texture specs and commit them. I really don't mind doing it. I've got the system worked out so I'm not worried about messing anything up.

[sparhawk]

UGH!!! That's the worst thing you can do, because it means that for each texture I will have two versions on CVS, without the benefit of being able to download them. Since textures are stored as binaries it means that my sever will ALWAYS take the full load for each and every copy and you immediatley replace it with a lesser version. I hope you understand that I'm absolutely against this approach.

 

Disclaimer: Note that this posting is not being against the idea per se and not arguing for the sake of arguing.

[New Horizon]

UGH!!! That's the worst thing you can do, because it means that for each texture I will have two versions on CVS, without the benefit of being able to download them. Since textures are stored as binaries it means that my sever will ALWAYS take the full load for each and every copy and you immediatley replace it with a lesser version. I hope you understand that I'm absolutely against this approach.

 

Disclaimer: Note that this posting is not being against the idea per se and not arguing for the sake of arguing.

 

I'm not sure I understand. How would you have two copies of each texture on CVS, when I am removing the hi-res version and replacing it with a low res? You're saying that 'overwriting' the hi-res texture on CVS, which is how we replace any file on CVS and is what I've been doing all along, is wrong? This is the same method I used to replace all the hi-res textures so people with dialup could download them. Let me go through the steps here to be sure we're on the same page.

 

1. I sync with CVS.

2. Download new textures.

3. I copy the hi-res textures to my local backup copy.

4. I resize the newly downloaded textures and re-commit them to CVS in their smaller form.

 

I've never put the hi-res versions back on CVS, during the whole time we've been using this method.

 

Unless I am misunderstanding how CVS works, and I think by now I have a pretty good understanding... ... you should only have 1 copy of each texture, the low res copy, because I would have over written it.

 

If you're just talking about the 'server' load...then I can ask people to upload to the FTP instead and I will process the textures and THEN commit them to CVS 'after' they have been reduced in size.

[sparhawk]

AAAAHHHH!!! Now I know why my CVS folder is almost twice as big as it should be.

 

When somebody uploads a binary file to CVS it is stored as it is. When you upload a new version of the same file it is AGAIN stored as it is. What do you think CVS is doing? You can go back in history and download ANY earlier revision of any file that has been commited. If I wanted to know what somebody changed in any given file two months ago, I can look it up. So with this technique of yours you almost duplicated the storage requirements of my CVS repository without getting any benefits at all from it.

 

I should have noticed this, if I had realized earlier that the notifications are not working for the mod part of the CVS.

 

Whenyou commit a new version of the same file, you don't replace it, you just add a new version to it. And even if you would delete the old version on CVS before you recommit, it, you still would not replace it, because CVS also maintains the original file for history reasons.

 

If you pull tricks with the CVS system you should have asked me before doing it. If we had created a seperate CVS repository darkmod_hires then I would store exactly the same filesize, but at least people could download it if they wish to do so.

[Macsen]

We could never agree on the campaign, so it's best just to wank our own dicks, rather than each others. We'll get a lot more done that way, rasther than wasting time arguing about it.

I'm sure we'll be able to tie them together with a plot.

 

Well if we do that the thief's name will mysteriously change from Farrell to something better by the time he gets to my mission.

[sparhawk]

Which is what we should avoid, as we are the creators of the TDM universe and we set the standards. We should do this now before we do a release, and since we already have beta mappers working on their maps, it would be good to tell them such details, so they can fill them in in their backgroundstory.

[pakmannen]

So what should we do when we want to upload a new version of a binary file then?

[Springheel]

we are the creators of the TDM universe and we set the standards. We should do this now before we do a release, and since we already have beta mappers working on their maps

 

Well, beta-mappers can call their main character whatever they like.

[New Horizon]

If you pull tricks with the CVS system you should have asked me before doing it.

 

Why didn't anyone stop me before I did it? I thought I was being pretty clear on what I was doing.

 

Okay...now I see why it's such a horrible idea and will no longer do it. Sorry about that Spar, had I known..I certainly wouldn't have done it.

 

I honestly didn't think CVS kept backups of every revision like that...I just thought the version numbers were to indicate that it had been updated. I didn't know exactly how the program worked at the server level...GAH.

 

 

Now, getting back to the subject of a darkmod_hires repository...I have a bone to pick about that.

 

If we had created a seperate CVS repository darkmod_hires then I would store exactly the same filesize, but at least people could download it if they wish to do so.

 

I asked you to do this for us back in July and you argued against it, saying that we needed Jpeg compression and four different repositories. I said that all we needed was a darkmod_hires to upload the hires tga textures to, and then the lower res tga textures would go where they always go, in the main darkmod folder because everyone was happy with the size of the low res TGA's...and the jpegs could not be used because they didn't render correctly in Doom 3 and mappers didn't want this.

 

Not finger pointing, just saying that this could have been solved months ago if we had of gone with this simple approach of the darkmod_hires repository. That's all we were asking for...but it turned into an argument over silly filter detials.

 

So, lets correct this issue once and for all. Here is what I am requesting for the textures.

 

One new repository, darkmod_hires. That's all, nothing more...nothing less. No jpeg compression..no filters. Just a separate repository for the hi res stuff.

 

If you still have all the backups of the hi-res textures are you able to move them into that repository so people can download them? That would be perfect.

 

I'll write up a little tutorial on how people upload hi-res to darkmod_hires and low res to the regular repository. It's easy...requires no additional filters and will solve all our problems. I'll get started adding the info on how to upload to darkmod_hires to the texture guidelines post.

 

Many thanks.

[Springheel]

Well, regardless of who suggested what when, it sounds like a good idea to have a hi-res repository somewhere on CVS. People with higher performance machines will probably want the hi-res textures at some point, but we don't want to be constanly downloading them right now.

[sparhawk]

So what should we do when we want to upload a new version of a binary file then?

 

If you upload a new version because it had to be changed, then it is ok. But you shouldn't upload new versions just for the fun of it. If you improve a texture, of course you should upload it and replace the old one, but you shouldn't upload it just because you think the new upload will cause any statechanges in CVS, because it doesn't.

[sparhawk]

Okay...now I see why it's such a horrible idea and will no longer do it. Sorry about that Spar, had I known..I certainly wouldn't have done it.

 

It's not a big deal because I have enough storage space and my disks in the server are mostly empty. But I have a daily backup running and keep the last seven versions, as well as additional backups in between which are not going to be overwritten, so this adds up over time.

 

I honestly didn't think CVS kept backups of every revision like that...I just thought the version numbers were to indicate that it had been updated. I didn't know exactly how the program worked at the server level...GAH.

 

How do you think does CVS come up with an older revision when you want to take a look at what as been changed?

 

 

I asked you to do this for us back in July and you argued against it, saying that we needed Jpeg compression and four different repositories. I said that all we needed was a darkmod_hires to upload the hires tga textures to, and then the lower res tga textures would go where they always go, in the main darkmod folder because everyone was happy with the size of the low res TGA's...and the jpegs could not be used because they didn't render correctly in Doom 3 and mappers didn't want this.

 

Well, I was maintaining that we should have such a repository but we should ensure that they are in sync with each other. Not that we have textures in one and other textures in the other.

 

Not finger pointing, just saying that this could have been solved months ago if we had of gone with this simple approach of the darkmod_hires repository. That's all we were asking for...but it turned into an argument over silly filter detials.

 

Yeaht. The reason being that I fear that people who upload, will forget that they are in one repository and upload stuff that belongs in the other. If I implement a script, then you can upload only the hires version, and I can convert it and check in the lowres in the other repository. This would be the best approach, because this way I would prevent uploading textures to the lowres repository completly and only allow other files there. So maps, def, and such stuff would go in the lowres and textures would only go in the hires and are propagated to the lowres by the server. This would ensure that we always have the same textures in both repositories and users wont have to remember what to upload where, because after some time this wil happen and we have to clean it up, which I want to avoid.

 

One new repository, darkmod_hires. That's all, nothing more...nothing less. No jpeg compression..no filters. Just a separate repository for the hi res stuff.

 

I wouldn't have put a JPG filter on the hires version. Maybe we were talked about different things with the same name. I was talking about a filter for CVS, not for textures. That filter would only ensure that you can't store maps or def, or other files in the hires repostory and vice versa for textures.

 

If you still have all the backups of the hi-res textures are you able to move them into that repository so people can download them? That would be perfect.

 

That's a lot of work, because basically it means that I have to extract every single texture manually and check if a hires version exists for it and if so, then upload it to the other repository. I don't see how I could automate this process. You said you have your local copy of the hires version. How accurate is it?

 

I'll write up a little tutorial on how people upload hi-res to darkmod_hires and low res to the regular repository. It's easy...requires no additional filters and will solve all our problems. I'll get started adding the info on how to upload to darkmod_hires to the texture guidelines post.

 

If people have to remember instructions they will forget or make errors. That's the nature of it. Disclaimer: I don't mean that users are stupid or what (for those ho might feel offended by that remark). But it's only logical that if something is not prevented by the software it will happen. That's why I think that it's better to implement the filters if possible.

[sparhawk]

OK. So I will create this repository today.

[New Horizon]

I'm pretty sure I have 99% of the hi-res textures as I kept a few older copies of the mod on my hard drive. That being the case, don't worry about moving the textures. I can upload them to the proper repository and I will post explicit instructions on how to do this.

 

If you're worried about people making a mistake, we can just ask for them to put the hi-res in darkmod_hires on CVS and then I'll download them, convert them and upload them to the darkmod repository.

 

We'll see how it works getting everyone to do their own for now though.

 

Thanks.

[sparhawk]

If you're worried about people making a mistake, we can just ask for them to put the hi-res in darkmod_hires on CVS and then I'll download them, convert them and upload them to the darkmod repository.

 

The problem is not that people are to lazy or to stupid or whatever, the problem is that it is easy to forget that you should switch the repository. So you finished this great model along with textures and you created a def file for it and material and whatnot. Then you upload the hires textures to the hires repository, switch to the other rep and upload the rest of the stuff. This is where it is easy to forget about it and upload everything.

 

Well, I can at least write a filter that ensures that only TGA files may be uploaded to the hires rep, so that people will get an errormessage. I guess we only use TGA files as textures, right?

[New Horizon]

Well, I can at least write a filter that ensures that only TGA files may be uploaded to the hires rep, so that people will get an errormessage. I guess we only use TGA files as textures, right?

 

Yeah, just TGA is needed for the hi-res stuff. I noticed that someone used DDS for a candle flame but that's low res and should only go into the main mod folder anyway. So that would work perfectly if the hi-res only allowed TGA.