NML - a Newgrf Meta Language

[FooBar]

why can not do this at NML?

Because NML takes care of setting that property automatically.

If you must you can specify it manually:

Code: Select all

property {
0x15: <value>;
}

Don't know if it will be overridden by NML though.

[Yexo]

why can not do this at NML?

Because NML takes care of setting that property automatically.

NML sets this property always to 0xFF (=first refit-able). It works this way because with GRFv7 the property was broken. Now with GRFv8 you should be able to set the default cargo, it's simply a missing feature.

If you must you can specify it manually:

Code: Select all

property {
0x15: <value>;
}

That doesn't work, because NML wouldn't know what size the property is.

[akasoft]

Because NML takes care of setting that property automatically.

But I want to set this of the my choice. And NFO lets me do.

That doesn't work, because NML wouldn't know what size the property is.

Not work? I cannot set any properties using the syntax, described FooBar? It's a pity.

[FooBar]

That doesn't work, because NML wouldn't know what size the property is.

Hmmm, you have a point there...
In vague memory I remember doing that, but probably found that it didn't work, ending up patching NML myself (for the object views, which is long since added to NML).

In other news, I'm currently looking into adding bridge support to NML. I'm about to test the basic property support. The graphics bit will be a challenge though, for I know very little about the internals of NML (or coding in Python for that matter). I'll start by finding how the NML code for the bridge graphics could look and we'll see from there.

[MinchinWeb]

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.

This is very useful to understand when writing an AI that deals with a more advanced vehicle set like FISH. But what is it that makes passengers passengers, and mail/goods different from other cargo? I presume it's some combination of cargo classes, but which combinations...?

[Yexo]

I think that's hardcoded by cargo slot. Not entirely sure though.

Also it's only a default. A NewGRF can set a different capacity for each cargo type.

[Hirundo]

I think that's hardcoded by cargo slot. Not entirely sure though.

Also it's only a default. A NewGRF can set a different capacity for each cargo type.

There is some magic code in OpenTTD that works because, and only because, no-one has dared yet to override passengers/mail/goods with other cargo types. Doing so would be equivalent to dividing by zero

[akasoft]

When is add to the articulated vehicles a bit flag into the misc_flags props (var 27), which would mean that the full capacity of the articulated vehicle is evaluated only on its first element, it will help to save the ID.

We will be able to use a chain like:

Code: Select all

switch (FEAT_TRAINS, SELF, engine_articulated_part,
  extra_callback_info1)
{
  1..5: return engine;
  return CB_RESULT_NO_MORE_ARTICULATED_PARTS;
}

item (FEAT_TRAINS, engine)
{
  ..
    cargo_capacity: 124;
  ..
  graphics {
    ..
    articulated_part: engine_articulated_part;
  }
}

What do you think about this?
Do I need to add a feature request to the tracker?

[planetmaker]

Sorry, what exactly is your suggestion?

And why / where do you need to save vehicle IDs?

If your suggestion is to automatically add the capacity to the first articualted part for display purposes in the purchase menu: that cannot be done automatically as the capacity may vary depending on refits and whatever variables the author chooses like date and so on.

[FooBar]

I think he wants an additional flag that basically says "don't multiply capacity property by amount of vehicle parts in purchase menu".

[akasoft]

Oh, my English. Maybe my NML will better.

Now. Define 3 articulated parts.

Code: Select all

item (FEAT_TRAINS, engine)
{
  ..
    cargo_capacity: 25;
}

item (FEAT_TRAINS, part2)
{
  ..
    cargo_capacity: 100;
}

item (FEAT_TRAINS, part3)
{
  ..
    cargo_capacity: 75;
}

For MU-vehicle of 6 parts with articulated_part cb

Code: Select all

switch (FEAT_TRAINS, SELF, engine_articulated_part,
  extra_callback_info1)
{
  1..5: return engine;
  return CB_RESULT_NO_MORE_ARTICULATED_PARTS;
}

item (FEAT_TRAINS, engine)
{
  graphics {
    articulated_part: engine_articulated_part;
  }
}

total cargo_capacity of vehicle is amount of 25+25+25+25+25+25=150.

For MU-vehicle of 4 parts

Code: Select all

switch (FEAT_TRAINS, SELF, engine_articulated_part,
  extra_callback_info1)
{
  1: return part2;
  2: return part3;
  3: return (engine + CB_RESULT_REVERSED_VEHICLE);
  return CB_RESULT_NO_MORE_ARTICULATED_PARTS;
}

item (FEAT_TRAINS, engine)
{
  graphics {
    articulated_part: engine_articulated_part;
  }
}

total cargo_capacity of vehicle is amount of 25+100+75+25=225.

(The first item in the ammount is from the engine.)

I suggest add new bit flag into train misc flags in openttd newgrf code

Code: Select all

    #train misc flags
    'TRAIN_FLAG_TILT' : 0,
    'TRAIN_FLAG_2CC'  : 1,
    'TRAIN_FLAG_MU'   : 2,
    'TRAIN_FLAG_FLIP' : 3,
    'TRAIN_FLAG_AUTOREFIT': 4,

TRAIN_FLAG_MU_NO_AMMOUNT, which would mean for the same code

Code: Select all

switch (FEAT_TRAINS, SELF, engine_articulated_part,
  extra_callback_info1)
{
  1..5: return engine;
  return CB_RESULT_NO_MORE_ARTICULATED_PARTS;
}

or

Code: Select all

switch (FEAT_TRAINS, SELF, engine_articulated_part,
  extra_callback_info1)
{
  1: return part2;
  2: return part3;
  3: return (engine + CB_RESULT_REVERSED_VEHICLE);
  return CB_RESULT_NO_MORE_ARTICULATED_PARTS;
}

and

