No error when tram_type property is set without a tram typetable

[audigex]

If a tram is created with no tram_type property, OpenTTD will use the default ELRL. But if a tram_type property is set (even to ELRL) without a tramtypetable, OpenTTD does not default to ELRL

NML should throw an error in this scenario.

Possibly also around some similar "You've set tram_type but no ROADVEH_FLAG_TRAM" edge cases (and vice versa), if required, I generally found it a bit confusing to create a tram with no feedback when I was missing properties and multiple are required

[glx22]

Same applies to road_type without roadtypetable.

[glx22]

Ok, so I checked the code in nml source. It's worse than I imagined.

There are default tables (not included in the grf output): https://github.com/OpenTTD/nml/blob/master/nml/global_constants.py#L1431-L1441.

The properties are parsed (https://github.com/OpenTTD/nml/blob/master/nml/ast/item.py#L152-L153) using https://github.com/OpenTTD/nml/blob/master/nml/global_constants.py#L1470-L1487 so if you have identical labels in roadtypetable and tramtypetable but at different index then tram_type will actually use the index from roadtypetable, or even from cargotable if it's also a cargo label.

Note that labels are not shared between features, so the same label can be used for multiple items. For example, the label "RAIL" can be used for a railtype, roadtype, tramtype, and cargotype simultaneously without conflict. from the doc is just not true. Well, it's true in NFO spec, but clearly not when compiling an nml file with nmlc.

[glx22]

I think putting labels from tables into the global space (so you can use labels directly everywhere) was a mistake.
We should have forced authors to always use [cargo|rail|road|tram]type().