Schmoozerd

In [11827].

First note is that in wotlk the dummy spell 18947 is removed. So the solution for wotlk will look like: In void Aura::TriggerSpell() CastCustomSpell(19698 , BASEPOINTS==GetAuraTicks()*someDmg) On classic however you are right, you must use the dummy spell. The dummy spell should be cast with a triggeredByAura parameter, this should give you the tools to either get the duration or also get the Tick count with GetAuraTicks

In [11823] - at least the part for the npc flag - which is far more important

Just post your fixes in the review section

It is relevant - only I would like to talk to NF about this (and the other patch by Neatelves), as he knows most of the gossip handling.

in [11815], Thank you

In 11814. Thank you

In [11813] Thank you.

Simplier version added in 11812, thank you.

I noted today that for a few achievement criteria types we require entries in `achievement_criteria_requirement` in the world-db, but that we don't throw errors them if they don't have db entries. This patch would add throwing errors for criterias of types * ACHIEVEMENT_CRITERIA_TYPE_BE_SPELL_TARGET * ACHIEVEMENT_CRITERIA_TYPE_BE_SPELL_TARGET2 * ACHIEVEMENT_CRITERIA_TYPE_ON_LOGIN However I see no use to directly push this patch in haste. So I suggest you use this patch locally, add db-entries (likely (id, 0, 0, 0) or (id, 11, 0, 0) ) for missing types, and when you have released updatepacks which fix them you notify and I can push this change to master. diff --git a/src/game/AchievementMgr.cpp b/src/game/AchievementMgr.cpp index ca38d9f..fc21e3e 100644 --- a/src/game/AchievementMgr.cpp +++ b/src/game/AchievementMgr.cpp @@ -2345,8 +2345,6 @@ void AchievementGlobalMgr::LoadAchievementCriteriaRequirements() if(!criteria->win_bg.additionalRequirement1_type && !criteria->win_bg.additionalRequirement2_type) continue; break; - case ACHIEVEMENT_CRITERIA_TYPE_KILL_CREATURE: - break; // any cases case ACHIEVEMENT_CRITERIA_TYPE_COMPLETE_QUEST: { AchievementEntry const* achievement = sAchievementStore.LookupEntry(criteria->referredAchievement); @@ -2367,32 +2365,35 @@ void AchievementGlobalMgr::LoadAchievementCriteriaRequirements() continue; } } - case ACHIEVEMENT_CRITERIA_TYPE_FALL_WITHOUT_DYING: - break; // any cases - case ACHIEVEMENT_CRITERIA_TYPE_CAST_SPELL: // any cases - break; case ACHIEVEMENT_CRITERIA_TYPE_WIN_RATED_ARENA: // need skip generic cases if(criteria->win_rated_arena.flag!=ACHIEVEMENT_CRITERIA_CONDITION_NO_LOOSE) continue; break; - case ACHIEVEMENT_CRITERIA_TYPE_EQUIP_EPIC_ITEM: // any cases - break; case ACHIEVEMENT_CRITERIA_TYPE_DO_EMOTE: // need skip generic cases if(criteria->do_emote.count==0) continue; break; - case ACHIEVEMENT_CRITERIA_TYPE_SPECIAL_PVP_KILL:// any cases - break; case ACHIEVEMENT_CRITERIA_TYPE_WIN_DUEL: // skip statistics if(criteria->win_duel.duelCount==0) continue; break; - case ACHIEVEMENT_CRITERIA_TYPE_CAST_SPELL2: // any cases - break; case ACHIEVEMENT_CRITERIA_TYPE_LOOT_TYPE: // need skip generic cases if(criteria->loot_type.lootTypeCount!=1) continue; break; + + // any cases + case ACHIEVEMENT_CRITERIA_TYPE_KILL_CREATURE: + case ACHIEVEMENT_CRITERIA_TYPE_FALL_WITHOUT_DYING: + case ACHIEVEMENT_CRITERIA_TYPE_BE_SPELL_TARGET: + case ACHIEVEMENT_CRITERIA_TYPE_CAST_SPELL: + case ACHIEVEMENT_CRITERIA_TYPE_EQUIP_EPIC_ITEM: + case ACHIEVEMENT_CRITERIA_TYPE_BE_SPELL_TARGET2: + case ACHIEVEMENT_CRITERIA_TYPE_SPECIAL_PVP_KILL: + case ACHIEVEMENT_CRITERIA_TYPE_ON_LOGIN: + case ACHIEVEMENT_CRITERIA_TYPE_CAST_SPELL2: + break; + default: // type not use DB data, ignore continue; }

