🔨 Implement correct model sizes for melee/spell/ability range

[DiscipleOfEris]

I affirm:

• I understand that if I do not agree to the following points by completing the checkboxes my issue will be ignored.
• I have read and understood the Contributing Guide and the Code of Conduct.
• I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated.

Describe the feature

Melee range, spell range, nearly all distances are supposed to be calculated using model size of both the attacker/caster and the target.

Additionally, model size should be sent to the client in packets 0x00D, 0x00E, and 0x037. The model size should be sent (and thus probably what should be stored in our DB) as a one-byte integer in tenths of yalms (so a mob with a 1.2 yalm model size should have its model size sent as 12).

We have multiple issues here.

• First, we're always sending model size 8 (thus 0.8 yalms) for all mobs, regardless of model size in the DB.
  • Nearly every model size in the DB is wrong.
• Secondly, we are sending 0 model size for players (should be 4 or 0.4 yalms).
• Additionally, the base range for melee should be 2 yalms, spells should be 20 yalms, etc. Most small mobs have a radius between 1.0 to 2.0 yalms, thus resulting in a typical melee range of 3.4 to 4.4 yalms (base 2 + attacker radius + target radius).
• It seems long range stuff typically uses 2D distance (within a vertical limit of 8.5 up or 7.5 down), while short range stuff (like melee) does consider 3D distance.
  • I haven't yet determined a solid set of rules for which things are 3D distance and which use 2D distance with vertical limit.

For research/capture purposes, mob model size is sent in the 0x00E (CEntityUpdatePacket) packet as a uint8 in offset 0x25 (in units of tenths of yalms, e.g. a 2.4 yalm radius would have a value of 24).

The code in the DistancePlus Windower addon seems to indicate there are minor deviations in max range from the formula distance <= range + caster.model_size + target.model_size making it vary by as much as 0.1 yalms in specific situations, so there are potential edge cases that need research.

[TeoTwawki]

Strongly caution against attempt to fix this until after some refactoring involving how we store the bits for actual model size (that nameflags mask dsp had for years, and the monster version called enityFlags over in mob pools? very not right)

Fortunately there has been recent major documenting by atom0s of what retail actually does in packets these get sent back and forth in and WinterSolstice8 has been reworking a lot on our end to more closely match retail behaviors in how we use those bits, so there's a light at the end of this tunnel where these no longer get jammed together in big huge masks with undefined values that can accidently affect other things.

[TeoTwawki]

p.s. if that didn't make much sense remember "model size" has become a somewhat loaded term due to referring to multiple things that are not what you actually see on screen. the model size I refer to is the 2-4 diff sizes each model can appear on screen in game, which is supposed to affect distances by way of mob's radius and unfortunately also gets called model size, outside of where I explicitly renamed it in a failed attempt to avert mixing these up this repo.

[DiscipleOfEris]

Yes, I've definitely been watching those developments with the documentation atom0s is working on. I'll likely update this issue if/when the 0x00E packet documentation drops.

I don't really have an opinion on what the property is called, though radius is probably a better term than size.

[atom0s]

I'll likely update this issue if/when the 0x00E packet documentation drops.

Soon. ™️

Been busy with IRL stuff going on lately so I haven't had much time to work on the packet docs. I have 0x000D done and ready for its first pass release and 0x000E is mostly done but needs a bit more docing for the various sub-types of the packet.

[DiscipleOfEris]

Going by the docs, looks like 0x00E uses the a flag struct that is re-used for 0x00D, but... for different purposes. For players those bytes are RGB of the linkshell color, but for mobs it's the model hitbox size.