NML - a Newgrf Meta Language

[Wahazar]

thank you, I didn't noticed this table because these wiki pages are somewhat weird formatted (need to scroll some blank pages to get start of the table).

Honestly, I'm not sure a NewGRF should have any need to check for the breakdowns setting...

I have some expensive brand new and reliable (low reliability decay and retire early protection) vehicles, and some cheap "second hand" vehicles. These cheap vehicles should not be presented if vehicle breakdowns are disabled (or theirs stats should be altered),
but I can live with that and just put a one more newgrf parameter.

[Alberth]

Even if you could read the break-down value, a parameter seems better to me, as people don't expect grf behavior to change due to the break-down setting, I think.
That may lead to people posting pictures of the cheap vehicles and mentioning your grf. Other people try to get the same vehicles, and fail as their breakdown setting is different.

[planetmaker]

Even if you could read the break-down value, a parameter seems better to me, as people don't expect grf behavior to change due to the break-down setting, I think.
That may lead to people posting pictures of the cheap vehicles and mentioning your grf. Other people try to get the same vehicles, and fail as their breakdown setting is different.

I fully agree.

Adopting grf behaviour to random user settings is generally bad behaviour imho as it comes in unexpected.

[TadeuszD]

How can I check, whether the train vehicle is running under the bridge?
There is the NML variable vehicle_is_hidden. But it detects only depot and tunel.

[planetmaker]

How can I check, whether the train vehicle is running under the bridge?
There is the NML variable vehicle_is_hidden. But it detects only depot and tunel.

Of course, a vehicle under a bridge isn't hidden.

I've no clue if - and if so, where - that piece of information is exposed in the grf specs at all, can you enlighten me? (Nor do I currently see where drawing a vehicle should differ whether a bridge passes above (how high?) or not)

[TadeuszD]

Nor do I currently see where drawing a vehicle should differ whether a bridge passes above...

Sorry for modest information in my question. I'm looking for method to prevent glitches when long vehicle is covered/clipped by something. For depots and tunels I'm using special sprites (see the last spriteset in https://dev.openttdcoop.org/projects/pk ... x/120a.png) and special switch which uses vehicle_is_hidden as parameter.

Currently I'm looking for tricks how can I detect bridges. The NewGRF spec has no information about that. I hope, that are some methods, maybe not described yet...

[planetmaker]

Nor do I currently see where drawing a vehicle should differ whether a bridge passes above...

Sorry for modest information in my question. I'm looking for method to prevent glitches when long vehicle is covered/clipped by something. For depots and tunels I'm using special sprites (see the last spriteset in https://dev.openttdcoop.org/projects/pk ... x/120a.png) and special switch which uses vehicle_is_hidden as parameter.

Currently I'm looking for tricks how can I detect bridges. The NewGRF spec has no information about that. I hope, that are some methods, maybe not described yet...

No, you don't need that. Bridges are drawn on top of vehicles. You generally have no knowledge whether a bridge is *drawn* above the sprite. A vehicle which has a bridge over it, generally is drawn completely - especially for higher bridges. Additionally to unknown heights, you do not know the direction of the bridge over you.. it could be in track direction or perpendicular. Thus it is not a problem a NewGRF should even attempt to solve (though I don't even see that there is one - except if your sprites violate the grf specs in terms of size vs. bounding box. But I don't see that in your example.

[Eddi]

i prevent (most) such glitches by splitting the vehicle into parts, when it is not in a curve. this can be done in the nml template, without providing additional sprite files.

[TadeuszD]

Thanks for quick answers!

...except if your sprites violate the grf specs in terms of size vs. bounding box. But I don't see that in your example.

Yes, this problem appears when oversized vehicle goes in directions SE and SW. When the vehicle goes through the next tile, the rear part of vehicle hides the bridge.

i prevent (most) such glitches by splitting the vehicle into parts, when it is not in a curve. this can be done in the nml template, without providing additional sprite files.

I'm using two parts for longest coaches in my set too. But I see, I must reorganize my sprites and code. Thanks for the trick with NML templates! It is easier way than creating separate sprites.

[planetmaker]

Thanks for quick answers!

...except if your sprites violate the grf specs in terms of size vs. bounding box. But I don't see that in your example.

Yes, this problem appears when oversized vehicle goes in directions SE and SW. When the vehicle goes through the next tile, the rear part of vehicle hides the bridge.

Except when the bridge is two tiles higher. Then it happens at the 2nd next or so - but it's not under the bridge anymore when sprite clipping happens. And how's it when it's diagonal to the bridge? Thus your suggested variable would not be useful at all. Thus bridge above... that's nothing a NewGRF should query as vehicle. Sorry, it sounds harsh: NewGRF should provide sprites which adhere to the sizes they claim to have (however yours look like exactly 8/8?!) - if you provide larger sprites, you willingly disregard how the sprite sorter works by ignoring the bounding boxes. Anything larger than 8/8 is... too large for vehicles. Unless you create the proper solution: extend OpenTTD and the specs to deal with longer vehicles than 8/8 - and declare your vehicles in the NewGRF as long as they actually are.

[TadeuszD]

Planetmaker, you're right at all!
I know that vehicles longer than 8/8 are not properly supported by OTTD. But in Poland we have short proverb: "Rules are established, to break them."

Thus your suggested variable would not be useful at all. Thus bridge above... that's nothing a NewGRF should query as vehicle. [...] however yours look like exactly 8/8?!

I didn't suggest any variable. I asked only whether similar variable exist or not. Going this way, the variable vehicle_is_hidden is not useful too. NewGRF should not ask about that, because OTTD manages which sprites should be displayed or hidden (in tunel, depot). Anyway, this variable exist.
The passenger coach shown above are 11/8 long...

[Eddi]

vehicle_is_hidden means that the game does not actually try to draw the vehicle sprite (e.g. in tunnel/depot), whereas what you want to know is more like "vehicle is overlapped". but this is circular, because in all cases where the vehicle glitches, OpenTTD would also report the wrong value to the NewGRF, so you would not get any closer to a solution anyway.

the way OpenTTD decides this "overlapping" is by the bounding boxes, and as you know, there is no way to tell OpenTTD that the vehicle bounding box is larger than 8lu (length units). whether allowing that actually would help is another discussion, as large bounding boxes open more edge cases...

[planetmaker]

Planetmaker, you're right at all!
I know that vehicles longer than 8/8 are not properly supported by OTTD. But in Poland we have short proverb: "Rules are established, to break them."

Hehe, we have that proverb in Germany, too. And it's totally right

And then there's:
first learn the rules
then break the rules
then forget the rules

[Eddi]

... but in germany we also have "the revolution is cancelled, because it's not allowed to step on the grass"

[TadeuszD]

"the revolution is cancelled, because it's not allowed to step on the grass"

Nice.

Going to the thread, I have next questions about NewGRF...
I have three experimental train vehicles. All are articulated and can carry passengers and mail in different configuration:
Vehicle A:
1) Passengers
2) Passengers/Mail
Vehicle B:
1) Passengers/Mail
2) Passengers
Vehicle C:
1) Passengers
2) Passengers/Mail
3) Passengers
4) Passengers

