Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Kadeton last won the day on July 3 2018

Kadeton had the most liked content!

Community Reputation

1,930 Grand Vizier

About Kadeton

  • Rank
    Angst Bunny
  • Birthday 12/29/1982

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. For the Future Releases page and the newsletters, would it be possible to add the keyword info for those boxes where it's not otherwise stated? I realise it's in the images, but it would be nice to be able to search the page text or just to see at a glance in the email. When the details just say "WYR23114 Run Them Down $55.00", as a player it's hard to know whether to be interested or not. The keywords are a really good system for telling people whether a box will work with their current collection - I think we should leverage it more. "WYR23114 Run Them Down [Guard] $55.00" would be nice!
  2. No more snark, personal attacks, or baiting, please. Discuss things civilly and respectfully, or not at all. We're all here to try to make the game better, even if we disagree on the specifics of what should be done. Don't take proposed changes personally, and don't make them personal either.
  3. Just for clarity, I guess: For me, "general mechanics" are anything that functions the same way by default regardless of the game state, e.g. Conditions. "Special mechanics" are anything that only happens due to the rules of a specific model or models interacting with the general mechanics. If something is printed on a model's card instead of in the core rules, it's a special mechanic. Tokens don't do anything (and can't be assigned to models) until a rule printed on a model's card tells it what to do, so token mechanics are always special. Semantics, whatever. Your definitions are probably something entirely different.
  4. No, token removal isn't a thing. (Yet? Hopefully never.) This was a conscious decision by the designers as a core feature of M3E. Tokens are a really straightforward way to track unique crew mechanics, but that quickly starts to fall apart if you allow the opponent to mess with them. Allowing removal potentially gives a hard counter to an entire theme's core mechanic, which becomes extremely difficult to balance. Using tokens was an easy way to avoid M2E's situation where there were a ton of rules that amounted to "Condition X cannot be removed under these specific circumstances" to ensure that crews functioned as intended. That problem still exists to a certain extent for crews whose mechanics revolve around specific conditions instead of using tokens. Generally this is balanced out by the fact that conditions have their own built-in mechanics that don't require special mechanics to turn on, giving those crews ways to get those conditions out there easily, and/or having ways of punishing enemy models when those conditions are removed. It's much easier to balance a small number of condition-based themes that take condition removal into account, and use tokens when you want to track a resource but don't want to have to worry about enemy interference.
  5. This seems like a pointless argument which is turning belligerent. I'm reminding everyone to play nice. I don't normally make definitive statements on rules, but in this case it seems totally clear-cut: When a Trigger states "within range", it is referring to the range of the Action, including the range icon.
  6. I've pruned the thread of some inappropriate comments and issued warnings, since things escalated after I specifically asked people not to do so. Again: Be respectful of other forum users at all times, not "until they say something you disagree with" or "until they say something disrespectful".
  7. Everyone, play nice. People are free to voice their complaints, and to respond to those complaints with their opinions, but not if that devolves into personal attacks.
  8. While I agree this might not be the best place to raise interest in non-Wyrd stuff, anything mini-related is permitted by the current Trading Forum rules.
  9. That's a fascinating question. I think it would certainly require an implicit assumption that each ability (or whatever) can only come into effect in reaction to any specific event once, in order to not completely break the game. I'll be honest, the Vogel example has thrown me for a loop a bit.
  10. That's why some commenters are accusing you of setting up a separate "checking" step to determine which effects to resolve. You're essentially saying that as you're resolving effects, you don't want to re-check the updated game state for new simultaneous effects. You're looking for the passage of time - Colette unburies, then afterwards she gains Blighted - where it doesn't exist. Instead, at the start of Colette's activation, she unburies within Hamelin's aura and gains Blighted at the same time. No time passes, and it's still the "start". You don't check once, then resolve all. You check, resolve one, check again, resolve one, check again, resolve one, etc... until there's nothing left to resolve. That's how all simultaneous effects happen in this game. (More accurately you check continuously, since you can also create new effects within the resolution of effects, but it's harder to get across in context.)
  11. You guys are going nowhere with this back-and-forth. There's no point asking for "authority", since the rules are the only authority and they're open to interpretation. I'm hesitant to wade in to the discussion, but I figure I'll give it a shot. This is key, I think. As long as there are effects that might occur in the current timing step, you should be checking for them. The "start" of a model's activation is either a single instant in time, or the entire duration of the C1 phase (i.e. it is still the start of the model's activation until there are no more start-of-activation effects to resolve). There isn't enough detail in the rules to definitively argue for either interpretation. Either choice has significant consequences. However, we do know that there is no true simultaneity in the rules. The simultaneous effect rules are actually a way of sequentially ordering effects with the same timing point - the resolution of each effect is based on the current game state (modified by any previous "simultaneous" effects in the sequence), not on the game state as it existed at the timing point when it was put into effect. Given that events in the game can be simultaneous and yet resolve sequentially, it is also true that events can conversely be resolved sequentially and yet be simultaneous. This collapses the C1 phase to a single instant of time, the "start of the model's activation", in which all possible simultaneous start-of-activation effects are resolved sequentially. As you noted earlier, checking to apply is a continuous process - even though it's the same "instant", you still need to continuously check to see whether any new simultaneous effects need to be resolved whenever you change the game state. So that's my understanding: all the events in the C1 subphase occur simultaneously, at the same instant ("the start of the model's activation"). However, resolving effects always happens sequentially, re-checking for additional simultaneous effects after each is resolved, until there are no more effects that can be resolved. Only at that point has the instant passed, and we move on to C2. Hope that makes sense.
  12. I'm honestly not clear what makes Flight more explicit. If Blade Rush were worded in the same style, something like: Blade Rush: When resolving the Charge Action, instead of this model's Push being interrupted by other models normally, this model may Push through them and inflict 1 damage to them. Would that be equally explicit, and therefore modify the Action? I'm not sure what part of the rule text you're focusing on as explicit.
  13. I'm interested in the comparison. What's an example of an ability that explicitly modifies an action?
  14. I'm not sure how you reconcile the idea that "resolve any heal effects on the killed model" overrides "fully resolve an effect before moving on to the next", but all the other "resolve ... now" instructions in the damage timing don't. By that, I don't mean to say that you're wrong, just that I can't quite follow the logic.
  15. I think the contention is: Resolve damage effect on Black Blood model Step 5: Black Blood adds a damage effect on Viktoria to the resolution stack Step 6: Into the Fray adds a healing effect on Viktoria to the resolution stack Finish resolving the effect (model is removed, etc) Now resolve damage effect on Viktoria Viktoria is killed and removed from play Now resolve healing effect on Viktoria ... but she's already dead and gone So either way, she still dies.
  • Create New...

Important Information