[Unahim]

demiGOD is absolutely correct, per the description of Control Device on pg 238.

The benefit of rigger cyberware is a bonus to dice pools AND limits for any actions you're taking AND lower thresholds for any tests you make.  Also Riggers don't suffer the -2 for "windowed perception" tests made through the drone.

Help me out here: on what page do you find that -2?

I think he's referring to the suggested -2 for people watching an AR window while doing stuff in the meat too, but that seems to be taking it out of context a bit.

[Stainless Steel Devil Rat]

That's order of authority, though, it doesn't state whether you're actually costing the drone its own actions if I recall correctly. It simply says what control methods take priority, right?

Control Override on page 265 appears to be what you're thinking of.

[FasterN8]

demiGOD is absolutely correct, per the description of Control Device on pg 238.

The benefit of rigger cyberware is a bonus to dice pools AND limits for any actions you're taking AND lower thresholds for any tests you make.  Also Riggers don't suffer the -2 for "windowed perception" tests made through the drone.

Help me out here: on what page do you find that -2?

I think he's referring to the suggested -2 for people watching an AR window while doing stuff in the meat too, but that seems to be taking it out of context a bit.

Yeah, that's kind of what I meant, but I could have swore it listed it specifically as a penalty somewhere.  However, I just finished several searches of the book and I can't find it anywhere. 

Maybe I'm going crazy, but I thought there was a listed penalty for a Rigger to make "windowed" perception checks when he was monitoring several of his drones video feeds simultaneously.  I know I didn't just make it up, but I can't find it anywhere in the book so maybe I read it somewhere else and just got my rules crossed.  Sorry about that.

[FasterN8]

That's order of authority, though, it doesn't state whether you're actually costing the drone its own actions if I recall correctly. It simply says what control methods take priority, right?

Control Override on page 265 appears to be what you're thinking of.

So here's my question in the form of an example.  When a drone has an initiative of 23 and the owning decker has an initiative of 17, what happens when the Drone goes on 23, shoots someone and then the Decker wants to use Control Device on 17?  Does the drone get to fire a second time in that IP? 

Then what happens in the next IP?  Does the Drone get to act again on 13?  What if the Decker wants to use it to shoot again on 7, and the Rigger (who already has 3 marks on it) wants to use Control Actions on 3?  Could the Drone conceivably go 3 times in an IP?  My gut says no, but I don't have my brain wrapped around the crunch that should prevent those shenanigans.

I'm not sure if I see a command override situation here, or if there is one, how it works out with the Drone losing and regaining its autonomy.

[Stainless Steel Devil Rat]

That's order of authority, though, it doesn't state whether you're actually costing the drone its own actions if I recall correctly. It simply says what control methods take priority, right?

Control Override on page 265 appears to be what you're thinking of.

So here's my question in the form of an example.  When a drone has an initiative of 23 and the owning decker has an initiative of 17, what happens when the Drone goes on 23, shoots someone and then the Decker wants to use Control Device on 17?  Does the drone get to fire a second time in that IP? 

Then what happens in the next IP?  Does the Drone get to act again on 13?  What if the Decker wants to use it to shoot again on 7, and the Rigger (who already has 3 marks on it) wants to use Control Actions on 3?  Could the Drone conceivably go 3 times in an IP?  My gut says no, but I don't have my brain wrapped around the crunch that should prevent those shenanigans.

I'm not sure if I see a command override situation here, or if there is one, how it works out with the Drone losing and regaining its autonomy.

The first part depends on what method of control the drone was in before the owner wants to use Control Actions on his action.

If, on initiative 23 the drone was acting autonomously (autopilot), it does whatever it was doing on 23.  Then on 17, the decker can perform a Control Actions to make it go AGAIN on his action because by the Control Override rules Remote Control is higher than Autopilot, and no IP lockdown takes place.  However, then on 13 the drone does nothing because it is now remotely controlled.  On 7, the drone is still doing nothing if the decker doesn't do another Control action. 

