Transport Tycoon Forums

"And currently, no such authority has been named."

Jupix: I name you, assuming your willing to continue to contribute much of your time. It would not be out of place for you to make these calls. Geektoo is the wizard behind the code, and that's is his toy, but in regard to calling shots, and keeping updated, and having a general understanding of what's going on organisation wise and here on the forum, I would have no objection for contributing to a project that you give to by leading. I would not see it as out of place for you to state prerequisits for 'official' packs, or ways of working, as I strongly agree with various things you've said in the past.

So long as the main contributors agree with me here, and yourself, then don't let the 'lack of authority' be a hold up for the project any more.

Ben_Robbins_ wrote:"And currently, no such authority has been named."

Jupix: I name you, assuming your willing to continue to contribute much of your time. It would not be out of place for you to make these calls. Geektoo is the wizard behind the code, and that's is his toy, but in regard to calling shots, and keeping updated, and having a general understanding of what's going on organisation wise and here on the forum, I would have no objection for contributing to a project that you give to by leading. I would not see it as out of place for you to state prerequisits for 'official' packs, or ways of working, as I strongly agree with various things you've said in the past.

So long as the main contributors agree with me here, and yourself, then don't let the 'lack of authority' be a hold up for the project any more.

I totally agree, we definatly need some form of leadership and i agree with ben for choosing jupix, ive been roaming the 32bpp for a while now and he seems like a guy who would be a good leader of this project

Bazil

I would say its between Ben, Jupix and GeekToo
But,
Ben is just artist - just does a lot of really awesome stuff
GeekToo is a coder

That leaves Jupix, who also has a graphics repository (and a place on openttdcoop servers )

I suggest that we set-up a proper system of nomination and then voting.

1) A set number of days where people get to nominate up to three people for the job. Those with more than a set number of nominations (three?) will be entered into the competition.
2) Those nominated have to then accept their nominations.
3) We do a vote. This would NOT be a poll, but done via posting, so that only actual contributors get a say.

If everyone agrees with this format, I could set it up straight away.

Then we could turn towards creating the foundations for a base set, most importantly of all getting the patch to trunk standard and giving it 32bpp base set support.

Surely the contributors should get a say as to who leads them?

But you're right about the willingness thing. Perhaps it would be better to allow people to put themselves up and then just do a simple vote.

Excessive!

The contributors will read this I'm sure, no need for voting, endless discussions or anything, it just needs doing as planetmaker said. There are a few key names I would hope for an opinion from, and then *wam* lets get on with this if there's agreement.

Just to clear something up. I am currently around, but I do disappear and reappear from time to time for long periods. I contribute where I can, but this is why I stopped moderating, and therefore I'm not going to take any central role in anything at the moment.

Lord Aro: Geektoo has produced fine graphics as well as code! an all-rounder let's not forget.

I'm willing, but I can't just "grab power" as it were.

During the past couple of months, behind the scenes, I've been working on a project spec / white paper proposal, if there is to be a vote on anything I'd prefer it to be on implementing this. See attachment.

This is a collaboration between myself and Ben. I'd like your comments and thoughts on whether it's appropriate for me to put this up for vote. I would probably do that in General OpenTTD, outside the graphics forums on purpose, to get as many eyeballs on it as possible.

The attached document is draft 4 revision 2, still under works, as it is missing some sample pictures in section 7.

The authority thing is touched upon in section 3.

I'm willing, but I can't just "grab power" as it were.

Well, Jupix, if all the major contributors support you then it's not grabbing power. We should wait and see what maquinista and GeekToo say about it, but I think that this specs sheet is just more evidence that you are perfect for the role.

I had a few questions about the specs sheet (I apologise if my question is answered in there, I did not read it all in-depth).

1) How would you distuingish between current tars and base set sprites in the repo? Would there be a different category?
2) Also I don't believe it was made clear that each in-game 'item' should have its own tar.
3) What are we going to use as a sprites list? The wiki? What about a progress monitor?
4) Perhaps there should be a 'pool' of sprites that are to be shared among the base set (such as fences, lights, etc.). Perhaps that would be in another category in the repo?
5) Is the template in the proposal the same as the v2 from GeekToo? If not, we have to make one.

Wasila:

