NML - a Newgrf Meta Language

andythenorth · **Posted:** Thu Mar 08, 2012 9:04 pm

Bad_Brett wrote:

My plan is to include fishing boats and a "fish resource". It would be strange if it was be possible to send mail to the fishes.

You can do this

FIRS has fishing grounds (as does ECS). However...the stations for them accept passengers :shock:

One day this will be fixed in OpenTTD

Until then...this is the best you can do.

planetmaker · **Posted:** Thu Mar 08, 2012 9:05 pm

Ah, ok.

What you (additionally want to what was said above) is to modify the single tiles which make up your industry. You'll need to read up on tile layout for industries and then on the industry tiles themselves (they individually accept the cargo. You need to have tiles which accept all the cargos your industry shall accept).

Default station tiles and their respective industries: http://newgrf-specs.tt-wiki.net/wiki/NM ... stry_tiles
For the station tile you want to substitute the oil rig's tile which has the station (substitute property of the tile.

Bad_Brett · **Posted:** Thu Mar 08, 2012 9:13 pm

planetmaker wrote:

Ah, ok.

What you (additionally want to what was said above) is to modify the single tiles which make up your industry. You'll need to read up on tile layout for industries and then on the industry tiles themselves (they individually accept the cargo. You need to have tiles which accept all the cargos your industry shall accept).

Default station tiles and their respective industries: http://newgrf-specs.tt-wiki.net/wiki/NM ... stry_tiles
For the station tile you want to substitute the oil rig's tile which has the station (substitute property of the tile.

Interesting! There seems to be a lot of possibilities, even though these things seems a bit more complicated. Since I began learning the nml syntax yesterday, it might be wise for me to wait a couple of weeks before trying to fix this.

andythenorth · **Posted:** Thu Mar 08, 2012 10:21 pm

Bad_Brett wrote:

Interesting! There seems to be a lot of possibilities, even though these things seems a bit more complicated. Since I began learning the nml syntax yesterday, it might be wise for me to wait a couple of weeks before trying to fix this.

When learning industry code, I found it easiest to first learn how to adjust properties of default industries, whilst reusing their sprite layouts etc. I still have a 'catfood mine' grf somewhere :twisted:

FooBar · **Posted:** Thu Mar 08, 2012 10:27 pm

IIRC the oil rig station tile only accepts passengers. And there nothing you can do about that.
See FIRS for example, there you can also send passengers to fishing grounds and dredging sites.

Bad_Brett · **Posted:** Fri Mar 09, 2012 12:31 am

andythenorth wrote:

When learning industry code, I found it easiest to first learn how to adjust properties of default industries, whilst reusing their sprite layouts etc. I still have a 'catfood mine' grf somewhere :twisted:

I'm doing that right now. It's kind of exciting to finally be able to do these modifications without those pesky nfo-files.

Bad_Brett · **Posted:** Fri Mar 09, 2012 3:07 am

By the way... When I'm trying to add ground tiles at 4x zoom level, I know get a complaint about "corrupted sprites". These "corrupted" sprites, worked perfectly before. What's going on here? Are there some new size limitations that I don't know about? Normal zoom and 2x zoom works good though.

I tried to resize the z0 sprite from 256x128 to 200x100 and like magic, it worked! The z0 sprites need to be at least 256 pixels wide, which means that the png-file will have a size of 40-50 kbs and obviously, this isn't possible anymore.

Also, generating the .grf takes a lot of time as soon as I include larger pngs. I've only included 3 sprites and it already takes about 30 seconds to generate the grf. How can I fix this issue?

oberhümer · **Posted:** Fri Mar 09, 2012 3:38 am

Generating NFO and then using GRFCodec on that apparently improves the speed a lot. No idea about the rest.

Bad_Brett · **Posted:** Fri Mar 09, 2012 8:58 am

oberhümer wrote:

Generating NFO and then using GRFCodec on that apparently improves the speed a lot. No idea about the rest.

Hmm... I guess my best bet is keep using the old nightly release while testing sprites. Otherwise setting the offsets will be rather time consuming.

But the new restrictions in sprite size really bothers me.

Hirundo · **Joined:** Sun Jan 27, 2008 1:02 pm **Posts:** 298

Bad_Brett wrote:

By the way... When I'm trying to add ground tiles at 4x zoom level, I know get a complaint about "corrupted sprites". These "corrupted" sprites, worked perfectly before. What's going on here? Are there some new size limitations that I don't know about? Normal zoom and 2x zoom works good though.

Could you show me some example that demonstrates this? Because the word "corrupted" doesn't even appear in my nml repository, I have no real clue what you're talking about, nor am I aware of any such issue.

FooBar · **Posted:** Fri Mar 09, 2012 10:22 am

Bad_Brett wrote:

Otherwise setting the offsets will be rather time consuming.

Not necessarily. Just put the sprites in once, then use the ingame sprite aligner to find the correct offsets and transfer them back to the code (manually).

However, the best way is to use templates, like 8bpp development has been doing for years now. Then you only have to find the offsets once for all sprites of the same type. Easy as pie. And just let grfcodec or nml take care of cropping the excess blue.

