Trinitycore: Core/Misc: Error if flag is not allowed to be set manually

[offl]

Description:

We need:
IsAllowedUnitFlag for unit_flags
IsAllowedUnitFlag2 for unit_flags2
All dynamic flags should not be allowed in DB, I need to remove remaining UNIT_DYNFLAG_DEAD first

With possibility to remove or add flag from that list and throw error if any flag from that list was added in creature_template or creature.
The reason why is because almost all of those flags should never be in DB because some of them are handled only by server, some only by client and all other by spells. We can't just remove all of them because in some cases it will broke stuff so we'll need to replace it by auras. In some other cases flags can be removed without changes.

Legend:
- not allowed, not used currently
+ allowed, used currently
? very likely should be removed but I'm not sure enough
\ pending, should be removed and marked as not allowed (replaced by auras or removed if auras already added / handled by spell scripts)

-    UNIT_FLAG_SERVER_CONTROLLED     = 0x00000001,           // set only when unit movement is controlled by server - by SPLINE/MONSTER_MOVE packets, together with UNIT_FLAG_STUNNED; only set to units controlled by client; client function CGUnit_C::IsClientControlled returns false when set for owner
\    UNIT_FLAG_NON_ATTACKABLE        = 0x00000002,           // not attackable
-    UNIT_FLAG_REMOVE_CLIENT_CONTROL = 0x00000004,           // This is a legacy flag used to disable movement player's movement while controlling other units, SMSG_CLIENT_CONTROL replaces this functionality clientside now. CONFUSED and FLEEING flags have the same effect on client movement asDISABLE_MOVE_CONTROL in addition to preventing spell casts/autoattack (they all allow climbing steeper hills and emotes while moving)
-    UNIT_FLAG_PLAYER_CONTROLLED     = 0x00000008,           // controlled by player, use _IMMUNE_TO_PC instead of _IMMUNE_TO_NPC
-    UNIT_FLAG_RENAME                = 0x00000010,
-    UNIT_FLAG_PREPARATION           = 0x00000020,           // don't take reagents for spells with SPELL_ATTR5_NO_REAGENT_WHILE_PREP
+    UNIT_FLAG_UNK_6                 = 0x00000040,
-    UNIT_FLAG_NOT_ATTACKABLE_1      = 0x00000080,           // ?? (UNIT_FLAG_PLAYER_CONTROLLED | UNIT_FLAG_NOT_ATTACKABLE_1) is NON_PVP_ATTACKABLE
+    UNIT_FLAG_IMMUNE_TO_PC          = 0x00000100,           // disables combat/assistance with PlayerCharacters (PC) - see Unit::IsValidAttackTarget, Unit::IsValidAssistTarget
+    UNIT_FLAG_IMMUNE_TO_NPC         = 0x00000200,           // disables combat/assistance with NonPlayerCharacters (NPC) - see Unit::IsValidAttackTarget, Unit::IsValidAssistTarget
-    UNIT_FLAG_LOOTING               = 0x00000400,           // loot animation
-    UNIT_FLAG_PET_IN_COMBAT         = 0x00000800,           // on player pets: whether the pet is chasing a target to attack || on other units: whether any of the unit's minions is in combat
-    UNIT_FLAG_PVP                   = 0x00001000,           // changed in 3.0.3
-    UNIT_FLAG_SILENCED              = 0x00002000,           // silenced, 2.1.1
+    UNIT_FLAG_CANNOT_SWIM           = 0x00004000,           // 2.0.8
+    UNIT_FLAG_SWIMMING              = 0x00008000,           // shows swim animation in water
-    UNIT_FLAG_NON_ATTACKABLE_2      = 0x00010000,           // removes attackable icon, if on yourself, cannot assist self but can cast TARGET_SELF spells - added by SPELL_AURA_MOD_UNATTACKABLE
-    UNIT_FLAG_PACIFIED              = 0x00020000,           // 3.0.3 ok
\    UNIT_FLAG_STUNNED               = 0x00040000,           // 3.0.3 ok
-    UNIT_FLAG_IN_COMBAT             = 0x00080000,
-    UNIT_FLAG_TAXI_FLIGHT           = 0x00100000,           // disable casting at client side spell not allowed by taxi flight (mounted?), probably used with 0x4 flag
-    UNIT_FLAG_DISARMED              = 0x00200000,           // 3.0.3, disable melee spells casting..., "Required melee weapon" added to melee spells tooltip.
-    UNIT_FLAG_CONFUSED              = 0x00400000,
-    UNIT_FLAG_FLEEING               = 0x00800000,
-    UNIT_FLAG_POSSESSED             = 0x01000000,           // under direct client control by a player (possess or vehicle)
+    UNIT_FLAG_NOT_SELECTABLE        = 0x02000000,
-    UNIT_FLAG_SKINNABLE             = 0x04000000,
-    UNIT_FLAG_MOUNT                 = 0x08000000,
-    UNIT_FLAG_UNK_28                = 0x10000000,
\    UNIT_FLAG_UNK_29                = 0x20000000,           // used in Feing Death spell
-    UNIT_FLAG_SHEATHE               = 0x40000000,
-    UNIT_FLAG_IMMUNE                = 0x80000000,           // Immune to damage

