Project Organization Thread

[planetmaker]

Anyone wanting to claim work on the project must make a declaration here
Change wiki object flags to: Claimed/Unclaimed, then seperately - Not started/WIP/Finished
Add additional info: Date claimed, ETA (becomes unclaimed if inactive)
Add a link to tar/source/WIP preferably in the repo (if theres no link it to a coded tar it can't be marked as finished)
Add a field for license status (another factor that effects if it is marked finished)
No more "Done but no construction stages" "Done but not coded" "done but not this or that", its either finished or it's not

I'd simply create a project on the DevZone which can contain all base set sprites in 32bpp in whatever zoom level. 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, anyone who contributes to that set then will have to agree with the set's license), and start adding the sprites which comply with that license there.

You have a real issue tracker there, not just a wiki. Any person who wants to create a certain sprite which does not exist yet, creates an issue, assigns it to her or himself and then attaches the sprite to that issue once finished. Thus a coder of the set can simple grab it, align it and it's done and the issue related to one sprite (or a set of sprites) also offers a good way to communicate and discuss about them.

It has the additional advantage that it is quite easily hooked to a compile farm to the repo. This could in principle create updated bundles on a daily basis. I'll happily be of assistence with setting up these things there. Though I'd wait the few weeks with coding (but not with gathering and adding sprites there) till we can use EZ sprites in trunk as the way they need coding might differ.

[extrem123]

After reading your posts - it seems to release a new package more and more promising. Just got a little worried about duplication of wiki (part with uploads) + file repository (+ / forum) and now DevZone project. This all could be very difficult to observe (keep) and administer. I think when DevZone come to scene, than Wiki is no longe necessary. File repository is OK as a source of various (same type) graphics with legal notice. In my opinion is DevZone much more professional approach than wiki.

[OPS]

I'd simply create a project on the DevZone which can contain all base set sprites in 32bpp in whatever zoom level. 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, anyone who contributes to that set then will have to agree with the set's license), and start adding the sprites which comply with that license there.

You have a real issue tracker there, not just a wiki. Any person who wants to create a certain sprite which does not exist yet, creates an issue, assigns it to her or himself and then attaches the sprite to that issue once finished. Thus a coder of the set can simple grab it, align it and it's done and the issue related to one sprite (or a set of sprites) also offers a good way to communicate and discuss about them.

It has the additional advantage that it is quite easily hooked to a compile farm to the repo. This could in principle create updated bundles on a daily basis. I'll happily be of assistence with setting up these things there. Though I'd wait the few weeks with coding (but not with gathering and adding sprites there) till we can use EZ sprites in trunk as the way they need coding might differ.

I was actually thinking of using some sort of proper management script to start over and organise everything but thought it would be too much work to set up, especially if I'm the main force behind it. This sounds like a good alternative. I think the only question left is, will people actually use it? Its a fair bit different to the slightly casual attitude at the moment and will require everyone to sign up and spend couple mins claiming work again. The last thing I want to do is waste my or your time setting something up and it not be successful.

After reading your posts - it seems to release a new package more and more promising. Just got a little worried about duplication of wiki (part with uploads) + file repository (+ / forum) and now DevZone project. This all could be very difficult to observe (keep) and administer.

I think the information I would gain from spending time putting together a pack would be the same information needed to update or create a new tracker. So it makes more sense to fix the tracker and then new full and current packs can be generated automatically in the future.

I think when DevZone come to scene, than Wiki is no longe necessary. File repository is OK as a source of various (same type) graphics with legal notice. In my opinion is DevZone much more professional approach than wiki.

The wiki has a lot of other information on it so it won't be unnecessary in an overall sense. In terms of the current tracker there then it would become obsolete and would have to be that way for devzone to be successful. It would probably be best to remove the wiki tracker to encourage migration to the new system, however being new here I don't feel that is a decision I can make and in any case it shouldn't be removed until the new one is ready.

[GeekToo]

Hi OPS, thanks for your enthusiasm to bring new life to the 32bpp graphics packs.
You may not know me, I've been inactive for too long for various reasons. But I've been pretty active wrt 32bpp in the past:

-I am the creator of the extra zoom patch, and maintained it and provided support for it for several years
-I am the creator of the 32bpp-extra newgrf on openttdcoop
-I was one of the first to create pngcodeced graphics for ottd
-I have updated the wiki numerous times
-I have created several 32bpp graphics tars
-I have created the "standard tar template"
-I discussed and cooperated with Maquinista, Ben Robbins, Lord Aro, Jupix and several others on numerous occasions about 32bpp graphics.

