BuffStackTest (MQ2Main/MQ2Utilities.cpp)

[PeteSampras]

.

[Cr4zyb4rd]

Casts but doesn't land is an important distinction to make. Not from the point of what we return (a good stack check will cover all cases) but as far as implementation we should be moving towards letting the client do whatever checking it can do for us. Of course that means fiddling about until we find the mechanism but the fact that there's a difference means that somewhere a boolean check is being made and all this work to duplicate it is superfluous. We want to trap the things it "would have let you try to cast".

[PeteSampras]

.

[Cr4zyb4rd]

We don't actually cast the spell. We use the same function that the client would have used. We're hackers, this is the point of our endeavor. Was this not in the FAQ? Finding an offset isn't casting a spell.

[PeteSampras]

.

[demonstar55]

I don't think there is anything client side that handles stacking, its most likely 100% server side. (If your remove the stacking code in EQEmu everything will land and the client will do all the math [HP, mana, ect] as if they stacked)

[SwiftyMUSE]

We don't actually cast the spell. We use the same function that the client would have used. We're hackers, this is the point of our endeavor. Was this not in the FAQ? Finding an offset isn't casting a spell.

In what situation would you cast a buff spell that is already on you or that doesn't stack? Enlighten me.

Basically any buff that might be fading that you don't want to fade before you can cast again.

[PeteSampras]

.

[demonstar55]

${Spell[spell].Stacks[ticks]} works too.

[PeteSampras]

.

[demonstar55]

Still getting an error with Pyromancy (23514) and Arcane Arietta (18066)

[PeteSampras]

.

[SwiftyMUSE]

Still getting an error with Pyromancy (23514) and Arcane Arietta (18066)

Code: Select all

		 || (aSpell->Attrib[i]==339 || bSpell->Attrib[i]==339)		// Trigger DoT on cast
		 || (aSpell->Attrib[i]==340 || bSpell->Attrib[i]==340)		// Trigger DD on cast

This needs to be added to SpellEffectTest. Both the AA and bard song trigger a DoT when cast, that does not effect stacking.

[demonstar55]

That doesn't work, they're stacking because one is a spell and the other is a song.

(All assumed rank 12, because that's what I have) Pyromancy, Cryomancy, and Arcomancy don't stack. Pyromancy is overwritten by Cryomancy and Arcomancy. Pyromancy can't overwrite either. Cryomancy and Arcomancy can overwrite each other. So looking into the data, Cryomancy and Arcomancy have a base1 of 20, Pyromancy has a base1 of 15, so this is standard stacking/overwriting rules.

I'm still convinced what I stated early is actually true, where if death bloom and zombieskin do not stack, it's an exception to the rule, which may or may not have an unknown field we can use to know if that's the case, otherwise it's something hidden from us.

[SwiftyMUSE]

That doesn't work, they're stacking because one is a spell and the other is a song.

(All assumed rank 12, because that's what I have) Pyromancy, Cryomancy, and Arcomancy don't stack. Pyromancy is overwritten by Cryomancy and Arcomancy. Pyromancy can't overwrite either. Cryomancy and Arcomancy can overwrite each other. So looking into the data, Cryomancy and Arcomancy have a base1 of 20, Pyromancy has a base1 of 15, so this is standard stacking/overwriting rules.

I'm still convinced what I stated early is actually true, where if death bloom and zombieskin do not stack, it's an exception to the rule, which may or may not have an unknown field we can use to know if that's the case, otherwise it's something hidden from us.

Well, stacking never was really made to work with aas. Base1 does not have anything to do with stacking. I don't really want to go fully into details, but stacking is based on the effects (what we call attrib), base/base2/max all are affected by calc that tells you how much the spell does.