bug in NFORenum ?

[Dante123]

part of the code:

Code: Select all

     //////** Randomizer: use as last Action 2 in the graphics chain before normal Action2 -> Action1 definitions **
//!!Error (53): Rand02s require power-of-two sets to choose from.
  835 * 19	 02 		// action 2
				04 		// 04 for stations
				15 		// just some random ID for this action
				80 		// Use 80 to randomize the object (vehicle, station, building, industry) based on its own triggers and bits.
				00 		// not used? thus 00 - 	(when present) Location of controlling vehicle. 
				10 		//** use bit 16 (0x10) for randomization per tile**
				06 		// nr of sets to pick from (power of 2)
				00 00 	// pick from set 00
				16 00	// pick from set 16
				26 00 	// pick from set 26
				36 00	// pick from set 36
				46 00 	// pick from set 46
				56 00	// pick from set 56

renum wants to have power of 2 numers like 2,4,8,...

but in this case of random picking from sets, the example as shown just works ingame without any form of errors.
seems like a bug in nfo renum ?

[Rubidium]

The specification says it must be a power of 2, so NFORenum is right.

Looking at OpenTTD's source code it's probably working somewhat. Although, with your 6 groups it will mask the random bit with 5, so only sets 00, 16, 46 and 56 should be the result of that randomizer.

[Dante123]

when testing in game, the randomizer picks from all the 6 defined sprites

[Rubidium]

I'm not sure what you are using, but with the big tank (pipe connect) from dwe_stat_r.grf V0.4 it is definitely showing only "sprites" 0, 1, 4 and 5. It might not be noticable though as sprite 2 and 5, and 3 and 0 are equal. So you will seemingly see all sprites if you match them from the spritesheet to those you see in OpenTTD. But... that's just an ambiguous mapping.

[Dante123]

I'm not sure what you are using, but with the big tank (pipe connect) from dwe_stat_r.grf V0.4 it is definitely showing only "sprites" 0, 1, 4 and 5. It might not be noticable though as sprite 2 and 5, and 3 and 0 are equal. So you will seemingly see all sprites if you match them from the spritesheet to those you see in OpenTTD. But... that's just an ambiguous mapping.

in dont think i fully understand.

if for example i make 12 spites, so 6 for NW and 6 for NE,

within these sprites i just number them 1 to 6,
im sure that when placing them with this random set, all the numbers will show up at random.

[Dante123]

wow, that i did not know
just made a test
and as you already sayed, the result is like this:


indeed the numbers 3 and 4 seems missing now.

and ofc now rises the question, how do i make it pick from all in this case ? should i use the random in a different way ?

attached are the test files

[Rubidium]

Just follow the specs/NFORenum error: make sure you have a "power of two"-number of different choices. You can have multiple choices link to the same graphics like "0 1 2 3 4 5 3 5". That are 8 choices with 6 graphics, but the chance 3 or 5 will show up is just twice as high.

[Dante123]

ok will do that,

makes me wonder, is it for openttd programming hard to add such a future so it will just support any number of sets where it will pick random from ? so also un-even number of sets ? or is such a thing not possible because of the way openttd works ? ( really have no clue on how openttd works on this terrain)

[frosch]

You are missing one part:
The number of cases in the random action 2 also defines the number of random bits to use. It is quite essential for the Grf to define exactly which bits to use, so it can randomize multiple things independently.

Of course OpenTTD could just round up 6 to the next major power of 2, i.e. 8. But then it would be up to OpenTTD to decide which cases to favour (actually this is done in action F for town names). Overall it is much more transparent to leave this step to the GRF, so you can decide which cases to favour.

If you want to make the probabilities for the 6 cases more equal, you need to use more random bits.
For example:
3 random bits -> 8 cases -> probabilities for 6 layouts: 4 times 1/8, 2 times 2/8
4 random bits -> 16 cases -> probabilities for 6 layouts: 4 times 3/16, 2 times 2/16
5 random bits -> 32 cases -> probabilities for 6 layouts: 4 times 5/32, 2 times 6/32

The more random bits you use the smaller is the difference between the probabilities. While 2/8 is double of 1/8, with 5 random bits 5/32 and 6/32 are already quite close.

[Eddi]

makes me wonder, is it for openttd programming hard to add such a future so it will just support any number of sets where it will pick random from ? so also un-even number of sets ? or is such a thing not possible because of the way openttd works ? ( really have no clue on how openttd works on this terrain)

it is actually scientifically really difficult to do this, you can reduce the bias by using an extraordinarily high amount of random bits, but openttd can't possibly do that, because they need to be stored somewhere.

basically for openttd terms that means it's impossible to do.

Addendum:
within a varaction 2, it's actually really easy to make a scaling towards "uneven" numbers within the grf. all you need is to mask the bits that you want to use (e.g. 3,4 or 5 in the above example), and then do a "modulo 6" on them, then you will get values between 0 and 5 that are as evenly spread out as possible.