I don't provide this list to brag, I just want to show you that I know a bit about the subject matter.

Now my thoughs about the graphics pack:

I was actually thinking of using some sort of proper management script to start over and organise everything but thought it would be too much work to set up, especially if I'm the main force behind it.

You don't need to set it up, it is already there:
http://jupix.info/openttd/gfxdev-nightlies/

You may want to discuss the way the pack is created with Jupix, but I don't like the idea of having yet another graphics pack. Imho you should either move the pack creation from the Jupix site to openttdcoop or continue on Jupix's site, but please don't create an overlapping pack. There have been graphics packs in the past (like http://www.tt-forums.net/viewtopic.php?f=36&t=46682), and when multiple packs are available, and one of them is not maintained anymore, you will have to answer questions about it to newbies for years to come (speaking from experience). It also makes reference to it from the wiki a lot harder.

Jupix has set some very clear conditions for a tar to be included in one of the packs in his nightly builds. It would be very simple to expand the set of tars to be included, by just pngcodecing, providing a license, or just set the correct status. Unfortunately, not a lot of work has been done in this respect recently, and we can not expect Lord Aro and Maquinista to do all the dirty work of splitting tars, pngcodecing etc, we need more people there. Very often the work that is needed is small for individual tars, but it does not get done. Maybe the process is too complicated (then we should explain better), maybe there is another reason, but not much progress was made lately.

Another thing is the licences. In my opinion, licence issues are extremely boring, and basically I don't want handle them, but on the other hand, it is extremely important. Not having the correct license will get the assembled graphics pack (or the site offering it) into (possibly legal) trouble, sooner or later. So only include tars with a clear license, even when you want to progress fast.

For the tars themselves, bear in mind that they have to work for the opengfx base set, and also for the original graphics

[GeekToo]

Though I'd wait the few weeks with coding (but not with gathering and adding sprites there) till we can use EZ sprites in trunk as the way they need coding might differ.

WHAT??? You've got to be kidding. Why would you change that when there is already an impressive amount of tars available for extra zooms?

[ChillCore]

WHAT??? You've got to be kidding. Why would you change that when there is already an impressive amount of tars available for extra zooms?

GeekToo,
I really do not understand your reaction.
Forgive me for asking but you a aware that zoomzoom is availble in trunk now, are you?

You have been asked/suggested several times to support the 8bpp graphics correctly as else there was little chance of the EZ patch ever making trunk, I know because I remember suggesting it myself too. Your answer to that was very clear each and every time: "I do not care for trunk inclusion. Period.".
Now you can not blame someone for writing the code to do exactly that after you explicitely refused to do that on multiple occasions, can you?


The only thing trunk does not yet support is dedicated extra zoom sprites. Neither 8bpp nor 32bpp.
Therefore:

Though I'd wait the few weeks with coding (but not with gathering and adding sprites there) till we can use EZ sprites in trunk as the way they need coding might differ.

Don't take this the wrong way but dedicated extra zoom sprites support is coming to trunk (at some point in time) and if you want to be involved or not in the way they are going to be coded is up to you alone.
It would at least require to chance your point of view in regards of supporting the 8bpp sprites too.


Please do not take this as a personal attack that is not my intention at all.
I do apreciate the efforts you have made and I have enjoyed playing with your patch too ... only too bad that at some point in time you messed up the 8bpp sprites (from my personal point of view) and refused to change it back as that is the point when I stopped using your patch.

Regards,
ChillCore.

[OPS]

I was actually thinking of using some sort of proper management script to start over and organise everything but thought it would be too much work to set up, especially if I'm the main force behind it.

This was just to acknowledge planetmakers idea and to express the fact that when he mentioned using the DevZone I was already thinking along the same lines. I just didn't think of the DevZone. I have no intentions of running/hosting my own script.

You don't need to set it up, it is already there:
http://jupix.info/openttd/gfxdev-nightlies/

I'm already aware of the repo. There are many problems with it:
The nightly builds compiled from it are no longer nightly and haven't been for half a year.
Files have been uploaded with no license.
Files have been uploaded with different licenses, complicating the matter.
Theres no set out naming structure and if there is it hasn't been followed.
As its only a repo there are no built in features like tracking and assignment, thus requiring other systems aswell.