```cpp
- UNIT_FLAG2_FEIGN_DEATH = 0x00000001,
+ UNIT_FLAG2_HIDE_BODY = 0x00000002, // Hide unit model (show only player equip)
UNIT_FLAG2_IGNORE_REPUTATION = 0x00000004,
UNIT_FLAG2_COMPREHEND_LANG = 0x00000008,
UNIT_FLAG2_MIRROR_IMAGE = 0x00000010,
+ UNIT_FLAG2_DO_NOT_FADE_IN = 0x00000020, // Unit model instantly appears when summoned (does not fade in)
UNIT_FLAG2_FORCE_MOVEMENT = 0x00000040,
UNIT_FLAG2_DISARM_OFFHAND = 0x00000080,
UNIT_FLAG2_DISABLE_PRED_STATS = 0x00000100, // Player has disabled predicted stats (Used by raid frames)
UNIT_FLAG2_DISARM_RANGED = 0x00000400, // this does not disable ranged weapon display (maybe additional flag needed?)
+ UNIT_FLAG2_REGENERATE_POWER = 0x00000800,
UNIT_FLAG2_RESTRICT_PARTY_INTERACTION = 0x00001000, // Restrict interaction to party or raid
UNIT_FLAG2_PREVENT_SPELL_CLICK = 0x00002000, // Prevent spellclick
UNIT_FLAG2_ALLOW_ENEMY_INTERACT = 0x00004000,
+ UNIT_FLAG2_CANNOT_TURN = 0x00008000,
UNIT_FLAG2_UNK2 = 0x00010000,
UNIT_FLAG2_PLAY_DEATH_ANIM = 0x00020000, // Plays special death animation upon death
UNIT_FLAG2_ALLOW_CHEAT_SPELLS = 0x00040000 // Allows casting spells with AttributesEx7 & SPELL_ATTR7_IS_CHEAT_SPELL

```cpp
-    UNIT_DYNFLAG_LOOTABLE                   = 0x0001,
-    UNIT_DYNFLAG_TRACK_UNIT                 = 0x0002,
-    UNIT_DYNFLAG_TAPPED                     = 0x0004,       // Lua_UnitIsTapped
-    UNIT_DYNFLAG_TAPPED_BY_PLAYER           = 0x0008,       // Lua_UnitIsTappedByPlayer
-    UNIT_DYNFLAG_SPECIALINFO                = 0x0010,
\    UNIT_DYNFLAG_DEAD                       = 0x0020,
-    UNIT_DYNFLAG_REFER_A_FRIEND             = 0x0040,
-    UNIT_DYNFLAG_TAPPED_BY_ALL_THREAT_LIST  = 0x0080        // Lua_UnitIsTappedByAllThreatList

Branch(es): both
TC rev. hash/commit: 9ae23ef2fdb98bd2a2bf6dee4eb35c1b44cfc427

[jackpoz]

It would be nice to define a mask of what is allowed and what not and a log that prints the name of the flag.

