Janu

Tank skill, gear, talent build, and fight mechanics are big variables in the threat/second equation. You may be comparing apples to oranges.

How do you mean this? The players are the same, so he can play his char The great difference is the gear yep, cause on Offi it is ICC and on my server it is TOC equip.. But I think this threat difference is quite too much on the whole. On retail the last player in the threat list has more threat than the tank on mangos and this can definitely not be correct even with this equip difference

Could it be that all the values in DB are incorrect or is this problem more on the core side, like in sending packages to the client or threat calculation on the whole?

I do not know with which classes exactly

But if you look at the numbers there seems to be a huge difference so something has to be wrong here

Hey guys,

there seems to be a problem with the threat calcultion:

This are screenshots of the Addon "Omen" after the raid has done ~200k damage on the bosses.

Left side is on retail servers and right side is in mangos. I think you can see the differences in BPS and threat amount quite clearly Besides it is much more difficult for tanks to keep holding their threat high enough in raids than on retail.

Maybe someone has a solution for that?

Thanks and Regards,

Janu

Hmm, I do not think that is a good idea. It is quite difficult to keep the overview of the bugs and tools like Lighthouse or Mantis were created for keeping this overview a bit easier

So make life a bit easier for the Devs and keep Lighthouse

So your aim is to handle the respawn time only in the database (creature respawntime) without adding new colums and removing the config options?

First thanks for your extensive reply and your work

It is a bit confusing for me to distinguish between respawn time with corpse decay time, but if get the patch correct it is relly great!

But I have some logical questions:

1. (respawn time in database) /3 < corpse decay in config

Is the corpse delay "(respawn time in database) /3" then?

2. (respawn time in database) /3 > corpse decay in config

Is the corpse delay " corpse decay in config" then?

If my assumptions are correct will this happen for rare, elite and normal mobs? Besides I will test this in the next days and give you some feedback about this

Hi,

maybe you mean ".gobject add" to spawn gameobjects? =)

Regards

For information: The critical client errors related to pets are gone, nice work

@laise:

Thanks , works like charm!

Maybe an additional option to assign tickets not only per name but also per number would be fine, like: .ticket assign 1 GM_NAME? =)

@fdb_:

I wrote a patch to close tickets instead of deleting them, so tickets stay in your database:

http://paste2.org/p/969283 (it is tested and works fine)

if you now add assigning ticket to gm before closing, it would be the result you wanted =)

Yes, but it seems that this patch brakes some more things in Pet-handling. If you mount, the name of your pet will become unkown.. I guess this is in PetHandler.cpp

Any news about client crashes?

No one has any information on that?

Hey,

I have got a problem concerning the respawn time of creatures. Some of them needed for quests, should have a very short respawn time.

Example:

http://www.wowhead.com/npc=28834

needed for quest: http://www.wowhead.com/quest=12701

http://www.wowhead.com/npc=31099

needed for quest: http://www.wowhead.com/quest=13166

The problem here is that there are some options in config:

Corpse.Decay.NORMAL = 60
Corpse.Decay.RARE = 300
Corpse.Decay.ELITE = 300
Corpse.Decay.RAREELITE = 300
Corpse.Decay.WORLDBOSS = 3600

So due to that the creatures listed above have a respawn time of 5m / 1h in addition to the DB content what is clearly too long.

They have no loot and should give no experience, so they are only the target of quests. As far as I know fromofficial servers, they have a shorter respawn time than this.

I thought of checking if the creature has some loot entry in the DB. If not you can reduce the respawn time. This code here is only a temp solution, but works fine for me (maybe it is better to add an additional config option for that?):

