Menu
News
All News
Dungeons & Dragons
Level Up: Advanced 5th Edition
Pathfinder
Starfinder
Warhammer
2d20 System
Year Zero Engine
Industry News
Reviews
Dragon Reflections
White Dwarf Reflections
Columns
Weekly Digests
Weekly News Digest
Freebies, Sales & Bundles
RPG Print News
RPG Crowdfunding News
Game Content
ENterplanetary DimENsions
Mythological Figures
Opinion
Worlds of Design
Peregrine's Nest
RPG Evolution
Other Columns
From the Freelancing Frontline
Monster ENcyclopedia
WotC/TSR Alumni Look Back
4 Hours w/RSD (Ryan Dancey)
The Road to 3E (Jonathan Tweet)
Greenwood's Realms (Ed Greenwood)
Drawmij's TSR (Jim Ward)
Community
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions, OSR, & D&D Variants
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Resources
Wiki
Pages
Latest activity
Media
New media
New comments
Search media
Downloads
Latest reviews
Search resources
EN Publishing
Store
EN5ider
Adventures in ZEITGEIST
Awfully Cheerful Engine
What's OLD is NEW
Judge Dredd & The Worlds Of 2000AD
War of the Burning Sky
Level Up: Advanced 5E
Events & Releases
Upcoming Events
Private Events
Featured Events
Socials!
EN Publishing
Twitter
BlueSky
Facebook
Instagram
EN World
BlueSky
YouTube
Facebook
Twitter
Twitch
Podcast
Features
Top 5 RPGs Compiled Charts 2004-Present
Adventure Game Industry Market Research Summary (RPGs) V1.0
Ryan Dancey: Acquiring TSR
Q&A With Gary Gygax
D&D Rules FAQs
TSR, WotC, & Paizo: A Comparative History
D&D Pronunciation Guide
Million Dollar TTRPG Kickstarters
Tabletop RPG Podcast Hall of Fame
Eric Noah's Unofficial D&D 3rd Edition News
D&D in the Mainstream
D&D & RPG History
About Morrus
Log in
Register
What's new
Search
Search
Search titles only
By:
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions, OSR, & D&D Variants
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Menu
Log in
Register
Install the app
Install
Upgrade your account to a Community Supporter account and remove most of the site ads.
Community
General Tabletop Discussion
*Pathfinder & Starfinder
Order of triggered actions
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Dausuul" data-source="post: 5397906" data-attributes="member: 58197"><p>Here's how I'd go about it...</p><p></p><p>Basically, the way to organize this is with a (slightly modified) stack: Last in, first out. (There's a reason M:tG uses the term "stack" to describe its timing system--it's based on the computer science term, a fact I just now realized. 4E works much the same way.) Our stack will consist of an array of in-game events, plus four methods: <strong>AddInterrupt, AddReaction, ResolveEvent</strong>, and <strong>ExecuteStack</strong>.</p><p></p><p><strong>AddInterrupt</strong> takes an event as parameter. It inserts that event at the <em>end</em> of the array. We will use this method when an immediate interrupt or opportunity action is declared, or when an action is declared on an empty stack.</p><p><strong>AddReaction</strong> takes an event as parameter. It inserts that event in the <em>second-to-last spot</em> in the array. We will use this method when an immediate reaction is declared, or when an event creates another event (e.g., a successful attack roll creates a damage roll).</p><p><strong>ResolveEvent</strong> looks at the <em>last</em> event in the array and does the following:</p><ol> <li data-xf-list-type="ol">If event has not been resolved: Resolve it (but do not apply the result), then check to see if anyone has a response. If someone responds, exit ResolveEvent (do not do step 2).</li> <li data-xf-list-type="ol">Apply the result of the event and remove the event from the array.</li> </ol><p><strong>ExecuteStack</strong> checks to see if anyone wishes to add an event with AddInterrupt or AddReaction. It continues until no one wishes to add an event; then call ResolveEvent. Repeat until the array is empty.</p><p></p><p>A key thing to note is that I say "event" rather than "action." This is going to be an important distinction, because a lot of actions involve multiple events--typically an attack roll and a damage roll, the latter being contingent on the result of the first.</p><p></p><p>So, with the example above, we start with an empty array. Since the wizard is casting into an empty stack, we call AddInterrupt to put the spell in the array:</p><p></p><p>{ Spell }</p><p></p><p>Then ExecuteStack. Two enemies respond with opportunity attacks, #1 and #2. (As to which of them declares first, I'd go in reverse initiative order.) These are treated as interrupts, so we use AddInterrupt again:</p><p></p><p>{ Spell, OA #1 }</p><p>{ Spell, OA #1, OA #2 }</p><p></p><p>Nobody else has anything to declare at this time, so we proceed to ResolveEvent. The event at the end of the array is OA #2.</p><p></p><ol> <li data-xf-list-type="ol">OA #2 has not been resolved, so we resolve it by making an attack roll (say it hits). Then check to see if anyone has a response. No one does.</li> <li data-xf-list-type="ol">Apply the result. This produces a damage event, so we call AddReaction, resulting in this:</li> </ol><p>{ Spell, OA #1, OA #2 Damage Roll, OA #2 }</p><p></p><p>Then remove OA #2 from the stack:</p><p></p><p>{ Spell, OA #1, OA #2 Damage Roll }</p><p></p><p>ResolveEvent finishes. We're still in the middle of ExecuteStack, and the array is not empty, so we check for new events (none) and ResolveEvent again. This time it's the damage roll. We resolve it (say, 6 damage); check to see if there's a response (no); apply the damage (reduce caster's hit points by 6); and remove the event.</p><p></p><p>{ Spell, OA #1 }</p><p></p><p>Go through the same process with OA #1. Maybe this one misses, so we never get a damage roll event; we just move straight on to the spell.</p><p></p><p>{ Spell }</p><p></p><p>Check for new events, then ResolveEvent once more. This is where things get tricky. We resolve the spell; the attack misses. Then we check to see if there's a response--and get a yes! The warlord wishes to respond with an interrupt. So we call AddInterrupt and exit ResolveEvent.</p><p></p><p>{ Spell, Warlord's Reroll }</p><p></p><p>Notice that at this point, <em>the spell event is resolved</em>. The attack roll has already been made and its value is sitting in Spell. This is important, because if Warlord's Reroll is somehow prevented, the original attack roll should apply--we don't want to come back to Spell and start all over!</p><p></p><p>Anyhow, we're still in ExecuteStack and the array is <em>still</em> not empty. So we look for new events (no) and ResolveEvent yet again. This time it's Warlord's Reroll. We resolve it by re-doing the attack roll for Spell. Then we check to see if there are any responses and get none. Next, apply the result; go into Spell and change that attack value sitting there to whatever Warlord's Reroll produced. Finally, remove Warlord's Reroll from the array.</p><p></p><p>{ Spell }</p><p></p><p>Back here again. We call ResolveEvent. It looks at Spell and sees that <em>this</em> event is already resolved; there's no need to do it over. So it proceeds directly to applying the result. Say the spell hits, we have to call AddReaction to insert a damage roll:</p><p></p><p>{ Spell Damage Roll, Spell }</p><p></p><p>And then remove Spell from the array:</p><p></p><p>{ Spell Damage Roll }</p><p></p><p>ResolveEvent one more time, to deal with the damage roll--it should be pretty clear by now how this goes. ResolveEvent finishes, Spell Damage Roll is removed from the array, and the array is empty. ExecuteStack ends.</p><p></p><p>(And <em>damn</em>, that was a lot more complicated than I thought it would be when I started writing it. I don't even want to think about what happens if the spell has multiple targets.)</p></blockquote><p></p>
[QUOTE="Dausuul, post: 5397906, member: 58197"] Here's how I'd go about it... Basically, the way to organize this is with a (slightly modified) stack: Last in, first out. (There's a reason M:tG uses the term "stack" to describe its timing system--it's based on the computer science term, a fact I just now realized. 4E works much the same way.) Our stack will consist of an array of in-game events, plus four methods: [b]AddInterrupt, AddReaction, ResolveEvent[/b], and [b]ExecuteStack[/b]. [b]AddInterrupt[/b] takes an event as parameter. It inserts that event at the [i]end[/i] of the array. We will use this method when an immediate interrupt or opportunity action is declared, or when an action is declared on an empty stack. [b]AddReaction[/b] takes an event as parameter. It inserts that event in the [i]second-to-last spot[/i] in the array. We will use this method when an immediate reaction is declared, or when an event creates another event (e.g., a successful attack roll creates a damage roll). [b]ResolveEvent[/b] looks at the [i]last[/i] event in the array and does the following: [LIST=1][*]If event has not been resolved: Resolve it (but do not apply the result), then check to see if anyone has a response. If someone responds, exit ResolveEvent (do not do step 2). [*]Apply the result of the event and remove the event from the array.[/LIST] [b]ExecuteStack[/b] checks to see if anyone wishes to add an event with AddInterrupt or AddReaction. It continues until no one wishes to add an event; then call ResolveEvent. Repeat until the array is empty. A key thing to note is that I say "event" rather than "action." This is going to be an important distinction, because a lot of actions involve multiple events--typically an attack roll and a damage roll, the latter being contingent on the result of the first. So, with the example above, we start with an empty array. Since the wizard is casting into an empty stack, we call AddInterrupt to put the spell in the array: { Spell } Then ExecuteStack. Two enemies respond with opportunity attacks, #1 and #2. (As to which of them declares first, I'd go in reverse initiative order.) These are treated as interrupts, so we use AddInterrupt again: { Spell, OA #1 } { Spell, OA #1, OA #2 } Nobody else has anything to declare at this time, so we proceed to ResolveEvent. The event at the end of the array is OA #2. [LIST=1][*]OA #2 has not been resolved, so we resolve it by making an attack roll (say it hits). Then check to see if anyone has a response. No one does. [*]Apply the result. This produces a damage event, so we call AddReaction, resulting in this:[/list] { Spell, OA #1, OA #2 Damage Roll, OA #2 } Then remove OA #2 from the stack: { Spell, OA #1, OA #2 Damage Roll } ResolveEvent finishes. We're still in the middle of ExecuteStack, and the array is not empty, so we check for new events (none) and ResolveEvent again. This time it's the damage roll. We resolve it (say, 6 damage); check to see if there's a response (no); apply the damage (reduce caster's hit points by 6); and remove the event. { Spell, OA #1 } Go through the same process with OA #1. Maybe this one misses, so we never get a damage roll event; we just move straight on to the spell. { Spell } Check for new events, then ResolveEvent once more. This is where things get tricky. We resolve the spell; the attack misses. Then we check to see if there's a response--and get a yes! The warlord wishes to respond with an interrupt. So we call AddInterrupt and exit ResolveEvent. { Spell, Warlord's Reroll } Notice that at this point, [i]the spell event is resolved[/i]. The attack roll has already been made and its value is sitting in Spell. This is important, because if Warlord's Reroll is somehow prevented, the original attack roll should apply--we don't want to come back to Spell and start all over! Anyhow, we're still in ExecuteStack and the array is [i]still[/i] not empty. So we look for new events (no) and ResolveEvent yet again. This time it's Warlord's Reroll. We resolve it by re-doing the attack roll for Spell. Then we check to see if there are any responses and get none. Next, apply the result; go into Spell and change that attack value sitting there to whatever Warlord's Reroll produced. Finally, remove Warlord's Reroll from the array. { Spell } Back here again. We call ResolveEvent. It looks at Spell and sees that [i]this[/i] event is already resolved; there's no need to do it over. So it proceeds directly to applying the result. Say the spell hits, we have to call AddReaction to insert a damage roll: { Spell Damage Roll, Spell } And then remove Spell from the array: { Spell Damage Roll } ResolveEvent one more time, to deal with the damage roll--it should be pretty clear by now how this goes. ResolveEvent finishes, Spell Damage Roll is removed from the array, and the array is empty. ExecuteStack ends. (And [i]damn[/i], that was a lot more complicated than I thought it would be when I started writing it. I don't even want to think about what happens if the spell has multiple targets.) [/QUOTE]
Insert quotes…
Verification
Post reply
Community
General Tabletop Discussion
*Pathfinder & Starfinder
Order of triggered actions
Top