[offl]

Added legend:
- not allowed, not used currently
+ allowed, used currently
? very likely should be removed but I'm not sure enough
\ pending, should be removed and marked as not allowed (replaced by auras or removed if auras already added), UNIT_FLAG_PVP should be removed or replaced by bytes2 256

[offl]

Let's make it worse.

[xvwyh]

Is there any real examples of UNIT_FLAG_NON_ATTACKABLE being used in sniffs?

[offl]

In TC it's mostly used as hack, I removed replaced a lot already but still a lot of work to do, especially in CPP
In retail it's used in Birth spell. Maybe in more spells, I didn't checked yet all cases
When creature starts to cast Birth (250ms cast), it adds that flag (guessed, Birth is used as on-spawn spell, so flag is already added). When spell hits creature, flag will be removed. In some cases creature casts instantly another spell, but in general they just adds removes flag

So far I don't know how exactly this will be handled. By single spell script or it's the same story as Feign Death with its different effects(non-selectable immune to pc immune to npc) but I definitely don't want to leave that flag as allowed even in SAI if it's not SOURCE TYPE SPELL

[xvwyh]

In that case its actual name should be "Spawning".

Here's what we have in alpha's .pdb:

Image

All of these are CGUnit's functions. CGUnit consists of CGUnitData (what we call "update fields") and CMovementData (ditto "movement info"), so all the functions you see there are related to either of these classes:

Almost all of these functions are so simple that they got inlined and you can't even find any of these names with IDA, but they are in .pdb.

Anyway, the highlighted section contains functions related to unit flags. Above it are movement flags functions, below it - npc flags functions etc. Here they are in order, along with their equivalent from our code:

|Client|TC|
|---|---|
IsDisconnected|-
IsSpawning|-
IsClientLocked|UNIT_FLAG_REMOVE_CLIENT_CONTROL
IsOnTaxi|UNIT_FLAG_TAXI_FLIGHT
IsPlayerControlled|UNIT_FLAG_PLAYER_CONTROLLED
IsPlusMob|-
IsBeastmaster|-
IsImmunePC|UNIT_FLAG_IMMUNE_TO_PC
IsImmuneNPC|UNIT_FLAG_IMMUNE_TO_NPC
IsLooting|UNIT_FLAG_LOOTING
IsInCombat|UNIT_FLAG_IN_COMBAT
IsMounted|UNIT_FLAG_MOUNT
IsPureMountActive|-
IsPureMountMounted|-
IsFeignDeath|UNIT_FLAG_UNK_29 (?)
IsStealthed|- (moved to UNIT_STAND_FLAGS_CREEP?)
IsInvisible|- (maybe moved there too??)
IsConfused|UNIT_FLAG_CONFUSED
IsFleeing|UNIT_FLAG_FLEEING
IsAffectingCombat|UNIT_FLAG_PET_IN_COMBAT (?)

These functions are not exactly in the same order as the flags, but they have "streaks" of correct order with an occasional flag out of place. Because of this, I can extrapolate the following:

---

IsBeastmaster is right before IsImmunePC/IsImmuneNPC, and what do we have there? UNIT_FLAG_NOT_ATTACKABLE_1. It matches: in my opinion "beastmaster" prevents the units from being aggroed onto and attacked by their enemies, kinda like our .gm mode does, it's available in the client as a cheat, alongside "godmode" which prevents you from dying upon reaching 1 hp. The reason this cheat needs a unit flag is because, unlike godmode which simply makes the server zero out damage taken, beastmaster does alter how the client interacts with the unit: stops allowing the player to autoattack it, target it with spells etc.

Blizzard actually has actions in their scripting system to set/reset beastmaster flag at runtime, so it actually might be possible to encounter UNIT_FLAG_NOT_ATTACKABLE_1 in some sniffed content.

AI_GROUP_BEASTMASTER_ON Turn on beastmaster flag for the group
AI_GROUP_BEASTMASTER_OFF Turn off beastmaster flag for the group

Interestingly enough, at some point after alpha they gave them a different description:

