pasdVn

The current implementation of this targetmode in Spell::SetTargetMode is not fully correct, as I think. I listed all spells with those implicit target here. You can see at the combination of target modes, that this target mode is not meant to provide any unit targets, but just a random point around the 'current' target coordinates. Any effects, that need unit targets always have another target mode (e.g. http://www.wowhead.com/?spell=40649 that searches a random point around the dynamic object coordinates and than has additionally has TARGET_ALL_ENEMY_IN_AREA_INSTANT that gets the unit targets in the area around this random point). In most cases this mode is used for summon spells. Problem is, that mangos always needs a unit target to do the spell effects (while those summon spells in fact would only need some coordinates to spawn the new object), so I added the caster for positive spells (note: with old implementation no summons as well as multiple spawns are possible, because of aoe unit target detection). patch: http://github.com/pasdVn/mangos/commit/30f55d3446924871fd4294060b9b76e9ffd11204 The original implementation of this mode was done here. 24.03.2010: Patch rebased onto [9443]

Ah, oh good. I misunderstood you... You mean pets that are summoned by creatures. I'll see if I can fix it now.

At least attack speed won't work for now. Maybe it is a good idea to use the entry from creature_template for all non-hunter pets. No big deal... Other damage schools besides physical is not supportet at all at mangos currently, or am I wrong?

Ahh, I understand the problem now! Thank a lot you for your patience and detailed explanation :-) As the method is quite big I took the way to explicit instantiate it in spell.cpp, althoug I don't know if this is a good coding style now ... :-/

I already tried this, but no changes :-/

Hmm, 35 posts for such a simple problem^^. MrLams fix is nearly correct, except that we don't have to hardoce the standart (not RAP dependent) bonusdamge... I postet a fix in the 'under review' section...

Hmm, instantiate? FindCorpseUsing is just a (template-) method of class spell declared in Spell.h: template<typename T> WorldObject* FindCorpseUsing(); So I think I can just call it with specifying a typename - in this the type should be RaiseDeadObjectCheck of namespace MaNGOS, or am I wrong? As far as I can see the call of FindCorpseUsing<MaNGOS::RaiseDeadObjectCheck> () - in the position I mentioned in first post - is also not instantiate anywhere. Sorry, did not work that intensive with template function/classes until now :-/

Hey guys. I need the help of some c++ crack . I have the following specific problem: I want to call "template<typename T>WorldObject* Spell::FindCorpseUsing()" with "MaNGOS::RaiseDeadObjectCheck" as type in Spelleffects.cpp. I already included "GridNotifiers.h" in Spelleffects. So it looks like that: WorldObject* result = FindCorpseUsing<MaNGOS::RaiseDeadObjectCheck> (); I get the following linking error: If "FindCorpseUsing<MaNGOS::RaiseDeadObjectCheck> ()" gets called in Spell.cpp before (e.g. I modified the lines in Spell::SetTargetMap(...) where target selection of "Cannibalize" is coded) the problem does not exsist. Problem exsists also with other Check-Classes (CannibalizeObjectCheck, ExplodeCorpseObjectCheck).My c++ knowledge is too rudimentary to solve this problem :-/.

Updated...

Updated to apply without errors on current master HEAD.

Updatet patch for current master HEAD.

The new crash happened with the modification in Unit::SetMaxHealth? I compared your db values with mine. The only 'eventually' critical values are type_flags and family. As I already told you -in fact- should not be abled to tame a pet without values here (type&0x01 and any family = 1, wolf in this case). I can not image how this can produce such a crash, but who knows...^^ Maybe you can change your db values and observ the probelm... Thank you for your intensiv evaluation :-) Edit: Hmm, just found in your crashlog: this is a custom scrip, or am I wrong?

Hmm, no idea. Tried to reproduce the problem, but without success. Especially this pet is not tamable with my used db. Only after some modifications (type_flags, family) I was abled to tame. But than I did not get any crash. Anyway this behavior is very strange. To get exactly 0 HP you need less stamina than the creatures (or pet's in this case) base stamina, what is (and was already without this patch) theoretically possible if you have any debuff on your pet tha decreases it's stamina. Maybe it would a good idea to limit the hp>0 in Unit::SetMaxHealth(). Do you have any ideas to reproduce the crash. Did it also happen with other pets?

Can you post your crashdump (pastebin or whatever..)?

Ah... one more typo.. sry :-/ Update will follow.. Edit: Done.

Ouch... rookie mistake^^ Thank you guys. Updated, as always...

Ok, I rechecked the problem with the warlock pets. There was a typo... just a wrong bitoperation, so that they did not get ap and spellpower from owners fire or shadow spellpower. So thanks to morderek one more time! Everything that is now incorrect with wl pets stats should be db problem now (I hope), as I already mentioned. Branch and patches updatet. Depends on what you mean by "support". This patch makes the shadowfiend profit from the owner's spellpower. Maybe there are again some special hp per stamina (etc.) factors that we don't know about. And than we don't have correct DB values again here, I think...

Thank you for Patch. Nice feature! :-) PS.: Diving and Integer by anything else does not change it's type, so it still stays an integer and you won't need this typecast, as Lynx3d said. But that are only peanuts^^

Ok, branche and single patches updated. I'll see. Will be a lot of work ^^

Yes, you are right, that's a typo. Thank you :-) I'm going to update patches and branch soon!

Still to less Information :-/. I would need The owners stats that directly influence the pet stats (that are stamina, intellect, spellpower and armor if you like). Nevertheless I don't have any values to compare :-(. I don't have values from official servers about the pets base stats at any level (Warlock). I don't know if the scaling factors are corect (althoug I think they are) and I am unshure about hp/mana per stamina/intellect etc.I only have representativ datas for hunter pets (see sql). If anyone can provide correct values of Warlock etc. pets you are welcome to PM me ;-) In fact they only corrected their wrong old values^^ If I am honest, I trust my self gathered values more than wowwiki^^ (but anyway It shows, that mine seem to be correct). Resilence changed, but that is not a part of this patch anymore, as vladimir added an alternativ version in another commit already.Maybe I shoul take a deeper look at the Ghuul scaling... Thanks anyway for your hint! PS: Hmm, I just see that I linked a wrong patch in first post (with resilence).... Edit: Fixed links and rebased/merged onto/with [9266]

Thx for feedback, but I need more details ;-) * which pet * level & stats * owner level + stats * dmg against what (or the pet menu values)?

Update Sorry for long latency... did not have much time and motivation in the lask weeks/months :-/. I implemented a special scaling aura list for faster access and an "on-the-fly aura modifier update routine":cool:, as suggested by thenecromancer. Question is, if I should leave out the update delay completly, as the scaling aura update needs less cpu time now. Those update delay is anway a genral "feature" on offical servers with all statats (player/pets), I think. I will try to update and rebase the patch set from time to time to the current HEAD (the single pastes), but just merge my github branch with mangos HEAD so that update won't be a problem for anybody using this branch. Edit 01-11-2010 Sorry, I forgot about the new bonus damge system in Unit::MeleeDamageBonus(). Added some lines there and updated branch and pastes.

Nice catch! I plan to write an autoshot update if I haves some time. Checked the behavior in detail on an official server months ago already...

Wow, great. Thanks a lot for your detailed explanation *HAPPY*