NML - a Newgrf Meta Language

[Eddi]

actually, var 0C has a name: "current_callback", the "deprecated" part is that it is recommended to handle callbacks in the graphics block, instead of manually in a switch.

i hereby suggest syntax for procedures:

Code: Select all

CALL(switch_name)

for the programmer, this would then look like STORE/LOAD/etc.

this could automatically expand to NFO: ((var7E & 0) + var1C) to get the full 32-bit result

[Transportman]

What is the difference between the various error levels? I want to display a message like with FATAL when certain parameters* are set wrong, but I want to continue loading so that users can still change the parameters and solve it without too much problems. The ERROR level would be fine, but it doesn't give the big warning I want.

*The parameters set the availability of vehicles by changing the climates_available property, so changing during running games is relatively safe.

[Alberth]

Except normal users cannot change parameters of loaded newgrfs
(disable your developer rights to see what a user will see)

[planetmaker]

What is the difference between the various error levels? I want to display a message like with FATAL when certain parameters* are set wrong, but I want to continue loading so that users can still change the parameters and solve it without too much problems. The ERROR level would be fine, but it doesn't give the big warning I want.

*The parameters set the availability of vehicles by changing the climates_available property, so changing during running games is relatively safe.

That's not needed.

Either the person generates a new game. Then they can go back to the creation process and change parameters prior to map generation and re-generate the map. Once the map is created, no parameter can be changed. And you either error out and disable your grf which results in a red message to pop up. Or you issue an error which the user will see in the grf config.

[Wahazar]

I created forest replacement newgrf. I did not specified its name, therefore it inherited it from original forest name.
It works fine without another industry newgrf, but if other industry is loaded, there are two different industry with same name.
For a special reasons, I need to have both, but without name disambiguation.
Is it possible (without complicated "if grf status" chains) to keep original industry name without other industry set and change it if other industry sets are present?

[planetmaker]

I created forest replacement newgrf. I did not specified its name, therefore it inherited it from original forest name.
It works fine without another industry newgrf, but if other industry is loaded, there are two different industry with same name.
For a special reasons, I need to have both, but without name disambiguation.
Is it possible (without complicated "if grf status" chains) to keep original industry name without other industry set and change it if other industry sets are present?

No. You would need to check for each grf you want to be compatible with explicitly.

[Wahazar]

Is it possible to make transparent overlay on sloped ground?
I want to draw dirty tack as part of industry, on sloped grass tile:

Code: Select all

spritelayout logging_camp_slope_road_13_tile_layout {  
 ground { sprite: GROUNDSPRITE_NORMAL; } 
childsprite {  
 		sprite: logging_camp_slope_road_13_sprite ; 
 		always_draw: 1; 
 	} 
} 

tile_check CB is set to appropriate slope and works fine, but I see no difference if autoslope CB is set to CB_RESULT_AUTOSLOPE or CB_RESULT_NO_AUTOSLOPE - in both cases I have "steps": flat tiles with foundations.
If foundations CB is set to NO, tile and road is sloped, but weird glitches appears (smudges from nearby sprites) if screen is zoomed or moved.

EDIT: I just realised, that GROUNDSPRITE_NORMAL is valid for flat sprites only,
sprite: slope_to_sprite_offset(SLOPE_XX) + GROUNDSPRITE_NORMAL; solved the problem.

[Wahazar]

I want to change productivity and simultaneously store flag to register:

Code: Select all

switch(FEAT_INDUSTRIES, SELF, industry_steel_mill_acceptance_switch_off, 
(((waiting_cargo_1 > 2700) ? STORE_PERM(0,0x01) : waiting_cargo_1) * 
 ((waiting_cargo_2 > 1700) ? STORE_PERM(0,0x02) : waiting_cargo_2)
)
) {
 0 : return industry_steel_mill_production_wait;  //one of waiting cargo == 0   
return industry_steel_mill_production_full;       // both waiting cargo > 0
} 

where returned are produce blocks, both registers have value 1 initialised.
Something is going wrong, seems that these waiting_cargo_x interfere each other,
For example, if first line is commented, and first cargo is delivered, 0x02 register is zeroed if FIRST cargo is above 1700.
Here is example with first cargo neglected:

Code: Select all

switch(FEAT_INDUSTRIES, SELF, industry_steel_mill_acceptance_switch_off, 
 ((waiting_cargo_2 > 1700) ? STORE_PERM(0,0x02) : waiting_cargo_2)
) {
 0 : return industry_steel_mill_production_wait;  //one of waiting cargo == 0   
return industry_steel_mill_production_full;       // both waiting cargo > 0
} 

