mirror of
https://gitcode.com/GitHub_Trending/az/azerothcore-wotlk.git
synced 2026-10-10 07:06:38 +08:00
AndrewandClaude Opus 5
5054796f66
Spell::EffectForceCast always handed the forced cast the original caster as its unit target. When the triggered spell takes no unit target but does need a destination, Spell::InitExplicitTargets turns that unit target into the destination, so the forced cast resolves against the original caster instead of against the unit that was forced to cast it. Only pass the unit target when the triggered spell's explicit target mask accepts one, which is the same test InitExplicitTargets applies before discarding it. Twelve spells in the client data force-cast a spell that needs a destination but takes no unit target: 42073, 48759, 52187, 57838, 58566, 62207, 62301, 62921, 64088, 64598, 69839 and 70882. Seven of them place their summon somewhere new - 48759, 52187, 57838, 58566, 62207, 62921 and 64088, whose triggers summon at the destination itself or at a fixed offset from it. The rest do not move: 42073 force-casts on itself, 69839's force-cast effect is prevented by a spell script, and 70882's trigger overwrites the destination with TARGET_DEST_CASTER. 62301 and 64598 are the last two. Their trigger 62293 inherited the destination like the others, but a spell_info correction forcing its TargetB to TARGET_DEST_CASTER had SelectImplicitCasterDestTargets overwrite it with the forced caster afterwards, so Algalon's craters landed correctly in spite of the bug. With the root cause fixed that correction is dead code and goes with it; the fallback destination InitExplicitTargets now picks is the same position the correction used to write, so nothing moves in-game. TestEffects_ForceCastDestination covers both trigger shapes: 62221 and 62293 summoning at the destination itself, and 48757 summoning at an offset from it. Co-Authored-By: Claude Opus 5 <[email protected]>