Tiaquenes
-
Posts
14 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Posts posted by Tiaquenes
-
-
yes, and as I am aware of this, I added the needed framework in my post, feel free to use the round ball with phunny ears floating around a bit higher than your chest - this is usally the best way to get something done.
Lol i get it.
ofc it is possible that there are other and better ways than the one I thought of, but I think I understood enough of the aura-trigger spell problem, to suggest reasonable changes that will be helpfull for many cases.
Ofc, any problem has many ways of solutions. Some are dirty, tricky, hacky, some are wrong, some like revolution - wants to rewrite all around, but some are "right". In my opinion, right way is a best way by result/cost.
Mangos needs many and many changes. Mangos must be rewritten in many places. And if i'll be a "fan" of mangos, i'll start some rework in needed order.
But now, i want to choose better solutions for problems, which are not so hacky. I'm using oregoncore as source of tested and working solutions. I'm searching solution of mangos problem in oregon, analyzing it for getting idea how it works and applying it in my fork. If it works, i make a pull request.
well, the spell-triggering aura should know onto whom to cast the missiles, hence we need to get the target for arcane missiles, this has nothing to do with simple/ complicated, but this is the purpose of the spell (sending missiles from caster onto target of arcane missiles) - ofc if you don't want to care about this ..
Yeah, i want it too! Too, but now, i dont want to review huge amount of this code. It's okay for some time:
Unit* triggerTarget = GetTriggerTarget(); //it's a "real" target Unit* realCaster = GetCaster(); //it's a "real" caster realCaster->SpellCast(triggerTarget, 38700 ...);
One note: GetCaster() returns m_target from AuraHolder, which is a target from Aura constructor arguments.
Btw, you could edit your subject, because this is a bug of mangos master, too, and you can take the spell-ids I posted, to give a proper bug-reportRemoved version tag. Spell ids... it's no matter. This but appears on many spells, not only on AM.
Edit: Just looked at arcane missile spell again, and from the spell (42846) I think we must use some unexpected code somewhere already..
Yes, it is Aura::GetCaster().
-
For "one" it is'nt neccecery. It's repo keeps up to master and differences handled by, as said above, "version tag".
For zero... i dunno. It has not so big community and it'll die in separated forum. Anyway, it, like a "one", keeps(or trying) up to master, with backports of some patches. If somebody asks question about "zero" in "master" forum, it'll not be so terrible.
Just use "version tags".
ive never seen such interest in a WoW project like thisYou need to remember, we should try to stick together, becouse we have ot so many "sucscribers".
-
no, in my opinion entirely wrong way..
Oh, and one more thing about this but: it appears not only on AM. It appears in many encounters like last boss in MGT, last boss in Underbog. So, we need to fix not only AM, we need to fix this logical bug for many spells. That means we need more general solution, like i showed above.
-
Yeah, thx for pointing on TriggerSpell.
Make Aura::TriggerSpell a bit more clear to supportWhat you want? It's clear enough.
Add a way to handle all player arcane missiles into one place (possible one of these (for me) mysterious spell masksAM is a similar to many spells like Penance. So nothing "special" needed. Or, perhaps, i don't understand your thought.
support the dummy aura to add "lastArcaneMissileTarget" to Player on apply and clear on removeFor what purpose?
use triggeredCaster = aura.caster and triggeredTarget = aura.caster.GetArcaneMissileTarget();Too complicated. KISS,
Anyway, i found a... way.
Let's see a mangos SpellAuras.cpp in func TriggerSpell:
ObjectGuid casterGUID = GetCasterGuid(); //remember! it's always original caster! Unit* triggerTarget = GetTriggerTarget(); //and this is target ... // Victim, spellInfo, triggered, castItem, triggeredByAura, originalCaster .... triggerTarget->CastSpell(triggerTarget, triggeredSpellInfo, true, NULL, this, casterGUID);
That means, in "default case", caster will be always == victim, which is truth in server inner logic(AM is a aura on victim), but wrong in theory(it's a regular spell A->B).
Let's see a trinity core(oregoncore) in same place:
in constructor init: m_target(target) // m_target = target(from args) Unit* caster = GetCaster(); Unit* target = GetTriggerTarget(); uint64 originalCasterGUID = GetCasterGUID(); m_target->CastSpell(target, triggeredSpellInfo, true, 0, this, originalCasterGUID);
m_target is target, placed in Aura constructor.
So, let's see what happens on AM spellcast:
It places 2 auras with spellproto id of AM channeled spell(in case of TBC - 38699): with same target and caster pointer and with different target and caster pointers(second effect, with id 38700).
Important thing: in mangos and oregoncore it has same behavior! That means, real problem is betweet constructor calling and CastSpell!
Okay, we in constructor. So whats happend in it?
In oregon: save target into m_target.
In mangos: ... nothing!
Okay, next... In Aura::TriggerSpell():
In oregon: m_target casts AM(aura effect spell 38700) on target. But target is "GetTriggerTarget();"! Just a triggerTarget, in mangos.
In mangos: stupidly triggerTarget casts AM on itself.
Solution: save "target" from Aura constructor arguments, use it as target->CastSpell.
Really simple. Not tested, but all comment and thoughts are welcome.
-
If memory servers, there are two types of arcane missile targeting systems:
1) For player cast arcane missiles:
Dummy Aura on Target, Channeled spell on player
then the channeled spell must cast his arcane missiles every channeled-tick onto his target with dummy aura
2) for npc cast arcane missiles - example http://www.wowhead.com/spell=15790
Periodic Tick Aura on Target, this periodic tick must cast the spells from caster onto target (and not like usual periodic tick from target onto target)
But anyway, m_originalCaster will be really "original caster"? In first case - player, in second - npc? Does this mean that we can send m_originalCster instead of m_caster if available? I can just replace m_caster with GetAffectiveCaster() in packets creation functions of Spell.cpp(simply, in SendSpellGo/Start), but is it right way?
-
Pro add credits for painter
Done :3
-
As i remeber we can't add picture from game
Oh, now better?
-
Is it fixed in master?
-
Something wrong in Spell::WriteSpellGoTargets of spell targets struct. Anyway, it's a way to work. At least, now i know were i can find info about targets, which uses for spell projectiles Thx this paste for idea: http://pastebin.com/qELFxfYL
I see a spell targets: mask == 2 or just TARGET_FLAG_UNIT.
So, i'll try to debug this code part in oregoncore.
-
Projectiles flying(as animation) from target to itself.
It must be from caster to target, but it flying from caster's target and strikes back to target.
"painted" by sso1
You see? Arcane missles from Colossus hands to Colossos body! But it's my arcane missles!
Mangos from master, SD2 too, DB - MODB(https://github.com/iorlas/MODB).
Now i'm searching whats wrong in Spell.cpp, comparing with oregoncore.
-
This bug appears in mangos one. Confirmed.
I'll fix it, but not now. Now i have higher priority tasks like projectiles in channeled casts and my db refactorring.
-
Fixed by
else if(m_timer == 0 || m_IsTriggeredSpell)
This idea taken from "oregoncore", which has this code:
if (m_IsTriggeredSpell) cast(true); else { // stealth must be removed at cast starting (at show channel bar) // skip triggered spell (item equip spell casting and other not explicit character casts/item uses) if (isSpellBreakStealth(m_spellInfo)) m_caster->RemoveAurasWithInterruptFlags(AURA_INTERRUPT_FLAG_CAST); m_caster->SetCurrentCastedSpell(this); SendSpellStart(); if (m_caster->GetTypeId() == TYPEID_PLAYER) m_caster->ToPlayer()->AddGlobalCooldown(m_spellInfo,this); if (!m_casttime && !m_spellInfo->StartRecoveryTime && !m_castItemGUID //item: first cast may destroy item and second cast causes crash && GetCurrentContainer() == CURRENT_GENERIC_SPELL) cast(true); }
See commit https://github.com/iorlas/one/commit/411b0696887cb6df8b8c1140e6c5aa77be32488e
-
Mangos Version: master from github
Custom Patches: only pulled into master
SD2 Version: master from github
Database Name and Version : TBCDB fork https://github.com/iorlas/MODB
How it SHOULD work: Debuff must be applied instantly(proof at 1:20 - http://www.dailymotion.com/video/x3scyt_terrestian_music)
How it DOES work: Debuff waits full cast time(2.5 sec)
Arcane Blast start casting, casts, hits and need 2.5 sec more to Arcane Blast debuff activate.
I know why it works like this and i can fix it...
In void Spell::prepare(...):
m_casttime = GetSpellCastTime(m_spellInfo, this);
It returns cast time by spellCastTimeId from DBC, it equals 2500 = 2.5 sec(you can see spell 36032 in spell.dbc, it has 19 spellCastId, which equals to 2500 by SpellCastTimes.dbc).
Next line -
ReSetTimer();
It sets m_timer to m_casttime or 0, if it's <0.
So, at the end of function we have m_timer = 2500.
Next:
if (!m_IsTriggeredSpell) { ... } else if(m_timer == 0) ...
36062 is triggered spell, but m_timer = 2500... It means Arcane Blast debuff casts in... so, we have comment at the end of function:
// else triggered with cast time will execute execute at next tick or later// without adding to cast type slot
// will not show cast bar but will show effects at casting time etc
So, i can just add something like "|| m_spellInfo->Id == 36062" to "else if(m_timer == 0)" or make a switch... but i'm not sure if it right way.
Maybe cast time must be ignored in some spells not by id.
I know, it works on "oregoncore", but i cant test it, either i cant test it on mangos/mangos.
[BUG] Projectiles from casts(like Arcane Missles) bug
in OldBug reports
Posted
Not really a caster position. It works same as in mangos, but instead of trigger target, uses m_target as caster of spell:
That's all difference between mangos and TC(but, maybe it somehow reworked in master TC, i have only oregoncore, which is a TC with backported patches from TC).
Fixed and little bit tested now:
https://github.com/iorlas/one/commit/b5af4633392505b6df07de30acdf8b6739057ca7