Canadian Graphics by OzTrans [End-User Queries] ...

[OzTrans]

Its working, except for the trains 1.6

Now that is a bug in CanRail; I'll investigate it.

Could be interesting to find out the original idea behind that grf-ID, e.g. by scanning #openttd logs.

I new about it for quite some time.

Code: Select all

2014-03-09
»» 22:48:59 < andythenorth> grfid = r"CA\12\1E"
»» 22:49:13 < andythenorth> I left a comment that it is a joke
»» 22:49:17 < andythenorth> but I cba to work out what :P
»» 22:49:29 < Eddi|zuHause> andythenorth: the joke is it begins with CA
»» 22:49:53 < Eddi|zuHause> which is a "forbidden" ID :)
»» 22:50:07 <@planetmaker> nah, better \97\87\EA\XX or so
»» 22:51:06 < Eddi|zuHause> i'm sure there is a log about this, anyway
»» 22:51:17 < andythenorth> I bet
»» 22:52:09 < andythenorth> hmm it will be a joke about iron or something
»» 22:52:16 < andythenorth> not a good joke 

Now A question about a wagon. The Steam generator unit do what?

The SGU is a must on a cold winter morning in any Canadian passenger train to provide heating. In CanRail it is eye-candy and will/may give you a different livery.

[wallyweb]

Now A question about a wagon. The Steam generator unit do what?

The SGU is a must on a cold winter morning in any Canadian passenger train to provide heating. In CanRail it is eye-candy and will/may give you a different livery.

Perhaps a bit of history
By their very nature, steam engines were usually up to the task of providing steam for heating passenger wagons.
By their very nature, diesel engines weren't. Some did include a steam generator in the engine unit, but for obvious reasons, these generators were small. The solution was to design a wagon dedicated to the task ... the steam generator unit (SGU).
Only in Canada? Not at all. SGUs were widely used around the world wherever c-c-c-cold-d-d-d-d weather was a concern.
With the advent of modern electrically heated passenger wagons, SGUs have largely fallen out of favour and followed the steam engine out the door.

[V453000 :)]

Code: Select all

2014-03-09
»» 22:48:59 < andythenorth> grfid = r"CA\12\1E"
»» 22:49:13 < andythenorth> I left a comment that it is a joke
»» 22:49:17 < andythenorth> but I cba to work out what :P
»» 22:49:29 < Eddi|zuHause> andythenorth: the joke is it begins with CA
»» 22:49:53 < Eddi|zuHause> which is a "forbidden" ID :)
»» 22:50:07 <@planetmaker> nah, better \97\87\EA\XX or so
»» 22:51:06 < Eddi|zuHause> i'm sure there is a log about this, anyway
»» 22:51:17 < andythenorth> I bet
»» 22:52:09 < andythenorth> hmm it will be a joke about iron or something
»» 22:52:16 < andythenorth> not a good joke 

Blaming anybody is not a solution, removing agressive artificial checks from your newGRFs for disabling things, however solves ALL of those issues. Just let people use any combination of newGRFs they like, if it breaks it is their problem.

[PikkaBird]

Obviously a silly and inflammatory move by Andy, but what else is new?

We all have different ideas about what makes a good NewGRF, and if OzTrans wants to assert his god-given right to make grfs that nobody can use, that's entirely his prerogative. Let's keep it moderately civil, please.

[V453000 :)]

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

[OzTrans]

Its working, except for the trains 1.6 ... ... but there is still one conflict left.

Its working, except for the trains 1.6

Now that is a bug in CanRail; I'll investigate it.

No it is not a bug in CanRail, but you are using too many GRFs that contain rail types; not your fault either. There is a limit of 16 rail types in a game; CanRail uses 4, but by the time CanRail is activated 16 were already in use.

That Japanese GRF you removed must contain rail types. You can move CanRail further up, but then just another GRF will fail with a funny message.

It is unfortunate, that OpenTTD has decided not to use GRF Resource Management for rail types. If they did, we could check whether there are enough free slots left before we create a new railtype.

Obviously a silly and inflammatory move by Andy, but what else is new? ...

No argument from me. It is unfortunate, that Andy has also used Planetmuker's suggestion with his 'Road Hog' project. That GRFID is the same as Canadian Stations v1.6.

Players will be very thankful for this sort of sabotage ...

[Comm Cody]

I wish to report a bug with the Canadian Building Set and CanRail.

When the tourist parameter is activated, tourists are classified as a freight cargo which requires a caboose in order to not be hit by the speed restriction.

Bit weird to have a replica Canadian, with tourists and passengers limited to 83 miles per hour instead of 105.

[OzTrans]

I wish to report a bug with the Canadian Building Set and CanRail. When the tourist parameter is activated, tourists are classified as a freight cargo which requires a caboose in order to not be hit by the speed restriction. ...

Thank you for reporting this. I thought I fixed that one; I'll have another look.

Passengers, tourists and mail should not be speed restricted. You haven't got by any chance any freight cars (except the express car) in your trains ?

[Comm Cody]