4) Do you mean for photoshoping onto sprites? As in...standardised sprite elements, rather than just standardised textures and LS's?

In relation to this we need to sort the standardised materials out. The ones on the wiki were more just textures I was releasing publicly for people to use, there not really 'standardised'.

There are various things that do need to be agreed on...Such as the standard water appearance, fences hedges etc. They are mentioned on the wiki but that group was put together before any work was really done, and what would now work best I would say, has changed as things have evolved. A fine example of something that needs to be called.

Wasila wrote: 1) How would you distuingish between current tars and base set sprites in the repo? Would there be a different category?

Not necessary to make a distinction there, after all it's only a repository.

2) Also I don't believe it was made clear that each in-game 'item' should have its own tar.

Well, it's an inherent property of the standard tar format, but perhaps one that should be mentioned in the spec.

3) What are we going to use as a sprites list? The wiki? What about a progress monitor?

Not really relevant to the spec IMO, just yet another point in the good'ol todo list. It might be about time to write a php parser for reading the base set sprite tables, and make the script crawl the repository for sprite #s. That should make a pretty accurate tracker.

4) Perhaps there should be a 'pool' of sprites that are to be shared among the base set (such as fences, lights, etc.). Perhaps that would be in another category in the repo?

That's chapter 7.4 and it's called standardised materials & props. Physically it's at the wiki.

5) Is the template in the proposal the same as the v2 from GeekToo? If not, we have to make one.

It is.

Ben_Robbins_ wrote:People are just talking rather than ticking.

Sorry guys for jumping into this discussion so late, I did follow it with great interest, but I was ticking rather than talking, having made two updates for the patch tonight.

Anyway, the discussion has become rather big, spanning several issues. I'll try to express my opinion on some of them.

-No need for a formal vote of authority. But, on the other hand, some kind of decision maker could speed up developments a lot. We've seen it over and over again: some nice discussion about scaling, or lighting or whatever starts, several opinions are expressed, but no final decision is made. So creating a design document or graphics standard /spec is a great idea, and in fact the highest prio of the project. Providing clear directions will create followers, too much uncertainty will paralyze potential contributors. Jupix has taken the lead in creating such a document. I'm very willing to accept him being the judge of what is in the document or not. He's not around here since yesterday, and I'm very confident that he will take into serious consideration any sensible arguments that Ben or Maquinista or I or anybody will make. So that would not be a one man show, but a cooperative effort, with Jupix that happens to be the one to manage the document (if he wants to, of course). I suppose Ben would have a lot of influence in graphical issues, Maquinista in pngcodecing matters, I imagine I would have a vote in coding matters etc

Then there is progress and bug management. What I really would like, is to have some kind of feature/bug tracker. So finalising the spec is one of the things that needs to be done, adding stuff to the 32bpp-extra newgrf is another, bug/features for the 32bpp ez patch is yet another, updating the wiki, adding sprites features list. Individual sprites tracking could be made on a per sprite basis using a php tracker and the wiki, but the overall progress could be summarized in a bug tracker.
So, what do I have in mind? I happen to be the project manager for the 32bpp project on the openttdcoop devzone. I could add e.g. Jupix, Ben, Maquinista and others as project managers, developers, contributors for this project, to have a central to-do list, references to download locations and wikis, feature requests etc for the code. Users could instantly see what still needs to be done, and help out.

Project communications can be done here on the forums, but also on IRC, the openttdcoop project pages or by PMs

Sorry if this has become a long story, and I've not even said everything that is haunting my mind, but it's enough to react upon I think.

Not necessary to make a distinction there, after all it's only a repository.

Surely we'd then get confused as to what is part of the base set (and therefore standardised with correct lighting etc.) and what is old?

Anyway, the discussion has become rather big, spanning several issues

Indeed!

some kind of decision maker could speed up developments a lot

I suggest we wait on maquinista before acting, but it looks like Jupix is the most popular guy for the job.

