Transport Tycoon Forums

SlowRails

Here is the release thread for this newGRF.

This newGRF has very modest aims working towards version 1.0
- add to the game 6 new railtypes with speed limits: 40, 80 and 160 km/h (both normal and electrified)
- allow the user to select a price model for the use of those rails

Later versions will get slightly more ambitious, but the above is the core of what I want to accomplish.
Since I'm new at writing newGRFs, I've needed some time to come up with the NFO to reach my goals.
And yes, I'm aware things like GRFmaker and NML exist. I've briefly considered using them and rejected
the idea for a few reasons:
- neither seems entirely mature
- both seem to be only laying an extra layer on NFO, which in my eyes simply increases the chances of falling prey to some bug
- writing straight NFO might not be very user-friendly, but it's not all that bad either in my opinion

So I came up with the file attached, which *kind of* accomplishes the goals I had set myself. Still, there are some issues and questions I'd like to mention and I'd be gratefull for any helpfull hints regarding coding the more seasoned programmers among you could spare me.

Issue 1: NFOrenum and vehicle IDs above the standard range.
NFOrenum seems to like producing errors when you try to use vehicle IDs greater then the default. This is rather puzzling, since GRFcodec doesn't complain making the grf and the grf file itself works as expected.

Issue 2: Action 4 on trains behaving strange
According to the wiki, the offset in an action 4 can be either a byte or a word depending on the high bit of the language ID. It also mentions the byte version is only allowed when using it to set a vehicles name. I wanted to set a vehicles name, but decided to use the word version. Behold: it didn't work. I received no error, but the name wasn't set and the action 4 wasn't recognized by grf2html as belonging to the vehicle. Seems for some reason you're obligated to use the byte version, not simply allowed. Or maybe it's a bug. In the first case it's probably a good idea that this gets mentioned a bit clearer on the wiki. In the second case, I believe I just added something to someones workload

Working Not working Question 1: use of image sprites
I have zero talent at drawing stuff, so making image sprites myself is not an option for me. For this project, that doesn't look to be a major problem so far, as I managed to get a somewhat working version 0.1 without having a single image sprite in my NFO. Still, I'm a bit unsure about the way it works now. Am I right in assuming that my new railtypes simply take the images of the lowest railtype when I don't define anything myself ? Is there a way for me to point them to use other existing images without actually including those ? In particular, the menubar for the electrified railtypes would look nicer if copied from ELRL instead of RAIL.

Question 2: image sprites and license stuff
Sooner or later I'm going to need to include images somewhere. At that point, I'm facing the licensing horror issue. For things with a clear owner, I can always ask permission so that's easy. Is it allowed to include sprites present in the original game ? I assume not since those are probably considered licensed to Chris Sawyer. How about OpenGFX ? Do I need to ask permission there, or does it suffice to simply mention the origin of the graphics ? What's the policy on graphics from people you can't contact ? Does it suffice to give credit ?

Question 3: "activating" railtypes
From what I understand, railtypes are disabled by default until the player can buy at least 1 loc belonging to that railtype. Is there any way around that requirement ? Anything planned for the future that would help ? Having a way to activate a railtype when another railtype becomes active would help me here. So would activating a railtype using dates instead of checking the presence of a loc. Now I've been forced to include 6 locs I don't want. The best "solution" I've come up wih myself would be to request the owner of the "invisible" loc out there (a newgrf to allow wagons to be parked as eyecandy) to be allowed to use those sprites to make my locs invisible. That would still keep them on the list, but make them a bit less obtrusive.

Kimby wrote: Issue 1: NFOrenum and vehicle IDs above the standard range.
NFOrenum seems to like producing errors when you try to use vehicle IDs greater then the default. This is rather puzzling, since GRFcodec doesn't complain making the grf and the grf file itself works as expected.

Make sure you got both programmes from http://www.openttd.org/download-grfcodec (it's one package meanwhile).

Kimby wrote: Question 1: use of image sprites
Am I right in assuming that my new railtypes simply take the images of the lowest railtype when I don't define anything myself ?

You have to provide your own sprites, default sprites are NOT re-used. See the "cargotypes" for the railtypes feature for which graphics are manadatory and which need not be supplied http://wiki.ttdpatch.net/tiki-index.php?page=Action3

Kimby wrote: Question 2: image sprites and license stuff
Sooner or later I'm going to need to include images somewhere. At that point, I'm facing the licensing horror issue. For things with a clear owner, I can always ask permission so that's easy. Is it allowed to include sprites present in the original game ? I assume not since those are probably considered licensed to Chris Sawyer. How about OpenGFX ? Do I need to ask permission there, or does it suffice to simply mention the origin of the graphics ? What's the policy on graphics from people you can't contact ? Does it suffice to give credit ?

