OpenXcom Forum

Contributions => Programming => Topic started by: Phezzan on June 23, 2013, 11:04:55 am

Title: SoldierName look control
Post by: Phezzan on June 23, 2013, 11:04:55 am: 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
Title: Re: SoldierName look control
Post by: 54x on June 23, 2013, 10:57:44 pm: ...I just did the same thing on Sunday. ><
Title: Re: SoldierName look control
Post by: Phezzan on June 24, 2013, 02:29:47 am: Quote from: 54x on June 23, 2013, 10:57:44 pm
...I just did the same thing on Sunday. ><

Wow I love open source.
Title: Re: SoldierName look control
Post by: Volutar on June 24, 2013, 05:01:10 am: 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.
Title: Re: SoldierName look control
Post by: Phezzan on June 24, 2013, 05:14:18 am: 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.
Title: Re: SoldierName look control
Post by: Volutar on June 24, 2013, 06:52:09 am: 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: 75Chances 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.
Title: Re: SoldierName look control
Post by: 54x on June 24, 2013, 11:37:25 am: Quote from: Phezzan on June 24, 2013, 05:14:18 am
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)

Quote from: Volutar on June 24, 2013, 06:52:09 am
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: 75Chances 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.