When these vehicles are refitted to transport mail, we receive different cargo order in train information window:
Vehicle A:
- X passengers
- Y bags of mail
Vehicle B:
- Y bags of mail
- X passengers
Vehicle C:
- X passengers
- Y bags of mail

What rules decide about cargo order in information window? Does it depend on cargo order (first appearance of cargo) in subsequent articulated parts?
Can I change it without changing part order?

[Eddi]

i cannot confirm how it works, but what you describe is consistent with "go through the articulated parts, and record which cargo they carry"

so if the first vehicle part carries mail, mail will be the first line, if the first vehicle part carries passengers, passengers will be the first line.

[TadeuszD]

Please correct me, if I'm wrong.
I checked NewGRF documentation and I found interesting information.
Variable Consist cargo (42) available in VarAction2 contains four subvariables. One of interesting data is the result of OR-ing custom bits from all vehicles in the train (in NML: bitmask_consist_info). But this variable can be read in two modes - 81 (vehicle) and 82 (engine).
If I good understand, NML variable bitmask_consist_info with PARENT scope returns bitmask for whole train, but the same variable witch SELF scope returns bitmask info for current vehicle only? Is it something like reading bitmask_vehicle_info, which is write-only property?

It will be very usefull discovery for me. In some cases it can be easier to manage vehicle groups using vehicle custom bits instead of checking list of vehicle ids.

Code: Select all

switch(FEAT_TRAINS, SELF, switch_can_attach, hasbit(bitmask_consist_info, PASSENGER_COACH)) {
    1:  return CB_RESULT_ATTACH_ALLOW;
    return string(STR_YOU_CAN_ATTACH_ONLY_PASSENGER_COACHES);
}

[Eddi]

i don't think it works like this. i haven't read the specs, but i don't see how SELF would refer to the single vehicle. at best it would OR over all vehicles from this vehicle to the end of the chain.

[frosch]

Eddi is correct.

If used with VarAction2 type 81 (vehicle) it returns only cargo from this vehicle on, with type 82 (engine) that of the whole consist.

Using SELF scope gets the data for the consist starting at the current vehicle to the end.

[TadeuszD]

...at best it would OR over all vehicles from this vehicle to the end of the chain.

OK. But when you're attaching single wagon to the train in depot (see my example), these "all vehicles from this vehicle to the end of the chain" means exactly this single wagon. In practice it works.
Thanks, frosh, for complete explanation too.