[WIP] raidboss: UWU ActorSetPos update/Titan Jump trigger

[valarnin]

Updates the Ifrit initial dash detection to use ActorSetPos instead of CombatantMemory.
Also adds a trigger for Titan jumps, since it's now possible to detect jump direction with consistency via ActorMove.

Posting as Draft/WIP until I can test it in-zone, but looking for feedback on the TODO I left in the new trigger.

[cactbotbot]

@valarnin Thanks for your contribution! 🌵🚀

[wexxlee]

Do you have any log lines (CombatantMemory should be fine) that have position & heading right before the jump? Thinking we can use that data to determine the four possible (x,y) coords that he "faces", e.g., if facing west, he's looking at 80,100 or 75,100 or something. (Even if we can determine one set, we can probably infer the other three.)

If we knew the four sets of possible coords, we could calculate the relative heading to Titan's current location from each. Then it's just whatever set of coords satisfies Math.Abs(titanHdg - cardinalRelativeHdgToTitan) = Math.PI (probably with some rounding for safety).

[valarnin]

It's always 14 units out from middle on cardinals, so:

const jumpCoords = [
{ dir: 'W', x: 86.0,  y: 100.0 },
{ dir: 'S', x: 114.0, y: 100.0 },
{ dir: 'N', x: 100.0, y: 86.0  },
{ dir: 'E', x: 100.0, y: 114.0 },
];

This trigger does need a slight delaySeconds since the final ActorMove packet can arrive slightly after Titan goes untargetable.

Here's two examples, the first one we get the last ActorMove before the toggle, the second we get it after. Included the Geocrush hit line showing Titan position as well:

270|2024-03-07T22:23:50.0540000-05:00|40009725|-0.0146|0000|005A|100.1923|100.2838|0.0305|b081daac9c2258b7
34|2024-03-07T22:23:50.0540000-05:00|40009725|Titan|40009725|Titan|00|49a9935b0c7f0f51
22|2024-03-07T22:23:55.2660000-05:00|40009725|Titan|2B66|Geocrush|...|100.00|114.00|0.00|-3.14|00002E30|6|8|acd81104ca1958cd

270|2024-03-07T22:42:38.8620000-05:00|4000A537|-2.0514|0000|005A|100.0092|100.0092|0.0000|e6492c6d0457a6ab
34|2024-03-07T22:42:39.1300000-05:00|4000A537|Titan|4000A537|Titan|00|53fca40b59040cf2
270|2024-03-07T22:42:39.1750000-05:00|4000A537|3.1415|0000|005A|100.0092|100.0092|0.0000|be43bfa3c7ea0d28
22|2024-03-07T22:42:44.3350000-05:00|4000A537|Titan|2B66|Geocrush|...|100.00|86.00|0.00|0.00|00004389|3|7|efbe6e326b9c5c38

Our tank is really good about centering Titan properly so I won't be able to get any data with Titan very off-center.

[valarnin]

Also I guess here's the graph view I was using to verify angles and such, in case it helps. Always fun to remember that the Y axis needs inverted and the rotation angle needs adjusted by 180º.

[wexxlee]

const jumpCoords = [
{ dir: 'W', x: 86.0,  y: 100.0 },
{ dir: 'S', x: 114.0, y: 100.0 },
{ dir: 'N', x: 100.0, y: 86.0  },
{ dir: 'E', x: 100.0, y: 114.0 },
];

I think S and E coords need to be swapped?

But something like this should work. Tested with a range of values, and it looks good:

// could leave this func in the trigger file or move to util.Directions?  It's generic enough...
const xyToHdg = (x: number, y: number, centerX: number, centerY: number): number => {
  x = x - centerX;
  y = y - centerY;
  return Math.atan2(x,y);
};

type Dir = "N" | "E" | "S" | "W";
type JumpCoords= { dir: Dir, x: number, y: number }
const jumpCoords: JumpCoords[] = [ 
    { dir: 'W', x: 86.0, y: 100.0 },
    { dir: 'E', x: 114.0, y: 100.0 },
    { dir: 'N', x: 100.0, y: 86.0 },
    { dir: 'S', x: 100.0, y: 114.0 },
];

const centerX = 100;
const centerY = 100;
const titanX = 94.591; // from ActorMove
const titanY = 102.366; // from ActorMove
const titanHdg = -1.839 // from ActorMove

let jumpDir: Dir | "??" = "??";
for (const site of jumpCoords) {
   const hdgToTitan = xyToHdg(titanX, titanY, site.x, site.y);
   const combo = Math.abs(titanHdg - hdgToTitan);
   if (combo >= 3 && combo <= 3.28) // should be = Math.PI, but safety margin?
     jumpDir = site.dir;
}
console.log(`Titan jumping ${jumpDir}`);

[wexxlee]

I should add that this assumes Titan can't ever exceed the bounds of ([86-114],[86-114]), but I assume his jump coords are at the edge or outside the arena (sorry, I should remember, but I don't).

[wexxlee]

(sorry, one more thought)
FWIW, assuming the arena were square and Titan was all the way in the corner - say (86,86) - his heading for an E jump would be 1.107, and his heading for a S jump would be 0.463, or a delta of 0.644. With those arena bounds, that's the closest two adjacent headings can get, so a safety margin of +/-0.14 seems plenty without risking an erroneous reading.

[valarnin]

It's a little complicated both because the arena is a circle, and because that arena shrinks over the course of the phase every time he does a jump. So it starts at 15y diameter, then shrinks to 14y, then 13y. But he always jumps 14y out from the middle.

So the furthest out you could drag him at the start would be 110.607, 110.607 (without doing some janky snapshotting with the death wall and gapclosers), but then that shrinks to 109.9, 109.9 for the last jump.

[wexxlee]

So the furthest out you could drag him at the start would be 110.607, 110.607 (without doing some janky snapshotting with the death wall and gapclosers), but then that shrinks to 109.9, 109.9 for the last jump.

Starting to remember now 🙃. But as long as he can never be positioned more than 14y away on either the x or y axis, there's no chance that you'd get the same (or within the safety margin) hdgToTitan values for 2+ possible jump points. With Titan at (110.607, 110.607), I get the following hdgToTitan values from the four jump spots:

W hdgToTitan: 1.164
E hdgToTitan: -0.310
N hdgToTitan: 0.407
S hdgToTitan: 1.880

... so this approach should work, I think.

[valarnin]

I'll add this logic as a secondary trigger locally and test it on Sunday. I need to dig through and check the max delta between a 34 line and a 270 line arriving late to see if the 0.2s delaySeconds that I'm thinking of will be enough, as well.