Project Organization Thread

[neob]

I think Neob's take on it was 'open to all'

adding a group of user to the permissions of some files instead of only the owner permissions, that what i suggested. (or whatever is the fs permissions equivalent there)
i also added that unless there is revision control this will be a problem.

[32Bpp-Pack]

i see there was some updates on the repository, its nice to see that the work is going forward.

few questions:
1. Can i understand that the 4 files below, suppose to contain the latest in sprites in the ground category?
Ground - Fields - No Lines - v2.tar
Ground - Fields - With Lines - v2.tar
Ground - No Lines v3.tar
Ground - With Lines v5.tar

2. is 'Ground - Fields - With Lines - v2.tar' mislabelled as sources?
3. what with the V2 V3 V5 is there a problem with 'Version' function ?

[neob]

i am a big stickler to conventions, since i believe that they make big projects much simpler.
so i have to suggest to create a simple written down naming convention to help arrange and distinguish the content, so everyone know what is what on the repo.

second in regard to what was discussed before, i made a new files table: http://wiki.openttd.org/32bpp_Extra_Zoom_Levels_Files
if you notice i included tracker links, to show how at the moment the repo/tracker/our final TARs not exactly in sync.

so again i suggest to to make a working convention that will apply everywhere and work according to it)
if you have something added/changed in that temporary layout, please elaborate.

EDIT: i have no problem to change it to Varivar very nice layout but i think that its was designed for pre repo and at the moment the current layout provide much better functionality and ease of use.


also in regard to the symlink to add support for base set this how you do it in windows(run the cmd with admin permission):

Code: Select all

mklink /D trg1 ogfx1_base
mklink /D trg1r ogfx1_base
mklink /D trgir ogfxi_logos
mklink /D trgi ogfxi_logos
mklink /D trgc ogfxc_artic
mklink /D trgcr ogfxc_artic
mklink /D trghr ogfxh_tropical
mklink /D trgh ogfxh_tropical
mklink /D trgt ogfxt_toyland
mklink /D trgtr ogfxt_toyland

[Ben_Robbins_]

32Bpp-Pack: All 4 files are 'all zoom'. It was an uncorrectable mistake, but can now be corrected thanks to Jupix's changes.

The versions are...well different versions. If things change, then it's a different version. It makes this difference clear!

neob: That does look a very clear page. Important we get the far right 'opengfx compatible' column up to date as soon as possible. I don't think it's a matter of that page 'or' the other page (with pictures). I think both. One for the 'big tars' as you have set out, where there aren't different files with the same sprites. The other page can then have individual buildings/trains, or groups...how ever people see fit. I would say everything linked to on that page should be in an account on the repository where a handful of people can change it though. We should consider that the 'trunk' set of graphics. This ensures we can update files, rather than upload additional ones, and avoids the links being changed on the wiki.

[neob]

neob: That does look a very clear page. Important we get the far right 'opengfx compatible' column up to date as soon as possible.

that not a problem, i dont even care to re upload some of the existing files with symlinks but we do need some naming convention to distinguish between the individual works and the "final/trunk"(whatever you want to call it).

take the ground tiles for example, i understand 32bpp pack, i have no idea whats is what in the ground folder and i am not sure that those 4 files are the latest in all the ground section.

also its we should inlcude grf for the non "final/trunk" versions, to allow it to be loaded as additional content and not conflict with the current "finnal/trunk" versions
i figured how to make the symlink but i am not sure as to how to make the grf yet, any ideas/links?

I don't think it's a matter of that page 'or' the other page (with pictures). I think both. One for the 'big tars' as you have set out, where there aren't different files with the same sprites. The other page can then have individual buildings/trains, or groups...how ever people see fit.

the whole point is that now that i added the new column the other page is gone, so instead of us having separate resource pages we will have central resource for it.

i dont like the pictures layout because i think its will create a double work but as i said before i dont really care its not about what i like, i'll put what you ppl need, i already moved the pictury layout to the new files page.
again its suggestions time for everyone, if you want to add more details,category's,fields,whatever change colors, stay the way it was before etc say it now...