* Original graphics can be used, if you get permission from the copyright holder or possibly Simon Foster and Chris Sawyer.
* OpenGFX graphics can be re-used, if you comply to GPL v2
* Any graphics can be used, if the artist gives you permission to use (then his individual terms apply)
* Graphics without license must not be used without permission. Thus if you cannot contact the author of unlicensed graphics, they're "lost" for future use. (which shows why licenses like GPL are so very useful)

For works licensed under GPL you may do anything with it without asking anyone permission, provided
- you use GPL v2 for your work, too and that means:
- Give credit to the original author(s)
- Indicate clearly your own contributions
- Attach the license information clearly to your product
- Make sources available or provide a written offer to provide source upon request, valid for at least three years after publication
Sounds complicated? Not really. Just ship it with the license file. And for releases attach a zip of your development folder with the (p)nfo and graphics files to the forum posting and you're set.

You're welcome to ask for a repository at the DevZone, which then hosts your development repository. It also fulfills the conditions of "source available" and "indicate changes" to a varying degrees, too (depends on how it's used).

Kimby wrote: Question 3: "activating" railtypes
From what I understand, railtypes are disabled by default until the player can buy at least 1 loc belonging to that railtype. Is there any way around that requirement ?

There's currently no way around that. An introduction date property has been discussed but noone has written a patch to that end so far. Providing an engine is so far the only means. Nutracks uses that afaik, too.

Kimby wrote:NFOrenum seems to like producing errors when you try to use vehicle IDs greater then the default. This is rather puzzling, since GRFcodec doesn't complain making the grf and the grf file itself works as expected.

GRFCodec is "stupid"; it doesn't validate NFO beyond the bare essentials (nfo version + general sprite format), it doesn't look at the value of the bytes it's going to write. NFORenum is the tool that is used for performing most NFO validation. NFORenum has some understanding of the meaning of the different bytes and can based on that perform certain validations.

This is also the reason GRFCodec isn't called GRFCompiler; it isn't like a compiler as it doesn't do any semantic validation. That's what NFORenum is for.

Thanks for replying so fast

planetmaker wrote:

Kimby wrote: Issue 1: NFOrenum and vehicle IDs above the standard range.
NFOrenum seems to like producing errors when you try to use vehicle IDs greater then the default. This is rather puzzling, since GRFcodec doesn't complain making the grf and the grf file itself works as expected.

Make sure you got both programmes from http://www.openttd.org/download-grfcodec (it's one package meanwhile).

I've got them as one package indeed: version 5.0.0

planetmaker wrote:

Kimby wrote: Question 1: use of image sprites
Am I right in assuming that my new railtypes simply take the images of the lowest railtype when I don't define anything myself ?

You have to provide your own sprites, default sprites are NOT re-used. See the "cargotypes" for the railtypes feature for which graphics are manadatory and which need not be supplied http://wiki.ttdpatch.net/tiki-index.php?page=Action3

Strange, because I didn't supply any images in what I have so far and the behaviour seems to be that the images from railtype 00 are reused.

planetmaker wrote: * OpenGFX graphics can be re-used, if you comply to GPL v2

That I can probably manage. I'll go through the legalese when I'm in a masochistic mood.

planetmaker wrote: You're welcome to ask for a repository at the DevZone, which then hosts your development repository. It also fulfills the conditions of "source available" and "indicate changes" to a varying degrees, too (depends on how it's used).

Sounds like overkill for now.

GPLv2 is pretty easy. Include the license with your release. Include the source too, or be prepared to provide it on request for 3 years. That's pretty much job done.

Best thing to do is just release your source at the same time as the release, then you have no obligations to keep an eye on the topic in case anyone asks for it. Oftentimes people will ask for it straight away anyway, just in case you stop checking in.

Is it possible to reference standard rail graphics? It would make SlowRails compatibile with rail-graphics-changing newgrfs.

unfortuneately not, but i've opened a feature request regarding the depots, but i just added a comment about the rails as well.

http://bugs.openttd.org/task/4279

DJ Nekkid wrote:unfortuneately not, but i've opened a feature request regarding the depots, but i just added a comment about the rails as well.

http://bugs.openttd.org/task/4279

Strange: you seem to experience other effects then I see here. Are you using OpenGFX by any chance ?
I'm using the original sprites (but I seem to remember installing a 32bpp a year or so ago) and my new railtypes take over ALL the images of railtype 00 for me, including the graphics of the depot GRF I'm using.

