Which states pass on from TAG to Pilot?

I didn't say that 'the TAG profile is activated but it prevents AROs' rather I said 'it counts as not having been activated'. It's retroactive. But first you need the TAG profile to be able to declare Move at step 3. An IMM TAG cannot declare Move(Dismount) and so the Pilot cannot perform Move(Dismount). The declaration itself is prevented by IMM.

Compare Zondnautica. A Zondnautica has been hit by an ADHL and is IMM-2.

1. I activate the Zondnautica.
2. I spend an Order.
3. I declare Move, Dismount.

At this point my opponent informs me that that is an invalid declaration. It is exactly the same for TAGs.

Re: Possession. It's the retroactive nature of Dismount that (kinda) allows a Possessed TAG to declare Move (Unmount).

1. The possessor activates the Possessed TAG
2. He spends an order
3. He declares Move(Dismount)

All of that is 100% valid. It's how you resolve the rest of the order that's borked.

 

We are discussing a technicallity here, as long as the 2 players know that the TAG profile doesn't generate AROs it'll be ok. However I stand with my Reading, let me further explain:

The Zondnautica is a different case, this is a bike with a G:Sync remote attached. I have to look this rules a bit slower because here it also talks about profiles; but it also state that in the other profile the pilot is given a G:Sync remote, so it may implies that the remote is considered a separated trooper. I'll check that later.

But anyway. The "pilot" model is the controller and the bike is always being actívated because you cannot actívate a G:Sync without also activating his controller, so in this case both are always going to be activated.

In the TAG case you have 2 profiles that cannot be activated at the same time. When you actívate the TAG, you have to perform the whole order with the profile you actívate with that particular order. If you declare Move with the TAG, then the robot activates and moves but you cannot dismount the pilot after expending the order to actívate the TAG profile. You have to declare move(dismount) using the pilot profile, so the TAG profile never activates.
Similarily when you mount you don't actívate the pilot profile at any point, you actívate the TAG profile with the move(mount) because the requisites are met (pilot in b2b and non null/INM)

As I said, this is a technicallity. If you say you activate the TAG profile, and then dismount the pilot which happens before any ARO declaration which negates AROs versus that profile. I don't think it makes any difference with my sequence, but I think mine is more faitful to the rules

 

It's really not faithful or academic.

You have a TAG on the table

Step 1. You activate the Trooper (which is a TAG)

If your Trooper (the TAG) is Possessed you cannot complete this step.

Step 2. You spend and Order from your Order Pool.

If your Trooper is Isolated this step is not valid, and you cannot complete this step.

Step 3. The Trooper (still the TAG) declares Move (Dismount)...

If the Trooper is immobilised then the Trooper cannot declare Move, and you cannot complete this step.

(Step. 3 continued) ... You place the Pilot in B2B and the TAG-profile counts as not having been activated.

Yeah! You successfully Dismounted.

 

Lol, it's not academic, just a game XD.

Step 1 doesn't activate, you just say what is going to do. Step 2 is just "burocracy", remove order.
Step 3 declaration of first skill, is here where you are going to activate the trooper and these are the actions that may trigger AROs.
We have these rules:

It implies that is the new profile which is activated. The trooper (TAG + Pilot) declare move to dismount, the pilot profile is used for that whole order for both stats and AROs.
But again, your reading that in the step 3 you activate the TAG, declare dismount to switch to the pilot profile, and then count it as not activated makes no real difference with the other so there is no point in discussing this.

 

Well it does make a difference. Your reading would allow a Pilot to Dismount from an IMM TAG, mine does not.

Also, you're missing the phrasing in Pilot which is much closer to my timing than yours:

"This Pilot Troop Profile is usable only after the trooper declares a Move Short Skill and specifies he will use it to Dismount his Manned TAG or Vehicle."

 

I think the problem is that I see this as a trooper with 2 profiles that activates when the requirement are met, but you see it as if one profiles needs to interact with the other. In the end makes no difference, but let me explain how i see it:

Trooper: TAG (Tag profile + Pilot profile); Pilot mounted
States actives: IMM
(step 1) Declare i'll activate my TAG... (step 2) Order
(step3) I declare a move(dismount) order and I say I'll use the pilot profile. But as my trooper (which includes both profiles) is IMM that is illegal.

Trooper: TAG (Tag profile + Pilot profile); Pilot mounted
States actives: -
(step 1) Declare i'll activate my TAG... (step 2) Order
(step3) I declare a move(dismount) order and I say I'll use the pilot profile (no IMM so legal) so I place my pilot in b2b and move it (this miniature is the one that generate AROs)

Trooper: TAG (Tag profile + Pilot profile); Pilot unmounted in b2b
States actives: -
(step 1) Declare i'll activate my TAG... (step 2) Order
(step3) I declare a move(mount) order and I say I'll use the the TAG profile (no IMM so legal), so I remove my pilot from b2b and move the TAG profile (the TAG miniature is what generate AROs)

 

Your Pilot is Dismounted and 8" away from the TAG. You TAG is hit by an EM weapon and becomes IMM and ISO.

How is your Pilot affected?
Can you spend a Regular order on it?
Can you declare Move with it?

 

