Open TTD GRF File Library

[Ben_K]

Hey, chill out. It is a great idea. Id suggest you look at GRFcrawler. Maybe speka to whoever is in charge and see if you cant modify GRFcrawler to be more useful. I see the others point, but I also think it could be much improved.
Dont lose the enthusiasm!

[Kolijn Wolfaardt]

I think the idea could work. I've seen many grf files that aren't listed on grf crawler (like the INFRA project). I haven't been able to install ANY station sets, so some instructions for them (on the site) would be helpful.

I'll help with site construction, if it is needed

[Purno]

I don't think we need a new website for this. We already got GRFCrawler, which works fine. Alternatively, there's Linkage to link to GRF websites too. The last thing we need is even more scattering of useful resources.

[XeryusTC]

I don't think we need a new website for this. We already got GRFCrawler, which works fine. Alternatively, there's Linkage to link to GRF websites too. The last thing we need is even more scattering of useful resources.

The point is to get all the GRFs that are proofed to work with OpenTTD in one place, not also GRFs that aren't compatible with OpenTTD.

[Sleepie]

The point is to get all the GRFs that are proofed to work with OpenTTD in one place, not also GRFs that aren't compatible with OpenTTD.

But couldn't this achieved using different categories etc. on GRFCrawler? I agree with Purno here and think the best option imo would be some enhancements to GRFCrawler to fulfill the needs.

[Born Acorn]

I don't think we need a new website for this. We already got GRFCrawler, which works fine. Alternatively, there's Linkage to link to GRF websites too. The last thing we need is even more scattering of useful resources.

The point is to get all the GRFs that are proofed to work with OpenTTD in one place, not also GRFs that aren't compatible with OpenTTD.

Scroll down, to the bit below "GRFID" and above the download links.

[XeryusTC]

I don't think we need a new website for this. We already got GRFCrawler, which works fine. Alternatively, there's Linkage to link to GRF websites too. The last thing we need is even more scattering of useful resources.

The point is to get all the GRFs that are proofed to work with OpenTTD in one place, not also GRFs that aren't compatible with OpenTTD.

Scroll down, to the bit below "GRFID" and above the download links.

Never noticed that one before.

[eis_os]

It was introduced in the area51 version of GRF Crawler and is now offical in 0.8, if your browser supports javascript with xml remote gets, clicking more details on a list entry will show it aswell (instead linking to the details view)

[Kolijn Wolfaardt]

It looks like most people are against the idea. After thinking about it again, I came up with this idea: What If a grf file could have some kind of 'certificate' that would state with which versions of ttd, OTTD or MiniIN it is compatible with.

The file would simply be a text file, and would be included with the grf zip file. The file wouldn't be required to use the grf file, but would tell the user if it would work.

Also, I suggest that a certain group of people would 'give out' the certificates, so that no fakes could be made. A simple website could be created with a list of all certificates.

[DaleStan]

After thinking about it again, I came up with this idea: What If a grf file could have some kind of 'certificate' that would state with which versions of ttd, OTTD or MiniIN it is compatible with.

This already exists in TTDPatch. And it's hard-coded into the GRF, which makes faking it far more work than most people are willing to expend.

Open devs do not document any way for GRF authors to test the OpenTTD version information, but once they do, I'll happily update my GRF files to insist on the appropriate version(s) of OpenTTD, as they already do for TTDPatch.

The simplest option is to generate some equivalent to variable 8B, but I can't figure out how exactly to make this work.

A more robust option would be to specify a set of several standard version IDs, eg "TRNK", "MINI", "HOUS", "0.5X", "32BP", and then write that ID into a parameter using action D, and then read "patch" variable 12 into that parameter, where the result would be:
1) 0 if the ID is unrecognized,
2) The last-committed revision, if the ID specified is for the branch from which this executable was compiled,
3) The revision of the last sync with that branch, if, eg "TRNK" is requested from the newhouses ("HOUS") branch. (As a special case, requesting the trunk revision from eg MiniIN or 0.5 would return the last commit to trunk before 0.5 was branched.)
4) If this is trunk, and the requested branch has already been merged, either 2, or the revision at which the branch was merged.

In case it was not clear, the returned value must always be revision number for which there was a commit to the associated branch, unless the branch has been merged into the current branch (usually trunk), in which case the return must be at least the last commit to that branch (excluding the svn rm).

I think that should cover everything.

So, this procedure would read the code's trunk revision into parameter 0.

Code: Select all

0*0   0D 00 \D= FF 00 "TRNK"
0*0   0D 00 \D= 12 FE FF FF 00 00

For 0.5 and MiniIN, this would be 7535, for newhouses, it would be (currently) 8759, for trunk, it would be (currently) 8802, and so on.
Changing the "TRNK" above to "MINI" would return 0 for all branches except MiniIN, which would return 8644.