Project Organization Thread

[Wasila]

I have received a reply from Aracirion:

Hi Wasila,

I would be glad to release the files so they can be of any use! The one problem is that they are lightwave files, not blender files. Is there someone among the 32 bit gfx artists who could use those files? Otherwise I would first have to get my copy of lw back, and I don't even know if it still works in 10.6!

Best,
Christian

--

Is there someone who can use them?

[tsjook]

Lightwave files can be imported in Blender. Just let him send them and then we'll see whether importing them really works.

[Ben_Robbins_]

I've just been looking at the wiki trying to update a few links, to updated versions of files I've put in the repository. There's a few things I think we could do slightly better. There are the 2 pages now with links on. 1 to the repository, linking to 'entire' files. So 'ALL' of the roads for example. Then on the other page there are links (primarily to the forum) with some files being individual buildings. Both of these have there advantages, but also disadvantages.

People don't want the hassle of downloading hundreds of individual files, but then the big files often are not as up to date as some of there elements (individual files get updated). Firstly maybe all downloads should be on one page. There's something a bit 'off to one side' with the page of individual files/images.

The all inclusive 'big' files would ideally be stuck somewhere where a handful of people can update it easily, rather than just the uploader/owner. Or alternatively is there some automated method that could be made where the big files have a reference list of files they contain and every time one of the files on that list is changed, it's updated?

Another issue is listing files as outdated in some way. for the ground tiles on the wiki I have just uploaded the ground and field sprites with and without lines. All the other files on that page I think contain older versions of the same file. It's only use therefore is archiving, for recovery or working off. In terms of people getting the latest files there clutter. I can't do anything with these as there under another name. Therefore can there be a publicly available option to highlight outdated files? (any other ideas to this issue?)

Either way, there's something not working quite right at the second, as I've been trying to update files, but sometimes my files make up only sections of these bigger ones which would require a considerably greater amount of time to re-put together, and also are not under my name, so if I re-uploaded, I would have to then change the wiki accordingly. Long winded.

[Wasila]

So there's a problem with the wiki? Hmm... one for the devs?

[neob]

So there's a problem with the wiki? Hmm... one for the devs?

there is no problem with the wiki and its certainly not a dev's problem, you can log in and fix/add/update ....

------------

I've just been looking at the wiki trying to update a few links, to updated versions of files I've put in the repository. There's a few things I think we could do slightly better. There are the 2 pages now with links on. 1 to the repository, linking to 'entire' files. So 'ALL' of the roads for example. Then on the other page there are links (primarily to the forum) with some files being individual buildings. Both of these have there advantages, but also disadvantages.

can you expand on that, which pages do you refer to? (you can do it on their discussion pages as well)
because as far as i know there is only this page: http://wiki.openttd.org/32bpp_Extra_Zoom_Levels
the rest are just not maintained and marked as outdated (unless i missed another duplicate when i dug them up)

The all inclusive 'big' files would ideally be stuck somewhere where a handful of people can update it easily, rather than just the uploader/owner. Or alternatively is there some automated method that could be made where the big files have a reference list of files they contain and every time one of the files on that list is changed, it's updated?

i am not sure how you can do this but in any case its a repo issue, wiki only links to what is there.

Another issue is listing files as outdated in some way. for the ground tiles on the wiki I have just uploaded the ground and field sprites with and without lines. All the other files on that page I think contain older versions of the same file. It's only use therefore is archiving, for recovery or working off. In terms of people getting the latest files there clutter. I can't do anything with these as there under another name. Therefore can there be a publicly available option to highlight outdated files? (any other ideas to this issue?)

again i am not sure where have you seen outdated files, maybe you refer to the page it self being outdated.
also there is a props listing which we can expand to be linked to other works for reference.

Either way, there's something not working quite right at the second, as I've been trying to update files, but sometimes my files make up only sections of these bigger ones which would require a considerably greater amount of time to re-put together, and also are not under my name, so if I re-uploaded, I would have to then change the wiki accordingly. Long winded.

are you sure you are not speaking about the repo

[Ben_Robbins_]

I am talking about both the repository and the wiki, and even here, if that's where the files are. I'm just talking in general about updating files and managing groups of files under different peoples names. An example of outdated files would be ground sprites. There are files in there made from a handful of different ground versions. Not that an example in anyway validates the point further, since even if there was not an example of different file versions being in the repository, it will happen as things get updated...which they will, do, and have done. All the necessary files exist on that 'ground' page in 5 of the files. 4 uploaded by myself, 1 by Geektoo. The outdated files shouldn't be deleted, but it's important people don't muddle them up, especially in terms of visual-bug reporting.

The 2 wiki pages I'm referring to are:

http://wiki.openttd.org/32bpp_Extra_Zoom_Levels
http://wiki.openttd.org/32bpp_fullzoom_ ... aphics_set

The first link has now started to list download files. I thought it used to be that there was 1 page for installing the game, and 1 for downloading the files. I think having files clumped into the big sets that are linked to from the initial page is good, but the second link then becomes a bit 'shoved of to one side', and less maintained.

I'm wondering on having an account on Jupix Repository and just telling a handful of people the password. That could be used for keeping up a set of files which are just bundles of other files. That way, when I or anybody updates let's say the city roads, I can then make that change to the file which contains ALL roads. This means 1) I don't have to make another file like it which 2) is under a different name, so 3) there are then 2 versions of that file, 1 being outdated.

As I said though, ideally it would be possible to have lists where by if a file is changed that exists on that list, then the tar which consists of all groups of files on that list would be updated; ideally automatically.

[Wasila]

I see what you mean Ben_, I personally prefer the layout of the second page for downloads so perhaps the first one's links are the ones that are redundant (just link to the other page?)

I like your idea - it would certainly make things simpler. Perhaps consolidation of files should be a goal?

[GeekToo]

Another thing that complicates the matter, is that one page refers to tars that are referring to the original grf set (with directories like trg1r), and the other one to tars that refer to the opengfx set. That can be solved by recoding all tars with symlinks, or by dropping one of the two sets.

I started a discussion about that here: http://www.tt-forums.net/viewtopic.php?p=851382#p851382 and later responses,
but to not get further offtopic in that thread, I'd like to continue that discussion here. In the end it won't matter, when all 8bpp is replaced, but until that is the case, we should have a clear view of how to create the tars.

[neob]

I see what you mean Ben_, I personally prefer the layout of the second page for downloads so perhaps the first one's links are the ones that are redundant (just link to the other page?)

I like your idea - it would certainly make things simpler. Perhaps consolidation of files should be a goal?

sure it will, if you are willing to update the wiki page after every entry here, the whole point of this page:
http://wiki.openttd.org/32bpp_Extra_Zoom_Levels

that all work is done on the repo, so if you wish to update an existing file the only thing that changes is its version number in the repo.
also linking to category's on the repo allows us to provide few options until the 32opengfx will finalized (again no need updating)

while the other base set page requires everyone who posts work or an update to fix the link in wiki.
and unlike the repo you dont have a neat trucking table, so unless you go hunting for every posts on the sbject and update its will never be updated.

Another thing that complicates the matter, is that one page refers to tars that are referring to the original grf set (with directories like trg1r), and the other one to tars that refer to the opengfx set. That can be solved by recoding all tars with symlinks, or by dropping one of the two sets.

I started a discussion about that here: http://www.tt-forums.net/viewtopic.php?p=851382#p851382 and later responses,
but to not get further offtopic in that thread, I'd like to continue that discussion here. In the end it won't matter, when all 8bpp is replaced, but until that is the case, we should have a clear view of how to create the tars.

i still dont understand what is required to make symlinks for those tars to work but if its not a huge problem at this stage, we should strive toward including them.

http://wiki.openttd.org/32bpp_fullzoom_ ... aphics_set

The first link has now started to list download files. I thought it used to be that there was 1 page for installing the game, and 1 for downloading the files. I think having files clumped into the big sets that are linked to from the initial page is good, but the second link then becomes a bit 'shoved of to one side', and less maintained.

its not suppose to be links to download files but all to the repo.
but in any case its the added links are only a list of TAR's that come witg new grf's and placing them in the data folder will not work unless you activate the newgrf ingame.

I'm wondering on having an account on Jupix Repository and just telling a handful of people the password. That could be used for keeping up a set of files which are just bundles of other files. That way, when I or anybody updates let's say the city roads, I can then make that change to the file which contains ALL roads. This means 1) I don't have to make another file like it which 2) is under a different name, so 3) there are then 2 versions of that file, 1 being outdated.

i understand the problem, if Jupix can set permission to some files to everyone so we can have a "final" TAR on each field

[Ben_Robbins_]

neob: You seem to be taking the wiki page that links to all the files individually as 'having' to have those files on the forum. The forum is irrelevant here. They just need to be updated to the repository. The difference between the 2 downloading layouts (on either of the 2 wiki pages) is that 1 links to 'bundled' sets, where as the other has links to individual groups. (although varying in size still with 'all ground' being one, and an individual building or train making up another.)

It's not a matter of being bothered to update that wiki page. The bundled tar's aren't anything to do with saving time detailing what stage's of development things are at. Your muddling up graphic users, and artists. That wiki page is needed for the organisation of groups of sprites, but far smaller groups than 'all vehicles'. It too should be linking to repository, but to smaller .tar's, which don't need to be publicly editable, just publicly accessible. The same cannot be said for the files linked to on the other page.

