random_switch not working as expected

[ebla71]

In an industry NewGRW, I have one incoming cargo and I want to produce one (and only one) outgoing cargo out of a selection of three at each delivery.

My example is a recycling depot which receives RFPR and should either produce PAPR, POLY, or FERT selected at random - with a new selection for each turn.

However, the following code compiles correctly with the latest nmlc version but does not give the desired result, as only one cargo is produced - any ideas of what's wrong with it? Unfortunately, seems like there are not many code examples around and this was adapted directly from the documentation.

My expectation would be that in two out of four deliveries, POLY would be produced and in 1/4 of each deliveries, either FERT or PAPR.

Code: Select all

produce(recycling_yard_produce_3,
		[RFPR: LOAD_TEMP(1);],  // consume
		[FERT: LOAD_TEMP(1);], 	// produce
		0                       // don't run
)

produce(recycling_yard_produce_2,
		[RFPR: LOAD_TEMP(1);],  // consume
		[POLY: LOAD_TEMP(1);], 	// produce
		0                       // don't run
)

produce(recycling_yard_produce_1,
	 [RFPR: LOAD_TEMP(1);],   // consume
	 [PAPR: LOAD_TEMP(1);], 	// produce
	 0                        // don't run
)

random_switch(FEAT_INDUSTRIES, SELF, produce_recycling_yard_2) {
 	1: recycling_yard_produce_1;
 	2: recycling_yard_produce_2;
 	1: recycling_yard_produce_3;
 }

switch(FEAT_INDUSTRIES, SELF, produce_recycling_yard_1, [
	 STORE_TEMP(incoming_cargo_waiting("RFPR"), 1),
])
{
	 produce_recycling_yard_2;
}

switch(FEAT_INDUSTRIES, SELF, produce_recycling_yard_0, incoming_cargo_waiting("RFPR") < 1)
{
	 1: produce_none;
	 produce_recycling_yard_1;
}

[peter1138]

Where are you telling it to trigger re-randomisation?

[ebla71]

Where are you telling it to trigger re-randomisation?

That's exactly my problem - I don't know how to do that in my particular case based on the examples in the documentation.

In the code example at the bottom of the above page, it is suggested that the "random_trigger" callback is used for that with the events in the bitmask, but everything I tried was not allowed for FEAT_INDUSTRIES and the example is for FEAT_TRAINS

produce_recycling_yard_0 is called from produce_256_ticks in the graphics block further down that I did not show because it does not seem to be related to the issue.

[PikkaBird]

As the documentation you linked notes, industries can only be rerandomised by their tiles, so you'll have to have [at least one of] the tiles rerandomise the bits for the industry, probably on TRIGGER_INDUSTRYTILE_256_TICKS.

Alternatively, why not just eat 3 RFPR and produce one of each of the outgoing cargos every time?

[ebla71]

As the documentation you linked notes, industries can only be rerandomised by their tiles, so you'll have to have [at least one of] the tiles rerandomise the bits for the industry, probably on TRIGGER_INDUSTRYTILE_256_TICKS.

That will be easy, since the planned set will inherit from OTIS the idea of using just one single (and simple) tile for the industries that can then be covered by "eyecandy" overlaps.

So the TRIGGER_... should go in the item(FEAT_INDUSTRYTILES, ...) block - or some of the switch blocks that are usually called from there?!?

Alternatively, why not just eat 3 RFPR and produce one of each of the outgoing cargos every time?

Because I thought it would be more interesting if things are not that predictable

[OzTrans]

So the TRIGGER_... should go in the item(FEAT_INDUSTRYTILES, ...) block ...

From what I know about industries ... for what you try to do, you should use the Production Callback. There you can request random bits in var 0x10, randomised when the callback is triggered. They are randomised on trigger, but remain the same on additional iterations of the callback.

[PikkaBird]

Well that's well-buried in the spec. Presumably it's the random_bits var in NML.

[peter1138]

It'll be var10 (extra_callback_info1). the random_bits var is the same as what random switches use.

[peter1138]

That will be easy, since the planned set will inherit from OTIS the idea of using just one single (and simple) tile for the industries that can then be covered by "eyecandy" overlaps.

Sad, this is a bad way to do things.

[ebla71]

That will be easy, since the planned set will inherit from OTIS the idea of using just one single (and simple) tile for the industries that can then be covered by "eyecandy" overlaps.

Sad, this is a bad way to do things.

Why?

I'm not a good graphics artist, to put it mildly, and like to fine-tune the look-and-feel of my industries myself in a running game ...

Plus many of the industries in popular sets are too large for the kind of maps I like to play ...

[OzTrans]

Well that's well-buried in the spec. ...

Not for NFO Coders ... the specifications : Industry Production Callback.

[PikkaBird]

Not for NFO Coders ...

Yes, it is. It's a little note in a section called "details", at the very the bottom of the action 2 page, and a "Special industry flags" bitflag hidden among miscellanea. Not an easy thing to find, unless you already know what you're looking for.