You may want to discuss the way the pack is created with Jupix, but I don't like the idea of having yet another graphics pack.

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. Most existing files will comply with the new guidelines already, others will need arranging and a few won't make it. Not being able to use some files that exist is an unfortunate consequence of things not being set out in the first place (not that its anyones fualt, thats just the nature of small projects). The legal issues will prevent an easily distributable pack ever being made unless these steps are made to oragnise and standardise the files.

Jupix doesn't seem to be very active anymore. This is fine but it means we need the files in a more community driven place like the DevZone. There the project can easily be taken over by other members when people become inactive. DevZone can provide a continously active group of staff so support for the compiling and other settings currently managed by jupix should be much more available to change and fixes.

Jupix has set some very clear conditions for a tar to be included in one of the packs in his nightly builds.

I did not know any conditions exist. I know only files with certain flags like "standard tar" are put into the nightly, perhaps thats what you mean by conditions. Either way the nightly build is no longer nightly and therefore out of date and useless. And files with mixed or no license are confusing the situation.

Another thing is the licences. In my opinion, licence issues are extremely boring, and basically I don't want handle them, but on the other hand, it is extremely important. Not having the correct license will get the assembled graphics pack (or the site offering it) into (possibly legal) trouble, sooner or later. So only include tars with a clear license, even when you want to progress fast.

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. Any compiled pack will be legally sound and anyone wanting to finish WIP files can do so knowing the license allows them to.

For the tars themselves, bear in mind that they have to work for the opengfx base set, and also for the original graphics

This will be taken care of by whoever creates them. I am simply discussing the options for a legally sound pack and an organised place to store them.

I appreciate the work you, jupix and everyone has put into Extra Zoom and the 32bpp project.

[Lord Aro]

I appreciate the work you, jupix and everyone has put into Extra Zoom and the 32bpp project.

... but you seem to want to sweep it all aside and start again?
IMO, this seems very counter-productive

You don't need to set it up, it is already there:
http://jupix.info/openttd/gfxdev-nightlies/

I'm already aware of the repo. There are many problems with it:
The nightly builds compiled from it are no longer nightly and haven't been for half a year.
Files have been uploaded with no license.
Files have been uploaded with different licenses, complicating the matter.
Theres no set out naming structure and if there is it hasn't been followed.
As its only a repo there are no built in features like tracking and assignment, thus requiring other systems aswell.

Many incorrect things here:

- Yes, the builds haven't been nightly for a while (since the server move). but there really hasn't been any new stuff since then. If the speed of production picks up again, i'm sure jupix will be able to fix it.
- Files with different/non-compatible/no licenses are not included in the nightly builds.
- There is a set naming sturcture. It needs to be followed for stuff to work ("<sprite-number>_z<zoom-number>.png", e.g. 123_z1.png)
- Yes, there is no tracking or assignment, but i find it hard to see how the devzone could accomplish this, without a similar amount of work being done that would provide the repo with these features.

[extrem123]

OK, so why that DEV pack is outdated too. What about some new "released" buildings, trasnportation ... and other stuff?

//Edit: Because I downloaded from the File Repository nearly 300 megabytes of graphics yesterday.

[extrem123]

.... so here we have a problem that we solve on multiple levels:

1) Personnel issues - such as who will do what and licence issues

We should agree who will do what. Creators are enough here on the forum. Someone of the experienced is supposed to start organizing them to make it clear what is required from them (which models are missing, they need to remake), and under what license. If someone don't want to share his/ her work under proper licence, so we are no further "wasting" time with that people.

2) Personnel issues - roles people

To everything worked as it should, you need to know what people will do and what will be in charge. Only then can we move on.

3) The organization of work and licences (of course)

File repository and wiki are trying somehow to capture existing graphics, and also with respect to time - the state. It's not a perfect organization both in terms of points, and in terms of course work. Have a special file would be to use the repository, but the Wiki (preferably in a table) to monitor who is doing what and when it will be done.

If the license is not satisfactory from our point of view (unified graphics package), graphics should be shared separately or not shared at all. Properly unlicensed models are already on the File repository and must be licensed by their creator or could be (re-) moved somewhere else to other cathegory (whole tree probably), because from point of graphics pack is these models only extraGRF. if the graphics from the graphic package is removed (replaced by a new model) can be moved into that extraGRF tree and can be further shared.

[OPS]

I appreciate the work you, jupix and everyone has put into Extra Zoom and the 32bpp project.