I don't disagree with your listings of the repositories qualities, but that's just irrelevant. It's a file storage location, which is best linked to from other user friendly pages.

GeekToo: The issue you stated is really what's made me come to this. I can't replace most of the existing files with ones that use symlinks and work for all, becuase the files are under other peoples names. I would instead have to upload it again, change all links to it, and hope people don't accidentally download the file still there under someone else's name and complain that it doesn't work. and..If sprites are also changed, hope they don't report visual bugs or even just be disappointed by issues on things that have been upgraded or fixed.

Anyway, I think an option I would quite like is to have 2 areas in the repository. 1 where we put any files, source files, finals, any stage, don't delete them, just leave them there so as much as possible is accessible. We then have a second section which has bundled graphics. Maybe only 5-10 tar's as I said. We upload these under a user name which a handful of people can use. To ensure these stay up to we could try the following:

The files have a list to go with them of the files they contain. So All vehicles may comprise of the files from 5-6 other tars. The tar's in the other (already existing section of the forum should have some form of tick box if people think there outdated). We then tick them when we upload a new version of something. The list would be used to check all the files that make up the tars are un-ticked. Upon ticking, it would be highlighted as needing updated.

Ideally the update could be automated, but Manual would also work.

The other slight variation of this is just splitting the repository into 2 again, 1 for anything that isn't final, and one for anything that is. The 'big tar's' then just track any changes in sub-folders within the same folder there in.

Of course all this is would require Jupix to make it possible, and I don't want to make it look like what we want just happens, and what he has made so far has many advantages. This is just my suggestion for an answer to the problems I stated.

[maquinista]

Other problem is that some graphics has various propossals.

I suggest a page like this example:

• 1×x1 row of flats:
  • northstar2 - finished & coded
  • dmh_mac - needs some color tweaks, coded as new GRF.
  
• 1×1 house and pool:
  • Ben_Robbins_ - WIP
  
• 1×1 Flats:
  • Varivar - finished and coded
  • Ben_Robbins_ - WIP
  
• 1×1 town houses with garden:
  • Varivar - Coded and finished
  • dmh_mac - needs some color tweaks, coded as new GRF.
  
• 1×1 group of town houses:
  • Dmh_mac / GeekToo - Finished and coded, but the first construction stage modeled by Maquinista is ugly.
  
• 1×1 country house 2:
  • Brupje - It doesn't have construction stages, but their Blend file is available here.
  

[neob]

neob: You seem to be taking the wiki page that links to all the files individually as 'having' to have those files on the forum. The forum is irrelevant here. They just need to be updated to the repository. The difference between the 2 downloading layouts (on either of the 2 wiki pages) is that 1 links to 'bundled' sets, where as the other has links to individual groups. (although varying in size still with 'all ground' being one, and an individual building or train making up another.)

It's not a matter of being bothered to update that wiki page. The bundled tar's aren't anything to do with saving time detailing what stage's of development things are at. Your muddling up graphic users, and artists. That wiki page is needed for the organisation of groups of sprites, but far smaller groups than 'all vehicles'. It too should be linking to repository, but to smaller .tar's, which don't need to be publicly editable, just publicly accessible. The same cannot be said for the files linked to on the other page.

I don't disagree with your listings of the repositories qualities, but that's just irrelevant. It's a file storage location, which is best linked to from other user friendly pages.

ok, i understand that you want a place to link to individual works, the problem is that its not what we have now
currently this page base graphics list suppose to host a list of TARS that support the base graphics set.

while this page hosts those TARS that are works with OpenGFX, and bothhas nothing to do with download layouts (the later one was was probably chosen as a more efficient way)


so if you wish another download layout its can be arranged but in the correct place, personally i think its stupid to have two list one for base and for opengfx and since the main 32bpp_Extra_Zoom_Levels is growing big, i was hoping to separate the Tar list from the main topic, thus we can merge it with the base set list layout under a different name.


p.s. we also have the tracker: http://wiki.openttd.org/32bpp_graphics_ ... ra_zoom%29




as for the rest what you basically saying is that we need to start to assemble the "final" 32Opengfx TAR's out of what we have.
and to make it more productive we need remove the limitation that allows only the uploader to handle it.

again we need to wait for 'Jupix' word on the matter to see what is possible.
also you should note that fewer TAR's means bigger TAR's and each reassembly probably means reupload
and if few ppl have access than you should hope there is some kind of revision system otherwise 1 bad upload and you screwed.

[neob]

Other problem is that some graphics has various propossals.

i think the current Tracker pages are enough.

[maquinista]

Other problem is that some graphics has various propossals.

i think the current Tracker pages are enough.

