Option to use job name instead of player name

[Jaehyuk-Lee]

Summary

I know why triggers are calling player name, not the job name. You can have two or more player with same job.
But usually when you go latest raid content, you normally have one player per job. I think there's quite a few people who wants to know the job name, not nickname. I often hear that if there is any way to called by job name instead of nickname from community, especially from those who uses PF/RF without static.

[Jaehyuk-Lee]

I've briefly thought how to apply it, it seems not an easy one. I guess the player name is loaded directly from the log. So, there should be some table relating player with job.

[valarnin]

You can get any player in the party's job via data.party.details, for instance I have this in one of my custom triggers:

let playerJob;
data.party.details.forEach((p) => {
  if (p.name === partner)
    playerJob = Util.jobEnumToJob(p.job);
});

My question is, how on earth would you code this? A post-trigger filter to replace player names with jobs or something?

[Jaehyuk-Lee]

My question is, how on earth would you code this? A post-trigger filter to replace player names with jobs or something?

I guess so. I do think this would need a lot effort.

[valarnin]

Would it make more sense to do this based on indexed roles or something so it works even with duplicates? E.g.

Tank 1
Tank 2
Healer 1
Healer 2
DPS 1
DPS 2
DPS 3
DPS 4

I don't know if there's a way to get the party list in the order it's actually displayed in-client.

[Jaehyuk-Lee]

Oh... I understand what you mean. If we can get party member's list order, this can be different by each player, so we should get it from the client data, that's not a bad idea.
But I guess that's harder than just calling player's job.

[valarnin]

It's possible that it's the natural order of the party list returned by the FFXIV parser plugin, I'd have to check the decomp or do some tests in-game to be sure?

[Jaehyuk-Lee]

You mean FFXIV parsing plugin gives us party list order data? Party list order can be changed during fight... (I did it when disconnected then join party again. rejoining mixes the member order) So... we need real-time data of the list, but does parser gives us that information?

[valarnin]

No, looks like that's a bust, party order in partychanged event is random from what it appears? It also doesn't fire that event mid-fight at all, only when someone is added to or removed from the party.

[panicstevenson]

My question is, how on earth would you code this? A post-trigger filter to replace player names with jobs or something?

Something that pushes everyone's <name, job> to shortNames temporarily upon entering an instance? This would be especially terrible in the alliance raids when you're asked to stack on 'Red Mage (6)'.

[MaikoTan]

There are few sounds from Chinese community requesting this feature, too. Although for me the current method is Okay enough.

As far as I know there are extremely shorten job abbreviation which is usually in one or two character in Chinese and Japanese, such as "赤" for Red Mage and "ガ"/"枪" for Gunbreaker. Folks in CN are also prefer to call a player with their job name rather than their first name, especially when the player named in some uncommon characters that someone didn't know how to read them, unless there are duplicated jobs (And then they would call something like "那个四字黑魔"(The Black Mage with 4 characters (in his name)) rather than typing the poor BLM's name...).

So what I thought is that we can add a job abbreviation after player's name. For example, "Joe(赤)"/"Joe(RDM)", or "Michelle(暗)"/"Michelle(DRK)"...

[Jaehyuk-Lee]

I agree with using abbreviation. Korean server has one word(?) nicknames so mostly they are longer and just shorting the name is awkward (like calling Andrew as "And"). So, I think Korean exceptionally not use the nickname. For example my nickname "블러드트레일" is long. So just saying "용기사" (job name) is better than "블러드트레일 (용기사)" (nickname and job name in bracket). FYI. every Korean job abbreviation is maximum 3 letters.

[quisquous]

My question is, how on earth would you code this? A post-trigger filter to replace player names with jobs or something?

I think it could be possible to have data.ShortName handle this?

[trim21]

I'm using something like this.

(this script used to be broken but I fixed it in 2022-11-02)

"use strict";
export const jobIDToCN = {
  20: "武僧",
  21: "战士",
  23: "诗人",
  19: "骑士",
  24: "白魔",
  25: "黑魔",
  27: "召唤",
  22: "龙骑",
  28: "学者",
  30: "忍者",
  31: "机工",
  32: "DK",
  33: "占星",
  34: "武士",
  35: "赤魔",
  36: "青魔",
  37: "枪刃",
  38: "舞者",
  39: "镰刀",
  40: "贤者"
};
const playerNicks = Options.PlayerNicks = {};
addOverlayListener("PartyChanged", (e) => {
  for (const [key] of Object.entries(playerNicks)) {
    delete playerNicks[key];
  }
  for (const party of e.party) {
    const v = jobIDToCN[party.job];
    if (v) {
      playerNicks[party.name] = v;
    }
  }
});
console.log("enable name to job");

[MaikoTan]

