Zelda Ocarina of time Community Retexture Project

[death--droid]

None of this artwork is public domain or creative commons.
All artists retain the right to dictate who can and can't use there artwork, however upon submitting your artwork you do lose the right to pull your artwork from this project, most artists here would prefer there work not to be used by others.
So just to quickly sumarize that the only right we take away from them is the right to get there work removed from the pack, the creator of the artwork does keep all other rights.

Also I've only ever used SVN so I have no idea how git works.

I don't really care of the use of any images as long as they have permission from the creator of the image.

If the majority of active artists think that the git repo idea would actually work then I would gladly let it be done.
If you feel the git repo is a great idea then go ahead I just feel it will reduce quality control and may damage some artists rights. But then I'm not really one for legal knowledge at all.

EDIT:

Ok, if the majority of artists agrees with Smorg that we need a git repository then I'll set one up.
Anyway lets try and keep the chat to a minimum and focus on textures.

 

[mode7]

Smorg, maybe you could give us some quick overview of git like how does it work what are the advantadges what may be the disadvantadges.
Because I have no idea what this discussion is about

 

[Smorg]

None of this artwork is public domain or creative commons.
All artists retain the right to dictate who can and can't use there artwork, however upon submitting your artwork you do lose the right to pull your artwork from this project, most artists here would prefer there work not to be used by others.
So just to quickly sumarize that the only right we take away from them is the right to get there work removed from the pack, the creator of the artwork does keep all other rights.

Also I've only ever used SVN so I have no idea how git works.

I don't really care of the use of any images as long as they have permission from the creator of the image.

If the majority of active artists think that the git repo idea would actually work then I would gladly let it be done.
If you feel the git repo is a great idea then go ahead I just feel it will reduce quality control and may damage some artists rights. But then I'm not really one for legal knowledge at all.

EDIT:

Ok, if the majority of artists agrees with Smorg that we need a git repository then I'll set one up.
Anyway lets try and keep the chat to a minimum and focus on textures.

Yeah the copyright thing is a touchy issue that doesn't seem important at first but can bite after enough people have contributed to a project. The jist of it in most countries (as you're probably aware) is that the creator of any work by default retains all rights to their work unless they explicitly agree to give up those rights. In the case of free software projects, or any community-generated content like Wikipedia for example, that becomes a problem when you have 10 people that have all modified the same file - if there is no explicit agreement then you technically would need to get permission from all 10 in order to create a derivative work and redistribute it. If you have a project with a hundred contributors and a thousand files you can see that becomes an issue. If someone leaves and can't be contacted then you're screwed (which is exactly what kept the Glide64 'Napalm' plugin out of the Mupen64plus project for instance).

So to fix this in community projects you usually require that all contributors release their work under a permissive license which allows all future developers/artists/authors the freedom they need to keep developing without having to ask permission. Simply not allowing them to remove things isn't enough because they could still prevent you from creating derivative works thus potentially forcing you to lose control over and redevelop large portions of the project for no reason other than some rogue contributor's douchebagery. Since most of us don't want to deal with the legalese we just use some cookiecutter license that does the work for us which is what Creative Commons is really good for.</political rant>

Anyway, with regards to Git, it actually might not be the best choice depending upon what you want. If you wanted to follow a Cathedral model (as you currently are) then you might prefer SVN because it gives you complete control over a central repository. Since we're dealing with artwork binaries though and not source code there isn't any purpose in tracking diffs in individual files which is where Git starts to make more sense IMHO. The main reasons I can see to do this are:

1. All contributors get to see the current working state of development.
2. Syncing with that state takes next to no bandwidth for both the host and the user/contributor.

I personally disagree that disallowing derivative works and redistribution improves quality, but that's up to you guys (and I suppose I could be wrong). In practice it's really only the repository of the primary developers that gets any attention by the masses. That's exactly how the Linux kernel works which Git was specifically designed for developing. There could be 10 trillion branches sitting on people's computers but it doesn't really matter because the only branch anybody pays attention to is Linus'. And as I mentioned, the distributed nature means nobody is forced to use it (though it does work really slick), you can just keep importing tarballs, patches, or whatever.

Texture modding looks fun and I can't wait to see what I can do with it! :bouncy:

 

[death--droid]

@Smorg that's a brilliant write up, If most of the active artists agree with the move to using a git or svn repo then I'll gladly set one up, just will need to find a decent host that allows us to show a TOS and has the bandwidth allowance that we would require.

But that can wait till we have a majority of people that agree.

One last thing Smorg would you be able to write up a license that would fit this projects current structure since my attempts have being quite horrible(Look at first post) and you seem to know a lot about this sort of stuff.

 

[Smorg]

Oh, and I forgot to mention... what you guys REALLY might want to consider using is this thing called rsync (see http://en.wikipedia.org/wiki/Rsync ). I'd highly recommend it for a texture pack project like this - even over Git (especially if you don't care about decentralized development), because you probably don't care about all that history or diffs. All you want to do is be able to efficiently sync files against the newest working state. Rsync is used by Gentoo to distribute the portage ebuild tree. They actually use a combination of CVS for development, then distribute the tree to end-users using Rsync. (Of course there's also the Funtoo project which uses Git as an alternative to Rsync). Again, people aren't forced to use it necessarily.

One last thing Smorg would you be able to write up a license that would fit this projects current structure since my attempts have being quite horrible(Look at first post) and you seem to know a lot about this sort of stuff.

Yeah I could look in to it. IANAL... so writing a license from scratch probably isn't wise.

 

[death--droid]

@Smorg that does sound like something we should use, I'll look into it tomorrow
Thanks for helping out!

 

[mode7]

Ok, I get into it...a little. For me some questions remain:

Who or what is going to make sure someone does not (deliberately or not) mess up the whole pack)?

