Not enough random bits for the town name generation (34 needed, 32 available)

[Altitud49]

Hi, I've tried compiling MinchinWeb's Random Town Name Generator from source and while it seemed like the "not enough random bits for town name generation" issue had been fixed in #185, I get this error using the latest release.

[glx22]

I tried with 0.5.0 and it builds (but won't work as intended because #116). I tried with 0.5.1 and it fails with nmlc ERROR: ".\MinchinWebs_Random_Town_Names.1.1.nml", line 529: Not enough random bits for the town name generation (38 needed, 32 available) (#117 effect) I confirm 0.7.1 fails with nmlc ERROR: ".\MinchinWebs_Random_Town_Names.1.1.nml", line 3027: Not enough random bits for the town name generation (34 needed, 32 available) but I think it's probably not an nmlc bug. @MinchinWeb might know better than me.

[MinchinWeb]

Well, it is delightful to see that my code and townnames are still helpful!

(The code is also now on GitHub: https://github.com/MinchinWeb/openttd-minchinweb/tree/master/Names-Random )

As for the lack of (enough) random bits, that has to have been a change on the NML side since ca 2011 (the last time I pushed a release). What I can say is that my townname code was designed explicitly to use the entire available bit space. Not that it generates 2^32 names (I think it produces ~2 million town names), but it uses that bit space to control the relative frequency of prefixes, roots, and suffixes (i.e. so some names are more likely to appear, and the "bare" name is more likely that one with a prefix or suffix). I actually used a spreadsheet to ensure I was using the whole space! (Said spreadsheet is with the source code.)

So I guess the question becomes: is the additional 2 random bits being used somewhere by NML (that it didn't used to) a bug, or necessary to manage the resonance issue (#116)? Because nothing has changed with my code, and it did used to compile without complaint.

P.S. You're welcome to use my code as a test case for NML, if you want.

[MinchinWeb]

P.P.S. I don't think the Resonance Issue (#116) affected this townname set, as the various sub-lists had different lengths.

[glx22]

The error happens for:

town_names(PATH_A_1) {
//  English Male Prenames
    {
    text("", 15),
    town_names(GROUP_01_1_WATER, 1)
    }
    {
    town_names(GROUP_03,1),
    }
    {
    town_names(GROUP_04,1),
    }
    {
    text("", 7),
    town_names(GROUP_90_1, 1),
    }
}

First part needs 4 bits and uses GROUP_01_1_WATER which needs 7 bits Second part needs 1 bit and uses GROUP_03 which needs 4 bits and uses GROUP_03_1 which needs 3 bits Third part needs 1 bit and uses GROUP_04 which needs 6 bits Last part needs 3 bits and uses GROUP_90_1 which needs 10 bits

With 0.5.0: GROUP_01_1_WATER is assigned bits 0-6 (7 bits) GROUP_03_1 is assigned bits 0-2 (3 bits) so GROUP_03 is assigned bits 3-6 (4 bits) GROUP_04 is assigned bits 0-5 (6 bits) GROUP_90_1 is assigned bits 0-9 (10 bits) The first available bit is bit 10. First part is assigned bits 10-13 (4 bits) Second part is assigned bit 14 (1 bit) Third part is assigned bit 15 (1 bit) Last part is assigned bit 16-19 (3 bits)

All referenced groups share the same bits, which means they are interdependent. It's less visible than in #116 as the lists have different length, but a GROUP_04 result will always be associated with the two same GROUP_01_1_WATER results (if I correctly remember how the selection works)

With 0.7.1: GROUP_01_1_WATER is assigned bits 0-6 (7 bits) GROUP_03_1 is assigned bits 0-2 (3 bits) so GROUP_03 is assigned bits 7-10 (4 bits) (and there's a bug as GROUP_03_1 has not been reassigned) GROUP_04 is assigned bits 11-16 (6 bits) GROUP_90_1 is assigned bits 17-26 (10 bits) The first available bit is bit 27. First part is assigned bits 27-30 (4 bits) Second part is assigned bit 31 (1 bit) (only one choice so bit 31 will be reused) Third part is assigned bit 31 (1 bit) (only one choice so bit 31 will be reused) Last part is assigned bit 31-33 (3 bits) and it fails here because it's 2 bits over the total available

So for me nmlc is technically correct in how it assigns bits (if I exclude the missing reassignment ;) ), but that also means your nml can't be compiled with anything above 0.5.0.

[MinchinWeb]

Ugg.

This is just the first path that is used in the name generation (I think there's ~20), and they would all need to be reworked to reduce the number of bits used (i.e. not a small project).

Any chance more (random) bits could be assigned for townname generation? That would solve the particular issue. It's not that I'm trying to generation 2^32 names, but the bit space is helpful to control which names are more or less likely to show up. If I had a much larger space, I'd like to make a townname list including several provinces, or even all of Canada, but the current set up doesn't really let me go bigger than Alberta.