Findperson - New scenarios and some tests to give variation to the strings

[zonkmachine]

Addresses #6249 (Find person)

• Use different name forms in the risk messages for some variation. First name/Surname/Full name.
• Adds character roles. i.e. Instead of 'a family member', use cousin, step brother, uncle, etc.
• Adds more missions - 10 new scenarios (introtexts) for a total of 22.

---

The character roles are maybe a lot of lines but they are really easy to come up with and should be equally easy to translate.

• The name variations, if wanted, should probably be a member function in 'Character'. Too complex for now.
• They should be a separate file in data/lang/ much like the ships.
• The lists are currently inconsistent in that the employees and friends are in their indefinite form, but the realtives are in their base form. Maybe treat them fully like the ships with base, definitive, and indefinite forms?

[zonkmachine]

• Fix: Hyphenate brother in law/sister in law
• Character/Method - Instead of function randName in FindPerson.lua, create a member function in libs/Character.lua that returns one of name/surname/firstname. firstname is only an option if argument 'informal' is set to 'true'. The name returned is selected from the ascii value of the characters name.

[zonkmachine]

• Character/Method - Instead of function randName in FindPerson.lua, create a member function in libs/Character.lua that returns one of name/surname/firstname. firstname is only an option if argument 'informal' is set to 'true'. The name returned is selected from the ascii value of the characters name.

I removed these changes as it got too complicated. The change for variation is now a one liner. The name of {wanted} in the risk message is now hard coded to surname. This gives enough variation.

[zonkmachine]

• The name variations, if wanted, should probably be a member function in 'Character'.
• They should be a separate file in data/lang/ much like the ships.

I looked at putting roles, employee/friend/family, in a separate file but it just made it much more difficult to work with in the modules. Also, family and employee/friends and family, are different grammatically. This works for me now.

Code has been rebased on latest master.

[sturnclaw]

A few strings changes are required. Otherwise, this looks like a good expansion of the flavor available in this mission type.

[zonkmachine]

A few strings changes are required. Otherwise, this looks like a good expansion of the flavor available in this mission type.

Suggested changes committed and rebased on latest master.

[bszlrd]

Hmm, a stray idea for this, so I don't forget it later.
Maybe the mission giver could also show a photo of the person in question? Could even be shown in the mission details, instead of the mission giver.
(Yes, my mind is at the facegen again)

[sturnclaw]

I see the latest commit introduced a debug override for the number of missions. Are you wanting this PR to be merged soon, or is it still in-progress with more changes planned?

[zonkmachine]

I have been out of the loop for a while so I'm a bit rusty but I believe there is one thing in particular that should be discussed before merging.

The person roles employee/friend/relatives could be broken out into a separate file but I didn't find a nice/reasonable way to do this. I am happy with this solution too but some of the other scripts could benefit from more spiced up characters in the dialogue.

[sturnclaw]

I'd like to merge this PR if possible; enhancing the way various characters are represented sounds like a larger change to how multiple mission modules are handled? If so, I'd prefer that be tackled in a separate PR so we can ship improvements and bugfixes soon.

[zonkmachine]

@sturnclaw OK. In that case I'm cool with this. I'll give it a spin now to make sure there have been no regressions.

[zonkmachine]

Something definitely has happened... don't merge. 😬

False alarm. Very odd issues but it was not this PR and deleting the program files in $HOME and starting from fresh fixed it. This PR works well.

[zonkmachine]

Some changes. There are three groups represented here. Employees, friends, and family. Employees and friends have the same format. an engineer, an old friend. Family has only a word without an article, uncle.

  "EMPLOYEE_FEMALE_1": {
    "description": "",
    "message": "an engineer"
  },
  "EMPLOYEE_FEMALE_2": {
    "description": "",
    "message": "a scientist"
  },
...

  "FRIEND_FEMALE_1": {
    "description": "",
    "message": "a friend"
  },
  "FRIEND_FEMALE_2": {
    "description": "",
    "message": "an old friend"
  },
...

  "RELATIVE_FEMALE_1": {
    "description": "",
    "message": "aunt"
  },
  "RELATIVE_FEMALE_2": {
    "description": "",
    "message": "sister"
  },
  "RELATIVE_FEMALE_3": {
    "description": "cousin female",
    "message": "cousin"
  },

When using {relative} I have only done it as 'my {relative}'. This should probably be within the relative list "my grandmother", "my uncle", etc. to make it easier for translators. Also, the token should be renamed to indicate the possessive nature. RELATIVE_FEMALE_POS_1

  "RELATIVE_FEMALE_POS_1": {
    "description": "",
    "message": "my aunt"
  },
  "RELATIVE_FEMALE_POS_2": {
    "description": "",
    "message": "my sister"
  },
  "RELATIVE_FEMALE_POS_3": {
    "description": "cousin female",
    "message": "my cousin"
  },

[zonkmachine]

Squashed and rebased on current master. I also added the usual suspects, accountant and lawyer, to the employee role.

