Stuff about GrfIDs (Split from Canadian Graphics)

[OzTrans]

I just wanted to let people know what is the real issue.

One day, when you have attained a proven track record as GRF coder in a complex and sophisticated environment of graphic files across many features (let's say 10 to 15), then and only then may you bless us with your wisdom. If you do not know what you are talking about, then you should keep quiet. Having a little bit of knowledge about GRF specifications is a dangerous thing, especially so if you have no experience with GRF coding.

This of course goes for everyone else, who believes his/her ignorance should be aired too.

... me moves the honey-pot out of the way ...

Nobody, but absolutely nobody, needs to tell me how I should do my job as GRF coder; anybody is welcome to make suggestions and/or report issues, but definitely not placing bollards in my way, if they don't like what they see. Also, I am not in any way obliged to tell anyone why I do things in one way or another, but be assured all has always been because of a very good reason.

If OzTrans were to select an alternate range of GrfIDs, how long would it be before another conflict was instigated?

A few seconds after the villains learn about it.

If I claim a range or two of GRFIDs for my own personal and exclusive use, then I do have a very good reason to do so. BTW, two ranges of GRFIDs (e.g. 4341 xxxx and 9787 xxxx ) are 0,003 percent of all GRFIDs available to us coders. There are enough GRFIDs available for 33 odd thousand GRF coders to do the same as I do.

Can anybody help ? I cannot find any usage and I don't have any knowledge, that GRFID 6D620A00 is being used; therefore according to the logic of some, it is available for use by anyone. What do you think would happen, if I even dared to use this GRFID, I would be walking around as a headless chook.

We do not infringe other GRF authors turf by creating graphic files, whose GRFID falls within the range of others. The above GRFID may belong to a GRF that we don't even know about, but is being developed. I have several GRFIDs already allocated to graphic files only I know about; some insiders may guess what GRFs they are, but the general public has no clue. That is why we have ranges that we claim to be ours, this convention has been in use for decades.

Experienced GRF coders have their ranges; e.g. 4444 belongs to Pikkabird, Michael Blunck uses 6D62 and George 4D65 to name some. The rest of you, who do not follow this convention, should get organised and get in line without trampling on others feet.

Having said all that ...

If I cannot have a single complete range or two of GRFIDs for my own personal and exclusive use without interference, then there is no purpose for me to continue GRF development for OpenTTD. It is absolutely essential to have exclusive use of these GRFID ranges, otherwise leaving OpenTTD land and returning to the TTDPatch camp is the only option.

[V453000 :)]

if you have no experience with GRF coding

Your ignorance shines like a beacon, even brighter beacon than the stupidly-large-image beacon in my signature, NUTS Unrealistic Train Set has around 65k lines of code in NML while using many of the train spec features not to mention that I coded multiple other smaller newGRFs as well. And other people in this thread have even more experience than that...
Just fyi in case you feel like putting more arguments similar to "All of you know nothing.".


Nobody, absolutely nobody, needs to tell you what you should do. BUT people DO give you FEEDBACK from USING your NewGRFs. And a part of that FEEDBACK is:
Your newGRFs disabling themselves due to existence of other CA... NewGRFs is plain dumb, and is taken as an agressive move due to BREAKING functionality of your NewGRFs in certain situations - for no reason other than your egoism.
The people just want to play your newGRF and it is broken, they try to understand why it is broken; what reason do you have?
Nobody is telling you what to do; almost everybody is asking you why your newGRF works as it does.

Please, can you name one good reason why it is so majorly essential to have "your own" GRF ID range? One reason? I do not even remotely see how that matters as long as the grf ID is unique.

... Since there even is no way to truly technically reserve your own GRF ID range, then it indeed you probably cannot have your exclusive range just for you.

[Rubidium]

Experienced GRF coders have their ranges; e.g. 4444 belongs to Pikkabird, Michael Blunck uses 6D62 and George 4D65 to name some. The rest of you, who do not follow this convention, should get organised and get in line without trampling on others feet.

Maybe a significant part of people picking other people's ranges is the fact that it is not trivial to check whether someone has, more or less, allocated a range to himself.

The NewGRF specs say it's a convention that the first two bytes are the initials of the creator.
6D62 -> mb -> Michael Blunck, known as mb on the forum
4444 -> DD -> David Dallaston, known as Pikkabird on the forum
4D65 -> Me -> Not clearly the initials of George; looks a lot like just "me", after all with a normal name username it's quite reasonable to assume there should be a G in the first two bytes if it weren't just "me".
4341 -> CA -> Not clearly the initials of OzTrans; are they in real life? In that case it isn't common knowledge

434150 -> CAP -> Not clearly the initials of the group of creator(s), but an abbreviation of the original name: Climate Aware Ports, later renamed to OpenGFX+ Airports. In my opinion it's an honest mistake to not be aware that OzTrans' initials are CA. The whole discussion and GRF ID changing of the Canadian sets that have resulted from this could have easily been resolved by accepting someone made a mistake, not using the CAP sub range of CA range (0.4%), asking nicely to try to avoid your range and trying to think of ways to try to reduce the change of these range collission mistakes to happen. All what the discussion has yielded was a more extreme standpoint at both sides where it has become "funny" to suggest GRF IDs that fall within your range when someone asks for a GRF ID.