Code: Select all

item (FEAT_TRAINS, engine)
{
  misc_flags: bitmask(TRAIN_FLAG_MU, TRAIN_FLAG_MU_NO_AMMOUNT);
  ..
  graphics {
    articulated_part: engine_articulated_part;
  }
}

total cargo_capacity of vehicle is not amount of parts, only cargo_capacity from the first item, i.e. engine 25=25.

So it will be understood?

[FooBar]

I'm somehow having troubles with articulated vehicles, in that they don't show up ingame and that the NFO generated by NML looks incorrect. Using NML 1792 prebuilt from the bundles server, but the same thing happend with a self-built 1791.

This is my relevant NML (full file attached, ask for the lng and graphics if you need them):

Code: Select all

switch(FEAT_TRAINS, SELF, switch_emu_templatetest_articulated, extra_callback_info1) {
    1..7: return item_emu_templatetest;
    return CB_RESULT_NO_MORE_ARTICULATED_PARTS;
}

That to me seems correct. However, if I let NML output the corresponding NFO I get this:

Code: Select all

// Name: switch_emu_templatetest_articulated
98 * 23 02 00 F8 89 
10 00 dxFFFFFFFF 
b1 
wx8074 dx00000001 dx00000007 	// 1 .. 7: return 116;
wxFFFF // default: return 32767;

It appears that it has added to both values.

Am I doing something wrong, overlooking something stupid? Or is there a something wrong in NML?

[Yexo]

I'm not sure why it doesn't work, but how exactly does that nfo look wrong? To me it looks like a valid translation of the nml code.

[FooBar]

Shouldn't it return wx7FFF as "do not add more articulated parts"?
Also for the ID wx8074 does not equal 116...

I'll try tonight to compile the train example from the NML source, to see what that does. If that works, then probably I have done something wrong. Either way I'll get back to this

[planetmaker]

Shouldn't it return wx7FFF as "do not add more articulated parts"?
Also for the ID wx8074 does not equal 116...

A callback result in grf v8 has (always) 15 bit. Thus 0x74 = 116 and A result of 0x7FFF indicates 'callback failed'. The highest bit 16 which is not part of the callback result itself (0x8000) indicates that the return value is not an action2 ID but the final result (and 0x7FFF + 0x8000 = 0xFFFF).

[FooBar]

Oh, right. That happens when one stops coding in NFO

But that still leaves the issue that it doesn't work. I have like 20 of these vehicles that don't work. Strange thing is that they did work before GRFv8. I'll investigate some more, possibly by commenting most of the code so that I have barely enough to let it actually be a train. And if that works, add stuff step by step until it stops working.

Note to self: do a reboot of the virtual machine first. I just remembered that one time before that solved a grf that didn't build for no apparent reason.

[FooBar]

Well, the reboot didn't change anything, but at least I've found that the articulated vehicle callback is not the problem.

What is the problem is one of these three properties:

Code: Select all

refittable_cargo_classes: bitmask(CC_PASSENGERS);
non_refittable_cargo_classes: 0;
refittable_cargo_types: 0;

When I comment all of those out the train works. If I put any one of them back (doesn't matter which one) the train becomes unavailable.

Funnily enough all my trains that dissapeared are MUs that have a capacity. The ones that remained are all engines without capacity. As I previously used 0xFF to end adding articulated parts and changed that to the proper constant, I thought the problem had something to do with that. But it didn't.

Anyways, when uncommented, NML translates that to this piece of NFO (part of action 0):

Code: Select all

28 wx0001 
15 FF 
29 wx0000 
15 FF 
1D dx00000000 
15 FF 

Now this property 15 (cargo type) is the problem, as there's no entry FF in my cargo table. When I decode the grf, remove the three prop 15 definitions and reencode (grfcodec), the train works as it should.

So clearly this property 15 is the problem, however I have no idea if this is because I did something wrong or not. I can't imagine that I have to put passengers in my cargo table, as that's the whole point of using cargo classes...

If anyone could shed some light on this that would be grand!

[Hirundo]

Well, the reboot didn't change anything, but at least I've found that the articulated vehicle callback is not the problem.

What is the problem is one of these three properties:

Code: Select all

refittable_cargo_classes: bitmask(CC_PASSENGERS);
non_refittable_cargo_classes: 0;
refittable_cargo_types: 0;

When I comment all of those out the train works. If I put any one of them back (doesn't matter which one) the train becomes unavailable.

Funnily enough all my trains that dissapeared are MUs that have a capacity. The ones that remained are all engines without capacity. As I previously used 0xFF to end adding articulated parts and changed that to the proper constant, I thought the problem had something to do with that. But it didn't.

Anyways, when uncommented, NML translates that to this piece of NFO (part of action 0):

Code: Select all

28 wx0001 
15 FF 
29 wx0000 
15 FF 
1D dx00000000 
15 FF 

Now this property 15 (cargo type) is the problem, as there's no entry FF in my cargo table. When I decode the grf, remove the three prop 15 definitions and reencode (grfcodec), the train works as it should.

So clearly this property 15 is the problem, however I have no idea if this is because I did something wrong or not. I can't imagine that I have to put passengers in my cargo table, as that's the whole point of using cargo classes...

If anyone could shed some light on this that would be grand!

I think it is a bug in OpenTTD. Does adding PASS to the cargotable (and changing nothing else) solve the problem?

[planetmaker]

And... did you try with "the latest" nightly (yesterday / today)?

[FooBar]

I was still at 1.2.0-beta3, but with the nightly it works as expected!

So I didn't try expanding the cargo translation table, but what I gather from this that indeed would have caused it to work.


Sorry to cause all this fuzz about something that already was fixed, but thanks very much for your time trying to help me out here (and eventually helping me out)!