Janu

What bug does the patch fix? What features does the patch add? Corrected typo which caused huge problems with item saving. For which repository revision was the patch created? Compatible with newest revision Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. Haven't seen any Who has been writing this patch? Please include either forum user names or email addresses. Me Problem caused in: https://github.com/mangos/mangos/commit/846f6943ec5c7b50a07aa244c85c4b34ad1f8344 Fix: https://github.com/Iov/mangos/commit/e154d7067e532d64e5ed3bd944f2e5b5a2744d95 diff --git a/src/game/Item.cpp b/src/game/Item.cpp index b5a3307..ca3ea19 100644 --- a/src/game/Item.cpp +++ b/src/game/Item.cpp @@ -516,7 +516,7 @@ bool Item::LoadFromDB(uint32 guidLow, Field* fields, ObjectGuid ownerGuid) std::ostringstream ss; for (uint16 i = 0; i < m_valuesCount; ++i) - ss << GetUInt32Value(i) << ""; + ss << GetUInt32Value(i) << " "; stmt.addString(ss); stmt.addUInt32(GetOwnerGuid().GetCounter());

Hey, everytime I try to start mangos as deamon I get following crash. Can anyone help or has an idea? Program received signal SIGTERM, Terminated. 0x00007ffff5e1a42d in pause () at ../sysdeps/unix/syscall-template.S:82 82 ../sysdeps/unix/syscall-template.S: No such file or directory. in ../sysdeps/unix/syscall-template.S (gdb) bt full #0 0x00007ffff5e1a42d in pause () at ../sysdeps/unix/syscall-template.S:82 No locals. #1 0x0000000000a87ccf in startDaemon (timeout=10) at /opt/mangos/source/mangos/src/shared/PosixDaemon.cpp:66 No locals. #2 0x0000000000512897 in main (argc=<value optimised out>, argv=0x7fffffffe768) at /opt/mangos/source/mangos/src/mangosd/Main.cpp:182 cfg_file = 0xb3f730 "/opt/mangos/server/test/etc/mangosd.conf" mc_cfg_file = 0xb3f700 "/opt/mangos/server/test/etc/mangchat.conf" cmd_opts = {argc_ = 3, argv_ = 0x7fffffffe768, optind = 3, opterr = 0, optarg = 0x0, optstring_ = 0x7ffff7fdbf88, long_only_ = 0, has_colon_ = 1, last_option_ = 0x7ffff7fdbf60, nextchar_ = 0x0, optopt_ = 115, ordering_ = 2, nonopt_start_ = 3, nonopt_end_ = 3, long_option_ = 0x0, long_opts_ = {<ACE_Array_Base<ACE_Get_Opt::ACE_Get_Opt_Long_Option*>> = { max_size_ = 1, cur_size_ = 1, array_ = 0x7ffff7fafff0, allocator_ = 0x7ffff7ddb030}, <No data fields>}} serviceDaemonMode = 114 'r' option = <value optimised out> Main.cpp:182 is startDemon(); PosixDaemon.cpp:66 is pause(); PS: We have custom use of MangChat with additional config file. You can see here: mc_cfg_file = 0xb3f700 "/opt/mangos/server/test/etc/mangchat.conf"

Spell http://www.wowhead.com/spell=70728 is also working wrong (used by Hunter T10 http://old.wowhead.com/spell=70727) SpellInfo: Targets (20, 0) (TARGET_ALL_PARTY_AROUND_CASTER, NO_TARGET) Fix: https://github.com/Iov/mangos/commit/618b11d3a7b5ecc2c671c6ac8f8b883ac0e67751 diff --git a/src/game/Spell.cpp b/src/game/Spell.cpp index b47049f..c0ca3ea 100644 --- a/src/game/Spell.cpp +++ b/src/game/Spell.cpp @@ -2482,8 +2482,9 @@ void Spell::SetTargetMap(SpellEffectIndex effIndex, uint32 targetMode, UnitList& switch(m_spellInfo->Id) { case 24604: // Furious Howl + case 70728: // Exploit Weakness { - // from 3.1.0 only affect pet and owner + // only affect pet and owner targetUnitMap.push_back(m_caster); if (Unit *owner = m_caster->GetOwner()) targetUnitMap.push_back(owner);