Set "Uninteractible" flag for unit(s)
Reset "Uninteractible" flag for unit(s)

Maybe because developers couldn't understand what in the world does "beastmaster" mean, lol.

As I was reminded, these actions actually deal with UNIT_FLAG_NOT_SELECTABLE now, meaning they either "upgraded" their existing scripts from whatever "beastmaster" was to full nonselectability, or nobody ever used "beastmaster" and they just obsoleted and reused the script actions.

---

IsPlusMob goes right before that. And it matches with UNIT_FLAG_UNK_6. What is a "plus mob"? Some ancient variation on "elites". For whatever reason it's a runtime unit flag, meaning creatures could start and stop being "elite" during gameplay. Probably an artifact from early development. Nowadays all elite creatures have this UNIT_FLAG_UNK_6 flag, simple as that, you can check it yourself. Plus mobs were meant to have a slightly different portrait (with gold border around health and mana bars), and in the alpha client they were displayed with a "+" next to their level:

TargetFrame.lua

function TargetFrame_CheckLevel()
    local playerLevel = UnitLevel("player");
    local targetLevel = UnitLevel("target");
    if ( not UnitIsEnemy("target", "player") or ( playerLevel > (targetLevel - 15) ) ) then
        TargetHighLevelTexture:Hide();
        if ( UnitIsPlusMob("target") ) then
            TargetLevelText:SetText(targetLevel.."+");
        else
            TargetLevelText:SetText(targetLevel);
        end
        TargetLevelText:Show();
    else
        TargetLevelText:Hide();
        TargetHighLevelTexture:Show();
    end
end

Another proof that the "plus mobs" and "elites" are the same thing comes from GlobalStrings:

Alpha:

UNIT_LETHAL_LEVEL_TEMPLATE = "Level ??"; -- Level unknown for higher level units
UNIT_LEVEL_TEMPLATE = "Level %d"; -- Level of a unit
UNIT_PLUS_LEVEL_TEMPLATE = "Level %d+"; -- Level of a plus-mob unit

Modern:

UNIT_LETHAL_LEVEL_TEMPLATE = "Level ??"; -- Level unknown for higher level units
UNIT_LEVEL_TEMPLATE = "Level %d"; -- Level of a unit
UNIT_PLUS_LEVEL_TEMPLATE = "Level %d Elite"; -- Level of a plus-mob unit

UNIT_TYPE_LETHAL_LEVEL_TEMPLATE = "Level ?? %s"; -- As in Level ?? Beast
UNIT_TYPE_LEVEL_TEMPLATE = "Level %d %s"; -- As in Level 10 Beast
UNIT_TYPE_PLUS_LEVEL_TEMPLATE = "Level %d Elite %s"; -- As in Level 10+ Beast

---

What in the world is a "PureMount" I have no idea, but we do have an unused flag right between UNIT_FLAG_MOUNT and UNIT_FLAG_UNK_29, so maybe it's actually a remnant of IsPureMountActive, whatever it might be. IsPureMountMounted is not necessarily a flag in itself, it might be just a helper function that tests if both IsMounted and IsPureMountActive are set.

---

And so we're left with IsDisconnected and IsSpawning without an equivalent in our code. If we disregard the IsOnTaxi which is blatantly out of place, we're left with a perfectly ordered streak:
|Client|TC|
|---|---|
IsDisconnected|UNIT_FLAG_SERVER_CONTROLLED
IsSpawning|UNIT_FLAG_NON_ATTACKABLE
IsClientLocked|UNIT_FLAG_REMOVE_CLIENT_CONTROL
IsPlayerControlled|UNIT_FLAG_PLAYER_CONTROLLED
-|UNIT_FLAG_RENAME
-|UNIT_FLAG_PREPARATION
IsPlusMob|UNIT_FLAG_UNK_6
IsBeastmaster|UNIT_FLAG_NOT_ATTACKABLE_1
IsImmunePC|UNIT_FLAG_IMMUNE_TO_PC
IsImmuneNPC|UNIT_FLAG_IMMUNE_TO_NPC
IsLooting|UNIT_FLAG_LOOTING
IsInCombat|UNIT_FLAG_IN_COMBAT