Yeah, these are just the weak points of these rules right now. As I read it, the pilot is IMM-2 and isolated. The isolated part could make sense (let's say the pilot comms are directed through the TAG); the IMM one cannot be justified, but as there is no rules that prevent the state to affect the pilot, it does. Funnily enough, an engineer should be able to cancel these states "repairing" the pilot XDD.

However this is a niche scenario. How did this happen?
In your active turn the TAG generates no ARO (so unless you dismounted the pilot in the range of a model with an E/M AoE weapon, very bad idea, he cannot be targeted). Maybe you could have activated another model and move it near of the TAG so a E/M grenade could affect both, but again that's not that likely.
In your reactive turn the pilot needs to be outside of the TAG, which should never happens, also if the TAG is not active, it will probably be ignored or targeted with AP/EXP ammo, no reason to tickle it with E/M.

 

Because you have a Nomad player with a Pitcher who wants to Isolate or IMM the Pilot on Normal rolls.

Or an EM LGL or any number of other EM weapons. I've killed remarkably few TAGs.

Get stuck outside of a TAG isn't particularly niche.

 

via Imgflip Meme Generator


I don't know, getting stuck outside a TAG sounds like a very bad play to be honest, some Pilot profiles are specialists but risking a 80+ model using the pilot profile should be used with a lot of care. Something like position the tag to cover your pilot; dismount in total cover thanks to your TAG S generating no ARO, in b2b with the obj plus prone, snatch the obj and then back to the big robot in the next order.
If you end your turn outside your TAG, then eating a E/M is like the last of your problems.

I'm curious. In which situations have you seen pilots stuck outside their TAGs?

 

FTFY

Whether they have the specialist operative skill or some other skill that makes them a spec ops in all missions...

Remember, though, Operators are not Pilots.

 

She’s a paramedic, though.

 

Oh, good catch. I caught the KHD pilot (because I remembered there being one), but didn't think to look for other skills. Fixing post now.

 

No worries, just double checked because I remember one of the big things with making Pilots and Remote Pilots universal was to increase TAG utility by giving all of them access to a specialist.

 

It's good to know all pilots are specialist! I didn't check all of them so I wasn't sure.
We have already talked about RAW. Let’s get creative now. How would you rule this so it’d make more sense without overcomplicating things?


My try: Inside the pilot and remote pilot skill (or maybe in a new skill given to those TAGs) I’d add this:

Version 1, extended:

• A mounted pilot is affected by the same effects than his TAG unless stated otherwise. The states Burnt and Isolated are tracked sepparately for both troops profiles.
• Mounting is not possible when IMM is active in the TAG or the Pilot troop profile.
• If the TAG troop profile or the Pilot troop profile enters in a new state while the pilot is dismounted, that effect won’t affect the other profile unless stated otherwise.
• When mounting, do not apply any game state only active in the pilot troop profile to the TAG troop profile.
• An engineer that spends a short skill to remove states from a TAG with a mounted pilot will remove states from both troop profiles. If the states are removed from an unmounted pilot or an unmounted TAG, the effects are only removed from that profile.

Version 2, more simple

• A mounted pilot is affected by the same effects than his TAG.
• Mounting is not possible when IMM is active in the TAG or the Pilot troop profile.
• If the TAG troop profile or the Pilot troop profile enters in a new state while the pilot is dismounted, that effect won’t affect the other profile unless stated otherwise.
• When mounting, do not apply any game state only active in the pilot troop profile to the TAG troop profile.
• An engineer that spends a short skill to remove states from an unmounted pilot or an unmounted TAG will only remove states from that profile.

So the idea here is making both profiles behave a bit more realistically but still treating the TAG as the “reference” profile. In both versions when the pilot dismounts both profiles will have the effects active in the TAG profile but from that point they are on their own state wise. The version 1 save some of the pilot profile states, in the version 2 all states from the pilot are removed when he mounts again. The engineer can be used in the pilot but will be much more effective when used in the TAG (as it should be)

In the version 2 isolated was a tough one. For the sake of simplicity I leave it like this, but there is still an odd interaction: a non-isolated pilot mounting an isolated TAG will become isolated. I personally like more the version 1.

A thing that is kind of implicit and could generate doubts is that you can activate the model with a regular order while the isolated state is only in one of the profiles, but you cannot activate that profile. So maybe an extra bullet point could be added just for that:

• While isolated, this trooper can receive order from his order pool, but these orders cannot activate the isolated trooper profile.

Do you see worms in these extra rules? How would you rule it?

 

'play it like Zondnautica except the TAG never activiates' is how I'd play it [emoji14]

 

Well, let's call it a day!

 

A TAG that became G:Sync of its pilot, what a nice idea.

Please send it to the black lab for further development

 

Lab response: Developing it the other way around, the pilot is the G:Sync one; please wait for further instructions.

 

When it comes to game states and how they are applied to a TAG and Pilot, I think we must treat both as separate troopers in nearly every respect. The rules explicitly tell us when troopers who share some sort of connection also share certain effects.

• Players do not apply any game states of the TAG—other than Sepsitorized, Retreat! or those which specify so—to the Operator.

• If the Doctor/Engineer enters the Isolated state, or any Null state, then the G: Servant trooper will enter the Disconnected state at the end of the Order that happened.
• If the Doctor/Engineer is, or becomes, Impetuous or Extreme Impetuous, then his Impetuous Order also activates compulsorily the G: Servant trooper, which will be considered Impetuous or Extreme Impetuous as well.

Which means the default position the rules take is that no effects are automatically passed from one to the other. If it was the other way around, the rules would be telling us exceptions of when effects are not passed on.