Hi again There is a bug with VMaps concerning height calculation of Players. How to reproduce: 1. log off while sitting on a mount 2. login again and unmount 3. try to walk through a door You will see that you are not able to enter buildings. Regards Janu

We have a problem with this commit 70849 ist triggered and you have 2 charges, so everything seems fine. _But_ if you cast one of the effected spells both charges are consumend Anyone can confirm?

Hey all, is it possible that all cooldowns start on beginning of the proc and not at the end? As far as I know on official servers the cooldown is: spell duration + cooldown Maybe someone has more detailed information concerning this or can confirm it? Thanks and Regards Janu

Any news here? No chance for recheck or revert?

No, I have no custom patches concerning this. But in your last posted code the only thing affected is: mechanic_immune = IMMUNE_TO_MOVEMENT_IMPAIRMENT_AND_LOSS_CONTROL_MASK; Isn't this only to prevent stunning a player who already has aura of this spell? And not for getting out of stun with using this spell?

This does not help in this case, because you cannot even cast spell 42292 if stunning spell has other mechanic then SPELL_AURA_MOD_STUN.

* What bug does the patch fix? What features does the patch add? Prevents abilities that are "usable while stunned" being usable while in non-stun effects like Cyclone or Sap. With this patch the usability while stunned is restricted only to stun auras with mechanic stun. Ah, I see And you are right, patch is wrong and needs revert.

I think this just special spell case: "The warrior shouts, causing up to 5 enemies within 8 yards to cower in fear. The targeted enemy will be unable to move while cowering. Lasts 8 sec." It is fear effect, but applies stun aura

Hm, I think this commit is wrong in some cases spell http://www.wowhead.com/spell=51209 has: Mechanic = 13 (MECHANIC_FREEZE) Aura Id 12 (SPELL_AURA_MOD_STUN) spell http://www.wowhead.com/spell=33786 has: Mechanic = 18 (MECHANIC_BANISH) Aura Id 12 (SPELL_AURA_MOD_STUN) spell http://www.wowhead.com/spell=20066 has: Mechanic = 14 (MECHANIC_KNOCKOUT) Aura Id 12 (SPELL_AURA_MOD_STUN) spell http://www.wowhead.com/spell=20511 has: Mechanic = 5 (MECHANIC_FEAR) Aura Id 12 (SPELL_AURA_MOD_STUN) So in code "is_stun_mechanic = false;" will be set and using spells like http://www.wowhead.com/spell=59752 will be prevented I do not know all special cases, but maybe we should only exclude spells 59752 and 42292 here. if (!(*itr)->HasMechanic(MECHANIC_STUN) && spellInfo->Id != 59752 && spellInfo->Id != 42292) or we should check more mechanics here (probably better): rewritten code part of code in first post: if (unitflag & UNIT_FLAG_STUNNED) { // spell is usable while stunned if (m_spellInfo->AttributesEx5 & SPELL_ATTR_EX5_USABLE_WHILE_STUNNED) { bool is_stun_mechanic = true; Unit::AuraList const& stunAuras = m_caster->GetAurasByType(SPELL_AURA_MOD_STUN); for (Unit::AuraList::const_iterator itr = stunAuras.begin(); itr != stunAuras.end(); ++itr) // check spell mechanics if (!((*itr)->HasMechanic(MECHANIC_STUN) || (*itr)->HasMechanic(MECHANIC_FREEZE) || (*itr)->HasMechanic(MECHANIC_BANISH) || (*itr)->HasMechanic(MECHANIC_KNOCKOUT) || (*itr)->HasMechanic(MECHANIC_FEAR))) { is_stun_mechanic = false; break; } if (!is_stun_mechanic) prevented_reason = SPELL_FAILED_STUNNED; } else prevented_reason = SPELL_FAILED_STUNNED; }

Got only one freeze in the last days: http://pastebin.com/raw.php?i=whEJKiqU (just ignore above table errors, was a fail of mine ) But as you can see, there is no error with fishing bobbers in log. Besides server does not freeze if you exactly try to reproduze it. So this freeze seems to be fixed Maybe somebody else has feedback regardings this?

Tried to reproduce freezes on our Test-Server, but everything seems fine If it occurs again on our Live-Server, I will contact you. But as I said it seems fine for now

I had no chance to test this yet, but I am sure to have some test-results at the evening I will post feedback then