Apologies in advance for any misuse of terminology here...

Note: I am using PR #173 to build, but I don't think that affects this

When trying to pass a variable to a function which exists in the PARENT scope of the feature I'm calling from, I could only make it work by using a dummy switch in-between (or else it throws an error, due to being the wrong scope). This isn't a big deal, except it results in nmlc trying to "optimise" the switch (since it isn't doing anything except sending the variable), which results in the variable being apparently discarded and the callback failing to work properly.

I was able to work around this by making the dummy switch do some garbage operation (in this case store a value to a temp register) to prevent the "optimising" and make it work, but it seems like this shouldn't be necessary. Example below of what I'm doing:

switch (FEAT_INDUSTRYTILES, PARENT, switch_mineral_mine_prod_change_2, STORE_TEMP(0, 2)) {
	switch_primary_industry_prod_change(transported_last_month_pct("MNRL"));
}
item (FEAT_INDUSTRYTILES, mineral_mine_tiles_16) {
	property {
		substitute:          87;
//		override:            ?;
		accepted_cargos:     [[MAIL, 8]];
		land_shape_flags:    bitmask(LSF_ONLY_ON_FLAT_LAND, LSF_CANNOT_LOWER_NW_EDGE, LSF_CANNOT_LOWER_NE_EDGE, LSF_CANNOT_LOWER_SW_EDGE, LSF_CANNOT_LOWER_SE_EDGE);
	}
	graphics {
		default:             switch_mineral_mine_tiles_16_decide_ground_sprite;
		random_trigger:      switch_mineral_mine_prod_change_2;
		autoslope:           CB_RESULT_NO_AUTOSLOPE;
	}
}

Am I just doing this completely wrong? Is there a better way to do this without the use of a dummy switch? It's a bit hard to tell since there doesn't seem to be any obvious documentation on this feature, so I'm just taking shots in the dark here.

If this is "correct", it would seem that perhaps nmlc is being a bit overzealous with it's optimizations in this case, and that function calls should be ignored somehow. But I'd appreciate any advice to get me on the right track if not 🙂