Description:
CREATURE_TYPEFLAGS_FORCE_GOSSIP forces the client to show the gossip text for trainers, vendors and flight masters, even if they only have one gossip option to show.
Without this flag, when there is only one gossip option to choose, the client will automatically pick it for you. Flight masters will automatically show the flight path choices, vendors will show the items they sell, and so on.
Sometime in WotLK, this typeflag seems to have been abandoned. Flight masters, trainers and vendors all seem to skip the gossip text if they aren't currently involved in a quest.
More examples: this vendor, this other vendor, every class trainer in every starting zone, at the very least.
I don't know if there are enough sniffs around to re-parse every creature template as it was in 3.3.5a. But if this flag is still in use, it's very likely limited to a limited handful of cases (it has no effect on gameplay, it's mostly a cosmetic thing).
I think it's safe to remove it from every creature and re-add it manually if any such case is found.
Branch(es): 3.3.5
TC rev. hash/commit: f55ca6b
TDB version: 335.63
Suggested fix:
To revert change in 90ef83a:
UPDATE `creature_template` SET `type_flags`=`type_flags`&~134217728 WHERE `npcflag`>16 AND `gossip_menu_id`!= 0 AND `type_flags`&134217728;
To remove it everywhere instead:
UPDATE `creature_template` SET `type_flags`=`type_flags`&~134217728 WHERE `type_flags`&134217728;
Note: deleting the cache is needed for the change to show client-side.
The typeflag isn't abandoned. The problem is a commit where the flag was added to all npcs with only 1 gossip_menu_option (incorrect).
But there are many npcs with gossip and only 1 gossip_menu_option that never show the gossip.
@meji46: you're right, I assumed it was sniffed in a past version.
I'll try to dig up the commit that changed it and check which creatures had it before the change.
EDIT: here it is: 90ef83a
1432 creatures were affected by that commit. 12 creatures already had the flag before. Changed fix to only revert that commit's change.
There's a Type Flags field in SMSG_QUERY_CREATURE_RESPONSE, not sure if it's related to the type_flags in creature_template though.
@Killyana: do you perhaps remember any case where a creature should show gossip text with only one gossip option?
EDIT 2: even some creatures that had the flag before that commit make no sense (Gaeriyan doesn't even have any gossip option, for example). I'm still of the idea that it should be dropped everywhere and re-added if any case is found from sniffs or videos.
No, I just added this flag because I don't understand why there's a gossip text if it's never shown to the player, also it's more RP to read a text before access to the menu proposed by the npc.
You can run this SQL and it should produce all menu_ids that have a text at top of the gossip menu. The text is specifically coded for the gossip menu, so it could be quest immersion breaking for not to show the menu.
select GMO.menuid, GMO.optiontext, NT.* from (select *, count(*) as GMOC from gossip_menu_option group by menuid) GMO inner join gossip_menu GM on GM.menuid = GMO.menuid inner join npc_text NT on NT.ID = GM.TextID where GMOC = 1 ;
This SQL does not however show all cases where the flag would be needed as there may not be a text at the top of the menu always, but instead the gossip option label is what you should show.
Removing the flag is hard since you would screw everyone's custom content btw. Also you would need to add it back to make quests and other work more properly as shown above. I would suggest not removing the flag. Instead correct the ones that are wrong atm if possible, and add to any that dont have it but have a single gossip option coded in DB.
Removing this flag doesn't really break anything though, it just makes it so that if a creature is a vendor/trainer/flight master, and the player talking with it has no quest involving that creature, it skips the gossip text and goes straight to the vendor/training/flight path window.
That is the blizzlike behaviour - as shown by old videos. So far, every trainer (every race's starting zone, it's irrelevant at level 10+ due to more options being available), every vendor and every flight master I could check shows this behaviour.
It's bad for RP, but we have to decide whether or not that is more important than blizzlikeness.
It cannot be blizzlike to remove the flag from every NPC.
As I tried to show above it will destroy NPCs that have things to say in their gossip header text. This will destroy quest immersion and cannot thus be blizzlike.
For example in a quest (I have completed long ago ingame and cannot remember any ID or name) you need to talk to an NPC in order to finish the quest. The NPC has multiple menus that only have a single option for advancing the dialog.
Removing the flag would cause you to instantly get the quest completion checkmark instead of being able to read the dialog you are supposed to.
It may not functionally break anything, but it practically does and not even for pure "RP reasons" like seeing "I want to browse your goods" for vendors. You will be unable to see important quest texts!
The point is that this flag was not added based on sniffs or any other criteria related to retail.
This does not affect gossip options that aren't related to vendors/trainers/flight masters. For example, take the quest Lost in Battle where you need to talk with NPC Beaten Corpse.
This NPC only has one gossip option, but it's not handled by this flag. As such you can see it and click it. The quest works perfectly with or without this flag.
You just won't see the "I want to browse your goods", "Train me" and similar gossip options. Anything else is not affected.
As a rule of thumb, this only affects NPCs that, when you hover the cursor over them, have a special (a satchel for vendors, a book for trainers...) cursor icon.
It's blizzlike @Rochet2 . The flag only affects gossip_menu_option different from GOSSIP_OPTION_GOSSIP.
NPCs with 1 gossip_menu_option (vendor, flight master, etc.) and without the flag (hidden gossip menu) usually have another gossip_menu_option (with conditions) related to quests. The gossip menu avoids the "Greetings $N" in those situations (it works just like quest_greetings)
I was worried it would touch all single options.
But I see now that the reason Beaten Corpse works is that it has gossip_menu_option.optionicon 0.
For any option icon between 1-10 the flag is needed to show the single gossip option as meji46 said.
However I would still suggest that a no complete removal is made in any case. Rather revert the commit with the provided SQL or only apply the change to NPCs in TC DB.
Then I think this can be committed:
UPDATE `creature_template` SET `type_flags`=`type_flags`&~134217728 WHERE `npcflag`>16 AND `gossip_menu_id`!= 0 AND `type_flags`&134217728;
Reverts 90ef83a and makes most of (if not all) the NPCs involved act in a blizzlike way.
Is there any practical difference between
SET `type_flags`=`type_flags`-134217728
and
SET `type_flags`=`type_flags`|~134217728
in this case? (I have mostly seen the last method used, but I suppose the first method is valid too)
Do you mean this?
SET `type_flags`=`type_flags`&~134217728
Technically this one is a bitwise operation, while what I used is arithmetic. They're pratically equal in this case, but you're right, bitwise seems to be more used around here. I'll change it, thanks :P
Thanks. I often confuse how the operators are written if I don't look up the details in older commits, so thank you for pointing out the correct one. 馃憤
Any news on this one?
There's enough proof that Blizzard wanted to hide those gossip texts on 3.3.5a - a trend they kept for Cataclysm and beyond.
But if we want TC's experience to resemble those old let's play videos from WotLK, this is cosmetically needed :P
Final query, for reference:
UPDATE `creature_template` SET `type_flags`=`type_flags`&~134217728 WHERE `npcflag`>16 AND `gossip_menu_id`!= 0 AND `type_flags`&134217728;
To be on the safe side, I would prefer if either @Aokromes or @Killyana could confirm this and push it (with or without supplemental changes to the DB).
Just a thought: Would it be possible (let alone practical) to create a configurable option to choose whether to show or not to show the single gossip option?