NML - a Newgrf Meta Language

[TadeuszD]

P.s. is it possible in NML to refer to other files, rather then having a huge file? What command do I use to refer to external files in the main .nml code if that's possible?

Yes, of course!
Admittedly, GCC and python are parts of Linux, but if you are Windows user, you can use C-preprocessor too. For example, I'm using minGW environment for preprocessing many .pnml files in my project.

[planetmaker]

P.s. is it possible in NML to refer to other files, rather then having a huge file? What command do I use to refer to external files in the main .nml code if that's possible?

Yes, of course!
Admittedly, GCC and python are parts of Linux, but if you are Windows user, you can use C-preprocessor too. For example, I'm using minGW environment for preprocessing many .pnml files in my project.

You can use any pre-processor of your choice to concatenate the files as needed. Like cpp which also allows to use the #include command. NML itself doesn't allow including other files and will barf on files with include commands which have not been pre-processed.

[Eddi]

Having different lengths available in the purchase menu is quite a good thought actually... [BRAINSTORM]This throws in a whole new perspective, plus some comfort with autoreplace indeed. For the player it certainly adds a lot more insight in how to use the set. However, I'm also afraid of having an overcrowded purchase menu, since there really are a lot of EMU and variations. Then again, some EMU only have 2 or 3 consist variations, with most of them only 1 consist and a few 4-consist variations that don't exist all the time together. Hmm... Damn, it will certainly make coding a lot easier as well (I don't have to deal with invisible cars and such).[/BRAINSTORM]

the problem with making consists available as separate vehicles is that you get separate prototype offers at different times, you can't "combine" the prototypes and can't synchronize the availability

[Toni Babelony]

the problem with making consists available as separate vehicles is that you get separate prototype offers at different times, you can't "combine" the prototypes and can't synchronize the availability

That's a problem that I've encountered just now. I want trains to retire on a certain date and have a replacement model readily available at the same point in time when the older model retires.

For example:

Code: Select all

introduction_date:			date(1972, 1, 1);
model_life:					19;
retire_early:					1;

I was expecting the train to be introduced in 1972 and be retired from the purchase menu in 1990, but this is not happening at all. The engine life cycle's 3-phase model is pretty random if I understand it correctly, but I really would like to have strict introduction and retirement dates, rather than loose/random numbers. Is this possible, or is there any way how I can program a train in such a way it's more strictly regulated?

[FooBar]

The introduction date has a random number between 0 and 511 days added to the date you set.
So if you want to have a replacement available in the worst case scenario, you have to set the intro date of the replacement to 511 days earlier than the earliest retirement date of the first train (= intro date train 1 + model life train 1 - 511 days).

There is currently no way to have fixed non-randomized introduction dates, although that would be a welcome addition.

[andythenorth]

You also get 31 months - 17 years added to the model expiry dates
http://newgrf-specs.tt-wiki.net/wiki/Ac ... Model_life

Fun fun fun

[Eddi]

i can't help you with the randomisation, but CETS has the following calculation for lifetime (with some edge cases that are not of concern here):

every vehicle has three basic figures that define its "realistic" lifetime:

• the year the first unit was bought (intro_date)
• the year the last unit was bought (last_built) (for gameplay purposes, this is usually replaced by the intro-date of the next vehicle of the same category)
• the year the last unit went out of [commercial] service (decommissioned)

that gets transformed into the properties by these formulas:

Code: Select all

        values["intro_date"]=intro_date
        values["vehicle_life"]=decommissioned-last_built
        values["model_life"]=decommissioned-intro_date
        values["retire_early"]=values["vehicle_life"]-4

the magic -4 is to offset some other magic related to the 3 availability phases, and is subject to playtesting (in the future...). a -5 would make the vehicle available slightly longer, a -3 shorter. the purpose of this calculation is to have a vehicle bought at the last possible date to have full reliability during its entire vehicle lifetime.

in general, i think it's slightly more useful to have some small overlap between one vehicle and its replacement than to have a gap.

[Toni Babelony]

Thanks for the replies!

I think I'll adjust the values to the ones used in CETS for now. This is the best option for now, since I can't really come up with something better.

Having an overlap is good, since this is the same thing in real life. Next to that, many replacements in my set are mostly either rebuilds of early trains or gradual replacements, since manufacturers can't crank out large amounts of rolling stock in one go, not even in Japan.

Cheers!
Toni

[Hirundo]

Important changes to NML 0.3 wrt. refitting
As of today, the XOR-property refittable_cargo_types is deprecated and will be removed. Use cargo_allow_refit resp. cargo_disallow_refit instead.

Furthermore, you can now specify a default_cargo_type for trains, RVs and ships. You are urged to do so, because not setting it might cause your vehicle carry a (semi-random) cargo type if it cannot refit to any cargo.

Edit: frosch123 pointed out that my above (now struck-through) statement was false. Not setting a default cargo should not break anything, though setting all properties is -of course- still highly recommendend.

[akasoft]

Thank you, Hirundo. I`m really waiting for default_cargo_type (#1809). And capacity multiplier (#1821).

[stevenh]

Guys,

I've just spent a lot of time trying to work out why the latest nmlc wasn't creating GRFs that would show up in OpenTTD... it turns out the latest version is busted? Or it no longer works with the example here:
http://dev.openttdcoop.org/projects/nml ... ad_vehicle

I've switched back to:

Code: Select all

0.2.3 (5f2c23ef5e1f)
Library versions encountered:
PIL: 1.1.7
PLY: 3.4

And magic... everything just works as it should.

The GRF created by the latest:

Code: Select all

r1833 (319667152b09)
Library versions encountered:
PIL: 1.1.7
PLY: 3.4

was 150bytes bigger and OpenTTD (which I forced the GRF via the config) reported "ignoring invalid NewGRF: invalid".


Meanwhile, I'm unable to #define anything?

Code: Select all

grf {
	grfid : "SWH!";
	name : string(STR_GRF_NAME);
	desc : string(STR_GRF_DESCRIPTION);
	version: 1;
	min_compatible_version: 1;
}
 
template tmpl_tram(x, y) {
	[      x, y,  8, 18,   -3, -10]
	[ 16 + x, y, 20, 18,  -14,  -5]
	[ 48 + x, y, 28, 15,  -14,  -8]
	[ 96 + x, y, 20, 18,   -6,  -7]
	[128 + x, y,  8, 18,   -3, -10]
	[144 + x, y, 20, 18,  -14,  -9]
	[176 + x, y, 28, 15,  -14,  -8]
	[224 + x, y, 20, 18,   -6,  -7]
}

#define REFIT_PROPERTIES_PAX 
        refittable_cargo_classes:       bitmask(CC_PASSENGERS); // Allow passengers (and tourists) 
        non_refittable_cargo_classes:   NO_CARGO_CLASS;         // Disallow other cargos 
        refittable_cargo_types:         0; 
		reliability_decay:				1; 
		running_cost_base:				RUNNING_COST_ROADVEH;       // Default road vehicle running cost base 
		running_cost_factor:			135; 
		cost_factor:					143;

equals:

Code: Select all

E:HIROTR~1>nmlc hirotrams.nml
Illegal character '#' at "input", line 20

[FooBar]

#define requires cpp preprocessing. It's not a feature of nmlc.

[planetmaker]

Note also that a cpp define requires to be a one liner or lines concatenated by means of a backslash
See http://dev.openttdcoop.org/projects/ogf ... s.pnml#L27

[Yexo]

Guys,

I've just spent a lot of time trying to work out why the latest nmlc wasn't creating GRFs that would show up in OpenTTD... it turns out the latest version is busted? Or it no longer works with the example here:
http://dev.openttdcoop.org/projects/nml ... ad_vehicle

Which version of OpenTTD are you using? NML writes grf v8 newgrfs since r1833, you'll need OpenTTD 1.2 or a recent nightly to load those. For compatibility with OpenTTD 1.1 stay with NML 0.2.x.

[stevenh]

#define requires cpp preprocessing. It's not a feature of nmlc.

How does one pre-process via the command line via cpp?

Note also that a cpp define requires to be a one liner or lines concatenated by means of a backslash

These were there... I pasted something random.

Yexo, that explains everything else... thanks.

[planetmaker]

gcc -C -E - < file.pnml > file.nml

[stevenh]

Thanks!

So, the purchase callback under graphics replaces the gfx in the purchase menu... how would one then replace the gfx in the bought vehicles info window? It's trying to draw the separated pieces?
Would love to give it the easier-to-use purchase menu graphic.

[andythenorth]

...how would one then replace the gfx in the bought vehicles info window? It's trying to draw the separated pieces?

Can you post a screenshot of the issues?

[stevenh]

Was hoping these two would use the same sprite....
Otherwise it throws my miserable alignment miserably out.

[FooBar]

how would one then replace the gfx in the bought vehicles info window?

You don't
The vehicle info window uses the same sprites as if the vehicle was drawn ingame regularly (completely in the _ view). However it uses different offset distances between the separate vehicle pieces, unfortunately.

For trains there's an easy fix in the form of general variable train_width_32_px. Set that to 1 somewhere at the beginning of your grf and the train will be displayed the same in the info window as on the track. I.e.:

Code: Select all

train_width_32_px = 1;

Just put that somewhere outside of any other block.

For road vehicles, there exists no such fix. You either have to accept the broken info window, or have to accept sub-optimal alignment of the _ view sprites ingame. But IMO this is really something that should be fixed in the game.