raidboss: DMU P2 Initial Triggers

[Legends0]

This is separated out from the P1 branch and timeline drafts I have. Figured I would share what I have been working on.

There's probably a simpler way to resolve Forsaken than what I have so far. I'm still testing this out though as I don't have a full network log to compare against and there are many ways to do this phase which makes it trickier to figure out how to form a generic output.

[Legends0]

Oh and the tower locations appear to be available with MapEffects I think.

[Legends0]

Planning to add trines and fixup the last past/future before marking ready.

[Legends0]

I'm going to simplify the tower triggers, assume first 4 tower soaks (via received headmarkers) are 1 group, and the others that didn't soak group 2. The mechanic appears to require splitting into two groups (unless there is some strange way you could swap people between groups?).

[Bing-su]

I tried emulating it using logs up to P3, and it appears to work fine with Kroxy-Rinon. 👍🏻

[MetalKoola]

I was working with these earlier with Kroxy-Rinon, and a question came to mind, on all the other things it figured out which tower you needed to go to, except for stack marker players in 3/5/7, where it seems to just call out the two people with stack.
The stack should have the same priority system as in the rest, where Group A or Group B will have the same HTMR Left-to-Right priority (for a standard comp). Is this a intended or something that will be looked into in a future PR?

[Legends0]

I was working with these earlier with Kroxy-Rinon, and a question came to mind, on all the other things it figured out which tower you needed to go to, except for stack marker players in 3/5/7, where it seems to just call out the two people with stack. The stack should have the same priority system as in the rest, where Group A or Group B will have the same HTMR Left-to-Right priority (for a standard comp). Is this a intended or something that will be looked into in a future PR?

I had not implemented priority for the stack, but something I can look into adding tomorrow.

[Legends0]

@valarnin could you check over some of this from a typescript perspective?

Mostly just need to know about the function I wrote. I ran into some issues with data.party.isHealer due to this and not knowing how to handle the eslint of a possible unbound method, so I just switched to using the Util version of it:

// Get Partner's HeadMarker following HTMR Priority
// Requires data and Forsaken Group
// Will return the forsaken headmarker of partner
const getHTMRPartnerMarker = (
  data: Data,
  group: string[],
): forsakenHeadmarker => {
  // Avoiding use of unbound method with `this` in data.party.isHealer
  const isHealer = (
    x: string,
  ): boolean => {
    const jobName = data.party.jobName(x);
    if (jobName === undefined)
      return false;
    return Util.isHealerJob(jobName);
  };
  // Functions for determining party member DPS subroles
  const isRangedDPS = (
    x: string,
  ): boolean => {
    const jobName = data.party.jobName(x);
    if (jobName === undefined)
      return false;
    return Util.isRangedDpsJob(jobName) || Util.isCasterDpsJob(jobName);
  };
  const isMeleeDPS = (
    x: string,
  ): boolean => {
    const jobName = data.party.jobName(x);
    if (jobName === undefined)
      return false;
    return Util.isMeleeDpsJob(jobName);
  };
  // Function to dynamically determine which role to check
  const getRoleFunction = (
    role: string,
  ): (name: string) => boolean => {
    // Only a healer will supercede the tank
    if (role === 'tank')
      return isHealer;
    if (Util.isMeleeDpsJob(data.job))
      return isRangedDPS;
    // If we find a melee in our group we are the ranged priority
    // Partner should be a melee dps, for optimal comp
    return isMeleeDPS;
  };
  const playerHeadmarkers = data.forsakenPlayerHeadmarkers;
  // Need to look at what healer has in relation to us
  // Partner is whoever has the same marker
  const isMyRoleSameAs = getRoleFunction(data.role);
  const member1 = group[0] ?? '';
  const member2 = group[1] ?? '';
  const member3 = group[2] ?? '';
  const partner = isMyRoleSameAs(member1)
    ? member1
    : isMyRoleSameAs(member2)
    ? member2
    : isMyRoleSameAs(member3)
    ? member3
    : 'unknown';
  // Return partner's marker
  return playerHeadmarkers[partner ?? 0] ?? 'unknown';
};

EDIT: I need to fixup the comment / function name.

[valarnin]

Aside from the bind question, this looks good in general from a TS standpoint for me.

Though there's a lot of intertwined logic depending on config values, wish there was a better way to separate out the logic by e.g. having DMU P2 Path of Light Towers 2 Default, DMU P2 Path of Light Towers 2 Bowtie, etc.

[Legends0]

Aside from the bind question, this looks good in general from a TS standpoint for me.

Though there's a lot of intertwined logic depending on config values, wish there was a better way to separate out the logic by e.g. having DMU P2 Path of Light Towers 2 Default, DMU P2 Path of Light Towers 2 Bowtie, etc.

Yea. This mechanic might also be able to reduce the trigger count by simply having a Tower 1 (due to it assigning groups), then Odds vs Even towers instead of each tower.

[Legends0]

I'll give it another day to test after the recent changes to the stacks. The raidemulator still looks good to me, but I won't be able to test further until tomorrow.

[valarnin]

For future reference, the other way to fix that problem would be to return an inner anonymous function that retains a reference to data, something like this (didn't check syntax here):

  const getRoleFunction = (
    role: string,
  ): (name: string) => boolean => {
    return (name: string) => {
      // Only a healer will supercede the tank
      if (role === 'tank')
        return data.party.isHealer(name);
      if (Util.isMeleeDpsJob(data.job))
        return isRangedDPS(name);
      // If we find a melee in our group we are the ranged priority
      // Partner should be a melee dps, for optimal comp
      return isMeleeDPS(name);
    }
  };