hunuza

According to the comments on the page you linked Intervene is autocastable.

Won't work, because for example Wing Clip should also be removed, but it is not triggered. I think the only exception is daze which probably has some flag or so which causes it to be not removable.

I don't think that the problem that this patch addresses was fully solved in [8291]. There are some spells like Sacrifice where you should not be able to enable auto cast at all. Neither in combat nor out of combat. I don't see how [8291] should fix that issue.

Shapeshifting should remove snare, root and polymorph effects. The spells he mentioned are snares from my point of view.

Applied in [8285]. Thank you.

Ok, try that one: diff --git a/src/game/Player.cpp b/src/game/Player.cpp index 510976e..0f9ce0f 100644 --- a/src/game/Player.cpp +++ b/src/game/Player.cpp @@ -6959,7 +6959,7 @@ void Player::UpdateEquipSpellsAtFormChange() void Player::CastItemCombatSpell(Unit* Target, WeaponAttackType attType) { - Item *item = GetWeaponForAttack(attType, true); + Item *item = GetWeaponForAttack(attType, false); if(!item || item->IsBroken()) return; diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp index 83e1a43..4253159 100644 --- a/src/game/Unit.cpp +++ b/src/game/Unit.cpp @@ -11714,9 +11714,6 @@ bool Unit::IsTriggeredAtSpellProcEvent(Unit *pVictim, Aura* aura, SpellEntry con else item = ((Player*)this)->GetItemByPos(INVENTORY_SLOT_BAG_0, EQUIPMENT_SLOT_RANGED); - if (!((Player*)this)->IsUseEquipedWeapon(attType==BASE_ATTACK)) - return false; - if(!item || item->IsBroken() || item->GetProto()->Class != ITEM_CLASS_WEAPON || !((1<<item->GetProto()->SubClass) & spellProto->EquippedItemSubClassMask)) return false; } Somebody knows whether those enchants should proc when you are disarmed?

You should better check: cVictim->GetCreatureInfo()->lootid || cVictim->GetCreatureInfo()->maxgold > 0 Otherwise creatures that have no loot, but can drop gold will never be lootable.

If I remember well, there is in fact the chance that you can open the loot window but there is no loot in it on official servers.

What do you mean by everytime? If you mean everytime you login, I guess that is the correct behavior.

int32 amount = m_modifier.m_amount / m_stackAmount; m_target->CastCustomSpell(m_target, 33778, &amount, NULL, NULL, true, NULL, this, GetCasterGUID()); replace by: m_target->CastCustomSpell(m_target, 33778, &m_modifier.m_amount, NULL, NULL, true, NULL, this, GetCasterGUID());

Yes, that was changed in 3.0.2. Try this one: diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp index 0b67a2f..c45a745 100644 --- a/src/game/Unit.cpp +++ b/src/game/Unit.cpp @@ -11704,9 +11704,6 @@ bool Unit::IsTriggeredAtSpellProcEvent(Unit *pVictim, Aura* aura, SpellEntry con else item = ((Player*)this)->GetItemByPos(INVENTORY_SLOT_BAG_0, EQUIPMENT_SLOT_RANGED); - if (!((Player*)this)->IsUseEquipedWeapon(attType==BASE_ATTACK)) - return false; - if(!item || item->IsBroken() || item->GetProto()->Class != ITEM_CLASS_WEAPON || !((1<<item->GetProto()->SubClass) & spellProto->EquippedItemSubClassMask)) return false; }

Somebody can test whether that one would work fine? #ifdef WIN32typedef __int64 int64; typedef __int32 int32; typedef __int16 int16; typedef __int8 int8; typedef unsigned __int64 uint64; typedef unsigned __int32 uint32; typedef unsigned __int16 uint16; typedef unsigned __int8 uint8; #else #include <stdint.h> #ifndef uint64_t #include <linux/types.h> #endif typedef int64_t int64; typedef int32_t int32; typedef int16_t int16; typedef int8_t int8; typedef uint64_t uint64; typedef uint32_t uint32; typedef uint16_t uint16; typedef uint8_t uint8; #endif I don't use a 64-bit OS, so I can't test it myself.

Somebody can confirm whether Last Stand should be really autocastable? Still I think that if the flag is correct, SpellFamily checks should be unnecessary.

Well, I don't whether it is more work on their part. They once already did so, that's why I don't see any reason why they should not do it again.

It wasn't meant to overwrite data in the Spell.dbc, but to add data that just wasn't there. EffItemType were just 32 bits, where the SpellFamilyFlags were 64 bits. Now however, they both are 96 bits.

It wasn't before 3.x. I introduced it about 3 years ago, because since 1.12.x the EffItemType fields in the dbc were no longer correctly filled. I don't know whether that data is now needed by the client or why they decided to now put the correct data there once again. If it is still not needed, they could at any point decide to not put the data there anymore, just like they did with 1.12.x. Then we would need the table again.

Did you already add them to the index with "git add"?

This should probably be done in World::Update. That data probably should be stored in the WorldSession or in the Player class. If it is related to the currently logged in character then you should store it in the Player class, otherwise in the WorldSession. The data should probably be cleaned up in the adequate destructor. The whole login is handled in AuthSocket class. WorldSession::HandleWardenDataOpcode You should probably have a look at the other packet handlers, for example WorldSession::HandlePlayedTime. Again, if it is related to the currently logged in character, that should be done in Player::Update, otherwise in WorldSession::Update.

Hmm, if I get it right Warden would allow the server administrators to run any code they like on the clients (simply by writing some new Warden module)? I don't think that this is something we would like to support here.

Applied in [8072].

Actually it's less db load because a lot data in the data blob is not really used and overwritten on player load and you do not have to load/save the whole data field if you just want to update one value (for example money). Another reason why it is actually less db load was already given by freghar. Well, but their are several problems: * changing data field structure (as Vladimir already mentioned) Every time we switch to a different client version you currently need to update all your tools because the data field offsets have changed. * need of lots of string operations which are very CPU-intensive When you access data in the data blob, you probably use SQL functions like SUBSTRING_INDEX() etc. I actually did not test it, but I can't imagine that those string functions are very CPU friendly... * difficult to understand and read Especially for people who are new to MaNGOS the data field might be quite incomprehensible. It's not that easy for somebody, who is not very experienced, to for example figure out how the skill data is stored there. With a new table that stores all the skill data it should be a lot easier and more intelligible to figure out how the skill data is stored. How should a badly designed database help somebody who wants to learn about MMORPG servers?

Why should this patch be the end of a php web front end? I think this might even simplify most of those kind of scripts.

Most of the data fields are anyway overwritten on player load, so we only need to save a very small part of the old data field.

Hi, this patch is the first step to get rid of the data blob (characters.data). For now it increases redundancy by adding new fields to the character table (level, xp, money, etc.), but when all data from the data blob is saved separately the data blob can be removed. Patch: http://pastebin.ca/1469152 ATTENTION: If your database contains somehow characters that are not up-2-date the update sqls might not work. Be sure to make backups before applying this patch. Please report any bugs.

Patch applied in [8063]. Thank you.