Oh, the structure, it was just to annoy Suicider and his love for the config files than over 30,000 lines. I say this, however, my next package of the same initial author (only if the Quadro server allows me to upload it without errors) will have a more complex structure. Indeed, for large packages, I prefer to use a cascade structure. If it seems more complex (especially to do), it has many advantages, both for the creator (which can enable or disable a bunch of objects via the addition of a single "//" ; convenient for the debugging) and for the enduser who can integrating easier the textures whiche he chooses (the statements are unique for each texture and the embed code is included in these files). The end user can decide to use a single texture or one or more bunch in a very simple way, regardless of the content of the original folder or its updates. And it does not change anything for the engine which is ultra fast for open and read files.

It is true that by doing the gutter, I realized that there was no roof texture really good. That's why I already started to redo the only two roofs textures already included (from gor and mitaman). And even if your comment has been deleted because I had to redo the knot because of the current problems of Quadro server, I thought of you by doing this package.

It is also true that many textures Sauer (from games and even older) are now obsolete, because of their small size or lack of shaders. It's been so fun to work on better quality textures. I just hope they will be used in multiple maps !

Haha, very many I assure you, but I do not post everything and I do not have time to do it correctly all either. There is a year and a bit, I had the intention to create the compilation "Ultimate Sauerbraten" kind of 4GB to 10GB (1 or 2 DVD), with real multilang menus and all that I have gleaned on the net without touch the code completely, but by restructuring the folder structure, add and adapt contents, ...
I also downloaded all the contents/mods of Quadropolis since its inception, almost all versions of Cube1 to Sauer games and mods, a lot of skyboxes, textures and mapmodels "free" (over 20 GB in total prior to the sorting). I have worked (and I actually kept everything) but I have not been able to motivate enough frenchspeaking community that I created to help me in this mammoth project. In addition, serious gaps in the documentation require too much time to test everything properly. So I set out to create a frenchspeaking wiki against this shortcoming but, again, without help, the task was too big to do alone. I spent too much time to brew of air and I ended all up dropping, seen the reactions of the community.

As I am sick these days and my creativity is still relevant, I began to realize some packages. So to answer your question: I still have much on hand that I will try to publish soon.

Then now it would be a good time to organise everything into one node seperated into categories, because if you are to post every individual texture/model pack on its own node, we're done for.

EDIT : -post to eraze- (serv prob)

