Add BeastmasterGauge

[wangel]

Adds BeastmasterGauge (ClassJobId 43).

Mapped at runtime on 7.56 with a dalamud plugin I wrote that dumps every frame and
tracks per-byte min/max/distinct, then confirmed each field against the HUD or the combat log.

Offset	Field	Notes
0x08	TPGauge	0-250. No passive regen; granted by weaponskill combo bonuses. Instinctual skills spend the whole pool.
0x09	FamiliarTPGauge	0-250. One pool shared across Battlehorn slots, not per-familiar. Arrives in +12 steps from the familiar's auto-attacks.
0x0A	FamiliarTPAtLastUse	Familiar TP immediately before the last familiar action, which scales its potency.
0x0B	ActiveBattlehorn	0-3. The slot, not the creature.
0x0C	InstinctualComboState	Affinity, then 7 while Wavering Heart (Status 4643) locks out further combo advancement.
0x0D	CurrentAffinity	BeastmasterAffinity, 0-6. Clears ~7s after it is applied.
0x0E	ChainCount	Chained instinctual skills, matching the number drawn under the Inner Compass.
0x0F	KinshipState	Two nibbles: kin type high, Battlehorn slot low.
0x10	InstinctState	Two 2-bit counters: Natural Instinct low, Mastered Instinct high. Trait-gated, reads 0 below level 28.

BeastmasterAffinity has six values the four compass affinities plus the two combo results:

None 0  Volant 1  Rampant 2  Durant 3  Eldritch 4  Sunstrider 5  Moonstalker 6

The compass runs clockwise Volant -> Rampant -> Durant -> Eldritch -> Volant, and a clockwise pair inside the 7s window is what makes a combo.

Sunstrider and Moonstalker are the results are the affinity you started from. Odd = Sunstrider, Even = Moon.

The Status sheet backs this up. The six statuses the job applies are in this order (4595-4600).

The upgrade only lands if the target survives the combo.

0x10 holds two resources in one byte. Mastered Instinct (bits 2-3, trait Wild Heart III at
level 28) is gained when a you complete a combo...ie; You use tricks and then an axe skill. Rally is the spender.

Natural Instinct (bits 0-1, Wild Heart IV at level 40) is gained when a pet completes a combo....ie; you use an axe skill, then tricks. It's spent using Rallying Cheer.

Each caps at 3, each spender clears only its own bits.

Thanks to @Taurenkey for identifying the 0x0C 7 as Wavering Heart, and to @Haselnussbomber
for XBMManager and ActionManager.BeastmasterPets, which is where the familiar's identity
lives - the gauge only exposes the slot.

[Taurenkey]

The part you're not sure about should relate to the status you get as a player, when it's set to 7 you have the "Wavering Heart" status which prevents further advancement to the combo until it's cleared. Most likely to prevent triple weaving shenanigans breaking the gauge or something.

[wangel]

That's it exactly, thank you!!!!

"Otherwise engaged. Unable to perform combos with your familiar."

It also explains something that had been nagging me. I'd measured that hold at 2.22–2.23s and got the same number on every combo across three different pairings, which felt far too clean for a resolution delay. It isn't one, it's a fixed status duration.

Chasing it turned up a related bit of behaviour worth recording: if the second skill kills the target, you still get Wavering Heart and the ChainCount increment, but the affinity never upgrades to Sunstrider/Moonstalker. That had me convinced I had something broken.

Pointing me at the status side was worth doing twice over, because going back to the sheet turned up two more things.

First, the six affinities are contiguous and in the same order as the gauge values (4595 Volant Heart → 4600 Moonstalker), which independently confirms Rampant = 2 — the one value I had gotten from the compass position rather than actually observed. Sunstrider and Moonstalker also each say that using a skill with the other's affinity triggers an "infinitive combo", so there's a tier above intentional that pairs 5 against 6.

Second, and bigger: I'd written 0x0F off as a timer that goes up. It isn't a timer at all — I was reading it as a decimal. In hex it's two nibbles, high is the familiar's kin type and low is the Battlehorn slot it came from. I summoned one familiar of each kin and used Borrow:

0x11 Beast/1   0x12 Beast/2   0x83 Ash/3     0x51 Wave/1
0x32 Cloud/2   0x73 Soul/3    0x62 Scale/2   0x41 Seed/1
0x21 Vile/1

All eight kin types, each matching the familiar I had out and the Kinship status I actually got, numbered the same as the Kinship block at 4602–4609. So the branch now carries KinshipState and a BeastmasterKinType enum — kin type is in the gauge after all, which the original body said it wasn't.

While I was at it I also had to correct both TP fields, since neither gauge regenerates: player TP comes from the weaponskill combo bonuses (Axeblade Bite +13, Shieldsplitter +15), which averages neatly to the "~14 a tick" I had wrongly written down.

