The beams were summoned by hand with TEMPSUMMON_MANUAL_DESPAWN and no
duration, which InitStats turns into TEMPSUMMON_DEAD_DESPAWN, and NPC
33050 is a trigger with NullCreatureAI that can neither die nor despawn
itself. The only thing that removed them was an event on the elder, and
his event map stops running the moment he dies, so a kill taken while a
wave was up left the beams standing forever. With a 20s summon cycle and
a 15s despawn that was most kills.
Move the lifetime onto the beam: 33050 gets SmartAI rows that cast
Unstable Sun Beam and Photosynthesis when summoned, then cast Unstable
Energy and despawn after 18-25s. AIName and ScriptName resolve from the
base entry, so the 25-man template is covered too. The react-passive row
is required because InitializeReactState gives a SmartAI trigger
REACT_AGGRESSIVE; Freya's own Sun Beam (33170) carries the same row.
The elder now casts 62207 rather than placing two creatures himself, so
the placement comes from the spell: one beam at his feet, plus a forced
62221 on every player in range each summoning one under themselves. That
relies on the EffectForceCast fix in #27621.
Wave timing from a sniff: first wave 6s after the pull and then every
22-26s, against a fixed 8s and 20s. Beam lifetime 18-25s across eight
observed beams, against a fixed 15s.
The beam owning its own despawn and the 62207 cast mirror TrinityCore
60388f39073ca85f9592b1e67e88e507a1a79421. The timers come from the sniff
and the beam side is SmartAI rather than a C++ AI.
Covered by TestUlduar_BrightleafSunBeamsDespawnAfterDeath, which asserts a
beam lands on the player and that none outlive the elder. It enters at
Brightleaf's own spawn rather than the Freya pad: that pad is 12y from
Freya, and aggroing her banishes every living elder, after which he
schedules no beams at all.
Reported as https://github.com/chromiecraft/chromiecraft/issues/10163
Co-authored-by: Lopin <[email protected]>
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]>
DatabaseWorkerPool::Query already advances to the first row as part of
its result guard, so `for (count = 0; result->NextRow(); ++count)` steps
past it and the first row is never applied. Use the do/while idiom that
the other 16 loaders in this file already use.
On a stock DB the skipped row is spell 53 (Backstab, rank 1), the lowest
spell_id in the table, which therefore never receives
SPELL_ATTR0_CU_REQ_CASTER_BEHIND_TARGET and can be cast from the front.
The startup line also under-reports by one.
The same fix was submitted independently as #27416, which also provided
the in-game confirmation.
Co-authored-by: AlsoNotMehh <[email protected]>