Which matches IsSpawning with what you just told me about UNIT_FLAG_NON_ATTACKABLE.

Whether IsDisconnected still retains its meaning to this day, and our name UNIT_FLAG_SERVER_CONTROLLED is wrong, or whether it changed over the years I don't know.

(I wrote all this twice, because chrome crashed on me and github decided not to save the entered text...)

[illfated]

Thank you for the funny meme-pic at the top. It made me smile & chuckle, but it is still true.

[Wolffenstein]

Good write-up as always @xvwyh.

UNIT_FLAG_UNK_6 is indeed related to plus mobs, I was wondering what that was when I was digging into it a while ago as well. It's super ancient but IIRC there's still a script function to check if mob is a "plus mob" in 2.4.3 client (might be misremembering though). All in all it can be renamed to get rid of UNK and left unused.

UNIT_FLAG_UNK_29 is definitely UNIT_FLAG_FEIGN_DEATH and it should have been renamed to that long ago already.

I don't quite remember all the details as I was digging into it a long time ago, but I have UNIT_FLAG_SERVER_CONTROLLED as UNIT_FLAG_DONT_FADE_IN (prevents the client from displaying "fade in" animation when unit is spawned). Whether I was right and that was accurate for alpha and whether it's valid for further expansions or if I messed up and read the wrong thing - I don't know, but maybe it will help somebody research it further.

What in the world is a "PureMount" I have no idea, but we do have an unused flag right between UNIT_FLAG_MOUNT and UNIT_FLAG_UNK_29, so maybe it's actually a remnant of IsPureMountActive, whatever it might be. IsPureMountMounted is not necessarily a flag in itself, it might be just a helper function that tests if both IsMounted and IsPureMountActive are set.

Perhaps some very early distinction between Taxis/Mounts/Druid Forms? No clue.

Interestingly enough, at some point after alpha they gave them a different description:
Set "Uninteractible" flag for unit(s)
Reset "Uninteractible" flag for unit(s)
Maybe because developers couldn't understand what in the world does "beastmaster" mean, lol.

Yeah, I wouldn't know what "beastmaster" means either. I'm not sure if "Uninteractible" would be fully valid here, since I think you could interact with such units in a non-combat way? I guess it could be tested with spellclicks/vendors/trainers/etc. but I believe the term "Unattackable" would be better here. And even if this one gets corrected, there's still UNIT_FLAG_NON_ATTACKABLE_2 :p

[offl]

In that case its actual name should be "Spawning".