Branch and body are both updated.

[wangel]

Two updates and a thank-you.

Rampant = 2 is no longer inferred. I hooked UseAction in my dump plugin and attributed
each 0x0D transition to the press just before it. Avalanche Axe applies 2 directly, so every
value in the enum has now been seen in the gauge rather than derived from Status sheet ordering.
I've corrected that line in the description above.

The same attribution mapped the four standalone axes, one per compass affinity:

action	affinity
44884 Avalanche Axe	Rampant (2)
44887 Mistral Axe	Durant (3)
44888 Spinning Axe	Eldritch (4)
44889 Gale Axe	Volant (1)

These are fixed per action — the affinity is shown on the actions in game, and only the
familiar's varies. Nothing this PR needs, but it is independent confirmation that the enum
ordering is real rather than a coincidence of the Status sheet: the four axes cover all four
affinities, so there is always one at beast affinity + 1 and an intentional combo is available
whatever familiar is out.

The familiar's side resolves through the XBMPet sheet rather than the creature: affinity is a
property of the pet's AutoAttack action (see the sheet columns below), not of the pet
or its kin. Cu Sith and Puk share
AutoAttack 45187 and both apply Rampant despite differing in kin, Pet id and notebook
slot. Roughly 15 action ids cover all 50 pets. The unnamed 0x1A is not the affinity - Cu Sith
is 3 and Puk is 2, and both give Rampant.

Thanks @Haselnussbomber for XBMManager (4aa267b) — that joined up two things I had been
poking at separately. Some runtime detail back, in case it is useful to whoever writes the
binding for ActionManager::GetBeastmasterPet (0x1408F0590, named in the same commit):

• the argument is a Battlehorn slot, 0-based — 0, 1, 2. (Correction to an earlier draft of this:
  it is bounds-checked and returns 0 above index 2. I had called it through a 64-bit signature and
  was reading stale register bits above the returned byte.)
• the return is the Monster Notebook position, 1-based: 1 for a familiar sitting at notebook
  slot 1, 20 for one at slot 20.
• those values are the id IsPetUnlocked takes, and the bit index is petId - 1.
• BNpcBase BaseId = petId + 18915 held on all five familiars I tried, across petId 1–20.
  PetBuddy.DataID does not track it consistently — one familiar is off by one, so BaseId
  is the field that stays in step.

On XBMPet (51 rows, row 0 null): I had worked out some columns by matching the sheet against
familiars I had summoned, but nt153133 kindly sent me the SaintCoinach definition, which names
them properly and corrects two of my guesses. In dump order:

Description, TrickDescription, TemperedReleaseDescription, Icon, Pet, AutoAttack,
NaturalHabitat, Classification, two unnamed bytes at 0x19 and 0x1A, NaturalHabitatType.

Pet is the link to the Pet sheet - that is the id IBuddyList.PetBuddy.DataID gives you.
AutoAttack is an Action row. NaturalHabitat is a complexlink: PlaceName when
NaturalHabitatType is 1, ContentFinderCondition when it is 2. What I had taken for a tier was
the habitat type, and what I had taken for a text reference was the icon.

Classification is the kin type, 1-8 Beast/Vile/Cloud/Seed/Wave/Scale/Soul/Ash - that one I had
right, and it matches the gauge's 0x0F high nibble exactly.

One correction I guessed XBMModule was where the
slot→creature mapping lived. GetBeastmasterPet is the actual answer.

[wangel]

Rewrote the description in my own words - the original was written by AI was slop, I was being lazy with it. The data was all gathered from a plugin I wrote, that I used while testing and playing. If you any of you want the plugin to see it, hit me up and I'll share it.

[wolfcomp]

Still feels like AI written.

[wolfcomp]

All of this could be done with the bitfield attribute and check how it is accessed in the exe as it could reveal more detail about how each field is accessed.

[wangel]

Fixed --- using the bitfield attribute. I don't have a decompiler installed, everything was done during runtime in the game. I will get something installed.

[wolfcomp]

Check how this is actually accessed and stored in the exe and remove the comment as it is not needed to be this long.

[wangel]

I will work on getting a decompiler installed. Everything I did came from in the game during runtime.

[redstrate]

On the comment point: comments like that are so hilariously long and novel-ish tend to make the code unreadable instead of understandable. They need to be cut entirely - as suggested already - or written more concisely, CS doesn't need to be a job tutorial. That also applies to the commit message pre and post AI TBH, but I guess that's more of a personal opinion.

The real juice here is how and any quirks of how the data is stored that wouldn't be immediately obvious from the variable name or type alone, what wolfcomp suggests is going to be much better than manual documentation on every little nibble and bit.