I would say everything linked to on that page should be in an account on the repository where a handful of people can change it though. We should consider that the 'trunk' set of graphics. This ensures we can update files, rather than upload additional ones, and avoids the links being changed on the wiki.

its a good idea, but not my department, i have no idea whats going on this repo, i make the layouts you ppl shift through your mess.

The versions are...well different versions. If things change, then it's a different version. It makes this difference clear!

i think that the point was that for non source files there is no need for v1-5 its enough to have one file and use the repo version feature. (its also easier to maintain no need to change link on the wiki)

[Ben_Robbins_]

If a V1 file was under my name, and I changed it I could just reupload it over that, and therefore it wouldn't require v1-v2, except as a neat method of monitoring progress. But..as discussed if someone else has uploaded ground, and I change something then there are 2 grounds. To differentiate, I label the new one as v2. This means that the highest version number of any file on that page is going to be the one you need regardless as to who uploads it. The 'V' also makes it clear to people if they need to update. They can compare it to the 'V' they have.

Those 4 files are the latest in ground tiles, I am completely sure of that. That is why they have the highest V number of those files. I can list the changes between each version if necessary! The list of files I recently uploaded all have symlinks.

The advantage of the picture layout page is for when there are multiple versions of something people can pick before downloading. This is only needed for when people start picking and choosing rather than downloading the 'trunk-set'. (gotta love the use of made up terminology here!). I think (and I'm typing as I think), maybe it would be best to have the picture page have files never too large to be easily editable. So if you look on the repo, I've uploaded roads -with lines. That could be linked to from the picture-link page. Where as the page your creating would link to a pack with 'All roads from all scenarios and more'. Some information needs to be attached to the files on both pages to keep a track of progress. On the page your making we will need the last update date, and a .txt attachment of all the .tars and/or files that make up that 1 tar. Then on the 'picture' page files should state the date they were put into 'trunk', or updated. Then also showing the last day they were updated. If dates clearly contradict then people can see that the 'trunk' tar needs updating.

Any file on the page your creating I think needs to be more accessible on the repository to multiple users. Where as on the other page they do not. Inclusion into the main pack can be transferred in ownership on the repository as a prerequisite to inclusion in the 'big tars'.

Finally for the 'picture' page, I think the pre-requisite for sizes of packs is that there shouldn't be contradictions if you download 2 or more packs. i.e. if one pack has 'ALL ROADS' and another has 'CITY ROADS' then all roads contains city roads, and contradicts it. We would then break it down into sections. This ensures there aren't multiple versions of things floating around, and also files aren't needlessly large in that section.

[GeekToo]

also in regard to the symlink to add support for base set this how you do it in windows(run the cmd with admin permission):

Code: Select all

mklink /D trg1 ogfx1_base
mklink /D trg1r ogfx1_base
mklink /D trgir ogfxi_logos
mklink /D trgi ogfxi_logos
mklink /D trgc ogfxc_artic
mklink /D trgcr ogfxc_artic
mklink /D trghr ogfxh_tropical
mklink /D trgh ogfxh_tropical
mklink /D trgt ogfxt_toyland
mklink /D trgtr ogfxt_toyland

This is indeed how to do it for a minority of Windows users: i.e. only those with Vista or Windows 7.

also its we should inlcude grf for the non "final/trunk" versions, to allow it to be loaded as additional content and not conflict with the current "finnal/trunk" versions

This is not the reason. I guess you come up with this idea because you read my discussion on the Graphics release section, but missed the point a bit.

The original game came with a couple of grf files, the trg*.grf files ( in a dos and windows variant).
Opengfx did replace these files with ogfx grf files (except extra), where the sprite numbering was exactly the same.
When OpenTTD was developed further, extra sprites were necessary. They can be added to the game by means of so-called Action 5 in (new)grf. These sprites were put in openttdd/w.grf. Opengfx replaced these sprites with the ogfxe_extra.grf. The problem for 32 bpp is that the spritenumbering of the ogfx file and the openttdd/w is not the same, so a simple symlink is not working (at least, it won't have the effect you want, see the problem with coastal files)
This can be prevented by creating a newgrf file (at least for the extra sprites), with action 5 and a in it (replacing the extra sprites or the originals). That grf would also have to provide 8bpp graphics that will be replaced by 32bpp, so that could be a dummy black (but if you don't replace it with 32bpp it will indeed be black). This new newgrf-file would then be the basis for the spritenumbering in 32bpp, independent of what openttdw.grf or opengfx does.

It also means that all tars would have to comply to this newgrf file (but, and that's a good thing, only to this newgrf file). All tars coded for ogfxe_extra or openttdw would have to be renumbered and repacked. So I think it is wise to split the ofgxe/openttd directories in the tars, until this is really sorted out.
For starters we could propose a schema for spritenumbering in this newgrf (i.e. assign a number to all spriters present in openttdw / ofgxe)

If we take it one step further, and include all sprites (also from the 5 trg*grf) into this newgrf, we wouldn't even have to do symlinking at all, because all sprites could be in the 32bppgrf (or whatever the newgrf is going to be called) directory. Mind you, the newgrf itself would still be 8bpp despite it's name, it would only provide a stable numbering scheme for the 32bpp pngs.

[Wasila]

The Windows 7 minority is a fast growing one, and so should not be ignored .

[Zephyris]

Yeah, Win7/Vista make up about 1/3 of Windows users nowadays, definately don't ignore them!

[GeekToo]

I didn't ignore them because they can do it this way, Neob did ignore the Windows XP users .
Please reread my post above, I've added a long story to it.

[neob]

yep i tend to forget xp/2000 now days and to think i once manged 2000 pc on NT\2000 servers, time erase everything
anyway i already shared how i managed so solve the symlink problem on win7, if anyone can provide the solution for other system its will be grand
since its really looks like a few seconds job, which can really improve the quality of our work.

and please ppl anyone has any suggestions in regard to the layout even if the think them trivial, please share them.

and 'GeekToo', the grf idea is not new, its already working for the file packs, we have the 'base set' and the 'aditional set'
basically because we have few works for some sprites so to avoid any conflicts we put the "final" sprites in what i'll call '32Bpp base set'
and the rest supplied with grf files to allow to load the other works to be loaded instead of the base set from alternative locations.

[GeekToo]

Neob, I know there are already newgrfs to have alternate 32bpp graphics. For your information: I am the guy that wrote the extra zoom graphics patch, also one of the first to ever to pngcodec a png-file, to create one of the first tar-packs, the first to provide tars with symlinks in them, the one that created the extra zoom level page on the wiki, also the 32bpp download list on the wiki (and besides, I also wrote the Convoy AI). So trust me, you really don't have to explain the difference between base graphics and additional graphics to me.

But I was talking about a diffferent matter: how to create a newgrf that will take care of the current difference between the ogfxe_extra and the openttdw/d grf.
This will also have an impact on how tars will have to be created, so it is important to settle that before creating and distributing large number of tar files.


Btw, I've attached a template.tar file with symlinks in it, so XP-users can make tars by adding ogfx directories to it (do not add trg* directories, else the symlinks will be overwritten, the ogfxe_extra directory/ openttdd/w link may have to be deleted, when a newgrf is made) with e.g. 7zip

[neob]

i know, i learned most of this stuff here after all the problem that i hate not understanding what i read (and most of the stuff on the graphics generation is techno buble to me)
and since its a forum i always try to provide some detail the first time on each topic to allow other participate.(and make sure i am not wrong)

anyway on both accounts do you have any further reading, since i really dont know what the 'difference between ogfxe_extra and the openttdw/d' nor how to make those grf's

[GeekToo]

Sorry, crossposting again ( template.tar for symlinks for XP-users in previous post).
A nice start for coding newgrf is: http://wiki.ttdpatch.net/tiki-index.php ... phicsSpecs

The best way to illustrate the ogfxe_extra / openttd difference is to use grfcodec to extract both the grf files, and take a look at the two pcx files that it generates. You will see different sprite numbers for the same sprites (in a different style).
That is also what is causing the coast tiles to be so strange. When the're coded for ogfxe_extra, they show funny in openttd and vv because the numbers are not the same.
That can be prevented by providing a newgrf that replaces both of them, so the tars all can use the name of this newly to be created newgrf, without bothering renumbering of openttdw.grf or ogfxe_extra and that also works for opengfx users and default graphics users.

And sorry for sounding too arrogant, usually I'm quite harmless

[neob]

i was hopping for some thing more specific to our needs, since we dont really need to use any of the newgrf functionality but provide alternative path, no?
so if possible i want to make a simple script to do it, so ppl can focus on what they now best without all this compatibility "BS" to get in the way.

EDIT:btw grfcodec is not a new tool, any chance that some of the grf makers already have what need?

[GeekToo]

We do need need it, to be independent of future changes in one of these two basegraph sets, due to e.g. new gui elements. If that happens, we would need to recode and repack all tars, and when the numbers of tars grows, that won't be a pleasant task.

And you don't need to become a newgrf expert( I am certainly not), as far as I understand, knowledge of Action 5 and A, and possibly 1 would be sufficient.

And you're right about that people should do what they're best at, but the compatibility stuff, boring as it may be, is important, because it influences the way tars will have to be created. And thus is an important part of the 'organizing' part of creating sprites. And we better set a clear direction now, than having to redo lots of work afterwards.

So here's a couple of questions:
1. We want to create a complete newgrf, so no symlinking is needed anymore. Easier for future tar creators, lot more work in creating the newgrf
2. Or we only want to create a newgrf for the extra sprites, like the ones in openttdw, to solve the problems with different spritenumbers between ogfxe_extra and openttdw.grf, and keep symlinking the rest
3. Or: we have no idea what GeekToo is talking about

[maquinista]

We do need need it, to be independent of future changes in one of these two basegraph sets, due to e.g. new gui elements. If that happens, we would need to recode and repack all tars, and when the numbers of tars grows, that won't be a pleasant task.

And you don't need to become a newgrf expert( I am certainly not), as far as I understand, knowledge of Action 5 and A, and possibly 1 would be sufficient.

And you're right about that people should do what they're best at, but the compatibility stuff, boring as it may be, is important, because it influences the way tars will have to be created. And thus is an important part of the 'organizing' part of creating sprites. And we better set a clear direction now, than having to redo lots of work afterwards.

So here's a couple of questions:
1. We want to create a complete newgrf, so no symlinking is needed anymore. Easier for future tar creators, lot more work in creating the newgrf
2. Or we only want to create a newgrf for the extra sprites, like the ones in openttdw, to solve the problems with different spritenumbers between ogfxe_extra and openttdw.grf, and keep symlinking the rest
3. Or: we have no idea what GeekToo is talking about

I rename the files with a batch file made with a C source code. It is useful when you need increase one unit the number of a lot of sprites.

[GeekToo]

Maquinista,
renumbering with c can do a lot of the boring work, but won't solve the essential issue, that sprite numbers can change when openttdw or ogfxe changes. Then you will have to run your c-program on all published tars again, and duplicate/link all pngs again.

[Ben_Robbins_]

Geektoo: Ideally 1, but I think 2 with a light sprinkling of 3 will suffice. Since you've worked out how we can quite efficiently make tars that work without changes to anything other than the new sprites which currently have issues. Don't fix it if it's not broken and all that.

[neob]

So here's a couple of questions:
1. We want to create a complete newgrf, so no symlinking is needed anymore. Easier for future tar creators, lot more work in creating the newgrf
2. Or we only want to create a newgrf for the extra sprites, like the ones in openttdw, to solve the problems with different spritenumbers between ogfxe_extra and openttdw.grf, and keep symlinking the rest
3. Or: we have no idea what GeekToo is talking about

1. is this the way how OpenGFX constructed and thus when finished will potentially allow the 32bpp be load in the game options as the base graphic set?