BTW: I'm using a modified r21051 if that's possibly relevant.

And you also used another label which is neither RAIL nor ELRL?

planetmaker wrote:And you also used another label which is neither RAIL nor ELRL?

Yes, I used _040, _080 and _160 for normal rail with speed limits and E040, E080 and E160 for electrified rail with speed limit. I used the same naming scheme as nutracks in the hope it would improve compatibility in the future.

I didn't even know it was possible to reuse labels.

Kimby wrote: Yes, I used _040, _080 and _160 for normal rail with speed limits and E040, E080 and E160 for electrified rail with speed limit.

Can I assume you stick to those labels? Then I can use them in SER in order to implement parameters which allow the user to select the track type which SER provides graphics for.

And yes, exactly this is the purpose of the railtypes labels: that different newgrfs can reference the same rail type. Which means that they subsequently can modify it, too. Within your newgrf you probably should define a rail types translation table so that you do not forcefully overwrite a particular railtypes slot but rather the label.

planetmaker wrote:Can I assume you stick to those labels?

Yes, I'll be sticking to those labels. About the only thing I can imagine that would make me change them is if some significant group of programmers put together a standard and it was different from what I had.

Kimby wrote:

planetmaker wrote:Can I assume you stick to those labels?

Yes, I'll be sticking to those labels. About the only thing I can imagine that would make me change them is if some significant group of programmers put together a standard and it was different from what I had.

Document it in the NewGRF wiki - then it is standard

Kimby wrote:if some significant group of programmers put together a standard and it was different from what I had.

Why don't we just go ahead and do this now? Could be good to get it out of the way....

Here is my brainstorm for a handful of classes for a grf to choose from:

Slow Rail
Medium Rail
Fast Rail
HS Rail
Metro Rail
Narrow rail
Caternary versions of the above

Monorail A
Monorail B
Maglev A
Maglev B
(incase a set wants to differential between transrapid and JR styles for example)

Other?


Standard names for these could be helpful?

I don't think the descriptions need to have a standard

The rail type label on the other hand...

The part relevant for my newgrf uses two rules:

1) Any normal rail with speed limit has a label _XXX where XXX is the speed limit, if needed with leading zero
2) Any electrified rail with speed limit has a label EXXX where XXX is the speed limit, if needed with leading zero

Those were actually not my idea, but what was used by nutracks. That newgrf defines a lot more labels, most of which I'm not planning to ever use for SlowRails. Unless someone thinks there will be a need for a 4 digit speed limit, I think the nutracks system works well. If I had to invent it, I'd probably use an "R" instead of "_" for normal rail, but I guess there was a good reason to do it this way.

Kimby wrote: [rail type labels]

if some significant group of programmers put together a standard and it was different from what I had.

This has all been discussed in the original "New Rail Types" thread, nearly a year ago. Conclusion was that standardisation is neither needed nor wished for.

regards
Michael

I believe standardization could be helpful now, that people seem to be wanting to use railtype Grfs to reference other railtype grfs.

The above case of reference Swedish rail graphics, along with sentiments in the Nutracks thread about replacing graphics for certain speeds seems to reason enough for interested authors to agree on some standards. Other sets could of course op out of interoperability if desired. I think that once we get to a situation where the we have two or more railtype GRFs that can use graphics from two or more rail sprite GRFs, it makes sense for the authors or those four or more particular GRFs to label their track types in a way that is intelligible to the other participating sets.

The list I gave above was simply what I thought would be likely to see in a GRF, and soliciting suggestions for labels. If I had to come up with the labels myself; they would be perhaps like this:
These are just my first ideas, I did not use any numbers, apparently they will not work in NML.

In order to support this wish for some standard labels which different grfs can refer to, I added a few rail types labels which are already in use and which might see use elsewhere to the wiki: http://wiki.ttdpatch.net/tiki-index.php ... e_label_08_

Kimby wrote:I don't think the descriptions need to have a standard
The rail type label on the other hand...

The part relevant for my newgrf uses two rules:
1) Any normal rail with speed limit has a label _XXX where XXX is the speed limit, if needed with leading zero
2) Any electrified rail with speed limit has a label EXXX where XXX is the speed limit, if needed with leading zero

I agree on these accounts.

Please make sure to define clearly whether the speed limit is in km/h, mph or some other unit.

I just added the parameter selection to SwedishRails. You'll find the feature in the nightly r190 or later of the NewGRF (available from 18:30h 8th December onward). You can choose to replace 40, 80, 120, 160 and 230 km/h tracks. Separately for rail and electrified rail. The exact behaviour might still change a bit, but might be nice to know whether it fits what is desired.