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.

Well, now there's something strange... the /played command is being executed everytime. Even without player's consent =P

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.

I doubt they're going to remove it, though. That's just more work on their part, isn't it - much more work, actually?

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.

My opinion: If you need to override something with spell_affect... You're doing it wrong . It's a hack in the first place.

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"?

A way to schedule an event to switch the active module that is loaded on the server. Say every 3-4 hours [customizable]

This event must be fired on first load, so the server can load the initial module.

This should probably be done in World::Update.

I need an addition to the client's session information, Just a pointer to memory I can allocate to hold the various Warden data I need.

An way to clean up such data when the client disconnects of coarse.

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.

A client connect event

A client Session key generation event

The whole login is handled in AuthSocket class.

A Warden packet event.

WorldSession::HandleWardenDataOpcode

Have a way for me to send return packets from that function.

You should probably have a look at the other packet handlers, for example WorldSession::HandlePlayedTime.

Have a way to schedule a event that's fired every 15 seconds that will loop through each currently connected client firing an event in the dll.

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

And more colums > more DB usage (not much but still more)...

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.

Personaly i think its easy enough to select from the data-blob, if you keep track of the order...

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.

To simplify the DB to much will only alienate people who join to learn...

How should a badly designed database help somebody who wants to learn about MMORPG servers?

This will be defenetly end of minimenager

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.