Upgrading from a version prior to 0.7.3 changes specific use cases using vehicle random_bits

[heresyh]

Hello,

I recently upgraded from 0.7.1 to 0.7.5, and when I re-compiled a GRF (Mop's Expanded Road Vehicles) I noticed that some vehicles in-game had broken sprites.
I narrowed it down to this change, #288, after reading through the changelogs and testing different versions/commits.

This is due to how the original code is in deciding between different spritesets, f.ex:

switch (FEAT_ROADVEHS, SELF, switch_w_l_f_flat_e, random_bits ) {
    0..63:         spriteset_w_l_f_flat_e;
    64..127:       spriteset_w_l_f_flat_f;
    128..191:       spriteset_w_l_f_flat_g;
    192..255:       spriteset_w_l_f_flat_h;
}

As there is no default value or specific range defined there is no valid choice when the random value is between 256-65535.

I don't know if any other GRFs have the same issue, or if this is a very specific issue to how this GRF was written.
However, I do think it would be nice to have this show up as a warning in the nmlc output, if possible, so that its easier to catch if this is a problem in their code.

It also changes the probability between choices in cases like this, where it will now heavily favour the default value when compiled with a newer version of NML:

switch (FEAT_ROADVEHS, SELF, switch_o_box_b, random_bits ) {
        0..69: spritegroup_o_box_a;
        70..139: spritegroup_o_box_b;
        140..209: spritegroup_o_box_c;
        210..255: spritegroup_o_box_d;
        default: spritegroup_o_box_b;       
}

However, that is less of an issue, as it at least does have a default value to fall back to, even though it might lead to an unknown/unwanted change in behaviour for other GRFs, if they have implemented logic like this, and they are unaware of the random bits change.

[PeterN]

You should mask random_bits to the number of bits you need. random_bits & 0xFF

[WenSimEHRP]

A neater solution is to use a random switch instead of a switch

[heresyh]

You should mask random_bits to the number of bits you need. random_bits & 0xFF

Already changed things in my own fork, issue is more about lack of information about what might be wrong if someone updates to a newer NML version and things silently breaks or changes without any warnings or pointers to what is the cause.

I don't know if any other GRFs actually have coded in randomisation the same way it was done here by the original author, but I figured I'd make an issue about it at least, in case someone else stumbles upon the same.