(If this is your first time reading this post, read through it before visiting the link.)NOTE! This script is now obsolete and disabled
http://jupix.info/openttd/gfxdev-nightlies/
The pack currently available there has very few contained graphics, even though there are lots on the repository. Read on for why this is and what should be done to fix it.
A bit of background
If you recall, there was some talk in January about automating the "megapack" creation process, now that we have our content in a central place, which is the repository. It was suggested that I implement the tar bundling feature at the repository.
I (silently) acknowledged the idea as a good one, but there were some immediate concerns and things that prevented me from implementing it right away. I'll now throw in a quote from the discussion.
In short, the issues were:Jupix wrote: Ben keeps hitting the nail on the head in that the repo was never designed as a player resource - rather, it's an artist / developer resource with all the inherent negative aspects in regards to user friendliness, one of which is that files are, by definition, divided to small, easily manageable and modifiable packages which in an ideal situation contain only one "item", like a house.
[ ... ]
Now, the reason I went with this approach in the beginning is money, basically. As you may know the repo's already running on a 1mbps upline which translates to about 80 - 110 kB /s real download speed divided between all the concurrent users and users of my other websites. That's not a lot if I were to distribute megapacks that can reach 100's of megabytes in size. To get a bigger pipe to the server requires taking it into a server hotel which costs a fortune and as usual I'm not getting a penny out of doing this.
[ ... ]
Furthermore, automating the process of creating big packs at the repo takes considerable knowledge of how tars are handled using PHP and to be honest I don't have that knowledge, at least not yet. Also, it takes considerable server effort and we're running on a 600 MHz processor and less than 200 MB's of RAM. Compression is obviously right out of the question and I'm not sure how low specs like those would handle hundred megabyte uncompressed bundles.
1) philosophical issue with modifying the repository for this
2) bandwidth
3) programming knowledge and
4) server computing capacity
Well, now that I've had some time to work these out, I've reached the following conclusions.
Let's start with #3. It appears PHP has a very easy to use, although a bit buggy, tar manipulation library that I have now learned to use. So in short, this is now a non-issue. Although #1 still stands, I have implemented the bundle automation feature at a separate site that's rather closely knit together with the repository. This solves the problem of adding bloat to the repository app.
Now, as I was developing the tar bundling app, it became clear that the server performance problem did not exist so much for tar creation and manipulation, than it did for basic file manipulation tasks. Both need to be taken care of, so performance is an issue, but currently, for creating nightly builds, my server is somewhat adequate. A bundle of about 50 megs takes about 20 minutes to compile.
The only concern left therefore was bandwidth, but fortunately I received an offer from Ammler for hosting at the openttdcoop server. Once I get that automated, there should be plenty of bandwidth for you guys.
What does it do?
It takes graphics from the repository and bundles them into what we like to call a megapack. More information about sprite inclusion can be obtained at the compiler page.
My sprites are not included in the standard pack?
Your sprites need to meet the requirements for inclusion.
- Include sources in your release and pack it into a standard tar. Then set its type to "Standard tar".
- Finish models, model all construction stages, etc. to complete your item and update the repository entry. Then set its status to "released".
Important guidelines
If you're an artist or administrator, read this. This is how the automation process is supposed to work:
1. Repository contains individual items, like a house, or grass ground sprite set, or paved roads, or whatever.
2. Nightly bundle script takes these individual items and bundles them into a pack.
3. Updates to graphics are made at the repository, making changes to the individual packs.
4. Nightly bundle script takes the individual tars again, thereby distributing the fixes.
5. Repeat 3-4 indefinitely.
In order for the system to work, we need #1 to be the actual case. This means, there is work to be done for administrators (and artists who have bundled their work into multiple item packs). Divide individual works into individual entries using common sense (individual ground sprites can be bundled at the repository, but individual vehicles should not be, etc. If you're unsure, ask me.)