Bad_Brett · **Posted:** Fri Mar 09, 2012 12:08 pm

Could you show me some example that demonstrates this? Because the word "corrupted" doesn't even appear in my nml repository, I have no real clue what you're talking about, nor am I aware of any such issue.[/quote]

Sorry, I mean "corrupt":

Attachment:

corrupt.png [ 87.07 KiB | Viewed 752 times ]

[quote="Hirundo"]

This happens when I try to use this sprite for the 4x zoom level:

Attachment:

desert_tile_1_z0.png [ 41.51 KiB | Viewed 752 times ]

If I reduce the dimensions of it, to say, 230x115, the game stops complaining, which leads me to believe that it is a size issue.

planetmaker · **Posted:** Fri Mar 09, 2012 12:27 pm

If you could post a whole set of groundsprites (all 19 slopes) and possibly the source you use trying to get it ingame, I'll take a look.

Hirundo · **Joined:** Sun Jan 27, 2008 1:02 pm **Posts:** 298

Bad_Brett wrote:

If I reduce the dimensions of it, to say, 230x115, the game stops complaining, which leads me to believe that it is a size issue.

Your guess was in the right direction. Sprites with tile compressed size of 64kiB or larger are compressed using a slightly different algorithm. In NML this algorithm had a bug, which should be fixed in NML r1877. Could you verify that this is actually the case?

ATM I'm looking into the speed issue, it's quite likely that there is significant potential for optimization. NML being slow annoys the heck of out me too :evil:

Bad_Brett · **Posted:** Sat Mar 10, 2012 1:34 am

Hirundo wrote:

Your guess was in the right direction. Sprites with tile compressed size of 64kiB or larger are compressed using a slightly different algorithm. In NML this algorithm had a bug, which should be fixed in NML r1877. Could you verify that this is actually the case?

The error was in a build from March 7. I just tried the build from March 9 and it works perfectly now. It also appears that it was the dimensions and not the file size that caused the trouble, unless there's a direct connection between the dimensions and the file size when the files are imported in Python. I tried generating blank tiles that was only 1.28 kb big, but it still wouldn't work. Anyway, the problem seems to be fixed now. Great work!

Quote:

ATM I'm looking into the speed issue, it's quite likely that there is significant potential for optimization. NML being slow annoys the heck of out me too :evil:

Wonderful!

Hirundo · **Joined:** Sun Jan 27, 2008 1:02 pm **Posts:** 298

As of NML r1879, writing (big) real sprites should be much faster. The speedup is roughly x2 for opengfx, it might be significantly more or less depending on the grf involved. My test grf with a single large sprite (the desert tile posted above) the speedup was about x10! This is quite a corner case though.

Also I'd like to point out that the -u command-line option (which has existed for quite some time) disables lz77 compression, resulting in a larger file size but shorter compile time. This might be quite worth it for debug builds.

Happy coding

Bad_Brett · **Posted:** Sat Mar 10, 2012 1:45 pm

Hirundo wrote:

As of NML r1879, writing (big) real sprites should be much faster. The speedup is roughly x2 for opengfx, it might be significantly more or less depending on the grf involved. My test grf with a single large sprite (the desert tile posted above) the speedup was about x10! This is quite a corner case though.

Also I'd like to point out that the -u command-line option (which has existed for quite some time) disables lz77 compression, resulting in a larger file size but shorter compile time. This might be quite worth it for debug builds.

Happy coding

Great work!

I'm going to try it in a few hours.

While we're at it, I have another question. I searched the documentation on how to set closure_msg for industries and found this (http://newgrf-specs.tt-wiki.net/wiki/NML:Industries):

name | string | Name of the industry, use a custom string or one of the default TTD strings.

closure_msg | string | Message displayed when the industry announces closure. Use a custom string or one of the default TTD strings.

The problem is, that the "name" parameter is stored as a string while the closure_msg is not, yet they have the same description. Are there any good nml-file for industries that I can use as a reference, because it seems very hard to figure these things out in a stage when I don't know the syntax very well.

Yexo · **Joined:** Thu Dec 20, 2007 12:49 pm **Posts:** 3653

Bad_Brett wrote:

The problem is, that the "name" parameter is stored as a string while the closure_msg is not, yet they have the same description.

That was actually a bug in NML. I've fixed in it r1880. They should both behave like the 'name" property already did.

FooBar · **Posted:** Sat Mar 10, 2012 2:13 pm

If you need industry examples, check out the source of FIRS (it's on the devzone). Also OpenGFX+Industries may contain useful examples. AFAIK those are the only industry-related newgrfs in NML.

Bad_Brett · **Posted:** Sat Mar 10, 2012 6:17 pm

Yexo wrote:

That was actually a bug in NML. I've fixed in it r1880. They should both behave like the 'name" property already did.

Great. I guess it will be released within the next few days?

FooBar wrote:

If you need industry examples, check out the source of FIRS (it's on the devzone). Also OpenGFX+Industries may contain useful examples. AFAIK those are the only industry-related newgrfs in NML.

Will do, thanks!

Transport Tycoon Forums

NML - a Newgrf Meta Language

Who is online