[zonkmachine]

  "EMPLOYEE_FEMALE_1": {
  "description": "Female professional or work-related contact. Substitutes {employee}. Indefinite form (a/an + noun).",
    "message": "an engineer"
  },
  "EMPLOYEE_FEMALE_10": {
  "description": "Female professional or work-related contact. Substitutes {employee}. Indefinite form (a/an + noun).",
    "message": "an accountant"
  },
  "EMPLOYEE_FEMALE_11": {
  "description": "Female professional or work-related contact. Substitutes {employee}. Indefinite form (a/an + noun).",

As I understand it, lexicographic order is the preferred way. Is it also acceptable to sort in natural order?

[zonkmachine]

Found a glitch and I want to take some time to solve the person roles more centrally to let other scripts benefit from them more easily.

[zonkmachine]

Fixed glitch in capitalization in mission description.

[zonkmachine]

... solve the person roles more centrally to let other scripts benefit from them more easily.

I had a stab at a central file for person roles as it could come in handy. Does this look about right?
Should it have it's own equivalent of getNumberOfFlavours? getNumberOfRoles? (Fixed!)

[zonkmachine]

Once more ready for review. NB. The last two commits now moves the person role lists to their own file. Maybe this should be somewhere else?

[zonkmachine]

I have found one slightly annoying issue. The family name of the wanted family member doesn't relate to the client. Realistically it should, at least 50% of the time or so. The fix would probably need an extra array with info on what mission contain what role for wanted, if any. Looking into.

[sturnclaw]

IMO if these are centralized, prefixing the role name with RELATION_ (i.e. RELATION_EMPLOYEE_MALE_1) makes sense as we will most likely want to throw other language strings into this module... Otherwise this looks pretty straightforward and sane.

Do any languages (that you know of) break the my <relation> <name> pattern? Would it be more flexible to include an interpolant for the person's name in the relation strings, instead of effectively concatenating the two together?

EDIT: for the family roles, RELATION_FAMILY_FEMALE_1 is probably fine, unless you intend the POS part to be a future expansion for positive/negative family relations?

[zonkmachine]

IMO if these are centralized, prefixing the role name with RELATION_ (i.e. RELATION_EMPLOYEE_MALE_1) makes sense as we will most likely want to throw other language strings into this module... Otherwise this looks pretty straightforward and sane.

OK. Prefixed tokens with RELATION_.

throw other language strings into this module...

On that note, is persons a good name for the directory?

..., instead of effectively concatenating the two together?

I'm not sure what you mean. We don't concatenate <relation> and <name>. Example:

"Hello. My name is {client}. {relative}, {wanted},

<Relation> here is {relative}. They can be moved to wherever they need to be in the local language.

Do any languages (that you know of) break the my <relation> <name> pattern? Would it be more flexible to include an interpolant for the person's name in the relation strings,..

Again, I'm not sure what you mean. If you include an interpolant for the person's name in the relations string, you ARE concatenating them together. You now have the possibility to drop 'my' from the languages where it isn't useful to have it written together with the relation string. I don't have an example of this or even know if such a language exists, but this feels more flexible to me. In Swedish 'my' in the relation string isn't conjugated so it could have been a part of the main string. It can also be part of the relation string. We have the luxury of choosing where to put it. I'll probably put it with the relation string to stay as close to the English original, but at least at a quick glance I don't think it matters from the Swedish perspective. To me this is more flexible. I would like some input from other translators though.

EDIT: for the family roles, RELATION_FAMILY_FEMALE_1 is probably fine, unless you intend the POS part to be a future expansion for positive/negative family relations?

POS here stands for possessive but I'm not being specific as I'm not deep into grammar. When I searched it I got hints of a difference between possessive pronoun and a possessive determiner. 'My' in this case is the latter. I can't say I actually know what that means. I also see that the translation comment line doesn't describe this. Any suggestions for POS and the comment to better reflect the grammar of it? The reason I swapped to a different grammar for the relatives, 'my cousin' instead of 'a cousin of mine' was that it just had better flow. At least it had better flow trying it out rather quickly.

Thanks for the review!

[sturnclaw]

Again, I'm not sure what you mean. If you include an interpolant for the person's name in the relations string, you ARE concatenating them together.

{relative}, {wanted} is concatenation. I was asking if you knew of any language syntaxes where e.g. my {name} aunt is a needed form, where the person's name has to be interpolated inside of the relation string rather than succeeding it in the sentence. I don't have any issues with the possessive being inside the relation string, just checking if we're accidentally shooting ourselves in the foot. If you can't think of any off the top of your head this is probably good as-is.

Any suggestions for POS and the comment to better reflect the grammar of it? The reason I swapped to a different grammar for the relatives, 'my cousin' instead of 'a cousin of mine' was that it just had better flow.

My grammar nerdery doesn't quite extend this far, but the "my" form is more "active", whereas the latter is more passive. Family relations like this are by nature possessives ("a cousin"? Who's cousin?), so I don't think that POS_ needs to be part of the string key.

[zonkmachine]

I have found one slightly annoying issue. The family name of the wanted family member doesn't relate to the client. Realistically it should, at least 50% of the time or so. The fix would probably need an extra array with info on what mission contain what role for wanted, if any. Looking into.

This is now fixed. In order to be able to set a character as the same culture as another, I modified Culture:Names to also return the 'name' string which is the name of the culture/language. This is caught by Namegen ad Character and a character generated wit New() now has a new 'culture' string saved. I also added an array which track which flavour scenarios have a 'relative' in it. This works well but I am experimenting with a more advanced system for later. Nothing fancy, just more family constellations.

[zonkmachine]

Family relations like this are by nature possessives ("a cousin"? Who's cousin?), so I don't think that POS_ needs to be part of the string key.

OK, dropping. If someone wants to add different grammatical twist they can fix that later.

[zonkmachine]

Would it be more flexible to include an interpolant for the person's name in the relation strings, instead of effectively concatenating the two together?

Can you give an example of this?

Apart from wrestling with the grammar of it, I think this is done now. I gave up trying to keep it in nice separate commits and it's all squashed and just nice in another way.