Trinitycore: Core: The field bounding radius is unused by the core

[chaodhib]

Description:
The bounding radius of units is currently unused by the core. It is not well understood what this value represents. Each unit has a bounding radius and this value is sent to the client. Therefore, it must have a use.

Branch(es): both

TC rev. hash/commit: https://github.com/TrinityCore/TrinityCore/commit/b9d456fad1e39943502218b3fe065be36810e139

TDB version: Not linked to DB.

[Ovahlord]

since related to combat reach I think it might be the radius at which creatures should step back to stay in front of the enemy. On retail there is a feature that makes creatures moving back when they are too close to the caster. Dunno if its that thing of value that they use or if its the direct combat reach

[chaodhib]

This feature does not exist in 3.3.5. It was implemented later. Yet bounding radius already existed in 3.3.5. So this can't be what the bounding radius does.

The feature you are talking about probably uses the combat reach I think yeah.

[jerbookins]

I think it has to do with the range at which someone can hit the object. On the attacker, there is combat reach. On the defender, there is bounding radius.

[Killyana]

This makes sense as the issue that make players able to hit the target without taking melee attacks is still present.

[ccrs]

Thats completely different, its a problem with the movement generator and the point it moves the creature into. (fix slowly arriving 💃 )

[chaodhib]

@jerbookins Nice paint haha!

However, @ccrs is right in that regard. The bug that @Killyana mentioned is currently a bug in the targeted MoveGen. I wrote a quick fix here: https://github.com/TrinityCore/TrinityCore/pull/18923/commits/7565dcc34fe0c517c73a97a5f459b3beb25bd565 & https://github.com/TrinityCore/TrinityCore/pull/18923/commits/cea5c599bd6fe64fba79c7e34faae4fe1e12a426 as part of another PR. It should be fixed by @ccrs or me soon.

