breakwater

maybe you can explain, why you have write this patch with " _player->TeleportToBGEntryPoint();"

my opinion: thats the wrong place, maybe we should cancel all spells on mini pet in Spell:CheckTarget-function

new system with pointers http://paste2.org/p/1975602

Maybe someone can test this patch on a high populated server. Please no direct commit into mangosR2.

Spells this will need a check Spells with are effected by this patch: SELECT * FROM `dbc-spell` WHERE (`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA2 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB2 and `dbc-spell`.EffectImplicitTargetA1 != 0) or (`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB3 and `dbc-spell`.EffectImplicitTargetA3 != 0) or (`dbc-spell`.EffectImplicitTargetA2 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB2 = `dbc-spell`.EffectImplicitTargetB3 and `dbc-spell`.EffectImplicitTargetA2 != 0) Spells affected in Wotlk: 11728 Spells with are effected by this patch and with an different radius value: Spells that can make problems because spell target mask is same, but radius value has an other value SELECT * FROM `dbc-spell` WHERE (`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA2 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB2 and (`dbc-spell`.Effect1 > 0 and `dbc-spell`.Effect2 > 0) and `dbc-spell`.EffectRadiusIndex1 != `dbc-spell`.EffectRadiusIndex2) or (`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB3 and (`dbc-spell`.Effect1 > 0 and `dbc-spell`.Effect3 > 0) and `dbc-spell`.EffectRadiusIndex1 != `dbc-spell`.EffectRadiusIndex3) or (`dbc-spell`.EffectImplicitTargetA2 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB2 = `dbc-spell`.EffectImplicitTargetB3 and (`dbc-spell`.Effect2 > 0 and `dbc-spell`.Effect3 > 0) and `dbc-spell`.EffectRadiusIndex2 != `dbc-spell`.EffectRadiusIndex3)SELECT * FROM `dbc-spell` WHERE (`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA2 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB2 and (`dbc-spell`.Effect1 > 0 and `dbc-spell`.Effect2 > 0) and `dbc-spell`.EffectRadiusIndex1 != `dbc-spell`.EffectRadiusIndex2) or (`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB3 and (`dbc-spell`.Effect1 > 0 and `dbc-spell`.Effect3 > 0) and `dbc-spell`.EffectRadiusIndex1 != `dbc-spell`.EffectRadiusIndex3) or (`dbc-spell`.EffectImplicitTargetA2 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB2 = `dbc-spell`.EffectImplicitTargetB3 and (`dbc-spell`.Effect2 > 0 and `dbc-spell`.Effect3 > 0) and `dbc-spell`.EffectRadiusIndex2 != `dbc-spell`.EffectRadiusIndex3) Spells affected in Wotlk: 216 EDIT: A lot of Wotlk spells are fixed with this patch, because some effects has no radius (Example 72015, 72836) Spells with makes problems: often classic spells like: 6266, 3143, 8150, 10253

MANGOS_DLL_SPEC uint32 urand(uint32 min, uint32 max); ??? i think the urand(...) funcion should use direct in sd2 like this one m_uiEyebeam_Timer = 10000 + urand(1000, 5000); This works realy good, you doesn't need MANGOS_DLL_SPEC

We should check some cases in function SetTargetMap(...). The spells with same target mask must have same radius, chain-length, etc

What bug does the patch fix? What features does the patch add? For preventing an double calculation for effects with same targets For which repository revision was the patch created? actual, but i think for all Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. not know Who has been writing this patch? Please include either forum user names or email addresses. me Patch: http://paste2.org/p/1961898 new System with pointer http://paste2.org/p/1975602 Most target calculation of area spells are unnecessary. Spells with more then one spell effect with the same target mask and maybe an limitation works now right (limitation in function SetTargetMap(...)) Example Spells: 64218 63342 69674 Sry my english is bad, i hope you understand my idea.

take the Database: mangos -> table: creature_template -> column: subname

Take a deep and long look into mangos core code. Use the search functions in your favorite IDE(for OS windows ->visual c++). Good words for search are spellscript, achievement...) Maybe someone other ask the same question, use google for a good search in this forum. The original forum is stupid (30 seconds between searches; stupid solutions). Maybe you should fix some easier thinks, achievements are complex

