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