Check soldier names for duplicates

[Snickerdoodle]

When hiring new soldiers, it would be nice if the generated names were checked against the list of already hired soldiers. I have just 25 soldiers, and 4 pairs have identical names. 

It's not a big deal to change the names manually, but it's annoying, and it feels lke I live in a world of twins and inbreeding. 

It's also a little strange to hire the same name as the one I just sacked, but I realize that's unavoidable.

[kkmic]

Nice catch.

I think this is pretty easy to fix, but with the 1.0 7pretty close, I'm not sure it will make it until then. Warboy?

Why don't you fill a bug report on the bug tracker? That way it won't be forgotten by accident.

[Snickerdoodle]

I've filed a feature request, because it's not really a bug, and I don't know how hard it is to reproduce.

Anyone else have this problem?

[yrizoud]

I saw once that I had twice the same soldier. They were total clones : Same name, identical stats. A glitch in the matrix, I guess.

[Snickerdoodle]

Okay, this is getting weird. Not only are the names duplicated, but they're grouped, and in the same order.

[yrizoud]

Check if the twins have the same stats.

[kkmic]

I saw once that I had twice the same soldier. They were total clones : Same name, identical stats. A glitch in the matrix, I guess.

Most likely

[Snickerdoodle]

Check if the twins have the same stats.

They have the exact same original stats. Which means, in effect, that I can recognize good and bad soldiers from their names.

That is not good.

[SupSuper]

I ran a quick test and out of 1000 generated soldiers, only 5 were duplicate. So at least it doesn't look like anything wrong with the PRNG, but anything like modding the name lists or using save scumming options could bias it, so I'll add a duplicate check just in case.

I saw once that I had twice the same soldier. They were total clones : Same name, identical stats. A glitch in the matrix, I guess.

That's a side-effect of pseudo-random-number-generators. The same seed will produce the same sequence of numbers. So if you happen to get the exact same seed twice (which is pretty unlikely but not impossible), then all the soldier stats will be the same.

They have the exact same original stats. Which means, in effect, that I can recognize good and bad soldiers from their names.

That is not good.

Yes? You can also do it by just looking at their soldier stats.

[Snickerdoodle]

That's a side-effect of pseudo-random-number-generators. The same seed will produce the same sequence of numbers. So if you happen to get the exact same seed twice (which is pretty unlikely but not impossible), then all the soldier stats will be the same.

As long as it doesn't stray into a Minecraft-like procedural generation type game it shouldn't matter. Minecraft needs to be procedurally generated, OpenXcom needs to be surprisingly random.

Yes? You can also do it by just looking at their soldier stats.

Of course, but not all soldier stats are available early in the game, like the psi stats. I don't want to recognize the strength and weaknesses of individual soldiers right off the bat, just because I've seen his/her name before. It takes away some of the replay value. The unknown and unexpected is a major point of this game.

My $0.02

[yrizoud]

I ran a quick test and out of 1000 generated soldiers, only 5 were duplicate.

There are only 484 different male Arabian names, for example, so it would be normal to get name dplicates sometimes.

But here we have a much bigger issue : in order to get total clones, the identical data has to be :
Nationality (5 bits), gender (1 bit), first name (~5 bits), last name (~5 bits), looks (~2bits), stats (50 bits).
This is overall 68 bits of information that need to be the same. 1 chance out of 3e20. It is much more likely that there was an accidental reseeding (or bad reseeding) of the RNG, that made it enter the exact same sequence of numbers several times in the same game.

I looked at the code and I can't see an evident error (like storing a seed in a short int)...

[Snickerdoodle]

The comments for git_2014_04_26_2314 says "Avoid duplicate soldier names", but that doesn't apply for soldiers in transit.

I recruited 3 soldiers in 3 different hirings within the same hour, and 2 were identical clones. For silly reasons, I hired a soldier, saved, loaded the same game, hired another soldier, saved in the same slot, reloaded the same game again, and hired a third soldier. Number 2 and 3 were clones.

I starting to wonder if the "clone" issue might be a bigger problem than just the confusion with identical names.

[yrizoud]

Ok there IS a problem with either getSeed() or setSeed() : Here's a test program :

Code: [Select]

#include "RNG.h"
#include <stdio.h>

int main(int argc, char** argv)
{
  OpenXcom::RNG::setSeed(1000);
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("------------\n");
  OpenXcom::RNG::setSeed(1000);
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  OpenXcom::RNG::setSeed(OpenXcom::RNG::getSeed());
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
  printf("%d\n", OpenXcom::RNG::generate(0,99999));
 
  return 0;
}
This is supposed to produce 2 times the same series of 6 numbers.
But on the second run, I reseed with the current seed for the last 3 numbers, and the series change :
83691
89364
16020
9142
34131
54983
------------
83691
89364
16020
83691
89364
16020

So in OpenXCOM, when Save scumming is OFF (which is the default), saving and reloading does NOT restore exactly the right random numbers.

edit: gahh! Can't believe I didn't see it before : getSeed() returns the original seed (ie 1000 in my case) In order to actually save and restore the RNG state, the entire mt[] array should be stored in the save game, ie 2496 byte

re-edit Filed a bug for the developers : https://openxcom.org/bugs/openxcom/issues/562

[Snickerdoodle]

edit: gahh! Can't believe I didn't see it before : getSeed() returns the original seed (ie 1000 in my case) In order to actually save and restore the RNG state, the entire mt[] array should be stored in the save game, ie 2496 byte

Perhaps a more save-friendly RNG could be used?

The following 64-bit generator with 64 bits of state has a maximal period of 2⁶⁴ − 1 and fails only the MatrixRank test of BigCrush:

Code: [Select]

#include <stdint.h>
 
uint64_t x; /* The state must be seeded with a nonzero value. */
 
uint64_t next() {
x ^= x >> 12; https:// a
x ^= x << 25; https:// b
x ^= x >> 27; https:// c
return x * 2685821657736338717LL;
}

from https://en.wikipedia.org/wiki/Xorshift#Variations

[SupSuper]

Ok I've replaced the RNG and corrected the duplicate checks so this should hopefully be fixed.