Yeah but first it should be purged if not present in sniffs added as hacks. In 98% it was added as hack with no doubt. So far I encountered only 2 case where it is used, both cases are temp summons (Shirrak's focus fire & mirror images of last boss in Arcatraz). Both uses Birth + I've seen CMaNGOS devs scripted several Birth spells by their EventAI, so I guess all Birth spells applies that flag and removes it. Or just removes but I don't really like to store it in DB.

I doubt it's a good idea to rename it right now because currently it's used in 300+ cases and renaming will make all of them confusing. I can purge it from creature, creature_template, SAI but I doubt I want to remove 200 of it from CPP.
But I like the idea to rename it if it will be purged and if we are planing to leave it as allowed because nobody will know what Spawning does. Unlike NON_ATTACKABLE. So far one of the hardest part of that crusader strike against shitty flags.

Currently that flag acts like 'I can attack, nobody can attack me', I don't know if it's correct behavior. Current implementation looks logically correct if we want to allow combat instantly after spawn because our IsImmuneToAll(pc + npc) will block combat while UNIT_FLAG_NON_ATTACKABLE will not block it so creature can enter in combat instantly after spawn.
But is it correct? Here's the sniff https://gist.github.com/offl/eee4bd5c9f6cd3d8ec713362bc8f7536

Edit: [1] UNIT_FIELD_FLAGS: 2058 in CreateObject2 packet, creature casts https://tcubuntu.northeurope.cloudapp.azure.com/aowow/?spell=7398

"both cases are temp summons", "In 98% it was added as hack" means in the end we will have really few cases and probably they all will be related to Birth spell.

IsBeastmaster is right before IsImmunePC/IsImmuneNPC, and what do we have there? UNIT_FLAG_NOT_ATTACKABLE_1.

Blizzard actually has actions in their scripting system to set/reset beastmaster flag at runtime, so it actually might be possible to encounter UNIT_FLAG_NOT_ATTACKABLE_1 in some sniffed content.

Interestingly enough, at some point after alpha they gave them a different description:

Set "Uninteractible" flag for unit(s)
Reset "Uninteractible" flag for unit(s)

Maybe because developers couldn't understand what in the world does "beastmaster" mean, lol.

Unfortunately I don't check that type of flags, purely serverside flags (not applied by auras), that flag was used by really few creatures in TC, nothing in sniffs. It was added as hack with no doubt. Means we have zero creatures with that flag but yeah, quite possible something will be shown in sniffs.

Uninteractible... thing is Blizz devs also calls UNIT_FLAG_NOT_SELECTABLE Uninteractible

 entry  name                                                                          
------  ------------------------------------------------------------------------------
 30298  Invisible Stalker (Float, Uninteractible, LargeAOI)                           
 32662  Invisible Stalker (Floating, Uninteractible, Large, Sessile, Custom Phase 1)  
 32768  Invisible Stalker (Floating, Uninteractible, Large, Sessile, Custom Phase 2)  
 38310  Invisible Stalker (Float,Uninteractible,LargeAOI) (3.00)                      
 39842  Invisible Stalker (Hostile,Ignore Combat,Float,Uninteractible,Large AOI)      

IsPlusMob goes right before that. And it matches with UNIT_FLAG_UNK_6.
For whatever reason it's a runtime unit flag, meaning creatures could start and stop being "elite" during gameplay.
Nowadays all elite creatures have this UNIT_FLAG_UNK_6 flag, simple as that, you can check it yourself.

Are you sure it's a runtime flag? Because your explanation looks more like 'let's make it too serverside' if it's used by all elites.
I checked it right now but only 3200 of 8000 elites uses it right now. I know lots of creatures weren't updated from sniffs but 5k is too much. It's 1/6 of all creatures. But lots of those 5k indeed weren't updated from sniffs.

[offl]

UNIT_FLAG_UNK_29 is definitely UNIT_FLAG_FEIGN_DEATH and it should have been renamed to that long ago already.

I disagree, we already have UNIT_FLAG2_FEIGN_DEATH. And I opened today #25836, that spell is not Feign Death.
Also we all forgot about https://github.com/TrinityCore/WowPacketParser/blob/master/WowPacketParser/Enums/UnitFlags.cs
Some names & explanation were added to https://trinitycore.atlassian.net/wiki/spaces/tc/pages/1200128167/creature+template+3.3.5a#creature_template(3.3.5a)-unit_flags

PreventEmotes looks more correct if emotes are really prevented. I guess something is for sure prevented :D

Thank you for the funny meme-pic at the top. It made me smile & chuckle, but it is still true.

You will see it more often now, heh

P.S. I saw UNIT_FLAG_RENAME two times when creatures were going to attacks critters. Also current name is super confusing, is it 'rename me' or 'rename'?

Used here

bool Unit::CanSwim() const
{
    // Mirror client behavior, if this method returns false then client will not use swimming animation and for players will apply gravity as if there was no water
    if (HasFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_CANNOT_SWIM))
        return false;
    if (HasFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_PLAYER_CONTROLLED)) // is player
        return true;
    if (HasFlag(UNIT_FIELD_FLAGS_2, 0x1000000))
        return false;
    if (HasFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_PET_IN_COMBAT))
        return true;
    return HasFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_RENAME | UNIT_FLAG_SWIMMING);
}

[ratkosrb]

I also see Onyxian Whelp (11262) and Ragnaros (11502) with UNIT_FLAG_NON_ATTACKABLE (flag 2) in Classic sniffs.

[offl]

Ragnaros (11502) - no flag in 4xx, no spawn-in spell as well, I guess removed in 4xx
Onyxian Whelp (11262) - yep. they uses https://tcubuntu.northeurope.cloudapp.azure.com/aowow/?spell=15750
I guess all spells with cast time and effect Spawn may use that flag

