OK, I'm on my xmas holidays now for the best part of 3 weeks, so I have some time to concentrate on this.
I'm going through the thread starting with the first post and commenting as I go.
First off, I actually like the basic premise. It's an idea I've toyed with personally. To the target audience of our product, I think the quality of the graphics trumps quantity. As long as we don't have a complete set, it's silly that we don't even consider deriving temporary replacements from content we already have. The "block" style apartment/office building is a perfect case in point. Just by swapping colors and rotating the model, we can make the same model occupy 4 or 6 building slots.
This is something that even the vanilla game took advantage of, and I support using this technique now, to advance the set "artificially". Especially now, when it looks like we have a very slow trickle of new content, at least for the foreseeable future.
This may even be an important development as far as public perception is concerned. It doesn't really matter whether new content is actually available, as long as the product appears more mature. But now we are moving away from game development, into marketing.
So, let's get back to development. In order to ensure a result that meets our current quality standards, we still need to operate with an eye for not so much detail, but a wide perspective. Does an airplane hangar make a good house? Of course not. Can we skimp on shadows, or use clashing colors or brightness? No. What needs to happen is 3 things:
- Careful selection of model for your specific application: only residential buildings can replace such, ditto office buildings, and so on. If there's a "small market" building, that can go into residential neighborhoods, but I don't recall there being one. You get the idea: we hurt ourselves bad if we make the replacements appear random, or incorrect. Also, the theater is a very unique design. It suffers from repetition ill-effects badly. I strongly advise against repeating it any more than it already does, just occupying the theater slot.
- Minor adjustments to repeating models. I advise retouching buildings in the way of the above-mentioned example, the "block" office building. This makes it less obvious that we are, in a way, cheating. Even if we don't do this, fine, and other game developers have skipped this part and will continue to do so. It's not the end of the world; it just makes fixing the original problem (lack of models) more and more critical as the product gets more serious.
- Following the set's design specs. It's obvious the set has to look good. But the spirit of the spec goes much further. First, licensing was mentioned. The set can only contain GPL-compatible stuff. Second, don't just think of the present; think of the future. Compartmentalize, organize, advise. Make it easier to later on make adjustments and improve on the things you create. Finally, seek input. Nothing is a better developer tool than a thousand eyeballs.
On page 1 some content is being lifted off the Blender thread and the wiki. This dooms the end product as the content there is not free. As was said, we've had this happen before and we've learned, that the energy expended on such a pack is a total waste. The product can't be marketed and it just makes the whole project look bad.
Yexo's post about the 32bit graphics request I don't value much. The original post came in when I was so busy on other stuff I could only glance at it. It looked weird and useless. I wasn't consulted on any such effort either. I don't know why they expect to receive any additional content to what is already out there. Also, while they expect to receive, they don't appear to give much. What it boils down to is, they are flogging a horse that's gravely ill. What that horse needs now is carrot, not stick. I think a set that's playable and appears nearly finished would make a nice carrot.
We have content, and a process that works (in principle, even if the technology has been somewhat broken for a while), so I don't understand the need for a developer-driven parallel process. All it can do is confuse artists, or die quietly by getting buried among the noise.
As he said, though, coding sprites should not get in the way of artistry, and vice versa. We have people who've done a lot of one, while leaving the other to those who can, and are willing. It's silly to not use all resources you have available, and concentrate on stuff that
you do well.
extrem123 said:
I think all of creators who put their work to public forum on internet want people to use their work
That is utterly false. On the contrary, artists often post works in progress and get really mad if the work gets used in any set, official or otherwise. Not to mention the judicial problems. In a word: don't.
Maybe "TT-Forums.net" and "32bit Graphics Development File Repository" services could have in terms of use some sort of legal notice about posted graphics for non commercial usage. (f.e. like deviant art).
OpenTTD is, by its very definition, non-commercial. It's what has probably kept us alive for all these years. Therefore OpenTTD usage, which we do, basically constitutes "all usage". So, neither I or the administrators of TT-forums can make a blanket statement releasing everything uploaded to our sites for all usage. That is just silly. In the repository, rights available to a file are given on a case-by-case basis on the file's detail page. Some files are unlicensed and therefore unusable for anything but ideas and personal use.
planetmaker wondered about the up-to-dateness of my nightly pack. He's right of course, it's
not up to date, by a long shot. It's at the level of June, when it was last run. Like I said in my earlier post, the cronjob running it has been broken all this time. As I'm writing this, I started the process manually, so at least we'll have a December 21st edition of both the player and developer version. Still, I maintain, this pack is not the official 32bit release. It's just a hobby of mine.
OPS posted on page 3 about project organization. I'll go through it point by point as it's kinda up my alley.
I have no problems with taking on such tasks, its clear no one is hugely interested in such a job going by the age of the last thread that made a pack.
You're right, it is tedious. That's why I wrote a script to do it automatically. I'm in a unique position to do it as I have the repo database on my server. All I need is people to keep that database updated.
I noticed the wiki is currently being used as a tracker of sorts but not all objects appear to be listed and theres no way of knowing if someone is active. Some are claimed as WIP but don't even have the name of the person working on it. In some cases there is also no record of where the finished work exists on objects marked as finished.
The issue of using the wiki as a tracker is one that comes up about once a year or two. You're right, it's a rubbish solution to the problem. My principles about this are:
- There should never be any WIP entries on those lists. To me, WIP there means "dead". I have also enforced this principle at the wiki, by clearing WIP rows completely, but every now and then some creep in and the result you have in front of you.
- Tracking progress should be as automated as compiling the end product. I envision a grid of sprite numbers where highlighted in green are sprites that are found on the repo, in "released" status. This is something I've been planning on implementing as soon as school doesn't trump a couple days of gratis coding.
It would make sense to make sure any future work intended for the base set is done under a certain license (GPL?) or set of licenses.
You might want to read my spec proposal on 32bit gfxdev organisation:
http://www.tt-forums.net/download/file.php?id=129306
In it is a § for exactly this.
planetmaker would simply:
create a project on the DevZone which can contain all base set sprites in 32bpp in whatever zoom level.
but I wouldn't add any more websites behind a project that is held back by all except infrastructure. OK, a tracker would be nice, but it would take way less effort for me to just write one, rather than migrate everything to ottdcoop.
I'd fix the license to GPL v2 (no Jamaica dance around different licenses, just this one, then it's clear from the start, no questions needed
and that would be all fine and dandy, but doesn't take into consideration that a lot of our content hasn't been licensed specifically under GPLv2. Therefore we would lose a lot of content, which there is already a shortage of. It's counterproductive seeing as though there is no judicial problem with our current policy (free and GPL compatible content only).
Arguments against my nightly compiler:
I'm already aware of the repo. There are many problems with it:
Note that GeekToo was talking about the nightly build compiler. It has almost nothing to do with the repo, save for the repo-database connection. In principle they are completely different. The repo I consider official, but the nightly compiler is just a hobby of mine.
The nightly builds compiled from it are no longer nightly and haven't been for half a year.
This has been covered at some length now.
Files have been uploaded with no license.
This is not a technical problem. The nightly build compiler knows what releases have which license, and compiles accordingly. A new infrastructure for graphics does not solve the problem of some content not having a license attached to it. We went through a frenzy of contacting previous artists and begging them to license their content, with some success. The result is we got some content licensed, and some not. The latter portion is on the repo basically only for legacy reasons. It is not morally wrong since basically all of it is uploaded by the original artists, for all the right reasons.
Files have been uploaded with different licenses, complicating the matter.
See above. Since the repo knows which license is which, a set can be compiled with the right licenses.
Theres no set out naming structure and if there is it hasn't been followed.
There is a naming structure. There is also a handful of people who've administered the repo and repackaged content into that format. If you think compiling tars into a package is tedious, what do you think
this is. The exhaustion speed is, shall we say, high.
Also, there are only so many naming structures the game will accept, and we know them all. There is the current one, the Win32 one, and the DOS one. The nightly build dev version can read all of them and organizes all the content into the new format so that the content is all similarly set up.
As its only a repo there are no built in features like tracking and assignment, thus requiring other systems aswell.
For tracking, like I said, I've planned an automated tool, since I already have the data.
For assignment, we have no need, since we don't operate in an organizational structure with responsibilities. No one has the authority to assign anything. An artist claiming stuff is their own business, and this is good, since it results in a maximum throughput of content; if something is assigned and a WIP, it usually doesn't get done, since it just sits there, dead.
This is not another pack, it would replace all before it. It is intended to be properly organised and managed with set guidelines for what is classed as a finished tile and what license has to be used for it to have inclusion.
After all I've now already said, I don't think I have to tell you how funny I find what you wrote there. You are about to replace something that follows to the letter the principles that you're basing your new algorithm on. Talk about reinventing the wheel.
Jupix doesn't seem to be very active anymore.
For this my own reasons are no excuse. However, I did design the repo to be plenty community-driven. Also, on matters such as this, I'm still reachable by e-mail and PM, for consultation. I do also read the forum from time to time.
The whole idea of doing this has started from the mess of licenses. Starting a fresh on DevZone will mean all files uploaded must be gpl and also mean that no one in the future needs to deal with licenses in the way we do now.
I guess I don't have to tell you either, what a death blow it would be to start afresh. After all it has taken us the best part of a decade to get where we are now. You can add all infrastructure you want, but it would take a 32bit version of Zephyris, a tireless fast worker and a massive contributing and self-sufficient artist, to get anywhere.
.... so here we have a problem that we solve on multiple levels:
[ ... ]
I urge you to read my white paper, linked above in this post. The personnel side of things may need revision, but I don't think the rest of it is obsolete by any means.
OPS wrote:
Atleast be sensible. This is a disscussion about organisation and licensing issues.
We already have a thread for that:
http://www.tt-forums.net/viewtopic.php?f=36&t=46667
And on this subject, note that the organisational conversation that has ensued will be split off this topic and merged into that thread. This is for future people who then don't need to look for discussions among old, dead threads.
I think extreme has come to this project as a new user like me, wanting the latest set of graphics and in trying to find them discovered all the same problems I did.
You are in a unique position to make suggestions. I'm the first person in line to tell all managers that new people have the widest perspective, and the most open mind to make suggestions, start improvements, and get rid of old, nonfunctional processes. However, I must stress that it's obvious you don't have all the facts, and are in fact not aware of some ideas that are already just awaiting implementation. Also, there are some changes that while good in principle, would be counterproductive if not actually destructive.
I do urge you and everyone to read my
white paper. Tell me what you think, and also, tell me if you'd support it. I would like to revise it as far as personnel, and then have a vote on it, in order to get it ratified. It would have to be approved by as many developers as possible, and also the players who frequent the general discussion forums. This is not a change that should be done behind the scenes. In addition, it is one that I genuinely believe would benefit the project, by bringing clarity to a situation that you have stated, and everyone knows, is in some respects pretty chaotic.
GeekToo wrote:
I am not mad, on the contrary, I am really happy that the extra zoom functionality made it to trunk. It is not yet nearly as nice looking as the EZ-patch, but a very important step has been made by Peter1138 (or was it Petern? I always mix 'em up), and believe me, I know what effort it must have cost him. And yes, you're right, I did not care too much about getting my patch to trunk, I just wanted to show the possibilities, and do what I thought was nice to see. But the fact that the patch did create a nice community, and possibly inspired the devs to also implement it in trunk makes me feel good.
No matter whose code gets into trunk, I think it's safe to say you're already one of the greats, as far as OTTD graphics, along with AllTaken and Ben Robbins. You deserve your name in the credits more than some of the people there.
Now for the last post before mine:
The best thing you can do is migrate to the dev.openttd.coop server with everything.
Like I said earlier, I think this would be disasterous. Unless the change includes all content and software, the effort far outweighs the potential gain. Also, having to learn all new processes and sign up for new websites does not benefit a project that is sick due to lack of content.
What you need most now is a faster server, lots of storage space, a wiki (for getting new artists started), an issues tracker, version control
Faster server: I'd like that too. Everything under my domain runs off a theoretical 1mbps upline.
Lots of storage space: I currently have 132 Gbytes, I think that's enough, considering the whole repo consumes less than 1,5 Gbytes.
A wiki: are you kidding?
Issue tracker: I recall argumenting against this many times before. In principle, an issue tracker is good. But in our case it's an overly complicated solution to a problem that mostly doesn't exist. The issues would basically consist of alignment issues (glitches) and things like "X doesn't look good, someone should draw it again". Things like that are currently pretty well handled in the Blend thread. I also recall suggesting a thread for bugs only, when I get around to reorganizing the stickies on this subforum. (It's another thing that I've neglected since I lost my notes for what I was gonna re-glue.)
Version control: I think it's up to debate, whether version control would benefit a project such as this. All I can think of as far as pros, would be the ability to undo updates. The rest would be cons, a huge one being the added complication, in addition to just implementing the whole escalada in a way that doesn't cause hassle to artists. I think this would be just a solution to a problem that doesn't exist.
Most important IHMO is that their server will keep up if/when the sprite creation kicks in fourth gear when dedicated zoomed sprite support becomes available in trunk. A lot more people will be exposed to them zoomed sprites and their progress as the server is quite active.
They offered to mirror the packs long ago. Once I started to push the packs over there over SSH, it didn't work, and no one there bothered to investigate whether it was their problem, or mine. Nor just plain help.
Currently, we're doing fine with whatever bandwidth I have available, but I'm always open to new mirroring options that are somewhat easy to implement - meaning they work off the bat with SSH push, or they work at the mirror end with whatever method they prefer for copying the pack available on my end.
Trust me, the issue of migrating to ottdcoop has come up many times. Usually, opinions are divided into two. Those who run the site, or are affiliated with it somehow, are in support. Those who contribute content to this project, and who use the current toolset, are either indifferent or against. Personally, it would be difficult to convince me that a complete migration is best available alternative. I'm still not convinced.
I really appreciate this discussion, and look forward to your thoughts on how we could improve this thing of ours. I would ask you to spend a bit of time doing research into what has already changed during the past few years, and specifically
why we do this the way we do. I do have the best of the project on my mind as priority #1. Also note, that I don't speak with authority. I may hold a title but most it does is give me moderation privileges, and make a statement of some experience that I may at this point in time possess.
I would also like to remind you to expect at least the latter half of this discussion getting split off and merged into the project organization thread. In the future, this thread may get buried, but the organization thread will remain sticky for as long as I have anything to say about the subject.
As I post this, the standard megapack for today has finished compiling and is available at the usual place... and pace.