If, on initiative 23, some hostile hacker had control of the drone and made it do something, then on 17 when the decker re-assumes control, the drone does nothing at all (since this remote control is equal to or lower than the hostile hacker's remote control) until the IP after this action.  So on 13, the done does nothing for 2 reasons (it's being remotely controlled and does nothing independently anyway, AND it's in 'lockdown' due to Control Override).  Then on 7, the owning hacker can finally do something with the drone via Control.

Since there are 4 command types, you can theoretically squeeze 4 actions out of a vehicle/drone in one IP by jumping in order from autopilot, to manual control, to remote control, to rigger interface.  You'd need 4 people to do it, and you can only go up the scale once (going down means lockdowns).  Since it takes 4 people to make the drone act 4 times in one IP, I don't think it's necessarily broken.  Those 4 people would all be getting 4 actions in the pass anyway, they're just 'transferring' them to the vehicle/drone.  Especially so since it only works under specific circumstances.

[FasterN8]

OK, I can buy that, but when do you decide that the drone isn't under Remote Control of the Decker anymore (thus avoiding lockdown)?  If the VR Decker controls it on 17 (IP#1) but does some other thing on IP#2 at 7, when does the Autopilot kick back in?  Is the Drone still being remote controlled at 8(IP#2)?  what about 6 or 7(IP#2)?

The trouble with Remote Control there isn't really a equivalent to "Jumped In" where it's a specific state.   If there's a Rigger Jumped into a drone or vehicle, that state is pretty clearly delineated. But what determines whether a drone is being remotely controlled, and therefore likely to run into the lockdown issue.

And even with the 4 control types, you could still only get 3 actions out of a drone since it takes 1 complex action to jump into a drone.  And probably only 2 actions for a drone since I don't think there's any way to "Manually control" a drone, but a vehicle might be able to squeeze out 3 actions.  I don't really like that possibility, but I guess it's RAW.

[Stainless Steel Devil Rat]

OK, I can buy that, but when do you decide that the drone isn't under Remote Control of the Decker anymore (thus avoiding lockdown)?  If the VR Decker controls it on 17 (IP#1) but does some other thing on IP#2 at 7, when does the Autopilot kick back in?  Is the Drone still being remote controlled at 8(IP#2)?  what about 6 or 7(IP#2)?

If two hackers are seizing control back and forth, the drone is constantly in Remote Control (just under who's control is changing).  It will never act (autopilot or otherwise) until the hackers quit locking it up.  (or a rigger Jumps In)

The trouble with Remote Control there isn't really a equivalent to "Jumped In" where it's a specific state.   If there's a Rigger Jumped into a drone or vehicle, that state is pretty clearly delineated. But what determines whether a drone is being remotely controlled, and therefore likely to run into the lockdown issue.

The Control Override rules on 265 establishes that there are the 4 kinds of control, and every drone must be in one of them, and only one of them, at all times.  Once you use Control Device, it's under remote control (and standing idly by every IP you don't issue a control device action) until you explicitly release it to autopilot.

And even with the 4 control types, you could still only get 3 actions out of a drone since it takes 1 complex action to jump into a drone.  And probably only 2 actions for a drone since I don't think there's any way to "Manually control" a drone, but a vehicle might be able to squeeze out 3 actions.  I don't really like that possibility, but I guess it's RAW.

Yeah, I forgot about that.  Still, X number of PCs will get X sets of actions every IP.  Whether they perform those actions completely independently or (under specific circumstances) through the same drone/vehicle is  mox nix, in my opinion.

[FasterN8]

The Control Override rules on 265 establishes that there are the 4 kinds of control, and every drone must be in one of them, and only one of them, at all times.  Once you use Control Device, it's under remote control (and standing idly by every IP you don't issue a control device action) until you explicitly release it to autopilot.

Well, the idea of explicitly releasing a drone to autopilot isn't in the book that I know of, but I'm not completely opposed to the idea.  What kind of action would that be?  A Free action?  Being able to RC a drone and then immediately release it invites lots of multiple-RC-action shenanigans that lets a single drone act faster that the most wired Street Sammy on the planet....every IP.

And if the Drones Autopilot is effectively paralyzed after every Control Device action, what's to stop a Decker from simply sleazing on a few marks to the riggers drones and then using Control Device to shut down each drone, one at a time. (since the decker would never explicitly release RC).  That's particularly problematic for aerial drones since by that interpretation, the Autopilot would not even engage to maintain safe flight.