What about add an option in raidboss_config that user could choose the player naming style in raidboss callouts as "full name" / "short name only" / "short name+job abbr" / "job only(and note might confused when duplicating jobs)"? Additionally, a "first-letter only" (i.e. something like M.T.) style may be good to add in, too. Default to "short name only" by the way.

[panicstevenson]

job only(and note might confused when duplicating jobs)

Do you think we should solve this? You could theoretically have 15 of the same DPS in an alliance raid in the Duty Finder.

[MaikoTan]

job only(and note might confused when duplicating jobs)

Do you think we should solve this? You could theoretically have 15 of the same DPS in an alliance raid in the Duty Finder.

I think the user who choose this option should aware that there can be a situation like what you mentioned (we can also add a note on the option), what I talking about is more like a raid-oriented feature for those who don't want to use the Options.PlayerNicks or just don't know there is such an option.

[Jaehyuk-Lee]

You could theoretically have 15 of the same DPS in an alliance raid in the Duty Finder.

The default option is kept same as now, showing player name. If user change this option, they'll naturally understand this could be a problem with "more than one player per job" situation. I think users will use "print job name" option when they think good to use only. (one player per job situation.)

[valarnin]

Hmm, if there are 5 RDMs in a party, does it sort them alphabetically afterward, or is the order random?

If it's actually sorted alphabetically, they could be RDM1, RDM2, etc.

[panicstevenson]

Assuming you know ahead of time if there’s collisions (on instance load) you could do:

RDM (Joe)
RDM (Michelle)

And just the job if there are no collisions.

RDM

Basically the opposite of what MaikoTan proposed above. This way you wouldn’t need to swap the configuration between content types.

You could take Trim21’s example and extend it so that the record value is an array and anything with a length > 1 will set the playerNick to ${job} (${shortName}), otherwise how it is currently written.

Alternatively, you could do like MaikoTan wrote above in the style of “Name (Job)” for collisions; I don’t know which is more appropriate for each language.

[panicstevenson]

Also, another aspect to consider here is text to speech. I don’t know if the abbreviations (formal or informal) for other languages can be easily read aloud, but I imagine ‘RDM’ or ‘GNB’ don’t sound very good through TTS, and pronouncing each letter like ‘W H M’ (4 syllables) would take longer to pronounce than ‘White Mage’.

[Jaehyuk-Lee]

oh, that's good point. Korean abbreviation is fine. Korean each letter has full pronounce and call them same in speech.
I don't know if Japanese call abreviated words in same speech. ex) "竜" (DRG, "ryu")

[MaikoTan]

oh, that's good point. Korean abbreviation is fine. Korean each letter has full pronounce and call them same in speech.
I don't know if Japanese call abreviated words in same speech. ex) "竜" (DRG, "ryu")

Yes, there is an issue.
"竜" (DRG, "ryu") is okay with my TTS engine, but some job like "暗"(DRK, "an") would be pronounced as "kura" (but pass "暗黒"(ankoku) would call the right one), and "占"(AST, "sen") would be pronounced as "uranai"(even 4 tones, but the same, pass "占星"(sensei) then it comes the right one).

By the way, there is no TTS issue in Chinese abbreviations. And those folks in Chinese server often use https://github.com/Noisyfox/ACT.FoxTTS as TTS engine, which has a preprocessor for replacing text so that TTS would say the right speech. (I have a fork of it and implement Japanese support but didn't merge the preprocessor commit (/▽＼))

[quisquous]

You could theoretically have 15 of the same DPS in an alliance raid in the Duty Finder.

The default option is kept same as now, showing player name. If user change this option, they'll naturally understand this could be a problem with "more than one player per job" situation. I think users will use "print job name" option when they think good to use only. (one player per job situation.)

I think in general, there aren't options that people are switching back and forth per content type. I think if possible I would like to have options that people can set once and then not have to adjust constantly. Maybe that means we need more options for people to pick from or some options should treat raid/trial content differently than alliance content?

Would it make more sense to do this based on indexed roles or something so it works even with duplicates?

Unfortunately, as far as I can tell there is no ordered party list information in ACT or OverlayPlugin at the moment. So, the best you could do is to alphabetically sort them so at least "PLD 1" is always the same PLD if you have two. Or, use job + name instead as was also suggested above.

[JaneSmith]

I would like this. Player names mean nothing to me — especially when I use TTS and it struggles to pronounce the names. It would be so much clearer to hear "x on DPS" or "x on tank" rather than "x on Ksduhsdsdhuasd".

[quisquous]

Sorry for getting around to this 2.5 years later. Thanks for all the work and ideas, @valarnin. The base functionality is now there, but I've filed a few extra things that I suspect people want if anybody is interested in implementing it themselves. I think it should be pretty straightforward: #5917