Page 45 of 65

Re: NML - a Newgrf Meta Language

Posted: 09 Nov 2014 17:59
by Transportman
Why don't you do it like I did in the 2cc Trainset? Sounds like what you want to have and is only one switch-block.

Code: Select all

//Graphics for the unit wagon based on cargo class
switch(FEAT_TRAINS, SELF, switch_emu_Australia_CityRail_OSCars_cargo_selection, cargo_classes){
	bitmask(CC_PASSENGERS): spriteset_emu_Australia_CityRail_OSCars_middlepass;
	spriteset_emu_Australia_CityRail_OSCars_middlemail;
}
Keep in mind that that cargoes can have multiple classes.

Re: NML - a Newgrf Meta Language

Posted: 10 Nov 2014 10:56
by Eddi
McZapkie wrote:

Code: Select all

cargo_classes & CC_ARMOURED
this must be "cargo_classes & bitmask(CC_ARMOURED)" (but there are probably better ways to express this with hasbit)

Re: NML - a Newgrf Meta Language

Posted: 13 Nov 2014 09:00
by Wahazar
I got following nmlc error:
no unique free parameters available to use for internal computations
during compiling newgrf with recolouring scheme defined by #macros.

What is a real meaning of such error?

Re: NML - a Newgrf Meta Language

Posted: 13 Nov 2014 09:03
by planetmaker
McZapkie wrote:I got following nmlc error:
no unique free parameters available to use for internal computations
during compiling newgrf with recolouring scheme defined by #macros.

What is a real meaning of such error?
The meaning is "you want too much at once. This amount of choice in a single decision tree cannot be done within the NewGRF specs." Solution: offer fewer recolouring options, remove redundant choices, use a macro which expands to fewer choices.

Re: NML - a Newgrf Meta Language

Posted: 13 Nov 2014 09:29
by Eddi
in particular, you might want to combine multiple reserve-blocks into one, so not each of them needs a new parameter to store its sprite ID.

Re: NML - a Newgrf Meta Language

Posted: 13 Nov 2014 18:01
by Wahazar
Eddi wrote:in particular, you might want to combine multiple reserve-blocks into one, so not each of them needs a new parameter to store its sprite ID.
Exactly it was an error reason. I combined these block to:

Code: Select all

palette_##pname##_bulk = reserve_sprites(14); \
replace(palette_##pname##_bulk) { \
recolour_sprite { \
P0_COAL \
pname \
        } \
recolour_sprite { \
P1_GRAI \
pname \
        } \
recolour_sprite { \
P2_IORE \
pname \
        } \
...}
with call:

Code: Select all

COAL: return palette_##pname##_bulk; \
GRAI: return palette_##pname##_bulk + 1; \
...
and all now works fine, thanks.

Re: NML - a Newgrf Meta Language

Posted: 14 Nov 2014 07:16
by Hyronymus
Are roads programmable yet with NML? In the shortlist in the first topic I see railtypes mentioned as supported and roadtypes not mentioned as unsupported.

Re: NML - a Newgrf Meta Language

Posted: 14 Nov 2014 07:26
by planetmaker
Hyronymus wrote:Are roads programmable yet with NML? In the shortlist in the first topic I see railtypes mentioned as supported and roadtypes not mentioned as unsupported.
There are no roadtypes in NewGRF specs in general.

Of course you can replace the default road and tram sprites like you can replace any default sprite.

Re: NML - a Newgrf Meta Language

Posted: 14 Nov 2014 07:51
by Hyronymus
planetmaker wrote:
Hyronymus wrote:Are roads programmable yet with NML? In the shortlist in the first topic I see railtypes mentioned as supported and roadtypes not mentioned as unsupported.
There are no roadtypes in NewGRF specs in general.

Of course you can replace the default road and tram sprites like you can replace any default sprite.
OK, thanks for your reply.

YETI - problem with placing industries

Posted: 22 Nov 2014 01:16
by Sylf
In YETI, I've been having this problem.

One of the industries defined in it is clay pit. When I try to fund any industry near a clay pit, openttd says "Can't construct this industry type here... too closo to another industry" This does not happen around any other industries. Clay pit does not have conflicting_ind_types set. Neither do any other industries.

When I try to fund a clay pit near any other industries, it always succeed though.

Can anyone think why this might be?

Re: YETI - problem with placing industries

Posted: 22 Nov 2014 08:47
by planetmaker
Sylf wrote:In YETI, I've been having this problem.

One of the industries defined in it is clay pit. When I try to fund any industry near a clay pit, openttd says "Can't construct this industry type here... too closo to another industry" This does not happen around any other industries. Clay pit does not have conflicting_ind_types set. Neither do any other industries.

When I try to fund a clay pit near any other industries, it always succeed though.

Can anyone think why this might be?
Do you override an existing industry which has that property set by default? If so, you explicitly have to set the conflicting_ind_types property to 0 (or an empty array).

Re: NML - a Newgrf Meta Language

Posted: 22 Nov 2014 14:25
by Sylf
I've tried adding conflicting_ind_types for clay pit's property, but that didn't work before.

Now, I tried adding that (still an empty array) to other industries, and lo and behold, it works!

The code had disable_items(FEAT_INDUSTRIES) at very top of the code after grf{} block, but that must not have been good enough.

Re: NML - a Newgrf Meta Language

Posted: 22 Nov 2014 14:27
by Alberth
I am quite noob-ish here, but afaik "disable_items(FEAT_INDUSTRIES)" just stops the default industries from appearing. New industries are still copied from the default ones, with all their properties.

Re: NML - a Newgrf Meta Language

Posted: 22 Nov 2014 15:01
by Digitalfox
Alberth wrote:I am quite noob-ish here, but afaik "disable_items(FEAT_INDUSTRIES)" just stops the default industries from appearing. New industries are still copied from the default ones, with all their properties.
noob-ish I am as well, but you are correct :)

I had in my case to use conflicting_ind_types property to 0 as mentioned by planetmaker!

Re: NML - a Newgrf Meta Language

Posted: 12 Dec 2014 11:14
by Wahazar
I'm using callback to change mass, power and speed (after consist changed by refit), but
Units are not (yet) available
.
I found that I must multiply mass by 4, similar to speed (it depend on vehicle type), how power is scaled internally?
I have power in kW and seems that internally unit is 0.01 hp.

Re: NML - a Newgrf Meta Language

Posted: 12 Dec 2014 13:50
by planetmaker
McZapkie wrote:I'm using callback to change mass, power and speed (after consist changed by refit), but
Units are not (yet) available
.
I found that I must multiply mass by 4, similar to speed (it depend on vehicle type), how power is scaled internally?
I have power in kW and seems that internally unit is 0.01 hp.
No units means it uses "nfo units". Thus the description from the nfo grfspecs applies. The actual scaling depends on which vehicle type you deal with:
nfo units for
train: horse powers
road vehicles: 10 horse powers

Re: NML - a Newgrf Meta Language

Posted: 12 Dec 2014 23:13
by Wahazar
Rather 1 hp = 10 units?

Another question - have nml any access to openttd configuration parameters?

Re: NML - a Newgrf Meta Language

Posted: 13 Dec 2014 02:23
by Eddi
not all of them, but some are exposed via TTDPatchFlags

Re: NML - a Newgrf Meta Language

Posted: 13 Dec 2014 14:32
by Wahazar
Is it possible to check "vehicle_breakdowns" setting from NML level?

Re: NML - a Newgrf Meta Language

Posted: 13 Dec 2014 15:57
by planetmaker
http://newgrf-specs.tt-wiki.net/wiki/NM ... _variables has the general settings listed which are exposed

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