Also, we know today that the melee range of units is only depend on the attacker's combat reach and the target's combat reach. We learned this from a decompiled code portion of the client (cf https://github.com/TrinityCore/TrinityCore/commit/e6a52d4aae9e8facc46c3b05e0560d540a928d73 & http://paste2.org/2FUCZ4Ix).

Also, for information:

• the default combat reach of players is 1.5 yards.
• the default bounding radius of players is 0.388 (yards?).
• Also some mobs have high combat reach but low bounding radius (Malygos. entry 26310 for example. combat reach: 40. bounding radius: 4).
• While other mobs have low CR but high BR (Duronn the Runewrought, entry 30353 for example. CR: 6. and BR: 30).
• Also, the highest known combat reach is 77 (for Oacha'noa. entry:26648), in 3.3.5.
• And, the highest known bounding radius is 30 (Duronn the Runewrought and others), in 3.3.5.

[MrSmite]

Could it possibly be a radius for determining if a target is within an AOE hit? Or perhaps it's what tells the core that you can't fit through a door while mounted?

Maybe these are only used by the client to display an effect / graphic depending on the user's settings (eg: IIF withinBoundingRadius && maxGfxSettings : playMaxEffect, playMinEffect).

[chaodhib]

As far as I could tell from my observations, only the combat reach plays a role in AoEs. I could very well be wrong but I'm tired of looking. And believe me, I looked.

I tested the collision idea already. I made a player run parallel to a wall, very close to it using a ON_MONSTER_MOVE packet. Then I significantly increased his bounding radius. And i sent the same ON_MONSTER_MOVE packet.

No change observed. So it appears like it does not affect collision. Or at least not in that way.

Also I don't think being mounted or not will change anything. There are known packets for that: MOVE_SET_COLLISION_HGT. but it changes the height of the unit's collision box. not the radius.

And regarding your last point: Indeed, it could very well be used by the client for visual purposes only, with no impact on the gameplay whatsover. However, in the memory structure of the game (the client to be more specific), that field is surrounded by fields with a gameplay impact. So it's unlikely that this field does not. Also, even if it's only visual, it would be good to get to the bottom of this field so that when we try to solve a bug in the server, we know for sure that this field has nothing to do with it.

[MrSmite]

Have you tried changing the packet by removing the field entirely and see how the client reacts?

I wonder, if the surrounding fields affect gameplay what would the client do if those fields were suddenly shifted down by one in the structure. For example:

// instead of
struct {
int usefulField1
float boundingRadius
int usefulField2
}

// try sending
struct {
int usefulField1
int usefulField2
}

I suppose that would only work if the surrounding fields weren't the same size. What about setting bounding radius to a silly negative value like _-9000.00f_

NOTE: It's entirely possible this is a leftover field from Blizz. Maybe they tried to implement player to player collision (you know, when Mages complained about Rogues running through them and interrupting their cast) but decided to scrap it and didn't clean their code.

[jerbookins]

https://www.bountysource.com/issues/1413068-bounding-radius-combat-reach

Amazing. I just realized this went full circle. Oops.

[chaodhib]

@MrSmite Blizzard wouldn't transmit to the client unused fields. Don't forget that this field is sent for each unit that the player can see. Considering the amount of players simultaneously connected to the server, there is no way the networking engineers at Blizzard would let that kind of waste happen. Also, this field still exists in the latest version of the game (7.x).

Also, I'm not entirely sure but if I'm not mistaken, when the server does not send a value associated with the bounding radius when it initialize the unit on the client, the client uses a default value (1). This is true not only for 'bounding radius' but for all fields set through UPDATE_OBJECT packets.

EDIT: I tried the last point: not sending the field 'bounding radius' when initializing a player on the client. The result was that in memory, the field had 0 as its value. I tried with other fields and the result was the same. Knowing that, I'm not sure wether the client has a hard coded default value that it uses when it sees that the value is zero or if it actually uses zero for its computation.

[BARRELR0LL]

Disclaimer: I have no experience with TrinityCore, nor can I really test anything, but I like these kind of puzzles so here's my idea:

It could be a field used by the client to simplify (i.e. use a relatively cheap calculation) a ray cast operation to handle mouse clicks to see if a unit (that can move around in the world) has been clicked. If the value (in memory) is 0, a more expensive calculation might be used but for the sake of optimizing the engine, they may prefer a bounding box/radius check.

Haven't got a clue how you would test that though, maybe create a situation with loads of units with their bounding radius set to 0 and see if the framerate drops by any margin compared to when the units have their radius set to a valid value?

[chaodhib]

Well, thanks for your enthusiasm! But the hard part is to find a proof ofc :)

[offl]

Sad to see this almost abandoned, probably I need to open new issue later but the main reason I decided to write here is because people here already discussed both fields.

The way core calculates distance at that creature can attack other creature or player depends on combat reach and it looks horrible in game and causes some interesting issues like this one:

Steps to reproduce:
apply sql

-- Root Nergeld
DELETE FROM `creature_template_movement` WHERE `CreatureId` = 30403;
INSERT INTO `creature_template_movement` (`CreatureId`,`Ground`,`Swim`,`Flight`,`Rooted`,`Chase`,`Random`) VALUES
(30403,1,1,0,1,0,0);

-- We are rooted and not going anywhere
DELETE FROM `conditions` WHERE `SourceTypeOrReferenceId` = 16 AND `SourceEntry` = 30403;

.addi 42772 and pick up the quest from item
.go c id 30403
click on creature and wait for the waves of mobs
once mobs reach you, use the spell Punch
notice mobs receives no damage because the spell radius is just 3 yards. Since creature is rooted it can't move closer to attackers to be able to hit them with that spell

And the problem is in CanCreatureAttack

    if (Unit* unit = GetCharmerOrOwner())
        return victim->IsWithinDist(unit, dist);
    else
    {
        // include sizes for huge npcs
        dist += GetCombatReach() + victim->GetCombatReach();

        // to prevent creatures in air ignore attacks because distance is already too high...
        if (GetMovementTemplate().IsFlightAllowed())
            return victim->IsInDist2d(&m_homePosition, dist);
        else
            return victim->IsInDist(&m_homePosition, dist);
    }

These are values for 30403

[3] UNIT_FIELD_BOUNDINGRADIUS: 0.27899998
[3] UNIT_FIELD_COMBATREACH: 4.0499997

And these for one of the attackers

[5] UNIT_FIELD_BOUNDINGRADIUS: 0.31
[5] UNIT_FIELD_COMBATREACH: 1

All values in DB are sniffed. So total combat reach is 5 yards. Too much. Even 4 is too much but maybe I miss something in spell range calculation too and it'll be fine with 4. Didn't tried yet.

No idea how exacly combat reach should be used but definitely not this way. Some creatures has huge combat reach (20 yards) but in retail they can attack from way much closer distance. I'll try later to check more cases, compare them.

[offl]

Maybe player's values can help
This is for tbc \ classic, in wotlk combat reach is 1.5 for all of them
Bounding radius valid for wotlk

-- Human Male
UPDATE `creature_model_info` SET `bounding_radius`=0.306, `combat_reach`=1.5 WHERE `modelid`=49;
-- Human Female
UPDATE `creature_model_info` SET `bounding_radius`=0.208, `combat_reach`=1.5 WHERE `modelid`=50;
-- Orc Male
UPDATE `creature_model_info` SET `bounding_radius`=0.372, `combat_reach`=1.5 WHERE `modelid`=51;
-- Orc Female
UPDATE `creature_model_info` SET `bounding_radius`=0.236, `combat_reach`=1.5 WHERE `modelid`=52;
-- Dwarf Male
UPDATE `creature_model_info` SET `bounding_radius`=0.347, `combat_reach`=1.5 WHERE `modelid`=53;
-- Dwarf Female
UPDATE `creature_model_info` SET `bounding_radius`=0.347, `combat_reach`=1.5 WHERE `modelid`=54;
-- Night Elf Male
UPDATE `creature_model_info` SET `bounding_radius`=0.389, `combat_reach`=1.5 WHERE `modelid`=55;
-- Night Elf Female
UPDATE `creature_model_info` SET `bounding_radius`=0.306, `combat_reach`=1.5 WHERE `modelid`=56;
-- Undead Male
UPDATE `creature_model_info` SET `bounding_radius`=0.383, `combat_reach`=1.5 WHERE `modelid`=57;
-- Undead Female
UPDATE `creature_model_info` SET `bounding_radius`=0.383, `combat_reach`=1.5 WHERE `modelid`=58;
-- Tauren Male
UPDATE `creature_model_info` SET `bounding_radius`=0.9747, `combat_reach`=4.05 WHERE `modelid`=59;
-- Tauren Female
UPDATE `creature_model_info` SET `bounding_radius`=0.8725, `combat_reach`=3.75 WHERE `modelid`=60;
-- Gnome Male
UPDATE `creature_model_info` SET `bounding_radius`=0.3519, `combat_reach`=1.725 WHERE `modelid`=1563;
-- Gnome Female
UPDATE `creature_model_info` SET `bounding_radius`=0.3519, `combat_reach`=1.725 WHERE `modelid`=1564;
-- Troll Male
UPDATE `creature_model_info` SET `bounding_radius`=0.306, `combat_reach`=1.5 WHERE `modelid`=1478;
-- Troll Female
UPDATE `creature_model_info` SET `bounding_radius`=0.306, `combat_reach`=1.5 WHERE `modelid`=1479;

-- Draenei Male
UPDATE `creature_model_info` SET `bounding_radius`=1, `combat_reach`=1.5 WHERE `modelid`=16125;
-- Draenei Female
UPDATE `creature_model_info` SET `bounding_radius`=1, `combat_reach`=1.5 WHERE `modelid`=16126;

-- BELF Male
UPDATE `creature_model_info` SET `bounding_radius`=0.383, `combat_reach`=1.5 WHERE `modelid`=15476;
-- BELF Female
UPDATE `creature_model_info` SET `bounding_radius`=0.383, `combat_reach`=1.5 WHERE `modelid`=15475;