... but you seem to want to sweep it all aside and start again?
IMO, this seems very counter-productive

Atleast be sensible. This is a disscussion about organisation and licensing issues. Neither of these issues are solved by the current system. And neither of these issues destroy everything done before, to say so is rediculous. Even if we moved to a different site the work jupix done on the repo wouldn't have been wasted, it did the job up until now and therefore has been of benifit.

Theres no proper tracking or assignment and so no organisation. Theres no set license and so there are license issues. I have no problem with using the repo if that is what is decided upon, however we will still need those two issues resolved.

Many incorrect things here:

- Yes, the builds haven't been nightly for a while (since the server move). but there really hasn't been any new stuff since then. If the speed of production picks up again, i'm sure jupix will be able to fix it.

So not actually incorrect. Theres been plenty of new stuff, new trains, new tiles etc. Even if there was only 1 new house since the last nightly it would be noticable difference. Seeing a horribly pixelated 8bpp sprite instead of a new house which could be seen several times within the same screen.

- Files with different/non-compatible/no licenses are not included in the nightly builds.

I never said they were, however they exist there. So also not incorrect. The files that aren't of any use in the pack shouldn't be there. If the license on these files are ever resolved by the author then they can be added again.

- There is a set naming sturcture. It needs to be followed for stuff to work ("<sprite-number>_z<zoom-number>.png", e.g. 123_z1.png)

I did notice some had some sort of structure thats why I wasn't sure if it was something that had been set out. However it looks A LOT less than half are using it.

- Yes, there is no tracking or assignment, but i find it hard to see how the devzone could accomplish this, without a similar amount of work being done that would provide the repo with these features.

Its funny you make a list of incorrect things and two of the things in the list admit my points were correct. I'm not biast towards the devzone, as I said above its just a disscussion and that was an idea planetmaker put forward. I have simply expanded upon that. If you want to propose a well thought out solution that uses the repo as its base then feel free to do so. Infact it would be of more benifit if people gave more ideas to solve the problems and expanded the options.

I said I appreciated everyones work and that includes yours Aro. It would be understandable that you feel defensive towards the repo since you're an admin there and have done A LOT of work on it. I think there is also such a thing as being too close to something. You may not be able to see how poorly organised things really are or how difficult it is for new people to find an up to date set of graphics. I have seen you reply to extreme saying he has the latest pack and yet he went looking on his own like I did, and he found many more (thats without even including the unlicensed ones). Not everyone is going to be able to find things for themselves like me and extreme did, nor will they have the enthusiasm to do so. There are already other posts on this forum asking where the latest pack is.

.... so here we have a problem that we solve on multiple levels:

1) Personnel issues - such as who will do what and licence issues

We should agree who will do what. Creators are enough here on the forum. Someone of the experienced is supposed to start organizing them to make it clear what is required from them (which models are missing, they need to remake), and under what license. If someone don't want to share his/ her work under proper licence, so we are no further "wasting" time with that people.

2) Personnel issues - roles people

To everything worked as it should, you need to know what people will do and what will be in charge. Only then can we move on.

3) The organization of work and licences (of course)

File repository and wiki are trying somehow to capture existing graphics, and also with respect to time - the state. It's not a perfect organization both in terms of points, and in terms of course work. Have a special file would be to use the repository, but the Wiki (preferably in a table) to monitor who is doing what and when it will be done.

If the license is not satisfactory from our point of view (unified graphics package), graphics should be shared separately or not shared at all. Properly unlicensed models are already on the File repository and must be licensed by their creator or could be (re-) moved somewhere else to other cathegory (whole tree probably), because from point of graphics pack is these models only extraGRF. if the graphics from the graphic package is removed (replaced by a new model) can be moved into that extraGRF tree and can be further shared.

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.

[extrem123]

I think, that "tracking or assignment" can be provided manually, but only with project part responsible persons / asigned to control f.e. only one group of models.

[Lord Aro]

ok, ok, you win(-ish)

I've pm'd Jupix. Hopefully he'll turn up within a couple of days

However:

- There is a set naming sturcture. It needs to be followed for stuff to work ("<sprite-number>_z<zoom-number>.png", e.g. 123_z1.png)

I did notice some had some sort of structure thats why I wasn't sure if it was something that had been set out. However it looks A LOT less than half are using it.

This comment implies you did not read the above. The sprites must use this style to work. Therefore, any stuff on the repo that is anywhere near the 'working' stage, must be using this file naming structure. And i would estimate around 80% is in that stage

