pasdVn
-
Posts
261 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Posts posted by pasdVn
-
-
1) No, sql's are not needed anymore. I decided to make it directly, and not give focused fire any artificial proc flags.
2) Probably you are right. Maybe it's better to add any hardcoded check in checkcast? I just thought I could include it there, if hI ave to hack around in HandleDummyAura^^
-
Having a look at the description of TempSummonTypes in Object.h and the calculation of the despawn time in TemporarySummon::Update, you may notice that TEMPSUMMON_TIMED_OR_CORPSE_DESPAWN and TEMPSUMMON_TIMED_OR_DEAD_DESPAWN doing not the same as the description says. Looks like somebody copy'n'pasted here and forgot to modify!?
From 6944453630754217f38115e1118c5b9ac3ef2160 Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Fri, 12 Mar 2010 18:34:11 +0100 Subject: [PATCH] Fixed despawn logic of some temporary summons. --- src/game/TemporarySummon.cpp | 30 ++++++++++-------------------- 1 files changed, 10 insertions(+), 20 deletions(-) diff --git a/src/game/TemporarySummon.cpp b/src/game/TemporarySummon.cpp index 09c0661..7977eb9 100644 --- a/src/game/TemporarySummon.cpp +++ b/src/game/TemporarySummon.cpp @@ -104,18 +104,13 @@ void TemporarySummon::Update( uint32 diff ) return; } - if (!isInCombat()) + if (m_timer <= diff) { - if (m_timer <= diff) - { - UnSummon(); - return; - } - else - m_timer -= diff; + UnSummon(); + return; } - else if (m_timer != m_lifetime) - m_timer = m_lifetime; + else + m_timer -= diff; break; } case TEMPSUMMON_TIMED_OR_DEAD_DESPAWN: @@ -127,18 +122,13 @@ void TemporarySummon::Update( uint32 diff ) return; } - if (!isInCombat() && isAlive() ) + if (m_timer <= diff) { - if (m_timer <= diff) - { - UnSummon(); - return; - } - else - m_timer -= diff; + UnSummon(); + return; } - else if (m_timer != m_lifetime) - m_timer = m_lifetime; + else + m_timer -= diff; break; } default: -- 1.6.5.1.1367.gcd48
-
Don't know, if this is done out of intention, but currently e.g. auras defined in creature_addon or creature_template_addon are lost, if the creature evades the first time. In EventAI they get reloaded when creature reaches home. I think we sould do this also for AgressorAI!
From c83a0c51b0f277305de04e894a9de96d04e0797d Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Fri, 12 Mar 2010 18:13:40 +0100 Subject: [PATCH] Reload CreatureAddon at reaching home in AggressorAI --- src/game/AggressorAI.cpp | 5 +++++ src/game/AggressorAI.h | 1 + 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/game/AggressorAI.cpp b/src/game/AggressorAI.cpp index 4ab9a7a..51d3ec8 100644 --- a/src/game/AggressorAI.cpp +++ b/src/game/AggressorAI.cpp @@ -40,6 +40,11 @@ AggressorAI::AggressorAI(Creature *c) : CreatureAI(c), i_victimGuid(0), i_state( { } +void AggressorAI::JustReachedHome() +{ + m_creature->LoadCreaturesAddon(); +} + void AggressorAI::MoveInLineOfSight(Unit *u) { diff --git a/src/game/AggressorAI.h b/src/game/AggressorAI.h index 7b8feed..28b562c 100644 --- a/src/game/AggressorAI.h +++ b/src/game/AggressorAI.h @@ -36,6 +36,7 @@ class MANGOS_DLL_DECL AggressorAI : public CreatureAI explicit AggressorAI(Creature *c); + void JustReachedHome(); void MoveInLineOfSight(Unit *); void AttackStart(Unit *); void EnterEvadeMode(); -- 1.6.5.1.1367.gcd48
-
Update of patch for [9576], hoping that anyboy likes the patch :-D
-
No No
We have to use this object searcher to find the corpse. Ther have been some changes in [9510] that makes this class not fit to the tempalte of FindCorpseUsing (we need a Unit, no player). As this class is in fact not used, nobody noticed it. For any reason I am not abled to comment on commits at github currently :-/
I updated the patch in first post.
-
As this patch seems to be quite popular currently, I updated/rewrote it a bit.
What I noticed, is that the pet's dummy aura can also proc from hot's (Spirit Bonde) the proc flag (PROC_FLAG_ON_DO_PERIODIC) does not differentiate bewteen damage or healing :-/. Using SpellFamilyFlags is also not possible here, because than we would get procs from Growl.... But anyway it's no problem, as we can check everything during the dummy proc. I just wondered, how this is done with other procs...
Edit: przemratajczak, you are right. This hack is not needed anymore
-
That is no bug, it's a feature!
How do you think it should work work?^^ Have 3 ticks, even if your channeling time is reduced by a hit? I would always try to get often hitted, when using penance... some extra haste
-
Yes I did not include it in the branch. Makes no sense for me, as this is anyway not a part of the mangos project ^^. Take this Link: http://gist.github.com/273793 (the 2nd 'part' of the patch in the first post).
-
Improved Soul Leech: http://www.wowhead.com/?spell=54117
Not much to say. There are 4 different energize spells (1%, 2% each one time for master and one time for pet). I took the Sollution via CastCustomSpell. Don't know if this has any disadvantages...
http://github.com/pasdVn/mangos/commit/3dafce9ae824a9de5bfbf02da3ee8cd34de5559c
-
Siphon Life: http://www.wowhead.com/?spell=63108
It procs two times (from both auras), because we also alow SPELL_AURA_ADD_PCT_MODIFIER to trigger spells. Don't know if this is really necessary and maybe a general problem we should think about.
From this point of view, this fix is more like a workaround:
http://github.com/pasdVn/mangos/commit/7bc839ed6fa28e2478e38dca930652629b4e8bc7
-
Thats a problem of implicit target type 77. It will currently only work, if you focused a valid unit target (e.g. yourself).
-
The current implementation of this proc does not work (restore mana on unit kill, when Drain Soul is channeled). Maybe spells changed (I did not check that). Anyway, here is a fix, that makes it working:
http://github.com/pasdVn/mangos/commit/0c777d68865a0b9c6d82588db116c5b9c90bb4aa.patch
Improved Drain Soul: http://www.wowhead.com/?spell=18372
Drain Soul: http://www.wowhead.com/?spell=1120
-
Only the first chain heal target should benefit from this effect. My sollution to check this is via spell::m_targets, where the origninal client sended unit target is stored (this will also be the first chain heal target). Unfortunately m_targets is declared as private... Maybe we should write a method to access m_targets.unitTarget, but I did not want to do this for one strange spelleffect^^ Maybe there is also another sollution, to find out which one is the first chain target?
-
There is a general problem with this implemetation: The Buff is removed before the damage calculation. Normally it should be removed afterwards (like spellmods). I wrote a hacky fix some days ago^^: http://github.com/pasdVn/mangos/commit/e4ff2c347c1b47388b3e4fd4a8bb963f17af96fd
-
I think there is missing a parameter in function call. Without this, spells will be set as ACT_DISABLED in your Pet Action bar (you won't see these golden edges...^^), but in the next step added to m_autospells.
You will notice this bugfix, if you summon a temporary pet and the autocast state is displayed correcly (as saved the last time
).From 3cdec27d71add4d7aa235146f49200b0031d2404 Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Sat, 27 Feb 2010 16:01:46 +0100 Subject: [PATCH 1/2] Fixed autocast problem at temp.-pet loading. * autocast edges should no be shown correctly at client --- src/game/Pet.cpp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/game/Pet.cpp b/src/game/Pet.cpp index 7d89467..9127dc5 100644 --- a/src/game/Pet.cpp +++ b/src/game/Pet.cpp @@ -1395,7 +1395,7 @@ bool Pet::addSpell(uint32 spell_id,ActiveStates active /*= ACT_DECIDE*/, PetSpel if (IsPassiveSpell(spell_id)) CastSpell(this, spell_id, true); else - m_charmInfo->AddSpellToActionBar(spell_id); + m_charmInfo->AddSpellToActionBar(spell_id, ActiveStates(newspell.active)); if(newspell.active == ACT_ENABLED) ToggleAutocast(spell_id, true); -- 1.6.5.1.1367.gcd48
-
Thx, fixed it
-
Fixes the second effect of Riptide (Chain Heal Boost). We have to do this in Effect::Heal, because we have to access Spell::m_targets.
From 4ba89bd2ca23d2d47e2338893925259f2bf31403 Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Sat, 27 Feb 2010 11:27:25 +0100 Subject: [PATCH] Fixed Riptide Chain heal boost. --- src/game/SpellEffects.cpp | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/src/game/SpellEffects.cpp b/src/game/SpellEffects.cpp index 14b478a..e5ee64e 100644 --- a/src/game/SpellEffects.cpp +++ b/src/game/SpellEffects.cpp @@ -2948,6 +2948,19 @@ void Spell::EffectHeal(SpellEffectIndex /*eff_idx*/) addhealth = caster->SpellHealingBonus(unitTarget, m_spellInfo, addhealth, HEAL); m_healing+=addhealth; + + // Chain Healing + if (m_spellInfo->SpellFamilyName == SPELLFAMILY_SHAMAN && m_spellInfo->SpellFamilyFlags & UI64LIT(0x0000000000000100)) + { + // check for Riptide + if (unitTarget != m_targets.getUnitTarget()) + return; + Aura* riptide = unitTarget->GetAura(SPELL_AURA_PERIODIC_HEAL, SPELLFAMILY_SHAMAN, 0, 0x00000010, caster->GetGUID()); + if (!riptide) + return; + m_healing *= 1.25f; + unitTarget->RemoveAura(riptide); + } } } -- 1.6.5.1.1367.gcd48
-
As it was already mentioned the problem is, that the heal spell has SPELL_DAMAGE_CLASS_NONE. It would need some bigger changes in the bonus calculation logic to solve this problem clean (I think the original periodic trigger aura should receive the spell bonus, and cast the dummy aura with value...). SQL does not help here^^
-
I'm going to write you a PM. I think this is better than doing this conversation via the forum
-
Can I simply add the new versions into my server sources by manually editing or will there need to be some changes made to the patches, like renaming variables/classes/functions or declaring a uint64 as uint32?
Mostly that are really minor changes, another coding style or other small things. So I think it should be no problem for you to fix some merge errors by hand imo^^ Just be careful: The 'pet' branch is completly rebased, so probably you have some more work, if you merge with an older version of this branch, but that's off topic now :-/.
-
Hmm, not clear?
My Patch:
Just makes it possible, that triggerauras with multiple procEx flags (those, that are defined in spell_proc_event) - that means PROC_EX_NORMAL_HIT and anything else like PROC_EX_DODGE, PROC_EX_BLOCK - are abled to proc a spell. Currently we have the case that it is possible that they do not trigger because of 0 damage (-> active is false in IsSpellProcEventCanTriggeredBy). For example imgine a completly blocked attack.
Other solution is maybe just to remove this whole line, but don't know if this is correct. If this patch is such a problem just ignore it^^ I thought it is quite evident :-/
The one of KAPATEJIb does something else:
Just adds PROC_EX_NORMAL_HIT to spells that are are blocked or absorbed, but not completly. For example it makes possible that this spell can even trigger if you block a part of the damage.
Hmm, I can't find anything bad in masking a value multiple times :confused:By the way, this & PROC_EX_NORMAL_HIT & procExtramakes my eyes bleed...
-
- wrong post sry -
Needs hack or maybe we can find any flag?
-
Ah nice! That is also a thing that does not work correctly
(or how is this handled at official servers?.. partly blocked also a normal hit!?). Problem that is fixed by my patch is, the problem, when damage is blocked by 100% and so 'active' is false in IsSpellProcEventCanTriggeredBy(...).
-
Imagine the following problem:
A proctrigger aura has procflagsEx = PROC_EX_NORMAL_HIT | PROC_EX_BLOCK. When an attack gets blocked by 100%, there won't be triggered anything, because of a bug in SpellMgr::IsSpellProcEventCanTriggeredBy(...).
Don't know, if there are spells with such procExs currently, but at least there have been some in earlier versions.
From 8c47039bf1a3d33cbeb98c04d6516d0606e1f9f1 Mon Sep 17 00:00:00 2001 From: pasdVn <[email protected]> Date: Wed, 7 Oct 2009 14:21:00 +0200 Subject: [PATCH] fix proc bug with multiple proxEx flags Allow spells with multiple procEx flags to trigger also with 0 dmg, if current procExtra is no normal hit (e.g. block and normal hit as flags -> all dmg blocked). --- src/game/SpellMgr.cpp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/game/SpellMgr.cpp b/src/game/SpellMgr.cpp index 37fb5a0..7ea4d0a 100644 --- a/src/game/SpellMgr.cpp +++ b/src/game/SpellMgr.cpp @@ -1153,7 +1153,7 @@ bool SpellMgr::IsSpellProcEventCanTriggeredBy(SpellProcEventEntry const * spellP if (procEvent_procEx & PROC_EX_EX_TRIGGER_ALWAYS) return true; // Passive spells can`t trigger if need hit - if ((procEvent_procEx & PROC_EX_NORMAL_HIT) && !active) + if ((procEvent_procEx & PROC_EX_NORMAL_HIT & procExtra)&& !active) return false; // Check Extra Requirement like (hit/crit/miss/resist/parry/dodge/block/immune/reflect/absorb and other) if (procEvent_procEx & procExtra) -- 1.6.5.1.1367.gcd48
Contact Us
You can also email us at [email protected]
Privacy Policy | Terms & Conditions
[fix] trigger logic on trap activation
in ... under reviewOld
Posted
Just a small fix of a bug in SpellMgr::IsSpellProcEventCanTriggeredBy(), without paying attention to other bugs of this proc flag: It should definitly not trigger without checking other conditions!
If you just have a look at [this]spell as example, you will agree, that we have to check the spellfamilyflags in addition, because there are more spells with this proc flag (-> traps
) than those two.
I am quite sure, that I posted this fix years ago, but did not find it anymore^^