dpedroia15

I understand now, thanks Ambal + Vladimir (what happened to thank you button for posts?)

On a side note, why do we use CalculateSimpleValue i.e. why do we add 1 to the basepoint value? Is this only done with spells with basepoints that appear to point towards other spells?

Ahhh yes I see what you mean, watching the video the dummy aura is not removed and you're probably right, the spell checks to see if the dummy aura is present and then continues with a script if it is there.

* What bug does the patch fix? What features does the patch add?

Implements Dummy Effect for spell 45474

* For which repository revision was the patch created?

11346

* 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!

diff --git a/src/game/SpellEffects.cpp b/src/game/SpellEffects.cpp
index f0827d9..870ce22 100644
--- a/src/game/SpellEffects.cpp
+++ b/src/game/SpellEffects.cpp
@@ -1193,6 +1193,7 @@ void Spell::EffectDummy(SpellEffectIndex eff_idx)
                    return;
                }
                case 32146:                                 // Liquid Fire
+                case 45474:                                 // Ragefist's Torch
                {
                    if (!unitTarget || unitTarget->GetTypeId() != TYPEID_UNIT || m_caster->GetTypeId() != TYPEID_PLAYER)
                        return;

* What bug does the patch fix? What features does the patch add?

Implements Script Effect and Dummy Effect for spell 45958

* For which repository revision was the patch created?

11346

* 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!

diff --git a/src/game/SpellEffects.cpp b/src/game/SpellEffects.cpp
index 7e9697b..f0827d9 100644
--- a/src/game/SpellEffects.cpp
+++ b/src/game/SpellEffects.cpp
@@ -1459,6 +1459,11 @@ void Spell::EffectDummy(SpellEffectIndex eff_idx)
                    m_caster->RemoveAurasDueToSpell(45683);
                    return;
                }
+                case 45958:                                 // Signal Alliance
+                {
+                    m_caster->CastSpell(m_caster, m_spellInfo->EffectBasePoints[eff_idx], true);
+                    return;
+                }
                case 45990:                                 // Collect Oil
                {
                    if (!unitTarget || unitTarget->GetTypeId() != TYPEID_UNIT)
@@ -6594,6 +6599,11 @@ void Spell::EffectScriptEffect(SpellEffectIndex eff_idx)

                    return;
                }