just sayin'

[Jupix]

I've got my eye on this, but will not be able to dive in for the next couple of days. My daily free time and energy goes to my university studies and other hobbies as has been the case for the past months.

As for the nightly pack not updating, what you're witnessing is a technical issue that I haven't been able to remedy, not merely laziness or indifference. I wouldn't be opposed to a new technical implementation as long as the spirit and spec remain the same. Users of any such pack need to realize it was never an official 32bit graphics release mechanism, just a tool that I personally created to assemble suitable releases to a singular download. When I upgraded my server, the cron job for updating the packs broke, and I never figured out how to fix them.

Obviously, when I wrote up the 32bit graphics project spec I imagined a totally different method of delivering the final product.

What we don't need is energy expended on content and tools that we already have. Especially now, when activity is at an all-time low.

[extrem123]

Thx Jupix & Lord Aro. This is certainly a fundamental shift in the case of graphic package. Jupix, if I understand correctly, do you plan for the foreseeable future to repair the publishing script? Or we will build some kind of new tool?

[planetmaker]

It obviously needs also fixing company colours in at least one place, a review might be needed in this respect. The broken engine sprites which look like using a crude brown burch on the engine, are part of a 32bpp pack: http://www.tt-forums.net/viewtopic.php?p=986004#p986004

[Lord Aro]

Just FYI, i had a look at updating the 32bpp-ez patch last night, but... i broke it
I think the main problem stems from the fact that ez is now in trunk (in a slightly different implementation), and i cannot work out which part of the patch is for the ez, or which parts are for the colour changes or loading of 32bpp sprites

[GeekToo]

I really do not understand your reaction.
Forgive me for asking but you a aware that zoomzoom is availble in trunk now, are you?

You have been asked/suggested several times to support the 8bpp graphics correctly as else there was little chance of the EZ patch ever making trunk, I know because I remember suggesting it myself too. Your answer to that was very clear each and every time: "I do not care for trunk inclusion. Period.".
Now you can not blame someone for writing the code to do exactly that after you explicitely refused to do that on multiple occasions, can you?

Well, it seems you really misunderstood me. 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. I did not bother about 8bpp, because in my opinion, when all 32bpp sprites are created, you don't see 8bpp anymore, so who cares it looked ugly (with the 32bpp blitter). Unfortunately, creating a full 32bpp set takes a lot more time than we all hoped for.

Therefore:

Though I'd wait the few weeks with coding (but not with gathering and adding sprites there) till we can use EZ sprites in trunk as the way they need coding might differ.

This was the part why I gave my reaction: Planetmakers reaction suggests that the way extra zoom sprites will have to be coded if they are implemented in trunk could be different than for the EZ-patch. That really would be a shame imho. A lot of effort has already been put into pngcodecing sprites for extra zooms, and changing the coding would mean that that work would need to be redone. And it is already a problem at the moment to get fully coded and good graphics. Changing the coding would even set back what is already available. Depending on the changed way of coding, some of it could be automated, but it still would have to be done, and thus a big step back.

Please do not take this as a personal attack that is not my intention at all.
I do apreciate the efforts you have made and I have enjoyed playing with your patch too ... only too bad that at some point in time you messed up the 8bpp sprites (from my personal point of view) and refused to change it back as that is the point when I stopped using your patch.

Don't worry, I'm not offended at all, in fact I like a good discussion, as long as it is based on arguments.

[GeekToo]

It obviously needs also fixing company colours in at least one place, a review might be needed in this respect. The broken engine sprites which look like using a crude brown burch on the engine, are part of a 32bpp pack: http://www.tt-forums.net/viewtopic.php?p=986004#p986004

I think that is not caused by the graphics set but by the trunk implementation of the company colours, not using any kind of colour blending, but completely replacing the pixels with the mask pixels. Since for company colours only 8 colours are available in the palette (a typical 8bpp phenomenon), of which usually only 1 is used for the mask it effectively reduces the colour space from 32bpp to 3 bits (or 11 if we would use alpha for antialiasing). Since many vehicle are for a large part using CC, that will obviously not look good on 32bpp, you will lose all gradients. A colour blend for CC, maybe combined with creation of better masks for 8bpp, would improve the graphics quality an incredible lot.

[extrem123]

Please follow the discussion thread. What steps will follow to publishing the next version of the package successfully? What we can do? Respect your free time and other hobbies, but these are the main questions...