with Jupix that happens to be the one to manage the document (if he wants to, of course

He would also have to have the final say over any disagreements whatsoever (if, for example, there are two of the same sprites; which one goes in?) if we
want to make progress; of course, he would take in the opinions of those on either side of the argument.

adding stuff to the 32bpp-extra newgrf is another

How do you mean?

I happen to be the project manager for the 32bpp project on the openttdcoop devzone

Could you link us? That could be a perfect home for the project.

So, we better start a proper to-do list so we don't miss anything out!

1. Finalise the white paper.
2. Bring the patch up to trunk standard/make it base set compatible(?)
3. Organise a place on the wiki to create a tracker/progress monitor.
4. Create standardised materials.

Is there anything else?

Don't you just love constructive discussion?

GeekToo wrote: Anyway, the discussion has become rather big, spanning several issues.

Just to comment on this, if I had mod privileges, we would not be having this conversation in this thread. This is org-thread-worthy stuff we're touching. But this is something I need to take up with the mods. (Once again.)

I'm very confident that he will take into serious consideration any sensible arguments that Ben or Maquinista or I or anybody will make. So that would not be a one man show, but a cooperative effort, with Jupix that happens to be the one to manage the document (if he wants to, of course).

Indeed, there would be no change to my policy of consulting people in the know before attempting to manage processes. Unintentional oversights excepted, of course.

I suppose Ben would have a lot of influence in graphical issues, Maquinista in pngcodecing matters, I imagine I would have a vote in coding matters etc

Apart from maquinista's possible involvement, which I wholeheartedly welcome, in case he is willing and able of course, that is precisely the way the team proposal is laid out in the spec.

Then there is progress and bug management. What I really would like, is to have some kind of feature/bug tracker. So finalising the spec is one of the things that needs to be done, adding stuff to the 32bpp-extra newgrf is another, bug/features for the 32bpp ez patch is yet another, updating the wiki, adding sprites features list. Individual sprites tracking could be made on a per sprite basis using a php tracker and the wiki, but the overall progress could be summarized in a bug tracker.

So, what do I have in mind? I happen to be the project manager for the 32bpp project on the openttdcoop devzone. I could add e.g. Jupix, Ben, Maquinista and others as project managers, developers, contributors for this project, to have a central to-do list, references to download locations and wikis, feature requests etc for the code. Users could instantly see what still needs to be done, and help out.

Well, we've been over this before and I'm still not convinced that the devzone CMS does anything better and with less hassle than our current toolset, which is the wiki for documentation, todo lists & roadmapping, the forums for discussion, and the repository & related tools for technical stuff like content storage, distribution in the interim, sprite tracking, etc.

The lone exception to this is bug tracking which I've also touched on before; there exists a very limited number of types of bug graphics can contain, and as a result they are easy fixes and quickly fixed, removing the need for bug tracking. I will conceed that our current tools for bug reporting, basically public and private forum posts, are a matter of debate when it comes to how well they work. But again, throwing a lot of code at a problem doesn't necessarily make the problem go away, particularly when, if I'm correct, users would need to create yet another set of user credentials for reporting bugs.

Project communications can be done here on the forums, but also on IRC, the openttdcoop project pages or by PMs

The thing about taking discussions off site is (site in this case meaning the forum threads), they become immediately less public, which is basically a kick in the nuts for the project at large. This assumes, of course, that the discussion is on matters of public importance, but I think that can be assumed for "project communication". If the consensus of the discussion is not documented immediately in the various knowledge bases that we have, doing research into the topic later on is very difficult if discussions are spread between numerous medias. This, I think, is a weighty argument for centralizing our communications. Not to mention the fact that many of our contributors are unable to participate in discussions on most medias besides the forums.

This is not to say forum PM's aren't a useful media because they are private; the point is, the fruit of those conversations needs to reach the general public. The project spec you have now read is for a significant part a result of private conversations.

Surely we'd then get confused as to what is part of the base set (and therefore standardised with correct lighting etc.) and what is old?

Like I said, the distinction is not supposed to be made at the repository. The way it would work by my spec is you would have a base set development thread (for artwork) here at the forums and whatever is in there would go into the pack if there are no objections. The rest of the artwork, in other parts of the forum or in the repository, would be considered NewGRFs. That leaves no possibility for confusion.

He would also have to have the final say over any disagreements whatsoever (if, for example, there are two of the same sprites; which one goes in?) if we want to make progress; of course, he would take in the opinions of those on either side of the argument.

Well, that is not completely accurate. The authority would lie within GD32, of which I would be but one member. Any one of the people would have the privilege of chiming in, Ben before all, as he is mostly the visual mastermind. Also, the team would purposedly take no opinions into consideration, instead only factual arguments based on preimposed guidelines and standards, and ones that demonstrate an accurate "philosophical" interpretation of the base set conversion spec.

So, we better start a proper to-do list so we don't miss anything out!

Actually, we might as well just eat what's on our plate already. A todo/roadmap style "small project" is already in the works, by myself. It doesn't really help the thread to have numerous "parallel" discussions going on, as you've hopefully noticed by now. This thread hasn't been about the base set for ages.

Just to comment on this, if I had mod privileges, we would not be having this conversation in this thread. This is org-thread-worthy stuff we're touching. But this is something I need to take up with the mods. (Once again.)

Perhaps you/we should lobby orudge to give you mod privileges in this forum?

The lone exception to this is bug tracking which I've also touched on before; there exists a very limited number of types of bug graphics can contain, and as a result they are easy fixes and quickly fixed, removing the need for bug tracking. I will conceed that our current tools for bug reporting, basically public and private forum posts, are a matter of debate when it comes to how well they work. But again, throwing a lot of code at a problem doesn't necessarily make the problem go away, particularly when, if I'm correct, users would need to create yet another set of user credentials for reporting bugs.

Perhaps a thread dedicated to bug reports?

Like I said, the distinction is not supposed to be made at the repository. The way it would work by my spec is you would have a base set development thread (for artwork) here at the forums and whatever is in there would go into the pack if there are no objections. The rest of the artwork, in other parts of the forum or in the repository, would be considered NewGRFs. That leaves no possibility for confusion.

Are you suggesting using the forum as a file storage zone? The maintenance overheads to make that usable (like having a giant list of what artworks or on what page like was in the .blend thread) are huge and would depened on a single person. Your repo would do everything automatically and would not rely on anybody.

A todo/roadmap style "small project" is already in the works, by myself.

Is that in the wiki or what?

Interest already evaporated?

There is quite a read for people not speaking English as a first language

Anyway, the main issue is now done and sorted; now go back to your constituencies and prepare for government!...or something along those lines. Get back to work!

Is maquinista not English? Sorry, wasn't aware.

And also Ben, while one issue has been solved, there is still lots to do and organise. What's going to happen on the wiki? What's this progress thing Jupix is working on? How will bug tracking work? Are we going to finalise the white paper? And when are we going to start?

Firstly, I haven't got the answers.
Secondly, try giving suggestions...you for one follow the wiki closely, so suggestions would be helpful.
Thirdly, Start what? Everything has started, it's currently 'happening'. Add to it and it will happen faster, and/or get done.
Fourthly: Patience. I commit the time I have, so do others. Things happen when they happen. I hate to say this, but you've forced it out of me...if you really want things 'that' fast, then it would be worth your while learning to code, or learning to model/texture becuase you will get it quicker that way.

Firstly, I haven't got the answers.

I was making the point that there is still much to discuss.

you for one follow the wiki closely, so suggestions would be helpful.

Do I? Wasn't aware of that.

Thirdly, Start what? Everything has started, it's currently 'happening'. Add to it and it will happen faster, and/or get done.

What exactly has started? Could you please be more descriptive? I see as of yet no one making official 32bit base set replacement project graphics.

Fourthly: Patience. I commit the time I have, so do others. Things happen when they happen. I hate to say this, but you've forced it out of me...if you really want things 'that' fast, then it would be worth your while learning to code, or learning to model/texture becuase you will get it quicker that way.

Again, it is just I am failing to see progress and want to know what is going on. As for learning to code, I have started taking lessons (but they're doing Flash). Unfortunately I won't be able to help that much for the next fortnight since I have exams coming up. I should have some free time this coming week, though.

1) I agree, there is much.
2) Apologies, I got you muddled with noeb, the different names between wiki/forum confused me. Even so...I restate the same point. Suggestions are helpful. If you don't know, try to find something to give to the issue, becuase most of what we know is spelt out here on the forum.
3) ...Graphics, Coding, Wiki, Repo, All things that have had hours and hours...hundreds of hours committed so far. the 'base set' is one part of the whole project.
4) If you progress, and contribute that will be great!