Wrongly packaged (many unnecessary folders inside the zip-file, not ever texture needs to have it's own folder as it creates clutter).
I assume your trying to use the specular-mapped textures as masks for models either (very illogical why it's red elseway)? Put a tutorial for new beings how to reach your textures from the "models" folder to the "textures" folder if so.
The textures itself still seems to be very repetitive, as they are only 256x256. For a roof texture which commonly get used over a large distance, this looks very ugly. Make sure they have a resolution of at least 512x512.
Putting 5 "package.cfg" into the zip-file is pretty unnecessary, as people can also just specify 1 texture in their own map's config-file.

Wrongly packaged (many unnecessary folders inside the zip-file, not every texture needs to have it's own folder as it creates clutter).
I assume your trying to use the specular-mapped textures as masks for models either (very illogical why it's red elseway)? Put a tutorial for new beings how to reach your textures from the "models" folder to the "textures" folder if so.
The textures itself still seems to be very repetitive, as they are only 256x256. For a roof texture which commonly get used over a large distance, this looks very ugly. Make sure they have a resolution of at least 512x512.
Putting 5 "package.cfg" into the zip-file is pretty unnecessary, as people can also just specify 1 texture in their own map's config-file.

Really man, just make people can have access to your texture on a way easier way than having to specify 5 different folders before they finally reach the damn folder where your textures are at.
Just 1 folder after the "textures" folder would be enough, like called "fbp_roofs" (as of FrenchBadPing).

Nice try, but isn't looking better since it's killing the night-themed atmosphere (the textures are way too bright and not showing any contrast at all for the grey roof textures).
It still looks way too repetitive and would look way better if the resolution would be 512x512. (or at least not scaled down 4 times it's original size).
Keep in mind, a roof texture doesn't need to be really detailed as it's on roofs anyways. Players shouldn't be able in general to get close to roofs of buildings anyways. So it's better to have a large texture which contains a little repetiveness as a small texture which has the size of a trimming instead.

The problem which causes your way of packaging is that if Sauerbraten would do so in general, it would need at least 975 more folders and files as "packages.cfg", as that are the textures which appear in the default texture-palette of the current SVN version.
The ammount of folders and files like "packages.cfg" would probably be more than 2000 (as there are over 1000 textures which all need seperate folders since the default texture palette isn't showing all included textures). All those files needs to be packaged into the default texture-pallet also, which would take an enormous ammount of time to specify them all one by one.
Also, Assume that a file like "packages.cfg" for just 1 single texture would be like 0,9kb as yours are in overall of the roof textures, that would be over 900kb (0.9x1000), just to packages them all seperately.
It's also a fact that mappers specify textures in groups anyways when using them for maps (as I do for example), so the sense of posting every texture in seperate folders is gone.

Another point that this system lacks is simplicity, as you have to do something similar to this:
- Click on "packages" folder.
- Click on "textures" folder.
- Click on "Click right here for roof textures!" folder.
- Click on "Click another time before you reach the folder with the containing textures!" folder.
- Click on "Oops, sorry! You have to click another time before you reach the roof textures! folder.
- Click on "Almost there mate, just keep hitting the folders!" folder.
- Click on "Is this actually the right folder with the containing textures you really need?" folder.
- Click on "Oh ye hit me harder!" folder.
- Click on "You made it! You finally reached 1 of the 120 textures in this texture pack! The fitting wall-textures are somewhere else in this line of folders, so keep searching!" folder.
That actually pretty sucks as people don't want to get RSI just by clicking on folders and is very time consuming.

New beings won't learn anything of this structure compared to the original set up, as it's way less logical than the current system (we aren't putting maps, skyboxes or sounds in seperate folders also, aren't we? With exception of the way which non-default maps get written nog in the "My Games" folder, but that's just to prevent people will modify the default maps by accident).

I'll react on my own way to this node soon, but not now...

The scales are wayyy out visually.

Vscale is quite useful.

:-)) I was sure you would notice this little detail without any influence of the red specmap (which I made ​​especially for you).
If it is clear that I do not agree with your approach to the complex (not cluttered) that must have the folder structure, it is true that these textures are, like any textures, highly repetitive. Personally, I do not see no problem because the roofs are, by definition, repetitive. And, moreover, there is always the ingame textures blending. However, "50" for textures of that quality, I find it a little rough because current roofs texure are very far from this quality ! :-(
However, I must return once again on the issue of accessibility (which I am trying to make it more accessible and therefore more complex in my next Nobiax package).
The "file systems" (FAT, NTFS, EXT, ...) are, by nature, designed to structure the classification of files. In addition, as Sauer is extremely quick to open and interpret the file (images, scripts, ...) and it does at the opening of the map. So, technically, there is absolutely no problem to be ordered. After all, at your home, you not put your socks in the closet plates (or, maybe not in your case ;-) :P).

I'll try to take you a simple example. A newbie want to use one of your texture that is embedded in the file with 50 other textures. Well, he came to understand that he must open the file "package.cfg" for copying the texture definition, very well. But here, as in the case of "gor" or "mitaman" for example, because the images have weird names, the likelihood that he's mistaken of line are great (in fact it happens to me all the time). Now imagine he found the right line and copy it with the 3 or 4 following lines in the configuration file of his map. In your opinion, would he will realize itself as its texture has no effect because it has applied graphic forget to copy the declaration of the shader and its parameters, which is 250 lines at the top ?
So if he does not give up before, he will have to spend much time alone with its problems.

My solution is to say : 1 texture, 1 folder, 1 config-file.

Ok, the structure is super heavy, but since it did, technically, no impact, why not use it !?
In my case, the newbie will only have to: either copy the entire contents of the texture file, or simply use its line of execution. Thus, he can run so much easier its own configuration file (for example, simply by switching the lines of reporting - if he is smart enough for that).

You tell suicizer to keep his textures in a folder inside packages/textures to avoid main branch clutter and chaos is guaranteed.

IMO, unless you plan to release a huge texture pack containing hundreds of textures, you're better off keeping your bits and pieces in a folder with your name inside packages/textures and just place whatever else comes next in a subfolder; map specific textures and the such, i guess.

Things are only as complicated as you believe them to be. >_>