Who is going to decide which textures get replaced and which not.

Who is going to make sure everybody uses this system and who is going to explain it to the artist which are not so fit on the technichal side (like me)

apart from that: I think its a very good idea!

 

[Surkow]

I think it will be very easy to use in Windows (with a GUI). See here for more information. Basically when you change files you can commit the latest version of the file you edited. Other people can update to the latest version containing your edits. GIT allows a central repository or a decentralized system where updates are sent to.

 

[Chieftain459]

Provided there is a resource that doesn't involve a lot of code-writing (something I can't do very well), I'm all for using a better system for uploading, organizing and maintaining everything. D--D, it may help to take some of the pressure off of you for holding onto everything and releasing the packs by yourself!

 

[Phillip]

Went through the thread here and just wanted to say great work to everyone involved. This is some amazingly high quality work you guys have been turning out and it's very much appreciated!

 

[Smorg]

Who or what is going to make sure someone does not (deliberately or not) mess up the whole pack)?

Revision control isn't a free-for-all. It's just a system that allows you to track changes and distribute a huge project like this in a sane way. You take a part of your filesystem and add the dimension of time which allows you to track it's history and the changes you make. You can synchronize with someone else's, pull in changes made by others, push changes to others, all while having total control - at least over your own copy. If you deliberately mess up your own copy, nobody will download it from you. If you make it better, people will.

If someone decides to fork the project (copy, and then redistribute a modified version), then wreck it, nobody's stopping them, but also nobody will use the version they wrecked so it doesn't matter. If someone forks the project then makes a version 10 times better than yours, then you can either decide to merge in their changes or not.

People are free to do this whether you use a system like this or not depending on how the project is licensed. Virtually all successful free collaborative projects work in this way. People have to be allowed to make changes in order to contribute. This is generally considered a good thing and I can't see any reason to prevent it for a free non-commercial community project. You just need to use a license like the Gnu FDL that requires that all derivative works become public domain so that nobody can create a new project based upon yours without allowing you to modify and redistribute their changes. This is called Copyleft.

Who is going to decide which textures get replaced and which not.

You do. Nothing changes. You keep holding your own project to the same standards as you did previously.

Who is going to make sure everybody uses this system

Nobody. Some might already be using it without your knowledge. You can't and wouldn't want to force everyone to use it. Likewise, you can't force anyone not to.

and who is going to explain it to the artist which are not so fit on the technichal side (like me)

This would be something for technical users should they choose to use it. It isn't hard to learn and has many advantages. If not you'll just keep working off of a possibly outdated snapshot of the project like you're doing currently, and re-download the entire project when you want to update - or manually merge changes by hand like you might be doing currently. Revision control isn't a substitute for periodic snapshotting for doing public releases of polished versions. It's primarily for developers and those who wish to test out bleeding-edge versions.

• Git is considered distributed. SVN is not.
• Documentation mainpage. Go through the git tutorial because it's short and gives you just enough knowledge to do the basics.

By the way, rsync isn't considered revision control. It's just a handy way to distribute files. It misses a lot of features but is also easy to use and you might not want all those features anyway.

 

[death--droid]

At the moment I'm leaning towards using SVN as it allows us to control who can create branches and submit content plus I have used it before .

 

[mode7]

Thank you for the good explanation Smorg.
I'm on it. Still I'll support death--droid in this as he is in charge, so his decision will be mine.

 

[death--droid]

Just a quick note If i am to do it I won't do it till the next pack has being released.
Now back on topic from now on please.

EDIT:
XD I really fail at wall textures, especially bricks.

 

[lhthien08]

help!
i am using the Dijji 's texture pack but when the texture pack loading done there a eror "Failed to alocate memory" sometimes the window disaperce

 

[death--droid]

lthien that has nothing to do with this pack. Go get some help somewhere else.

 

[mode7]

lhthien: Probably you dont have enough video memory

@droid: why not using a brick photo texture?
If you want to do it in PS dont use the smooth bevel but the chisel method instead

 

[Phillip]

Having been inspired by all your guys' awesome work, I'd thought I'd try to contribute something.

My first texture. Just a quick note - I'm note sure what has been done since the last update and what hasn't. I did go through this thread but that was a few days ago but I might not have remembered everything. If someone already did this, I'll move on to something else.

With that said here's a simple sign texture (didn't notice it until after I looked at in game but the handwriting is supposed to be straighter, no curves):

original: http://img241.imageshack.us/img241/7871/14641447.jpg

new: http://img143.imageshack.us/img143/8329/newjs.jpg

Any feedback is appreciated.

 

[death--droid]

@Mode7 I couldn't find any brick photo texture that I was able to manipulate to the colour I required, I'm going to have another go at the textures later.
@Phllip that looks quite nice, need a screen shot from a bit further away to give some feedback tho, at the moment it looks quite good! Glad to have you helping out.

 

[Phillip]

@Phllip that looks quite nice, need a screen shot from a bit further away to give some feedback tho, at the moment it looks quite good! Glad to have you helping out.

No problem! Don't know if I'll be able to do as much as you guys (I'm not as skilled) but I'll do what I can.

Here's a shot from farther back:

http://img24.imageshack.us/img24/610/32380398.jpg