Actually I think if we want to discuss it, we need new global issue and multiple separate for each flag because there are lots of them, each is unique and requires unique fixes. Some of them may be just renamed, but other are used and their name should match what they do
This issue is mostly about dissalowing and purging flags and I really hope those IsAllowed will be implemented because I really don't want to clean up DB again

We also have https://github.com/TrinityCore/TrinityCore/discussions
I can add all new comments to it or to new issue, or we all can do it by chronological order

Or I can just move everything related to IsAllowed to new issue

[xvwyh]

@Wolffenstein

UNIT_FLAG_UNK_6 is indeed related to plus mobs, I was wondering what that was when I was digging into it a while ago as well. It's super ancient but IIRC there's still a script function to check if mob is a "plus mob" in 2.4.3 client (might be misremembering though). All in all it can be renamed to get rid of UNK and left unused.

Don't see why unused, just make the server set if if creature_template.rank >= elite, and unset it otherwise, to match retail behavior. Like I said, they're still using it, it just doesn't matter to the client.

UNIT_FLAG_UNK_29 is definitely UNIT_FLAG_FEIGN_DEATH and it should have been renamed to that long ago already.

There's already UNIT_FLAG2_FEIGN_DEATH with that name, someone needs to figure out what part of the behavior relies on what flag.

but I have UNIT_FLAG_SERVER_CONTROLLED as UNIT_FLAG_DONT_FADE_IN

That's definitely wrong, "no fade in" is in unit_flags2 as UNIT_FLAG2_INSTANTLY_APPEAR_MODEL.

I'm not sure if "Uninteractible" would be fully valid here

Well, that's how blizzard called it. :D
I'd just call it "beastmaster" to be extra obscure and to dissuade people from using it, as in 99% of the cases they should use ImmunePC/NPC instead. (read below)

@offl

Or just removes

Something that always bothered me was that on that one screenshot of WowEdit with zul'drak we could see that they use "Spawn" action inside "Spawn" event. It could be that all creatures by default spawn with that flag, making them non attackable, and designers need to explicitly call the Spawn command, be it through the script or through Birth spell (SPELL_EFFECT_SPAWN). But my god that would be incredibly painful to work with. So it's probably not that.

Currently that flag acts like 'I can attack, nobody can attack me', I don't know if it's correct behavior.

I think it's correct, I'm sure the CanAttackTarget/CanAssistTarget functions in client have been extensively examined and ported to the server, so if there was anything blocking attacks if you have that flag on you - it would've been ported already.

Typically the creature would be busy with casting that Birth spell, and because of that it won't be attacking anybody.

Uninteractible... thing is Blizz devs also calls UNIT_FLAG_NOT_SELECTABLE Uninteractible

Fuck. Yeah, you're right, there are no other script actions that would resemble UNIT_FLAG_NOT_SELECTABLE. The only one I see if "Unit(s) Set Untargetable By Client", but it's from Cata, so it's more likely one of the flags from UnitFlags2 that prevents targeting but still allows the creature to be spellclicked (e.g. secret statuettes in Uldum).

It's so crazy that they changed the functionality of that script action mid-way through development, after no doubt many scripts were already using it. And they did change it, the actions that once were "beastmaster"-related changed to "uninteractive/non-selectable", they kept the same enum value.

Or, well, maybe actually nobody was using it, and they just reused them. Doubt we'll ever know.

Are you sure it's a runtime flag?

Everything in unit flags is a runtime flag. That's the reason it's there and not in, say, creature_template.type_flags, i.e. static cache. But whether the server ever toggles it - that's a different question. :D

But yes, I'm 100% certain it's "plus mob" flag.

Because your explanation looks more like 'let's make it too serverside' if it's used by all elites.

