Transport Tycoon Forums

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.

Which is why I always use the same name . Good things the repo requires you to use your forum name.

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.

Coding and repo, of course, but the current graphics would not be valid in a base set? And I'm slightly confused about the purpose of the wiki - if Jupix did an automated tracker then surely it would be redundant?

It's not the graphics (sprites), it's just the way they are layed out/organised/the files there in etc. This doesn't put things at square 1, just as the various ways of getting graphics in game didn't set us back to square one each time they were changed. It's minor. It's barely that, it can be organised and sorted separately, while other graphics are worked on. So I say the same, hundreds of hours have already been put into making graphics, so yes..of course it 'has started'.

I was wondering; are the rules laid down by Jupix as to shading etc being used by sprites? Are new graphics using them (not that there have been many)?

Nothing has been released since. But things I have worked on since are following this.

Hmm... So have all the specifications been set out? If so, we need the tracker so we can put the new graphics in it (Jupix, if you're there, are you still working on it?)

Wasila

The tracker is just fluff. What you should be concerned about is me getting the spec finished and that will happen eventually when Ben has time to do the reference images for lighting etc.

Then we'll vote on it, and then we'll have standards. Or not, depending on whether people approve of it.

Only then we can start enforcing any standards. I'm not an artist, but I think it's comparatively easy to change lighting etc. on an item, after it's been decided what to change them to.

You have a point. Then again, the code seems to be presenting far greater a hurdle as of right now <_<.

As far as I see it we have an agreed-ish look which is the image I posted a few pages back? call it? Meeting that is the spec. An altered light setup is just a tool for getting to that spec. I will tweak some time soon. But..there will need to be the same changes made in blender and other programs. The noticeable difference is shadows. There now at 30% opacity for a truly black area.

Images of white-black and coloured cubes will be of value for matching light setups but in the end the final look is what matters. If it is fitting into an agreed 'set' appearance, then that's fine.

I'd imagine having some cubes as additional reference would make it easier to configure a lighting setup from scratch (if you want to do that, or if you're using software for which we don't have a template available).

Also, if possible, it'd be nice if there was an illustration of the camera position. Meaning a 0 degree angle shot with the camera visible in the correct position.

Here is a diagram of the Light setup, with the relevant measurements. The x values may be varied depending on other factors, but this is as I have them.

Thanks!

I have added an intro section to the wiki 32bpp extra zoom levels page.
http://wiki.openttd.org/32bpp_Extra_Zoo ... iles#Intro

Please review and improve, especially if you're new in using 32bpp graphics, then you know best what needs more clarification.

Great overview!

Other question:
When using those beautiful coastlines here http://jupix.info/openttd/gfxdev-repo/i ... ile&id=248 the OpenTTD Cinema disappears always.
This is reproducible "life" when ingame loading/unloading this "32 bpp Extra thing ..." entry that comes with those coastlines.

I already examined the coastline tar and even the 32bpp_extra.grf with decoding via grfcodec but this makes no sense as the OpenTTD Cinema (which exists as sprite 4405 in the other packs) it not present there...

Maybe I have put too much different 32 bpp files into my data dir? I already tried to randomly moving some of them away, but this did not helped either.

GeekToo wrote:I have added an intro section to the wiki 32bpp extra zoom levels page.
http://wiki.openttd.org/32bpp_Extra_Zoo ... iles#Intro

Please review and improve, especially if you're new in using 32bpp graphics, then you know best what needs more clarification.

everything else thank good to the Graphics packs / bundles because the Individual tars is a mess.

GeekToo wrote:I have added an intro section to the wiki 32bpp extra zoom levels page.
http://wiki.openttd.org/32bpp_Extra_Zoo ... iles#Intro

Please review and improve, especially if you're new in using 32bpp graphics, then you know best what needs more clarification.

Great job!

Just my 2 cents for issues that need clarification:
- add a installation section with links to the latest downloadable packs or other files that are needed to run it after the intro, because most questions from newbies on this forum are about installing it, getting it up and running and where to find the latest packs.
- don't link to the "32bit automated nightly bundle" page because there is little to none information on there (not only for newbies). it can better be incorporated as a section before or after the "individual tars"
- try to avoid linking to "32Bpp Graphics Pack (13/03/2010)" tread because there is now a lot of obsolete information on there which only adds to the confusion.

boen wrote:....

everything else thank good to the Graphics packs / bundles because the Individual tars is a mess.

You got a point. Is it possible to mark the usable tar's or sprites which are for some reason not in any of the megapacks. This way people easily find and add the other tar's or zoom sprites to their installation without having some copy right issues. It also gives the creators of the set extra encouragement and credit for all the hard work they put in to create it. The Spain set for example is very nice but unfortunately very hard to find in the repository especially for newbies.

Its a wiki, by all means edit yourself.

As for NewGRF 'visibility', i will ask jupix if he can add it, but the server is having connection issues atm, so give him so time

Hello everyone,
I am surfing the forum and wiki for several days. There are many new super graphics on this forum. Please, can anyone update the 32bpp full-zoom-graphics pack (or create new one)?

... It would be nice, if the "normal" fan could download some "complete" pack. For example, in "32bit-gfx-nightly-Megapack-2011-06-15-dev.tar (101 Tarsus, 65 MB)" are not crossings, trams, trees, bridges and other cool (apparently already debugged) items. I understand that the full-debuged-TAR is a long-therm-issue, but - Can anyone provide some newer DEV pack or something like that?

afraid not, you've got the newest-playable-bundle-of-files out there

you could of course help yourself

So, this thread should be called "Using what developers uploaded and make it more complete set 32bpp" .... OK, best route to success in this dilemma what can and can not use it simply change the terms use forum and file repository. Using and combining user software is one thing, then the second is the combining and sharing in an integrated package. This problem must be confronted head on, not just say that users can use the Nightly or hours and hours combine individual uploads. Graphics is a lot, therefore indeed I wrote in this thread. Pictures in the introduction suggested that work continue on the new package. So I asked for its disclosure. And that is it. That is the core of problem. Part of such integration could be necessary to vote, which models will be included in the standard pack (if there are more proposals) and which will be as newGRF. Graphics package should be a priority for "32bpp Full Zoom". I thought that's Nightly DEV, but that is no longer working. Not to mention the standard Nightly release.

Logically, then comes the consideration (as here) the user pack, which in time (with changes) could be a aspirant to the official package.

I'm sorry I stirred this discussion, but it's about what we're actually discussing the difference between guidance and managing the project. On this forum there are several threads that address what to do but it often does not address how to milk. These threads then eventually die. Let's try to avoid it and look for constructive way to use existing resources as quickly as possible to publish a new graphics package. I suppose this is what is the goal of this thread.

Above published package we can discuss what to add, what to remove and what to change. This deal should start six months ago, when the last Nightly came.
As Planetmaker said, it was unnecessarily lost a lot of nice pieces.

Let's find the way out of it all. Let's find access to the legal framework of the whole affair for all available 32bpp graphics.
Let's find a unified approach to data sharing, which would be consistent with the distribution of OpenTTD.

I appreciate you taking the time to explain things. I still think feel I made it clear after the first warning that I understood and nothing of that nature would be released by me. However I'll try to be more careful in future.

But moving on.

planetmaker wrote:It is VERY tedious work as there's not a single license for this project which was chosen initially. Sadly a mistake made back years ago and which cost lots of nice sprites. In this project and elsewhere.

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. I think the following may be a way forward.

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. Over all each tracker is different to the next category, theres no consistancy in the template used.

Maybe it would be a good idea to update the wiki and try and get all objects listed, or atleast the stuff being worked on/completed. Then make sure people know they can use the place to claim work. The persons name and the date they claimed the object would be needed (maybe an ETA too? it could be as rough as "a month" but would provide a better indicator of inactivity when the ETA passes). We can then easily see anything that has been sitting around for months or even years and free it up for someone else. This will become more and more important as time goes on and there is less work available. Any completed or WIP can then be uploaded to the repo and linked to. If its a WIP that is no longer being worked on by the author it should be unclaimed to allow someone else to continue. An object can be labled as "unlicensed work available" if that is the case and left untill it: becomes licensed/someone has another licensed version/no other work is left to do.

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. After all if it can't be used in the finished project theres no point in it being here, I'm sure there are many cases where work has been done for the project and not licensed simply because the author didn't know they needed to and now lost due to their inactivity(unable to get a license from them). Forcing authors who intend to work on the project to commit to a license at the start would resolve all this. Perhaps anyone who wants to claim an object to work on must first make a declaration on the page lord first linked me to here.

TLDR:
Add guidelines about licensing and how to claim work to the wiki and places new volunteers are likely to first visit, so everyone understands the system
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

Anyone have any problems or improvements with this idea? Hopefully something like this can be agreed upon to help organise the project better.