second cargo waiting is 0, but first cargo waiting is triggering STORE_PERM - why?

[Transportman]

Does it also happen the other way around (cargo 2 triggers storage you associate with 1)?

Also, are you sure you need > here and not <? I don't know the purpose of what you're coding, but based on the switch you posted I would have expected the other symbol.

[Wahazar]

Does it also happen the other way around (cargo 2 triggers storage you associate with 1)?

Yes, if I have

Code: Select all

switch(FEAT_INDUSTRIES, SELF, industry_steel_mill_acceptance_switch_off, 
(((waiting_cargo_1 > 1600) ? STORE_PERM(0,0x01) : waiting_cargo_1) )) {...

first registry will be zeroed if coal is delivered, however coal is a second cargo:

Code: Select all

accept_cargo_types:             [cargotype("IORE"),cargotype("COAL")];

Also, are you sure you need > here and not <? I don't know the purpose of what you're coding, but based on the switch you posted I would have expected the other symbol.

It is OK, initially both registers have value 1 (set by build_prod_change) and are zeroded if there is huge stockpile, to control industry tile cargo_amount_accept switch.
BTW, waiting_cargo_x works fine for industry tiles, whereas for industry, it looks like disambiguation.

Whole code is available here:
https://dev.openttdcoop.org/projects/ma ... ition.pnml
line 191, permanent register values are observed via extra text switch.

[Transportman]

Strange, maybe you can check other industry sets, if they use waiting_cargo_x and what the expected result should be and what happens in game. Because I'm surprised a bug like this to stick around with multiple industry sets being made*.

*Not saying it cannot happen, I encountered a bug with vehicles that seems to have been around for 4 years without noticing.

[frosch]

I think you are implying too much magic with using STORE_PERM conditionally inside ? :

Without checking details, I would claim that NML does not short-circuit logical expressions; they are always evaluated as a whole, and thus your conditional storing does not work.

Use separate switches instead.

[Transportman]

Use separate switches instead.

Or an array of expressions instead of one big expression:

Code: Select all

switch(FEAT_INDUSTRIES, SELF, industry_steel_mill_acceptance_switch_off, 
[waiting_cargo_1 > 2700 ? STORE_PERM(0,0x01) : STORE_PERM(1,0x01),
 waiting_cargo_2 > 1700 ? STORE_PERM(0,0x02) : STORE_PERM(1,0x02),
 LOAD_PERM(0x01) && LOAD_PERM(0x02)]
)

[Wahazar]

maybe you can check other industry sets, if they use waiting_cargo_x

I don't recognise any industry set, which is using NML and waiting_cargo_x. ECS is written in pure NFO. FIRS is using cargo delivered data (cargo is consumed instantaneously).

I would claim that NML does not short-circuit logical expressions

Maybe it is an explanation. And these expression arrays looks much more clear than my "jenga" condition statements style

[Transportman]

And these expression arrays looks much more clear than my "jenga" condition statements style

They might look more clear, but when they are not working, they are kind of useless. And I don't know if they are working as I'm not doing industry sets, but if they work (or not), a short post would be nice.

[Wahazar]

How often cargo_output switch is called?
I tried to implement such switch to cycle output cargoes, but seems that it is called only once when industry is founded.

[PikkaBird]

How often cargo_output switch is called?
I tried to implement such switch to cycle output cargoes, but seems that it is called only once when industry is founded.

That is callback 14C. It is, indeed, called only when the industry is founded. There is no workaround for the 3-in 2-out cargo limitation for industries.

[Wahazar]

cargo_classes variable: class of the currently transported cargo

- is it a bitmask of classes of the cargo to which the given vehicle is refitted?
I tried to make switch depending on cargo_classes variable, but It fails:

Code: Select all

switch(FEAT_ROADVEHS, SELF, refit_LCV_valu_check_graphic_switch, cargo_classes & CC_ARMOURED) {  
	0: return good_amount_spriteset_LCV_graphic_switch; 
	return valu_spriteset_LCV_graphic;  
}  
switch(FEAT_ROADVEHS, SELF, refit_LCV_mail_check_graphic_switch, cargo_classes & CC_MAIL) {  
	0: return  refit_LCV_valu_check_graphic_switch; 
	return mail_spriteset_LCV_graphic;  
}  

where refit_LCV_mail_check_graphic_switch is called as default,
but it gives me armoured sprite if refitted to mail, and goods sprite if refitted to armoured or goods.
Any idea what I've messed up?

[PikkaBird]

Any idea what I've messed up?

I don't see anything obvious, unless you've got your sprite sheets wrong.

[Wahazar]

Sprites are correctly set, cargo_type_in_veh switch works fine.