diff --git a/src/game/Creature.cpp b/src/game/Creature.cpp
index 04f562f..3f47097 100644
--- a/src/game/Creature.cpp
+++ b/src/game/Creature.cpp
@@ -1323,7 +1323,10 @@ void Creature::setDeathState(DeathState s)
{
    if ((s == JUST_DIED && !m_isDeadByDefault) || (s == JUST_ALIVED && m_isDeadByDefault))
    {
-        m_deathTimer = m_corpseDelay*IN_MILLISECONDS;
+        if (GetCreatureInfo()->maxgold > 0 || GetCreatureInfo()->lootid || GetCreatureInfo()->SkinLootId)
+             m_deathTimer = m_corpseDelay*IN_MILLISECONDS;
+        else
+             m_deathTimer = MINUTE*IN_MILLISECONDS;    // one minute despawn for all NPC's without loot

        // always save boss respawn time at death to prevent crash cheating
        if (sWorld.getConfig(CONFIG_BOOL_SAVE_RESPAWN_TIME_IMMEDIATLY) || isWorldBoss())

Can anyone confirm this problem or have further information of official servers about respawn time handling?

Think he means the missing "t" in GetGuidTransport()

Confirmed with Firefox

Allright, then I will make a post in SD2 forums and this can be closed

Thanks

http://www.scriptdev2.com/project.php?issueid=1018

(if someone is interested in)

At first thanks for reply

But the doors are only one example for this, another example would be the containment spheres in "The Nexus" to finally attack Keristrasza or something like that.

And why wrong forum, isn't this a bug?

edit: sorry, didn't get it.. you mean I should post it to SD2 forum?

Hey ladies and gentlemen,

got one question concerning instance progress. The problem is that after the server crashes the instance progress is not saved.

For example if a raid group is in Naxxramas and they kill bosses, some doors will open. If the server crashes now, the doors will be closed again and the raid group cannot proceed without help of a GM who opens the doors again.

Maybe there is any solution/idea to solve that?

Thanks and Regards,

Janu

uint32 HonorKills = GetUInt32Value(PLAYER_FIELD_LIFETIME_HONORBALE_KILLS);

This is how you have to define HonorKills if you want to use it in Player.cpp, but I did not find anything like that in clean mangos core too.

if m_spellInfo->Id == 72286
    uint32 spellid = skillval >= 300 ? 72284 : 72283;

This won't compile without brackets

@ Janu, as far as i can see...exactly the same code

take a closer look

I added some brackets, like I said, e.g.:

+                            if m_spellInfo->Id == 72286

changed to:

+                            if (m_spellInfo->Id == 72286)

Try this, I think he simply missed some brackets:

diff --git a/src/game/SpellEffects.cpp b/src/game/SpellEffects.cpp
index 5f8439e..a76efd7 100644
--- a/src/game/SpellEffects.cpp
+++ b/src/game/SpellEffects.cpp
@@ -5806,6 +5806,38 @@ void Spell::EffectScriptEffect(SpellEffectIndex eff_idx)
                    m_caster->CastSpell(unitTarget, 72588, true);
                    return;
                }
+               case 75614:                                 // Celestial Steed
               case 72286:                                 // Invincible
               {
                   if (!unitTarget || unitTarget->GetTypeId() != TYPEID_PLAYER)
                       return;

                   // Prevent stacking of mounts
                   unitTarget->RemoveSpellsCausingAura(SPELL_AURA_MOUNTED);
                   uint16 skillval = ((Player*)unitTarget)->GetSkillValue(SKILL_RIDING);
                   if (!skillval)
                       return;

                   if (skillval >= 225)
                   {
-                       uint32 spellid = skillval >= 300 ? 72284 : 72283;
+                       if (m_spellInfo->Id == 72286)
+                           uint32 spellid = skillval >= 300 ? 72284 : 72283;
+                       else if (m_spellInfo->Id == 75614)
+                           uint32 spellid = skillval >= 300 ? 76153 : 75617;
                       SpellEntry const *pSpell = sSpellStore.LookupEntry(spellid);
                       // zone check
                       uint32 zone, area;
                       unitTarget->GetZoneAndAreaId(zone, area);

                       SpellCastResult locRes= sSpellMgr.GetSpellAllowedInLocationError(pSpell, unitTarget->GetMapId(), zone, area, unitTarget->GetCharmerOrOwnerPlayerOrPlayerItself());
                       if (locRes != SPELL_CAST_OK || !((Player*)unitTarget)->IsKnowHowFlyIn(unitTarget->GetMapId(),zone))
+                       {
-                           unitTarget->CastSpell(unitTarget, 72282, true);
+                            if (m_spellInfo->Id == 72286)
+                               unitTarget->CastSpell(unitTarget, 72282, true);
+                           else if (m_spellInfo->Id == 75614)
+                               unitTarget->CastSpell(unitTarget, 75620, true);
+                       }
                       else
                           unitTarget->CastSpell(unitTarget, pSpell, true);
                   }
                   else if (skillval >= 150)
-                   unitTarget->CastSpell(unitTarget, 72282, true);
+                   {
+                       if (m_spellInfo->Id == 72286)
+                           unitTarget->CastSpell(unitTarget, 72282, true);
+                       else if (m_spellInfo->Id == 75614)
+                           unitTarget->CastSpell(unitTarget, 75620, true);
+                   }
                   else
-                       unitTarget->CastSpell(unitTarget, 72281, true);
+                   {
+                       if (m_spellInfo->Id == 72286)
+                           unitTarget->CastSpell(unitTarget, 72281, true);
+                       else if (m_spellInfo->Id == 75614)
+                           unitTarget->CastSpell(unitTarget, 75619, true);
+                   }

                   return;
               }

@Betaman2k:

http://github.com/Janu/mangos333/blob/master/addition/extension/dual-spec_fix.sql

This works fine for me. Seems that option_id and npc_option_npcflag aren't set correctly in `option_text`.

yes but it is interesting, because vehicles seem to work on wojtas repo. if I am wrong with this assumption, please correct me..

I have the problem that you do not "really" move if you enter the vehicle. You think you are moving, but if you enter the vehicle the player actually will stay at the enter-point. If you want to exit the vehicle, you really "fly" back to the point where you entered it at the beginning

Anyone else having the same problem or an idea for a solution?