I'm inclined to believe that the Autopilot would automatically reengage after some period of non-control via a higher control mode (RC or Manual Control).  In the same way, Remote Control as a "state" for the Drone should probably last for at least till the IP after the Drone received it's last RC action.

So when the Autopilot reengages, (however that happens) how does it reenter initiative?  Does it just go back to it's old score?  Do you reroll initiative for it?

[Stainless Steel Devil Rat]

The Control Override rules on 265 establishes that there are the 4 kinds of control, and every drone must be in one of them, and only one of them, at all times.  Once you use Control Device, it's under remote control (and standing idly by every IP you don't issue a control device action) until you explicitly release it to autopilot.

Well, the idea of explicitly releasing a drone to autopilot isn't in the book that I know of, but I'm not completely opposed to the idea.  What kind of action would that be?  A Free action?  Being able to RC a drone and then immediately release it invites lots of multiple-RC-action shenanigans that lets a single drone act faster that the most wired Street Sammy on the planet....every IP.

That's an excellent question.  And a logical one, if Control Override does not allow for a drone to be both autopilot and remote controlled at the same time.  I'd presume some action, yes.  Probably base it off communication. "Hey Drone, shoot anyone who comes out that door.." would be placing it back on autopilot, and probably only take a free action with DNI for instructions that simple.  More complex instructions might take a simple or even complex action.

However, strictly speaking, you're 'reasserting' control going down the scale.  So, if on 23 the drone does nothing because you have remote control, then on 17 you release control, the drone still does nothing on 13 as it is assuming the new, lower control mode of autopilot.  On 7, it's eligible to act but it does nothing, since it's no longer remote controlled and this is not its initiatve.  The drone will finally act on 3, so it doesn't seem like you can really overly abuse it to out-action a Sammy.

And if the Drones Autopilot is effectively paralyzed after every Control Device action, what's to stop a Decker from simply sleazing on a few marks to the riggers drones and then using Control Device to shut down each drone, one at a time. (since the decker would never explicitly release RC).  That's particularly problematic for aerial drones since by that interpretation, the Autopilot would not even engage to maintain safe flight.

Well the paralytic side effect only lasts until after the IP that you hijack control.  If the opposing side re-asserts control (not using a manner higher in the control override hierarchy) before then, that's the 'lockdown'.  You effectively have 2 people continuously struggling to control the drone; it makes perfect sense that it does nothing productive until the struggle is over.  As for flying drones, I don't think there's really too much at stake (unless the struggle goes on for a ridiculous amount of time).  Rotorcraft can autogyro down even in the event of engine failure, I don't see a barrage of confusing data coming in keeping the onboard computers from staying aloft.  Noone is able to direct it to crash, after all, while the struggle is going on.  If you assert remote control, then neglect to give it any instructions/control device actions, yeah, it probably will eventually crash.  But that's what should happen.

I'm inclined to believe that the Autopilot would automatically reengage after some period of non-control via a higher control mode (RC or Manual Control).  In the same way, Remote Control as a "state" for the Drone should probably last for at least till the IP after the Drone received it's last RC action.

I don't think that'd be problematic.  If it goes for rounds and rounds with confusing or conflicting data, seems plausible that it'd go into a holding pattern or hover till things get sorted out.  I don't think it'd be a good idea to say that the drone reasserts autopilot, however.  That'll not only allow the next hacker to jump back up the scale on control override and immediately use it w/o IP pass penalty, it also makes a nasty precedent for lower control modes to override higher ones.

So when the Autopilot reengages, (however that happens) how does it reenter initiative?  Does it just go back to it's old score?  Do you reroll initiative for it?