What I'm saying is that AT SOME POINT during development it:
a) was toggleable at runtime by the server for whatever reason, making the creature elite or not in reaction to SOMETHING, I have no idea what.
b) needed to be passed to client to display a different unitframe, but neither "type_flags" nor "rank" existed yet. So "eliteness" was passed via that flag, and they just never got rid of it, despite the fact that "eliteness" is now defined in a "rank" field in creature cache, so it's fixed and can never change at runtime anymore.

I'm more inclined to believe it's b). Just a remnant of the old system, still sort of supported even tho there's no reason for it anymore.

Also we all forgot about https://github.com/TrinityCore/WowPacketParser/blob/master/WowPacketParser/Enums/UnitFlags.cs
Some names & explanation were added to https://trinitycore.atlassian.net/wiki/spaces/tc/pages/1200128167/creature+template+3.3.5a#creature_template(3.3.5a)-unit_flags
PreventEmotes looks more correct if emotes are really prevented. I guess something is for sure prevented :D

Didn't know about this. Yes, I like this more. To hell with pure mounts! It was nothing but a guess anyway.

P.S. I saw UNIT_FLAG_RENAME two times when creatures were going to attacks critters. Also current name is super confusing, is it 'rename me' or 'rename'?
Used here

😮

We also have https://github.com/TrinityCore/TrinityCore/discussions

Freakin' finally. I no longer need to create "issues" about all this crap. :D

[xvwyh]

@ratkosrb

in Classic sniffs.

I searched far and wide for a sniffer, and didn't find one, goddammit! Don't tell me now that it existed. 1.5 years of gameplay for nothing! :D

[offl]

Everything in unit flags is a runtime flag. That's the reason it's there and not in, say, creature_template.type_flags, i.e. static cache. But whether the server ever toggles it - that's a different question. :D

If flag was added in CreatureDifficulty, it was added in Blizz's version of creature_template, so treated as default value, mostly they are not going to change that value. Yeah, they all are runtime but some are stored in DB and other should never be
I mean should we store it in DB or never store it in DB and apply if rank > 0?

[xvwyh]

I mean should we store it in DB or never store it in DB and apply if rank > 0? Because mostly all of them we should never store in DB

Unless someone finds definitive proof that SOME creatures with rank >= elite shouldn't have it or vice versa - we shouldn't store it in DB.

Also re: UNIT_FLAG_RENAME

I don't know what it's used for. It used to be used for pet renames, but it was later moved to a different field:
https://github.com/cmangos/mangos-classic/blob/185032ca367bf0890faf648130881f8a86079823/src/game/Entities/Unit.h#L489-L490

[offl]

Parser will go crazy if we remove that flag. It will try to update all those 8k creatures

In 3xx UNIT_FLAG_RENAME definitely used for something else, however I didn't tried to understand what exactly it does

[offl]

I also see Onyxian Whelp (11262) and Ragnaros (11502) with UNIT_FLAG_NON_ATTACKABLE (flag 2) in Classic sniffs.

Ragnaros (11502) - no flag in 4xx, no spawn-in spell as well, I guess removed in 4xx
Onyxian Whelp (11262) - yep. they uses https://tcubuntu.northeurope.cloudapp.azure.com/aowow/?spell=15750
I guess all spells with cast time and effect Spawn may use that flag

I guess all spells with cast time and effect Spawn may use that flag

Yeah, with no doubt
https://tcubuntu.northeurope.cloudapp.azure.com/aowow/?spell=34302 too adds and removes flag 2

[offl]

I guess if creature has flag (immune, not selectable) in CreateObject packet (read default set of flags after spawn, value we set directly in creature_template) but not in CreatureDifficulty, that may mean flag is set manually in script to prevent creature to reset flag after evade

[offl]

Currently we check if creature is elite to calculate skinning skill gain and experience

void Spell::EffectSkinning(SpellEffIndex /*effIndex*/)
{
    // Double chances for elites
    player->UpdateGatherSkill(skill, skillValue, reqValue, creature->isElite() ? 2 : 1);
}

                    if (creature->isElite())
                    {
                        // Elites in instances have a 2.75x XP bonus instead of the regular 2x world bonus.
                        if (u->GetMap()->IsDungeon())
                            xpMod *= 2.75f;
                        else
                            xpMod *= 2.0f;
                    }