+                case 45958:                                 // Signal Alliance
+                {
+                    m_caster->RemoveAurasDueToSpell(m_spellInfo->EffectBasePoints[eff_idx]);
+                    return;
+                }
                case 46203:                                 // Goblin Weather Machine
                {
                    if (!unitTarget)

That's sort of what I'm getting at. I'm interested in how you're going to implement it. What I was suggesting was something like this (forgive me, I've been doing a lot of Java lately)

/*
* Basic mod superclass, has functions for each hook we're implementing
*/
abstract class Mod {

   abstract void onMonsterKill(ObjectGuid victimGUID, Player* killer);

   ...

   ...
}

// hooks placed in functions that we'd want to hook...I don't know if this is the best way to do it
// but for example we could have

void Player::KilledMonster( CreatureInfo const* cInfo, ObjectGuid guid )
{
   if(cInfo->Entry)
       KilledMonsterCredit(cInfo->Entry, guid);

   for(int i = 0; i < MAX_KILL_CREDIT; ++i)
       if(cInfo->KillCredit[i])
           KilledMonsterCredit(cInfo->KillCredit[i], guid);

   //hook here
   sModMgr.onMonsterKill(guid, this);
}

//and then the ModMgr would work like script manager and iterate through loaded mod scripts  for onMonsterKill
std::list<Mod*> loadedScripts;
...
void ModMgr::onMonsterKill(ObjectGuid victimGUID, Player* killer)
{
   for(std::list<Mod*>::iterator itr = loadedScripts.begin(); itr != loadedScripts.end(); ++itr)
   {
        Mod* mod = *itr;
        mod->onMonsterKill(victimGUID, killer);
   } 
}

I do not know much about how the whole ScriptMgr system works and whatnot ...nor am I too skilled with C++ but this is just a crude mockup of the idea I had.

Would it not be modular enough to introduce this concept to SD2 scripts?

I don't know how you're planning to do this, but if you make a basic "core mod" structure which people would implement by overriding certain methods they want to modify, it seems like it could fit nightly into SD2.

I believe that one of the remaining ones leads the group

In general this statement is wrong.

In instances (and this was tested by my girlfriend in SSC just last week on retail) whenever you have a group of mobs that all come together on pull...

...whenever you whipe and at least one mob is still alive, then the whole group respawns and you have to do the whole group again.

This results for mob groups that no "leader change" is needed because on enter evade all respawn and the default leader is available again to link the other mobs.

I can't imagine a case where you kill just a part of a group and the rest needs to choose a new leader and continue their path - either you defeate them or they defeat you -> no mob left or all respawn and reset.

This grouped respawn (and also grouped aggro; means that you can define mobs standing together and you can never just pull one or a part of it) behaviour is missing for MaNGOS. If you take these challenges as seperate tasks and implement these first... you don't have to worry about the behaviour when patrolling mob groups just die partly.

Please note: Just take this statement valid for TBC instances as SSC, Eye, ... that I have seen myself working that way. I didn't pay attention to this in the open world area or WotLK/Classic instance content.

This is true for all instance contents through WotLK (haven't played Cataclysm but I'd guess its the same). Like FunkyBit said, if your group fails to kill a bunch of mobs, even with only one left, the entire group will respawn.

Yes, it doesn't matter either way. I was just following the convention that most other dummy/scripted effects follow

EDIT: NoFantasy made a commit regarding this spell, thread can be moved if needed

EDIT2: Posted a newer version of the commit with a slight change of NoFantasy's commit.

* What bug does the patch fix? What features does the patch add?

Implements Script Effect for spell 24751 (Trick or Treat)

* For which repository revision was the patch created?

11241

* 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!

@@ -6229,14 +6173,6 @@ void Spell::EffectScriptEffect(SpellEffectIndex eff_idx)
                case 24590:                                 // Brittle Armor - need remove one 24575 Brittle Armor aura
                    unitTarget->RemoveAuraHolderFromStack(24575);
                    return;
+               case 24714:                                 // Trick
+                {
+                    if (roll_chance_i(14))              // Trick (can be different critter models). 14% since below can have 1 of 6
+                        unitTarget->CastSpell(unitTarget, 24753, true);
+                    else                                // Random Costume, 6 different (plus add. for gender)
+                        unitTarget->CastSpell(unitTarget, 24720, true);
+                    return;
+               }
                case 24717:                                 // Pirate Costume
                {
                    if (!unitTarget || unitTarget->GetTypeId() != TYPEID_PLAYER)
@@ -6316,9 +6252,19 @@ void Spell::EffectScriptEffect(SpellEffectIndex eff_idx)
                    // Tricked or Treated
                    unitTarget->CastSpell(unitTarget, 24755, true);

+                    uint32 trickOrTreat = (roll_chance_i(50)) ? 24714: 24715;
-                    if (roll_chance_i(50))
-                    {
-                        // Treat
-                        unitTarget->CastSpell(unitTarget, 24715, true);
-                    }
-                    else
-                    {
-                        if (roll_chance_i(14))              // Trick (can be different critter models). 14% since below can have 1 of 6
-                            unitTarget->CastSpell(unitTarget, 24753, true);
-                        else                                // Random Costume, 6 different (plus add. for gender)
-                            unitTarget->CastSpell(unitTarget, 24720, true);
-                    }

+                    unitTarget->CastSpell(unitTarget,trickOrTreat,true);
                    return;
                }
                case 26275:                                 // PX-238 Winter Wondervolt TRAP

* What bug does the patch fix? What features does the patch add?

Implements Script Effect (send cheer emote) for spell 26004 (Mistletoe)

* For which repository revision was the patch created?

11218

* 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!

diff --git a/src/game/SpellEffects.cpp b/src/game/SpellEffects.cpp
index 9ccd01c..fea324a 100644
--- a/src/game/SpellEffects.cpp
+++ b/src/game/SpellEffects.cpp
@@ -6285,7 +6285,15 @@ void Spell::EffectScriptEffect(SpellEffectIndex eff_idx)
                    unitTarget->CastSpell(unitTarget,spellid,false);
                    return;
                }
-                case 26218:                                 // Mistletoe
+                case 26004:                                 // Mistletoe (stat buff)
+                {
+                    if(!unitTarget)
+                        return;
+
+                    unitTarget->HandleEmoteCommand(EMOTE_ONESHOT_CHEER);
+                    return;
+                }
+                case 26218:                                 // Mistletoe (creation)
                {
                    if (!unitTarget || unitTarget->GetTypeId() != TYPEID_PLAYER)
                        return;

* What bug does the patch fix? What features does the patch add?

Just fixeds a spelling error in SpellAuras.cpp

* For which repository revision was the patch created?

11217

* 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!

diff --git a/src/game/SpellAuras.cpp b/src/game/SpellAuras.cpp
index 9d00d56..67fe692 100644
--- a/src/game/SpellAuras.cpp
+++ b/src/game/SpellAuras.cpp
@@ -2270,31 +2270,31 @@ void Aura::HandleAuraDummy(bool apply, bool Real)
            if (!caster || !caster->isAlive())
                return;

-            uint32 finalSpelId = 0;
+            uint32 finalSpellId = 0;
            switch(GetId())
            {
-                case 19548: finalSpelId = 19597; break;
-                case 19674: finalSpelId = 19677; break;
-                case 19687: finalSpelId = 19676; break;
-                case 19688: finalSpelId = 19678; break;
-                case 19689: finalSpelId = 19679; break;
-                case 19692: finalSpelId = 19680; break;
-                case 19693: finalSpelId = 19684; break;
-                case 19694: finalSpelId = 19681; break;
-                case 19696: finalSpelId = 19682; break;
-                case 19697: finalSpelId = 19683; break;
-                case 19699: finalSpelId = 19685; break;
-                case 19700: finalSpelId = 19686; break;
-                case 30646: finalSpelId = 30647; break;
-                case 30653: finalSpelId = 30648; break;
-                case 30654: finalSpelId = 30652; break;
-                case 30099: finalSpelId = 30100; break;
-                case 30102: finalSpelId = 30103; break;
-                case 30105: finalSpelId = 30104; break;
-            }
-
-            if (finalSpelId)
-                caster->CastSpell(target, finalSpelId, true, NULL, this);
+                case 19548: finalSpellId = 19597; break;
+                case 19674: finalSpellId = 19677; break;
+                case 19687: finalSpellId = 19676; break;
+                case 19688: finalSpellId = 19678; break;
+                case 19689: finalSpellId = 19679; break;
+                case 19692: finalSpellId = 19680; break;
+                case 19693: finalSpellId = 19684; break;
+                case 19694: finalSpellId = 19681; break;
+                case 19696: finalSpellId = 19682; break;
+                case 19697: finalSpellId = 19683; break;
+                case 19699: finalSpellId = 19685; break;
+                case 19700: finalSpellId = 19686; break;
+                case 30646: finalSpellId = 30647; break;
+                case 30653: finalSpellId = 30648; break;
+                case 30654: finalSpellId = 30652; break;
+                case 30099: finalSpellId = 30100; break;
+                case 30102: finalSpellId = 30103; break;
+                case 30105: finalSpellId = 30104; break;
+            }
+
+            if (finalSpellId)
+                caster->CastSpell(target, finalSpellId, true, NULL, this);

            return;
        }