I'd roll initiative for it every turn regardless.  While in anything but autopilot, it's a needless number (drone will do things on the controlling player's initiative instead).  However, should the autopilot be engaged at any point, then the number is already available.

[FasterN8]

However, strictly speaking, you're 'reasserting' control going down the scale.  So, if on 23 the drone does nothing because you have remote control, then on 17 you release control, the drone still does nothing on 13 as it is assuming the new, lower control mode of autopilot.  On 7, it's eligible to act but it does nothing, since it's no longer remote controlled and this is not its initiative.  The drone will finally act on 3, so it doesn't seem like you can really overly abuse it to out-action a Sammy.

This is a bit confusing.  Why isn't it eligible to act on 13 if the Decker used a free action to release it on 17? (I'm assuming both of these are IP#1)  We already established that a drone is always in one of the control modes.  Either it's under RC or it's Autopilot on 13, but it can't be neither.

Well the paralytic side effect only lasts until after the IP that you hijack control.  If the opposing side re-asserts control (not using a manner higher in the control override hierarchy) before then, that's the 'lockdown'.  You effectively have 2 people continuously struggling to control the drone; it makes perfect sense that it does nothing productive until the struggle is over.  As for flying drones, I don't think there's really too much at stake (unless the struggle goes on for a ridiculous amount of time).  Rotorcraft can autogyro down even in the event of engine failure, I don't see a barrage of confusing data coming in keeping the onboard computers from staying aloft.  Noone is able to direct it to crash, after all, while the struggle is going on.  If you assert remote control, then neglect to give it any instructions/control device actions, yeah, it probably will eventually crash.  But that's what should happen.

That can't possibly be how it works.  Since no enemy hacker is ever going to deliberately relinquish control and would have to to expend NO actions to maintain his claim to Remote Control on the drone, then by executing one Control Device action he's effectively and effortlessly locked out anyone without a Control Rig until a reboot. 

It's worth pointing out that although we describe the competing commands as "struggling" for control, there's really no opposed tests here, so as soon as there is ANY control conflict at the RC level, the drone is effectively out of commission for 2+ turns.

Let me illustrate the logical consequences of this interpretation. (i.e. This is what I'd do as an enemy Hacker.)
Assumption: the Drone in question is not used by a Rigger.

End of Turn A - Enemy hacker uses control device to make the drone shoot your allies.
Sometime in turn B - Owner commands it to reboot (hoping the enemy hacker hasn't used Format Device on it)
End of Turn C - Drone comes back online with Autopilot in charge.

Result: The drone is out of action for 2 full rounds (B and C), I made the owner waste 1 Complex Action telling it to reboot, I may have made the Drone lose an action at the end of Turn A, and I got it to shoot one of his own allies.  That's all nasty, but  here's the icing on the cake - while all that's happening, I can be causing other mayhem for 2 full rounds (B and C) without having to do anything else against that drone, and I can be assured that it's going to be paralyzed for at least 2 rounds.

On the other hand, if we say that Autopilot reengages automatically on the next IP, then I'd have to continuously spend RC actions each turn to keep the drone under my control, or at least not under it's owners control.  That seems a lot more balanced and takes away the effortless lockdown trick.

Example:
IP#1
23 - Drone Autopilot autonomous action
17 - Enemy Hacker uses Control Device on Drone
IP#2
13 - Drone Autopilot superseded by Remote Control that was just asserted
7 - Enemy Hacker takes action other than Control Device, therefore RC is released, Autopilot in charge (but not its' turn yet)
IP#3
3 - Drone Autopilot takes autonomous actions again

[NCPtarmigan]

Example:
IP#1
23 - Drone Autopilot autonomous action
17 - Enemy Hacker uses Control Device on Drone
IP#2
13 - Drone Autopilot superseded by Remote Control that was just asserted
7 - Enemy Hacker takes action other than Control Device, therefore RC is released, Autopilot in charge (but not its' turn yet)
IP#3
3 - Drone Autopilot takes autonomous actions again

On the Initiative Pass after someone asserts control, a different user can assert control using an equal or lower control method. So, the drone's owner could reassert control over the drone on IP2, unless the enemy hacker spends another complex action to Control Device again. Let's say the drone's owner has an initiative of 14. I see it working like this:


IP#1
23 - Drone Autopilot autonomous action
17 - Enemy Hacker uses Control Device on Drone
14 - Owner is locked out (unless they are a rigger)
IP#2
13 - Drone Autopilot superseded by Remote Control that was just asserted
7 - Enemy Hacker takes action other than Control Device
4 - Owner is no longer locked out, uses Control Device to assert control, then Free Action to release control
IP#3
3 - Drone Autopilot asserts control, takes autonomous actions again

In other words, if the enemy hacker doesn't take a Control Device action each turn, control doesn't automatically go back to the Autopilot, but it does "unlock" the drone allowing another user to attempt to assert control. I agree with the general problem though - it's hard to determine when a user is or is not "controlling" a drone.

[FasterN8]

On the Initiative Pass after someone asserts control, a different user can assert control using an equal or lower control method. So, the drone's owner could reassert control over the drone on IP2, unless the enemy hacker spends another complex action to Control Device again. Let's say the drone's owner has an initiative of 14. I see it working like this:


IP#1
23 - Drone Autopilot autonomous action
17 - Enemy Hacker uses Control Device on Drone
14 - Owner is locked out (unless they are a rigger)
IP#2
13 - Drone Autopilot superseded by Remote Control that was just asserted
7 - Enemy Hacker takes action other than Control Device
4 - Owner is no longer locked out, uses Control Device to assert control, then Free Action to release control
IP#3
3 - Drone Autopilot asserts control, takes autonomous actions again

In other words, if the enemy hacker doesn't take a Control Device action each turn, control doesn't automatically go back to the Autopilot, but it does "unlock" the drone allowing another user to attempt to assert control. I agree with the general problem though - it's hard to determine when a user is or is not "controlling" a drone.

The problem with that interpretation is this: 
What control mode is the Drone in after init:7, IP2?  If it's RC by the enemy hacker, then there's still a control conflict with the owner on init:4.  If it's not under remote control at that point then it has to be the Autopilot since the Drone must be in one of the control modes.  If that's the case, then the owner doesn't have to waste a complex action "freeing the drone" (although he should probably do something about the enemy marks).

[NCPtarmigan]

The problem with that interpretation is this: 
What control mode is the Drone in after init:7, IP2?  If it's RC by the enemy hacker, then there's still a control conflict with the owner on init:4.  If it's not under remote control at that point then it has to be the Autopilot since the Drone must be in one of the control modes.  If that's the case, then the owner doesn't have to waste a complex action "freeing the drone" (although he should probably do something about the enemy marks).

Hmm, I see what you mean. I misread the rules as "the Initiative Pass after the current controller takes control." But you're right, if the enemy hacker "relinquishes control" by failing to control the drone on Init 7, IP2, then the owner shouldn't have to intervene - the drone's Autopilot should reassert control. Actually, by the RAW, even if that counts as "relinquishing control", the drone is still RCed by the enemy hacked until the end of IP2, and neither the owner nor the Autopilot can reassert control until IP3. I think your initial example is correct then - failing to control the drone at Init 7, IP2 counts as relinquishing control, and on IP3 the Autopilot, or anyone else, is free to reassert control. And a rigger could assert control at any time, because rigging beats RC for control override.

This would mean you can't use Control Device on drone that's already being RCed, right? You can only use Control Device on a drone that's on Autopilot (or being manually controlled, to the extent that applies to drones). Thus, you couldn't have two hackers battling for control just using Control Device back and forth, as the initial controller would have a lock until he explicitly relinquishes control. The more I think about this, the more it makes sense. Compare it to manual control - if you want to take control of a car, you'll have to push the driver out of the way first. Similarly, if you want to take control of a drone, you'll have to crash the controller's deck, jam his signal, erase his marks, or do something else to "push him out of the way." I think I like this, it seems like it would make hacking drones more dynamic.

[FasterN8]

I think we're on the same page, but IIRC, a Drone that is already under RC and gets another Control Device command is just going to sit there and do nothing.  So, to extend your example, if someone is driving the car and someone else ALSO grabs the wheel, nobody is actually in control until one of them lets go (or both so the Autopilot can take over).

Just looked it up on pg 267:

Drones receiving multiple contradicting commands on the same control levels (see Control Override, p. 265) before they have a chance to enact those commands on their Action Phase fail to perform any of them and instead send an error message back to the users attempting to issue the commands.

[Xenon]

Just looked it up on pg 267...

This is only for multiple people sending commands to the auto pilot (like the owner sending one command to the auto pilot and a decker sending another, spoofed command - acting as the owner... once the auto-pilot is acting it get confused and does nothing).

Only one will be in control when using remote control and he will be in control until he choose to no longer be in control (and then someone else can start to remote control during the next IP) or if someone override him with jumping in.