Played Rescue and the question of whether or not you can touch a Civilian along a movement path then keep moving and still declare the sync civilian short movement skill. It is an odd occurrence within the order declaration sequence which really goes all the way back to bumping an ITS objective and not being in BTB at the end of an order, but for years we've played that it is a legal sequence even though we aren't meeting the requirements to declare the skill at resolution. Please review the red important box on page 31 from N3.
I'd say that "everything happens at the same time" means you can do touch & keep going in the first short order, then syncronize in the second short order... it's the same principle of planting a mine alongside your path. Now the red box you mention is about CC, where you have to stop all movement when in B2B with an enemy trooper, aside from that I see no contradiction: you declare your movement path, all enemy AROs are declared (if any), then you declare the sincronization of the civilian. Since you are not attacking in melee a civilian...
The important box is for all orders/skills... CC is an example. The only other time this has mattered is for activate for opening doors and that doesn't involve a roll. I am all for over emphasizing that part (on my part) as rescue is already a difficult enough mission.
Spoiler: red box The first phrase I think gives the more info, and the use of CC as an example is relevant because the CC sequence demands you to be B2B with the target before declaring CC attack (meaning that if you move, touch base, then keep moving prevents you from declaring CC attack). Aaaaand after checking Sinchronise Civilian (HSN3 pg 94) it is the same as CC: you must be B2B to declare, so yeah, move, touch base, end move, declare. RAW at least.
There's nothing that would stop you doing a 'drive-by' Synching, just like there's nothing that stops you doing a drive-by Doctoring or objective interaction. What stops you doing a drive-by CC Attack is that your movement instantly ends for the rest of the Order when you reach base contact with an enemy, see the General Movement Rules: A trooper's Movement ends automatically whenever he enters base to base contact with an enemy, even if the movement route specified is cut short as a result.
How is the CC example an example at all then? You can't declare CC attack without being in BTB in the first place, and to my knowledge there isn't a situation in the game where you could meet the requirements of CC and then at resolution somehow not meet them (which has been my hang up with that entire important box) Regardless, Rescue became slightly less a pain.
The CC example is probably the same reason as the Engage example not taking into consideration it was using a model with a 3 inch engage range. :fearscream: But I think it's safe to assume that it's a result of the various rules that would have been able to (or used to be able to) create the situation where you declare CC against something and the discover that it's invalid have been rewritten to avoid the situation. Sort of like how Hacking vs. holoprojector got rewritten to eliminate (at least some of) the guessing about whether the target is a valid hacking target before you declare hacking.
I've always wondered why the above bit, despite being so generally important, is only ever presented explicitly in the BS Attack section (written specifically with BS Attack in mind). Considering how important Movement is to the relationship, it would be nice if something similar were presented in the Movement section, or even the All At Once section. For instance, an Important! box with the following information would make the whole thing very clear...
*add "where it is a valid declaration." at the end of that. You can't declare a skill that requires LoF, for example, at a point along the movement that does not have LoF (though, why you would want to do that, I don't know).
I'd say it's not the most clarifying (capturing objectives would, since those don't have the "stop movement" caveat of B2B with enemy models, which is kinda needed for CC), and that saying that you need to be B2B before declaring something might be misleading (since a common interpretation of the rules is that you can declare whatever the heck you want, and if the troop the order is spent on cannot execute the declared order, then it just does Inaction).
Just to repeat, CC Attack is completely irrelevant to the actual subject being discussed, because it involves specific changes to the movement rules.
I can declare my sniper starts break dancing like a morlock on drugs if I want, and since the rules don't allow him to do so, that first short order defaults to Inaction (we use a lot of "I shake" instead of inaction in Spain, for example). On a more serious note, an engineer with a Servitor: the engineer suffers the IMM-2 state due to Adhesive ammo and a PH failed roll. I can still declare orders to him (move + engineer) to move the servitor, but the engineer will do "inaction + inaction" while the servitor touches his base and tries to remove the glue (using the engineers WP, funnily enough).
What's that got to do with "(since a common interpretation of the rules is that you can declare whatever the heck you want, and if the troop the order is spent on cannot execute the declared order, then it just does Inaction)."? Requirements have to be fulfilled when declaring a Skill so you can't, for example, declare BS Attack with a Rifle if you don't have LoF to the target. EDIT - and what's it got to do with dlfleetw's question?
I'd argue that the G:Servant rules do not necessarily extend to the general case, so that doesn't quite work, but the only situation I can think of off the top of my head is ZoC declarations... but that's only due to a quirk in the timing of measuring your ZoC. It certainly doesn't allow you to declare "break dancing like a Morlock" in any situation. As to the OP, are we all in agreement that you can "drive-by" sync civilian, then?
Is there functionally any difference between a simple requirement and a requirement that specifies some relationship exist in order to even declare it (LoF, B2B, etc)? For instance, you can't declare Synchronize Civilian followed by Move, unless there was B2B contact with the target at the beginning of the order. On the other hand, Doctor lists B2B contact as a requirement, but not a requirement to declare. Seems like declaring Doctor outside of B2B contact, followed by a Move into contact would be legal, right? Seems odd to me that they wouldn't just list all such relationship based requirements as necessary for declaration, if the timing of the relationship doesn't actually matter when combined with a first skill move. Under really specific circumstances, you could maybe force ZoC Change Facing AROs by declaring Doctor, Engineer, or many of the mission specific skills outside of an enemies LoF, and then moving into B2B with the target using the second skill.
I'm confused. Where does it say you can do this? If you are talking about the wording the G:Servant/Sync skills...
Sorry about the confusion, I wasn't referencing anything to do with G:Servant/Sync. It probably could have been a new thread, but the discussion earlier got me thinking about the relevance of certain requirements when Move isn't the first skill declared. We're almost always presented with examples of the Move-Skill variety, making the simultaneous nature easy to follow. However, the fact that many skills have requirements to even declare them time stamps them in a way, setting them distinctly before any movement takes place if they're declared first (Synch Civvie, BS Attack, etc). The exception, from what I can tell, are those skills that have requirements that don't specify declaration (Doctor, Engineer, most mission specific Skills like Hack Antennae, etc). At that point, I assume we would fall back on the problematic red Important box on page 31 that was mentioned previously. If an invalid skill can be declared, actual validity is determined at resolution, meaning a second Move skill could satisfy the requirements (why not, everything is simultaneous, right). Seems to me that this would mean a potentially invalid skill declaration would actually turn out to be valid, and not count as an Idle.