The problem is that there are graphics that have two or more proposals, one of them will be coded as default graphic, but the other two should be coded as new GRFs.

With the current tracker is very difficult to handle these multiple proposals. Also, there are graphics that are done but needs little changes, like the 1×1 group of town houses. This building has a ugly first construction stage and It will need some retouching. The current tracker is not enough to handle these details.

[neob]

i am pretty sure i can fit some more option in there. Also i fear that by creating another tracker with multiple options we will only cause one of them go unmaintained and outdated soon. (like it happened with to many other pages, i had to weed many duplicates like this)

but hey i am opened to suggestions (p.s. on WIKI my user name is MOR)

[Ben_Robbins_]

maquinista: I agree with your point although that really just comes down to some wiki editing. We should list all various of remakes, as well as listing which one is in the 'trunk'. i.e. the 'big tars'. There is plenty of things like that that I think, if people wish to organise and really move the project on without coding or graphic making there is plenty that can be done.

neob: I know that's not we have now!...otherwise it wouldn't be a proposal, and idea, a suggestion etc...In fact, why would I bother to be talking about what we have, and requesting we have it?!. There is no 'supposed' in it. It's how we see fit. Helpful though all those links are, I have seen them all before. Without putting to finer point on it, I didn't sign up to this project yesterday, and I have made, coded, uploaded, moved, reassembled and re-tar'd literally thousands of sprites, so my opinion here isn't out the blue, or made up for the sake of conversation. The tar sizes were covered in what I said before. The bigger the tar, the less easy to change. In this stage of the project it's equally, if not more important to have the tar's easily updated, than saving graphics users a few seconds by a few less clicks.

Of course being GPL v2 or other copyleft licences all these graphics can be assembled and reorganised pretty much how people wish. But in relation to the front page of all this which is the wiki, that needs controlling.

[neob]

good, i am just trying to make sure we are all on the same page as to what we have to avoid wrong "terminology"
and try and make it short and to the point as to what needs to be done, preferably break it down to small steps.

[Wasila]

No time to join in conversation, but new message from Aracirion.

Here are 3 files, as I said I cannot open them at present, so I hope I included all textures... Else just let me know the path of the missing files. Let me know whether the Blender import works -- I had my problems with it, but then I didn't really know Blender

http://dl.dropbox.com/u/659990/EV_lwos.zip
http://dl.dropbox.com/u/659990/EV_maps.zip

Best,
Christian

[Jupix]

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. Let's not forget this.

Linking to files hosted there from player resource listings at the wiki is already bordering on crossing the line, but I've not been opening my mouth on that as some obviously find it useful. Problems with it include, but are not limited to: 1) IIRC you're linking to specific filenames, which are subject to change as the entry at the repo is updated and 2) you're ignoring forks which, in theory, are newer and better than the originals (otherwise there should be no fork) and 3) the files you're linking to should also contain sources and a player doesn't need those.

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.

This could be solved by openttd.org hosting the user-friendly version of the repo, but seeing as no developer is that interested in the project, I don't see that happening. Though, I haven't asked since I think late 2008 or something.

This could also be solved by hosting the actual files somewhere else, like rapidshare, and have the files actually managed in a communal manner at a user-friendly repo, the sort you suggested. But I don't think this would improve anything compared to just using the wiki and forums for management.

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.

In conclusion, I suggest we treat repositories in general and this current repository only as what it is, which is an "insider" resource, and come up with a new, better way of distributing content to players. I haven't run the game in ages so I don't know what the built-in custom content browser currently can/does distribute, but I suggest we look into using that.

Ben, you're thinking of creating a shared account for managing some kind of graphics packages. Even though you explained it I'm still confused as to what kind of packages they are and why a shared account. Shared accounts with RW permissions are inherently bad for security so unless this is an issue concerning player ease of use (disgarded above), I think this is a problem I need to solve. Possible solutions include 1) adding a possibility to share management of your file entry with other accounts, which shouldn't be too difficult or 2) a "moderator" like user group who can freely edit any file, which is actually already a hidden feature within the repo.

Anything else you want me to comment on, let me know.

[Ben_Robbins_]

Jupix: Thanks for your opinion on this. By a shared account, I'm not meaning open to all, but maybe just a handful of people. I think Neob's take on it was 'open to all' but this wasn't what I meant. Even just having the option to associate more than 1 user for a file would be advantageous. I.e. I could make updating of the file open all the contributors of that file. Moderator status may also be helpful.

Just to elaborate slightly on the point of multiple versions of 1 sprite. Making big tars linked to from the wiki not only requires updating when changes are made to individual files which they contain, but also the choice of which of a variety of the same building (For example) should/will be used. This adds issues with simply 'replacing files'. Moderator status would therefore also require some decision making for sprite choice, as well as general managing of files in the repository under other names.