NML - a Newgrf Meta Language

[FooBar]

Eddi's solution is indeed the best if you want a capacity of exactly 188.
Depending on NML version and size of your vehicle set you may run out of vehicle IDs that can be articulated (there's only 128 in GRFv7).

Personally I use one ID for the entire vehicle and live with the fact that the capacity has to be a multiple of the number of vehicle parts. I then define both the cargo_capacity and purchase_cargo_capacity callbacks. In this case I would have the first one return 190 for the first vehicle part and the second callback return 19, e.g.:

Code: Select all

switch (FEAT_TRAINS, SELF, rs5_cargo_capacity, position_in_vehid_chain) {
    0: return 190;
    return 0;
}

graphics {
    cargo_capacity: s5_cargo_capacity;
    purchase_cargo_capacity: return 19;
}

In this case it doesn't really matter what you set the capacity property to, as in all cases the callbacks are used. I'm not sure what happens if you don't set the capacity property at all, I would need to test that, but maybe somebody knows by heart.

[akasoft]

Using replacenew() block like

Code: Select all

  replacenew(CATENARY, "catenary_wire_pylons.png")
  {
    // 36 спрайтов
    [306, 10, 32, 26, -29, -11]
    [354, 10, 32, 26,  -1, -12]
    [402, 10, 32, 11,  -1, -12]
...

receive a error

nmlc: An internal error has occurred:
nmlc-version: r285M (153aa62095cb)
Error: (NotImplementedError) "__str__ must be implemented in BaseStatement-
subclass <class 'nml.ast.replace.ReplaceNewSprite'>".
Command: ['nmlc', '--nfo=xussr.nfo', '--grf=xussr.grf', '--nml=xussr_optimize
d.nml', '-M', '--MF=xussr_dep.txt', 'xussr.nml']
Location: File "nml\ast\base_statement.py", line 109, in __str__

[Yexo]

Bug in nml, see http://dev.openttdcoop.org/issues/3450

As a workaround don't use nml-output (the --nml flag).

[akasoft]

If I used CB_RESULT_REVERSED_VEHICLE in articulated_part callback

Code: Select all

switch (FEAT_TRAINS, SELF, rs5_articulated_part,
  extra_callback_info1)
{
  1: return rs5;
  2: return (rs5 | CB_RESULT_REVERSED_VEHICLE);
  return CB_RESULT_NO_MORE_ARTICULATED_PARTS;

how I detect CB_RESULT_REVERSED_VEHICLE in default callback to get a valid spriteset?

Code: Select all

switch (FEAT_TRAINS, SELF, rs5_get_spriteset,
  ???)
{
  1: rs5_reversed_spriteset;
  rs5_spriteset;
}

item (FEAT_TRAINS, rs5) 
{
  graphics
  {
    default: rs5_get_spriteset;
    articulated_part: rs5_articulated_part;
    ...
  }
}

Variable vehicle_is_reversed is 0.

[Yexo]

if a vehicle is going to east it'll display the west sprite. So you shouldn't need to do anything special.

[akasoft]

And there is a problem described here.

How I can return valid sprites to reversed and non-reversed vehicle with valid align view in the depot and on the viewport?

[Eddi]

maybe var C8 is the correct one here?

"vehicle is reversed" is definitely not correct, because that changes every time the train goes backwards (e.g. at stations, line end, click the reverse button in train window) -- use this flag for simulating push-pull service.

[akasoft]

Yes, it work.
Added to my definition.pnml:

Code: Select all

// Для выбора правильного набора спрайтов в случае флага TRAIN_FLAG_FLIP
// или CB_RESULT_REVERSED_VEHICLE
#define is_flipped() (var[0xC8, 0, 0xFF] != 0xFD)
#define is_not_flipped() (var[0xC8, 0, 0xFF] == 0xFD)

For getting "flipped version" of the spriteset used the same template with shift by formula: (shorten - 8 ).

For example:

Code: Select all

// Шаблон 6 (size 6) **
// обычный
template s6_template(x, y, shift)
{
  [x,     y,  7, 38, -2,        -32-2*shift]
  [x+16,  y, 17, 30, -10+2*shift, -22-shift]
  [x+48,  y, 24, 20, -8+4*shift, -16]
  [x+80,  y, 17, 30, -1+2*shift,  -21+shift]
  [x+112, y,  7, 38, -2,        -28+2*shift]
  [x+128, y, 17, 30, -14-2*shift, -20+shift]
  [x+160, y, 24, 20, -16-4*shift, -16]
  [x+192, y, 17, 30, -5-2*shift,  -23-shift]
}
..
// Шаблон 10 (size 10) **
// обычный
template s10_template(x, y, shift)
{
  [x,     y, 12, 62, -5,          -18-2*shift]
  [x+32,  y, 42, 42, -34+2*shift, -13-shift]
  [x+80,  y, 64, 17, -48+4*shift, -13]
  [x+160, y, 42, 43, -26+2*shift, -34+shift]
  [x+208, y, 12, 62, -5,          -49+2*shift]
  [x+240, y, 42, 43, -14-2*shift, -33+shift]
  [x+288, y, 64, 17, -16-4*shift, -13]
  [x+368, y, 42, 42, -6-2*shift,  -14-shift]
}

In vehicle desc:

Code: Select all

spriteset (_9p_1_spriteset, IMAGEFILE)
{
  s6_template(0, 0, 0)
} 

spriteset (_9p_flip_1_spriteset, IMAGEFILE)
{
  s6_template(0, 0, -2)
} 
..
spriteset (rs5_diesel_spriteset, IMAGEFILE)
{
  s10_template(112, 131, 0)
}

spriteset (rs5_diesel_flip_spriteset, IMAGEFILE)
{
  s10_template(552, 131, 2)
}

[akasoft]

In NML wiki:

date_of_last_service
date(year, month, day)
No
Not valid before 1920 and after 2090.

In NFO wiki:

4B
D
Supported by OpenTTD 1.2 (r23068)1.2 Not supported by TTDPatch
Long date of last servicing

Tell me, it is long date 0 based or date between 1920 and 2090? If the latest, what contains a variable, if the year is less than 1920 or more 2090?

[Yexo]

In NML versions < r1707 it'll contain 1 january 1920 for dates before that date. Since NML r1707 the variable is 0-b sed, the documentation was outdated, I've fixed it now.

[akasoft]

If I defined cargo vagon as

Code: Select all

item (FEAT_TRAINS, boxcar_11_xxxx) 
{
  property
  {
...
    refittable_cargo_classes: bitmask(CC_BULK, CC_PIECE_GOODS, CC_EXPRESS);
    cargo_capacity: 52;
...
  }
}

then in refit ui window I see 104 cargo units for goods (cargo_capacity * 2) and 52 units for other cargo.

If I use cargo_capacity callback, like this

Code: Select all

item (FEAT_TRAINS, boxcar_11_066) 
{
...
  graphics
  {
...
    cargo_capacity: return 52;
  }
}

doubling goods does not occur.

Why is the doubling of the goods? This bug? What I doing wrong?

[TadeuszD]

Everything is OK.
If you define wagon with refittable_cargo_classes = CC_BULK and CC_PIECE_GOODS, the default cargo type for this wagon is probably COAL. In this case cargo_capacity=52 means 52 tons of coal.
If you refit wagon to load goods, the new cargo_capacity will be 104 piece of goods, because in OTTD 1 piece of goods = 1/2 tons of bulk cargo.

But, if you define cargo_capacity callback, you can define capacity for all cargos independently.

[Hirundo]

Everything is OK.
If you define wagon with refittable_cargo_classes = CC_BULK and CC_PIECE_GOODS, the default cargo type for this wagon is probably COAL. In this case cargo_capacity=52 means 52 tons of coal.
If you refit wagon to load goods, the new cargo_capacity will be 104 piece of goods, because in OTTD 1 piece of goods = 1/2 tons of bulk cargo.

But, if you define cargo_capacity callback, you can define capacity for all cargos independently.

When refitting in OpenTTD, one unit of normal cargo is equivalent to two units of mail/goods, or four passengers. Note that the weight of the cargo doesn't (directly) matter here.
These 'capacity multipliers' are applied automatically, for example try refitting one of the default aircraft. (Note that aircraft have their own peculiarities for pax/mail which I shall not discuss here)

If you refit via callback, this multiplier effect is overridden and you always get the exact, specified capacity.

To summarize, it's a "feature" in OpenTTD, not a bug in NML or OpenTTD. I'll add a note about this to the NML documentation.

[PaulC]

I'm taking my first steps in nml coding and have a working town name grf. However, I would prefer to maintain compatibility with TTDP if at all possible. Does that require me to use an older version of nml, e.g. the latest stable release (0.2.1 I think) rather than the latest nightly? Is there any disadvantage to using older versions of nml, or anything I need to be aware of, or for something as basic as a town name set will it not make any difference?

[planetmaker]

Indeed it means you'll have to use an NML from the 0.2 branch like 0.2.1.

With respect to town names nothing has changed though and no special precautions need be taken - or at least none I can think of right now For a starter I can recommend to look at the (codewise) relatively simple Dutch Townname NewGRF which also comes w/o any makefile fancies, thus allows to simply compile the NML.

[Yexo]

You'll indeed need to use a 0.2.x version of nml to stay compatible with TTDPatch. Nothing has changed for town name grfs, so using that should be fine. There has been no testing for TTDPatch compatibility for a long time, so please do report back if you manage to get it to work. (it should be fine, but without testing you never know).

[PaulC]

Thanks guys. I tried 0.2.1 but that doesn't allow url-information in the grf-block, so I'm now using r1742 instead. Anyway, I've recoded my grf and it seems to work just fine in TTDP.

[akasoft]

How to define (use) the property "default cargo" 0x15 for trains (and other vehicles) with nmlc 0.3?

GRF8
GRFSpecs

[FooBar]

Note that the default cargo cannot be selected explicitly. Instead it is automatically set to use the first refittable cargo, whenever one of the refitting properties is set.

From http://newgrf-specs.tt-wiki.net/wiki/NML:Vehicles

[akasoft]

On the NFO the property 0x15 (0x10, 0x0C) can be specified explicitly in Action 0, why can not do this at NML?

Maybe there is a workaround, such as using var[] for undefined variables?