I wish to report a bug with the Canadian Building Set and CanRail. When the tourist parameter is activated, tourists are classified as a freight cargo which requires a caboose in order to not be hit by the speed restriction. ...

Thank you for reporting this. I thought I fixed that one; I'll have another look.

Passengers, tourists and mail should not be speed restricted. You haven't got by any chance any freight cars (except the express car) in your trains ?

No. Only mail and passenger.

[michael blunck]

It is unfortunate, that OpenTTD has decided not to use GRF Resource Management for rail types. If they did, we could check whether there are enough free slots left before we create a new railtype.

Yes, that´s a flaw for sure. OTOH, there had been attempts to "standardise" railtypes, so that might be a possibility for train sets bringing their own rails.

regards
Michael

[V453000 :)]

Players will be very thankful for this sort of sabotage ...

May I ask how is anybody sabotaging your newGRFs if they disable themselves?

Especially since there is no REAL conflict between the newGRF IDs as they are not the same ...

CanadianStations 1.6: \97\87\EA\81
RoadHog \97\87\EA\FE

81 and FE seems like a difference to me.

[FooBar]

It is unfortunate, that OpenTTD has decided not to use GRF Resource Management for rail types. If they did, we could check whether there are enough free slots left before we create a new railtype.

Oh but you can even so without GRM. See Metrotrackset for an example, or ask Eddi who's suggested that to me.

[wallyweb]

Especially since there is no REAL conflict between the newGRF IDs as they are not the same ...

CanadianStations 1.6: \97\87\EA\81
RoadHog \97\87\EA\FE

81 and FE seems like a difference to me.

I find this all to be very strange.
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.
Then, when moving to the 1.6 versions, OzTrans selected a block of IDs that avoided numbering associated with text characters so as to avoid these types of conflicts.
Now we find that, considering all the numerical only possibilities, a conflicting GrfID sequence accurate to the first 6 of 8 digits is used. The probability of this happening accidentally, although not impossible, is extremely remote, to the point that one would be hard pressed to dispute an observation that this was done intentionally. OzTran's use of the word "sabotage" would seem to be at best an understatement.
Who selected that GrfID and what was the rational for doing so?
If OzTrans were to select an alternate range of GrfIDs, how long would it be before another conflict was instigated?

Pardon me if were to conclude that somebody's feet are firmly stuck in a honey-pot.

[Mr Fox]

Should there be a list for programer so when the created a new GRF they can avoid conflict with other GRF?

Like a serial number would be assigned to Oz so his stuff will not be conflicting with another GRF so those like me use many GRF can actually use them fully?

[michael blunck]

Should there be a list for programer so when the created a new GRF they can avoid conflict with other GRF?

There´s a list by Rubidium somewhere on the OpenTTD user pages, derived from usage of newGRFs on MP servers.

Like a serial number would be assigned to Oz so his stuff will not be conflicting with another GRF so those like me use many GRF can actually use them fully?

The historical procedure is to take 2 characters related to the releaser´s name and two more characters/numbers specifying said newGRF in more detail.

This had worked for years, with some very few collisions having been resolved in collaboration.

regards
Michael

[Alberth]

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. Making over 60,000 useful NewGRFs takes more than one person life time.

At that time OpenGfx+ airports fell in that range, and was thus "unauthorized" according to OzTrans. It had (and has) however a GrfID not used by OzTrans. Technically there is thus no conflict with respect to GrfIDs. The GRFspecs only define conflict as two grfs having the exact same number, a notion like "common prefix" does not count as conflict. Apparently the same happens with Roadhog. It has a Id in that block, but not exactly the same, and thus no conflict in the technical sense.

The only reason that these NewGrfs cannot be used together is because OzTrans consiously programmed his NewGRFs to disable themselves as soon an "unauthorized" NewGRF uses a GrfID from those 65,536 IDs.

[Mr Fox]

Well then, what is required is a mediator to fix those problem. But to be able to do so, all party must agree in the mater.

So anyone agree with that idea so there will no longer be any conflict in any way with NewGrf in the future and maybe "fix" the problem with existing GRF?

I'm just a user and I would like to be able to use any GRF with any other GRF and not having conflict. Beside I see no point in trying to almost have a monopoly in the use of GRF in the game.

So make peace and make the users happy by not making conflict with your creations so anyone who want to use GRF with any other.

I do not care who, why, when, where or how. All I would like is to be able to use GRF that I want with any other GRF.

[mart3p]

Should there be a list for programer so when the created a new GRF they can avoid conflict with other GRF?

There´s a list by Rubidium somewhere on the OpenTTD user pages, derived from usage of newGRFs on MP servers.

You can find it here.

[andythenorth]

I don't know of any good reason why Road Hog's grfid is so close to Canadian Stations. I might change it.

'Reserving' such a large range of grfids is obviously silly, but if I was intentionally trolling I'd pick something funnier. I'm a satisfied user of Canadian Stations.

[Mr Fox]

I found a bug in the Canadian trains set, but its in version 1.1

Now in the 1.6 version there is a conflict with OpenGFX+Airports0.4.1