If we want to prevent such "namespace" collisions in the future, there should be something that starting NewGRF authors can check to see if they would infringe someone's "namespace". Preferably at the location where the specification is, i.e. in the previously mentioned link and that location should be linked to from the NML specification. Possibly also add a link to GRFcrawler and http://devs.openttd.org/~rubidium/newgrf.html so they can see whether the NewGRF ID they want to use is already in use (it won't prove it is not in use). It is, however, quite hard to search those systems for just the "namespace". As such, it would be useful if the ranges that are in use are clearly noted in some place. I even made a start for adding some "known" ranges to the specs.

[andythenorth]

I am +1 to a simple way to check. The last page or so of this thread is a molehill being super-sized to a mountain, which is daft.

There was no sabotage. If I wanted to troll OzTrans I would have my grfs screw with his, in amusing ways. But that would be acting like a dick. I use some of the Canadian grfs, I have zero interest in this particular handbag fight.

The original 'CA' grfid for Iron Horse was suggested innocently by frosch because DanMacK is Canadian. End of story. The 'joke' is that the grfid is 1830 because it starts in 1830, which turns out not to be a joke, just my poor memory. Frosch doesn't troll afaict.

There is a list of the grfids known by bananas here. I don't know if that's acceptable as not everyone can use bananas. If it's not, let's not repeat that tedious debate, we'll just use Rubidium's list or some other form. I only propose bananas because it's easy to find and the list is maintained by uploading grfs. Manually maintaining lists is busy work.
http://bananas.openttd.org/en/newgrf/

I don't have any respect for the convention of reserving large ranges, it's pointless. On the other hand I can't be arsed to fight about it and will change the CA for Iron Horse and Road Hog if that's really necessary. If anyone wants to insist on the convention, then they need to stay out of the following
- F125 (FIRS)
- 4348 (CHIPS)
- 4150 (HEQS)
- 414E (FISH)
- whatever Iron Horse and Road Hog move to

[wallyweb]

A simple solution?
A database of ranges, perhaps hosted at http://newgrf-specs.tt-wiki.net
- where a range is uniquely identified by the two leading pairs of a GRF ID [rr rr xx xx]
- where the database fields consist only of selected/assigned ranges
- where newly selected ranges are dynamically added to the database (AJAX is our friend)
- ranges 4141 through 7a7a (AA through zz) for those prefering alpha
- ranges <4141 and >7a7a for those prefering numerical
- Currently existing selections retained to avoid a mad rush of recoding headaches (With appologies to the Bayer Aspirin company)
- Exceptions - The few GRF IDs that fall within obviously already existing ranges are requested to change to avoid conflicts.
- a text field to note the name of the range owner and/or the name of the GRF (perhaps two fields?)
- a limit of two or three ranges per owner (would four be better?)
- a form for range selection that returns a "please try again" message for where an existing range is selected
- Did I miss anything?

[andythenorth]

- Did I miss anything?

Spam bot protection. The first serious bot that encounters the form will submit a lot of forms.

Also someone to code it

[kamnet]

Or, you could just maintain the list on the OpenTTD wiki.

[michael blunck]

The NewGRF specs say it's a convention that the first two bytes are the initials of the creator.

That´s a valuable addition you put there.

