SoldierName look control

[Phezzan]

Hi all.

I've been tweaking.  One thing bothering me is the evenly random distribution of appearance regardless of nationality.

So I added an optional 'look' array in SoldierName files.

Code: [Select]

maleFirst:
... https:// skipped a bunch
maleLast:
... https:// skipped a bunch
  - Svensson
  - Lindgren
look:
  - 0
  - 0
  - 0
  - 0
  - 0
  - 1
  - 1
  - 1
  - 2

The net result is decent control over Soldier Appearance.
If I can figure out git diffs I'll post a patch after I sleep.

Phez

[54x]

...I just did the same thing on Sunday. ><

[Phezzan]

...I just did the same thing on Sunday. ><

Wow I love open source.

[Volutar]

Making no outlook labeling would lead to mess at some point, even if everyone would be very cariful with outlook ordering. In opensource project that's 100% possible.

[Phezzan]

I have no idea what you're trying to say ... perhaps you mean 'mapping numbers in files to the enumerated in-game appearance is likely to desync when someone adds more appearance sprites'
To that I can only say, it's a very minor problem IMHO, and I look forward to having a reason to solve it.

OTOH, I imagine what 54x is working on will be a lot more thorough. (I've skimmed the thread) so I'm looking forward to replacing my change with his.

[Volutar]

You got me right. Labeling of outlook will help to avoid enum desync.

Code: [Select]

look:
  - type: white
    chance: 10
  - type: darkhair
    chance: 25
  - type: asian
    chance: 75
Chances are normalized after checking IF there are actual look sprites. It is possible that someone will add "advanced" namesets, but forget to add appropreate sprites.
Every "common" user-f*ckup should be considered.

[54x]

I have no idea what you're trying to say ... perhaps you mean 'mapping numbers in files to the enumerated in-game appearance is likely to desync when someone adds more appearance sprites'
To that I can only say, it's a very minor problem IMHO, and I look forward to having a reason to solve it.

OTOH, I imagine what 54x is working on will be a lot more thorough. (I've skimmed the thread) so I'm looking forward to replacing my change with his.

My implementation had a fallback default weight when the number of weights in the .nam file is different to the number of maximum looks. (which is passed into the function when it's called)

You got me right. Labeling of outlook will help to avoid enum desync.

Code: [Select]

look:
  - type: white
    chance: 10
  - type: darkhair
    chance: 25
  - type: asian
    chance: 75
Chances are normalized after checking IF there are actual look sprites. It is possible that someone will add "advanced" namesets, but forget to add appropreate sprites.
Every "common" user-f*ckup should be considered.

Yep, I believe my code currently considers the possibility of having more looks in the .nam file than in the ruleset, but I'll have to check that. If it doesn't, I'll add that before I PR. I believe the intention was just to ignore any extra lines beyond the number of coded looks.