maybe you can ask a question?

Hi author: me Revision: i think the actual([11927]) https://github.com/Reamer/mangos/commit/388a3ff5bdc21866fe5d6ad43d6abc4e92eadeb0 Now the heal from NPC's, special from shaman wolfs (last talent-spell in melee talent tree) are show in combat log.

IsReachable is already in mmaps. at the moment i have found this call in bool Unit::SelectHostileTarget() // check if currently selected target is reachable // NOTE: path alrteady generated from AttackStart() if(!GetMotionMaster()->operator->()->IsReachable()) {

stacking system need a complete rewrite in mangos Use the search function and search for: aura stacking michalpolko should post a rewrite long time ago

take a look into this commit, this should help^^ https://github.com/Reamer/mangos/commit/762edc95bc93895c3a10135bc1250e8aae144945

why the check target == PLAYER? I think that's unnecessary. I think the remove is wrong, because the player with 0 mana should die in explosion. If one player with 0 mana have 15k life, this player is alive after explosion (Basepoints from Explosion BasePoints = 10213 to 11288). But without remove the player dies in next tick . + switch (GetId()) + { + case 31447: // Mark of Kaz'rogal + { + if (target->getPowerType() == POWER_MANA && target->GetPower(POWER_MANA) == 0) + { + target->CastSpell(target, 31463, true, NULL, this); + } + break; + } + } NOT TESTET

my actual code The original cast is important, because of faction between trollgore and creatures. Trollgore should make damage http://paste2.org/p/1801801 I think that's unnecessary: target->SetDeathState(JUST_DIED); because creature is dead. Maybe a long time ago, this spell works with fake death creatures Hope thats help PS: Code is to old for a good patch-file

I think that it's more natural, that adds are despawning after a certain time 2-5 Minutes after Boss FAIL Despawn after Boss reach home (FAIL) looks unnatural, also after DONE.

maybe we can fix TEMPSUMMON_TIMED_DESPAWN_OUT_OF_COMBAT and despawn creature when dies or despawn? I think that is a lot of better

* What bug does the patch fix? What features does the patch add? add a new TemporarySummon Type * For which repository revision was the patch created? for a lot of * Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. no * Who has been writing this patch? Please include either forum user names or email addresses. me https://github.com/mangosR2/mangos/commit/90b054874e4fcc00beae426d93b76cc7879a0d0c In my eyes good for manuell summon in scripts. Example: Boss summon add, this add despawn when corpse vanish or add is a specific time outfight(if bossfight fails) Best time in my eyes 2-5 minutes

No post in under review because me solution is only a hack for some creature_models, which bouding_radius is bigger than 2. The right meaning of bouding_radius is still unknown. If someone is interested, copy the code where bounding_radius is limit to 2.

What is jFusion plugin?

After testing on gameserver with this change I can say: I have no monsters with wrong movement. If I should test special monsters movement, tell me. I post the solution in this thread.

I have 4 folders: dbc, vmaps, maps and ->buildings<- where is your building folder? Also look for a right path, I think that's the real problem

I have make a big mistake, it was late and i have change combatreach, but the meaning of combatreach is clear. I have change me core to thisone. Boundingradius has a max value of 2. I hope that helps against wrong movement void Unit::UpdateModelData() { if (CreatureModelInfo const* modelInfo = sObjectMgr.GetCreatureModelInfo(GetDisplayId())) { // we expect values in database to be relative to scale = 1.0 SetFloatValue(UNIT_FIELD_BOUNDINGRADIUS, GetObjectScale() * modelInfo->bounding_radius < 2.0f ? GetObjectScale() * modelInfo->bounding_radius : 2.0f); // never actually update combat_reach for player, it's always the same. Below player case is for initialization if (GetTypeId() == TYPEID_PLAYER) SetFloatValue(UNIT_FIELD_COMBATREACH, 1.5f); else SetFloatValue(UNIT_FIELD_COMBATREACH, GetObjectScale() * modelInfo->combat_reach); } }