Fishing Packet Information (From Retail)

[atom0s]

Since the last major fishing update the fishing packets have changed. 0x66 and 0x81 are no longer used and have been replaced with:
- 0x110 (Sent from the client.)
- 0x115 (Sent from the server.)

Packet 0x115 Information
This looks to be a copy over from the original 0x81 with some modifications done to it. Possibly to help deter hacks. This is how the client uses the packet:

Code: Select all

char __cdecl sub_10097B70(int a1, int a2, int a3)
{
  unsigned int v3; // eax@1
  unsigned int v5; // eax@5
  unsigned int v6; // ecx@5

  JUMPOUT(dword_1043EF30, 0, *(unsigned int *)std__codecvt_base__do_always_noconv);
  dword_1043EF30 = (int)operator new(8u);
  v3 = (unsigned int)operator new(0x38u);
  dword_1043EF34 = v3;
  if ( !dword_1043EF30 )
  {
LABEL_7:
    JUMPOUT(v3, 0, *(unsigned int *)std__codecvt_base__do_always_noconv);
    sub_102E0550(v3);
    dword_1043EF34 = 0;
    JUMPOUT(*(int *)std__codecvt_base__do_always_noconv);
  }
  if ( !v3 )
  {
    sub_102E0550(dword_1043EF30);
    v3 = dword_1043EF34;
    dword_1043EF30 = 0;
    goto LABEL_7;
  }
  *(_DWORD *)dword_1043EF30 = *(_DWORD *)(a3 + 20);
  *(_DWORD *)(dword_1043EF34 + 8) = *(_WORD *)(a3 + 4);
  *(_DWORD *)(dword_1043EF34 + 4) = *(_DWORD *)(dword_1043EF34 + 8);
  *(_DWORD *)dword_1043EF34 = *(_DWORD *)(dword_1043EF34 + 4);
  *(_DWORD *)(dword_1043EF34 + 12) = *(_WORD *)(a3 + 6);
  *(_DWORD *)(dword_1043EF34 + 16) = *(_WORD *)(a3 + 8) - 128;
  if ( !*(_WORD *)(a3 + 10) )
    *(_WORD *)(a3 + 10) = 1;
  *(_DWORD *)(dword_1043EF34 + 20) = 20 * *(_WORD *)(a3 + 10);
  *(_DWORD *)(dword_1043EF34 + 24) = *(_WORD *)(a3 + 12);
  *(_DWORD *)(dword_1043EF34 + 28) = *(_WORD *)(a3 + 14);
  *(_DWORD *)(dword_1043EF34 + 32) = 60 * *(_WORD *)(a3 + 16);
  *(_DWORD *)(dword_1043EF34 + 36) = 0;
  *(_DWORD *)(dword_1043EF34 + 40) = *(_BYTE *)(a3 + 18) & 1;
  *(_DWORD *)(dword_1043EF34 + 44) = ((unsigned int)*(_BYTE *)(a3 + 18) >> 1) & 1;
  JUMPOUT(*(_DWORD *)(dword_1043EF34 + 44), 0, *(unsigned int *)std__codecvt_base__do_always_noconv);
  v5 = sub_101A6CD0(dword_1043EF34);
  JUMPOUT(v5, 0, *(unsigned int *)std__codecvt_base__do_always_noconv);
  v6 = *(_DWORD *)(v5 + 160);
  JUMPOUT(v6, 0, *(unsigned int *)std__codecvt_base__do_always_noconv);
  (*(void (__cdecl **)(signed int, unsigned int, signed int, _DWORD, _DWORD))(*(_DWORD *)v6 + 672))(
    905,
    v6,
    1852399981,
    0,
    0);
  return 1;
}

The pointer seen here 'dword_1043EF34', is the clients internal fishing structure. What this is doing is populating the fishing structure with the new fishing data.
The known offsets inside of the client are currently:
+00 = max stamina
+04 = stamina
+12 = id3
+20 = id1
+24 = id2
+28 = id4
+32 = fight time

Which line up with this packet perfectly. (With some unknown values.)

This packet can be interpreted like this:

Code: Select all

struct packet_115
{
    unsigned int header;

    unsigned short  Stamina;
    unsigned short  FishID3;
    unsigned short  Unknown1;   // -128
    unsigned short  FishID1;    // *20
    unsigned short  FishID2;
    unsigned short  FishID4;
    unsigned short  FightTime;  // *60
    unsigned char   Unknown2;   // &1
    unsigned char   Unknown3;   // Not used (padding)
    unsigned int    Unknown4;   // Not sure
};

Note the comments, some of the values are altered to skew their info from being visually readable.

[atom0s]

Some other misc information...

Fish ID4 seems to alter the fishes stamina:

Code: Select all

          v10 = dword_1043EF34 + 4; // fish stamina
          v5 = (signed __int64)(sub_100133E0(v5) * (double)*(signed int *)(dword_1043EF34 + 28) * 0.5) + *(_DWORD *)(dword_1043EF34 + 4);
          *(_DWORD *)v10 = v5;

+04 is the offset to fish stamina
+28 is the offset to fish id 4