19:20, 23 June 2014? Rubidium (Talk | contribs)? . . (+156)? . . (Add andy's list)

But it makes no sense to set up another list of *single* newGRF IDs. (Apparently Andy doesn´t care about "conventions" ...).

regards
Michael

[wallyweb]

- Did I miss anything?

Spam bot protection. The first serious bot that encounters the form will submit a lot of forms.

Damn! I've been found out! /me hides the WB spam bot.

Also someone to code it

orudge? Doesn't he like coding stuff?

Or, you could just maintain the list on the OpenTTD wiki.

I tried this with NewObjects ... It has been largely ignored. A DB once set up (with UGH! spam bot protection) would be self maintaining.

[Ammler]

Yes, there was a GrfID conflict with OpenGFX + Airports and a temporary fix was offered by OzTrans with an OpenGFX + Airports clone using a compatible ID.

Depends on how you define "GrfID conflict".

At some point in time, OzTrans claimed all 65,536 GrfIDs starting with "CA" as exclusively owned by him. According to him, he and he alone was allowed to make NewGRFs with an ID starting with "CA", even though it is highly unlikely to say the least, there will even near that number of useful NewGRFs from him in the "CA" block.

You can reverse that statement, there are over 60 thousend "AuthorIDs" around, do other people really need to use one of these?

[andythenorth]

But it makes no sense to set up another list of *single* newGRF IDs. (Apparently Andy doesn´t care about "conventions" ...)

Nope. Fetishing part of the grfid is of no use afaict. It only matters that it's a provable uid. Within reason, I just don't care what the grfid is. It's not significant information.

For same reason, it's also why I don't mind changing grfids to avoid silly conflicts with the range OzTrans wants. I'll just pick another from the thousands of other usable uids. The two grfs that conflict aren't released as stable, now is a good time to do a grfid change.

[Alberth]

You can reverse that statement, there are over 60 thousend "AuthorIDs" around, do other people really need to use one of these?

True, but just because we have plenty means you can claim such a large block? In my view, claim a small block (256 is already too large for a person, you can probably go down to 16 or 32 for most authors).

That way there is always another block if you need one.

Claiming such large blocks makes it really unclear what can be used in the future, after an author has left. It's not always clear that he left, or if he will return.
Also you get problems when two authors arrive with the same initials (assuming you want to use the GRF 8 convention).

[michael blunck]

[Rubidium´s list of newGRF-ID ranges on newgrf specs]
But it makes no sense to set up another list of *single* newGRF IDs. (Apparently Andy doesn´t care about "conventions" ...)

Nope. Fetishing part of the grfid is of no use afaict. It only matters that it's a provable uid. Within reason, I just don't care what the grfid is. It's not significant information.

Well, you could clearly see by now why it´s more straightforward to set up a simple and proper scheme, rather than riding that acronym pony, or whatever.

regards
Michael

[wallyweb]

...

read my proposal ... initials do not have to be used.

At the moment, the base is so huge that there is no need to move to smaller ranges. If, down the road, we find ourselves with a huge number of authors needing a range, then that would be the time for reconsideration. Meanwhile, the proposal as I laid it out is elegant, simple and manageable.

[michael blunck]

read my proposal [... which] is elegant, simple and manageable.

Wally, why are you still trolling?

14:44 <fonsinchen> Party on V453000, give those pesky Canadians what they deserve!
14:45 * fonsinchen gets more chips and beer
14:45 <V453000> :)
14:46 -!- Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd
14:47 <V453000> I just loved the part where he tells me I have no idea ... while I might not be the most experienced, still...
14:47 <V453000> I am still missing his "Greater reasons" though
14:58 <fonsinchen> Some people have just such immense egos that you cannot avoid bumping into them here and there.
14:58 <fonsinchen> Just ignore it.
14:59 <fonsinchen> I mean, such a fuss over a bunch of numbers without any actual problem sort of speaks for itself.
15:05 <@planetmaker> why is that topic still alive? Just don't feed the trolls...

regards
Michael

[andythenorth]

If Iron Horse and Road Hog change grfid, is there anything left to discuss? Will I have to sit here all night hitting refresh, in case someone is wrong on the internet?

[wallyweb]

Wally, why are you still trolling?

15:05 <@planetmaker> Just don't feed the trolls...

Because I am a hungry Canadian who is always looking for a free meal.

Is beakfast ready yet?

Will I have to sit here all night hitting refresh, in case someone is wrong on the internet?

Putin and Obama are always good for a few laughs.

[SquireJames]

If Iron Horse and Road Hog change grfid, is there anything left to discuss?

I believe the original issue was with OpenGFX Airports. So, that one would need to change also.

[frosch]

Just to state some math facts:

There are 26 letters in the alphabet. Using upper and lower case and using the two-letter-initial method you get (2*26)^2 = 2704 possible author prefixes.

Now, if you are naive you will think that there will never be 2704 NewGRF authors and everything should be fine.

But if you have basic knowledge about stochastics, you will know the birthday problem. And it will tell you, that it only needs about 60 NewGRF authors for a probability of 50% of an initial collision. And that is assuming that all letters are equally likely (including X and Q), and that they agree on upper and lower case.

If you drop upper/lower case, you only need about 30 NewGRF authors to reach 50% probability of a collision.

So, the 2-letter-initial rule only worked 10 years ago, when there were like 3 people doing NewGRF. In fact the only reason why there has been no collision till today is, that noone uses this rule, except those 3. (just check the NewGRF list from the master server) (this is an exaggeration, there may also be 5)

So, sorry, everyone who claims the 2-letter-initial rule is a suitable solution: I can not help, but call you stupid.

[wallyweb]

...

Hopefully my suggestion posted above would give everybody some options.

A simple solution?
A database of ranges, perhaps hosted at http://newgrf-specs.tt-wiki.net
- where a range is uniquely identified by the two leading pairs of a GRF ID [rr rr xx xx]
- where the database fields consist only of selected/assigned ranges
- where newly selected ranges are dynamically added to the database (AJAX is our friend)
- ranges 4141 through 7a7a (AA through zz) for those prefering alpha
- ranges <4141 and >7a7a for those prefering numerical
- Currently existing selections retained to avoid a mad rush of recoding headaches (With appologies to the Bayer Aspirin company)
- Exceptions - The few GRF IDs that fall within obviously already existing ranges are requested to change to avoid conflicts.
- a text field to note the name of the range owner and/or the name of the GRF (perhaps two fields?)
- a limit of two or three ranges per owner (would four be better?)
- a form for range selection that returns a "please try again" message for where an existing range is selected
- Did I miss anything?