hm - if I don't miss a thing these much simplier changes are enough to improve the things you improve in your patch. But ofc if more powerfull features are required, more changes will be needed with this simplier approach. Assuming I have no logic mistake, I think I would prefer this because: * I think we should change the way Text is handled to, wrapt the many functions into one DoMonsterText(ChatType t, ...) instead of the various chat-type functions * Clearify if we want to use MonsterYellToZone or replace this with Map::MonsterYellToMap About the nordend fishing event I think we need a bit more information, like: Text said by one mob that can be heard in all-except-one zones, or are there many mobs who tell texts? Also I tend to wonder about maybe adding phase checks related to yell (not sure if the default MonsterText workers already take this into account), the Map:: functions don't. diff --git a/src/game/Map.cpp b/src/game/Map.cpp index 6a4a5e1..bc86d42 100644 --- a/src/game/Map.cpp +++ b/src/game/Map.cpp @@ -3230,13 +3230,15 @@ void Map::MonsterYellToMap(CreatureInfo const* cinfo, int32 textId, uint32 langu * Function to play sound to all players in map * * @param soundId Played Sound + * @param zoneId Id of the Zone to which the sound should be restricted */ -void Map::PlayDirectSoundToMap(uint32 soundId) +void Map::PlayDirectSoundToMap(uint32 soundId, uint32 zoneId /*=0*/) { WorldPacket data(SMSG_PLAY_SOUND, 4); data << uint32(soundId); Map::PlayerList const& pList = GetPlayers(); for (PlayerList::const_iterator itr = pList.begin(); itr != pList.end(); ++itr) - itr->getSource()->SendDirectMessage(&data); + if (!zoneId || itr->getSource()->GetZoneId() == zoneId) + itr->getSource()->SendDirectMessage(&data); } diff --git a/src/game/Map.h b/src/game/Map.h index 31e8731..8bcbb9d 100644 --- a/src/game/Map.h +++ b/src/game/Map.h @@ -257,7 +257,7 @@ class MANGOS_DLL_SPEC Map : public GridRefManager<NGridType> void MonsterYellToMap(ObjectGuid guid, int32 textId, uint32 language, Unit* target); void MonsterYellToMap(CreatureInfo const* cinfo, int32 textId, uint32 language, Unit* target, uint32 senderLowGuid = 0); - void PlayDirectSoundToMap(uint32 soundId); + void PlayDirectSoundToMap(uint32 soundId, uint32 zoneId); private: void LoadMapAndVMap(int gx, int gy); -- ------------------- Changes in SD2: diff --git a/ScriptMgr.cpp b/ScriptMgr.cpp index 04c9ebb..e058b4f 100644 --- a/ScriptMgr.cpp +++ b/ScriptMgr.cpp @@ -166,7 +165,12 @@ void DoScriptText(int32 iTextEntry, WorldObject* pSource, Unit* pTarget) if (pData->uiSoundId) { if (GetSoundEntriesStore()->LookupEntry(pData->uiSoundId)) - pSource->PlayDirectSound(pData->uiSoundId); + { + if (pData->uiType == CHAT_TYPE_ZONE_YELL) + pSource->GetMap()->PlayDirectSoundToMap(pData->uiSoundId, pSource->GetZoneId()); + else + pSource->PlayDirectSound(pData->uiSoundId); + } else error_log("SD2: DoScriptText entry %i tried to process invalid sound id %u.", iTextEntry, pData->uiSoundId); }

I have heard that indeed characters can be lost. However this must be fixed proper with sql transactions and rollbacks to force that DELETE + INSERT are only done when both will succeed (And afaik they should be already secure..)

EventAI is very fine with only doing combat stuff. I think extending it should be done very slowly and only related to the main focus. (normal mob scripting) it would be possible to add a new collumn to gossip_menu, to identify a scriiptID, which would fit more naturally into current system. However one important question: Are there many or more cases where an action would be required in OnGossip-Hello? If we don't want to add a 'virtual' GOSSIP_OPTION (which is reasonable as of stlye issues) and there are only very few cases where we need this feature, maybe adding these few gossips by SD2 is as good.

The SD2 part looks wrong, there is a mismatch in the order of the params. Maybe just add a new chat-type to have only zone-yells, and treat current as Map-yells?

No, infact it was very good that you reported this bug (and many others you do) so fast! And you are right - a test with a filled DB would have showns this bug on the obvious test. However, if you change something, and know that your change cannot harm anything (which in this case is the truth, because it was basicly a rename). You don't test carefully.

Are fixed in 11808 In defense of SilverIce - this was _not_ a bug caused by his commit!

This actually seems (first look) the way it is that we have no information about any additional related spell here. About the details of the implementation I cannot say anything.

For additional information: In http://udb.no-ip.org/index.php/topic,12774.0/topicseen.html clearifies crackm that the DB-values are correct. Remark additionally that many elevators seems to be not workign correctly now. Might be some general missed problem.

I think your username "hpägaren" might cause it. Try to copy the whole mangos source tree to some other place (like C:\\Mangos\\ ) If this helps and you think this is a stupid error, then I totally agree with you.

Post your complete built-log

The error must have happened earlier. Without .git directory the genrevision creates a dull revision.h file, but it creates one.

Related to documentation: would it be possible to create somewhere a script to create some auto-documentation, publish it on the web and update it every day?

OK, do you have a patch for this effecT?

With some changes in [11801], Thank you

unfortunately these links don't hold enough information. And for research you need something trustworthy, and tc is unfortunately not trustworthy, though now and then they get something right ofc Basicly the problem boils down to a required formula: max_dmg = function(caster, feared); Where currently this formula in mangos is uint32 max_dmg = getLevel() > 8 ? 25 * getLevel() - 150 : 50; Possible we also need some additional way to store the amount of total already dealt damage (as it is said that the dear should break after a total amount of dmg is done)