Fish ID2 seems to be used to possibly alter the strength of the fish or the fight time: (not quiet sure which one)

Code: Select all

dword_1043EF18 = 10 * (rand() % (2 * *(_DWORD *)(dword_1043EF34 + 12)) + 2);

+12 is the offset to fish id 2

[mutiny]

I have tried to do some extensive testing on the incoming packet with ID of 0x0115 as well. These are my findings:

First of all, the so called "Fish IDs" we have been used to are not exactly IDs, although they can sort of be used as such in most cases. This is probably well known and understood. They are paremeters which affect the fishing minigame itself.
By testing effects of different items and equipments, I feel the purpose of each value can be determined.

This is the data as considered directly from the incoming packet.

Code: Select all

struct packet_115
{
    unsigned int header; //
    unsigned short stamina; // (max/initial stamina?)
    unsigned short sideTime; // rod hangtime
    unsigned short regen;
    unsigned short rodMove; // rod movement (why the multiply by 20?)
    unsigned short depletion; // stamina depletion (correct input)
    unsigned short recovery; // stamina recovery (incorrect input)
    unsigned short fightTime; // (why the multiplication by 60 when storing?)
    unsigned char biteType;
    unsigned char unk1; // padding? for 2 byte align?
    unsigned short intuition; // see below
};

1. header: seems to always be 0xD15 for incoming packet 0x115. I don't know its significance. Along with packet counter/timer. Probably general to all packets?

2. stamina: Fish's initial/max stamina for the fish on that particular bite. I have found that it directly relates to the fish's level. By taking several samples, for example:
Ryugu Titan range of "stamina" values:
8835
9021
9114
9300
9672
It can be seen that the possible values of "stamina" for Ryugu Titan have differences in multiples of 93. This value "93" is determined by floor(fishLvl / 2) + 18. In the case of Ryugu Titan, it's level has never been determined, but from this equation we then know that its level has to be 150 or 151. This property has been verified using fishes with known level caps crayfish (lv 7, multiple of 21), silver shark (lv 76, multiple of 56), black ghost (lv 88, multiple of 62).
From above, the -128 makes sense, as the sign (or 0 value) directly indicates regen-ness.

3. "ID3": The amount of the time the rod stays in the left or right position once moving from center. The item "Penguin Ring" causes ID3 and ID1 to increase by 2 under its effect, without going over 15. The description of this ring states that it "increases skill at tiring fish".

4. regen: this value is related to the difference between the player's fishing skill and the fish's level cap (among other possible factors), and also related to the "stamina" value. If this value == 128, the fish's HP is stagnant (it does not auto-deplete, nor does it regen). If this value is < 128, the fish's hp automatically depletes. The smaller this value, if less than 128, the more potent the auto-depletion. The same occurs if this value is > 128, where the fish auto-regens hp, with a stronger regen the higher it is over 128. For fish significantly lower level than the player's fishing skill, I have seen this value fluctuate with the "stamina" value (such as on lv 7 crayfish). It doesn't make sense, but the larger the "stamina" the lower this value would go, meaning more stamina = stronger auto-depletion. This value can be affected by: advanced fishing support, fishing apron/smock, ebisu rod, and possibly other untested factors.

5: "ID1": The amount of rod movement, or the tendency for the rod to move toward the left or right side from the center position. See 3. ID3.

6: "ID2": The amount of stamina depleted upon a "correct" input to the minigame (for normal blue arrow anyways, not gold). Gold arrow doubles the amount of stamine depletion of this value. Value only changes with fishing rods (decreasing with improved rods). Yes this is correct, more "improved" rods have a smaller value than cheaper/weaker rods. A willow rod can kill a fish faster than Ebisu rod. Whether it is better at actually reeling them in is the difference.

7: "ID4": The amount of stamina recovered by the fish upon an "incorrect" input to the minigame. Value changes with fishing rods, but also changes with an "angler's discernment" proc, as well as Heron Ring. On angler's discernment proc, this value is decreased by 30%. If Heron Ring is equipped with fishing support in effect, this value also decreases (investigating on decrease amount, seems like 10% decrease rounded to nearest 10 or 20 if not integer result).

8: fightTime: The amount of time (in seconds) you have from bite to losing catch.

9: biteType: This value relates to the type of fish or other conditions on fish bite.
0 = small fish/small item
1 = large fish/large item/monster
2 = "angler's discernment" proc on small fish
3 = "angler's discernment" proc on large fish
From atom0s above post, seems to be a 2 bit packed flag. 0b10 bit indicates discernment, 0b01 bit indicates catch size.

10: slotID: I believe (with no evidence) that this relates to a pool or slot ID of the fish biting. This value MUST match the appropriate value in the outgoing "reel in" packet after a successful fish fight.
...
actuall, after further investigation, this appears to be related to "intuition", or the chance for gold arrows to appear during mini game. This value increases on use of "Duck ring" or on angler's discernment proc, both of which increase chance of gold arrows. Interesting that they would use this value as an "ack" response in the catch packet. It seems this value also varies over time, probably varies on day/season/moon.