There would be no way to do it without modifying the client DBC files. You could probably do a server side hack though if you created a character then changed races.

* What bug does the patch fix? What features does the patch add?

This patch implements the dummy effect for the spell "Curse of the Eye".

* For which repository revision was the patch created?

11136

* 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.

diff --git a/src/game/SpellEffects.cpp b/src/game/SpellEffects.cpp
index d12a664..32bf82d 100644
--- a/src/game/SpellEffects.cpp
+++ b/src/game/SpellEffects.cpp
@@ -769,6 +769,14 @@ void Spell::EffectDummy(SpellEffectIndex eff_idx)
        {
            switch(m_spellInfo->Id)
            {
+                case 3360:                                  // Curse of the Eye
+                    if(!unitTarget)
+                        return;
+
+                    uint32 spell_id = (unitTarget->getGender() == GENDER_MALE) ? 10651: 10653;
+
+                    m_caster->CastSpell(unitTarget, spell_id, true);
+                    return;
                case 7671:                                  // Transformation (human<->worgen)
                {
                    if (!unitTarget)

You can just copy and paste codes and make a vip teleport table.

I know that we don't want to flood the repo with many inexperienced developers, but wouldn't it make sense to give more people the ability to review patches and commit them?

I would agree that we definitely don't have enough developers to keep up with Blizzard. At the moment, we only have 24 part-time developers. Yet there are many people on this forum that have proven they can write code up to the standard of MaNGOS (e.g. qsa, cyberium).

The more people that we have who would be able to review and commit patches, the more work we would get done.

You can play around with the command level's in the database table 'command'. If you made a custom security level (e.g., bump all GM/Admin/RA levels up one and make the level 1 for VIPs), you could easily give them access to the teleport command that GMs have, which is essentially what you have here.

Again, no comments on wowhead say anything about a different heal from the potion (all comments talk about it passively modifying the potion heal, none say that you get the potion heal and then a second "heal" ->21399 equal to 40% of the potion).

If someone could test this on retail it would be great.

Didn't do anything when I tested with them.

Maybe they are cast with custom basepoints = 40% of the potion. But I couldn't find anyone on wowhead who said you get a separate heal.

Deathbringer's Will only can proc on physical damages, so if a caster gets this trinket it won't proc until the caster does physical damages, so in mele most probably, then if will most probably never happen. If you have confirmation that it procs haste when used on a warlock, I personally think it's safe to proc this for all casters since this trinket is really useless for them. I can only imagine an elementary chaman who goes in mele range(!) getting one use of this trinket if really he does not even have a lvl 150 caster one

Shorter answer: a caster has no chance to get this trinket (ICC 25) except by .item add, so proc haste or nothing for them

We're still going for being as blizzlike as possible. If Vladimir has proof that on retail, you can get the hast proc as a caster meleeing, then why shouldnt we implement it.

And I'm still trying to draw Vladimir's attention to this thread. His version of Tiny Abominations in a Jar is not blizzlike.

Errr, Vladimir, your version of this spell in the official repo is wrong (talking about Anger Capacitor).

It isnt a random weapon hit with main or off hand, it's based on which weapon procced the 7/8th stack.

My way of doing this may not be the way you want, but it certainly works, and I'm surprised you havent at least revised your edition of your commit.

You're probably on a revision that is more recent than this one.

Well seeing as everyone's adamant that it isn't correct, I'll take it out. I think Patman maybe right, because I definitely notice a speed decrease when its a 1v1 between me and a target (dont have Infected Wounds specced).

The effect is unique to all spells that prevent fleeing, e.g. Glyph of Rake and Judgement of Justice.

I literally just tested this on my level 43 Druid on retail in WSG. I have Glyph of Rake, and when I apply it to say, flag carrying druids, their speed is reduced to 100%, and there are no movement impairing effects on them.

Erm, not quite sure what you're trying to say.

I know what fleeing means, but what does that have to do with this patch?