Yet another matrix question, This one is less complicated than usual Options

[Moon-Hawk]

Matrix pg 101
Restrict Icon
Test: Control
Utility: Validate
Action: Complex
Quick summary:
The target's DF is added to the target number. So for a decker to do this the target number is Control + DF of target - Validate. Successes can increase tally or decrease DF. Great.
Question:
For a security decker, is the target number still as above, or is it: DF of target - Validate, without Control since the security decker is allowed to perform this operation by the host?
2nd Question(s):
If this is used to decrease DF, is this still in effect if the decker who performed the Restrict Icon operation is crashed? Is it still in effect if the decker moves to another host?

Thanks.

[mfb]

1: i would say yes.
2: note that restrict is an ongoing operation. crash the decker, crash the ongoing operation.

[Moon-Hawk]

1: Thanks. Now I can run it that way, more certain that I'm not screwing the player.
2: You're right! That was a stupid question. :spin:

[Moon-Hawk]

Come to think of it, why would they make it an ongoing operation instead of a monitored operation? Wouldn't monitored make more sense?

[Dashifen]

unless you concider a decker's detection factor to be an always changing screen of code that the decker puts between him/herself and the matrix. Then, a restrict operation would have to be ongoing because you would have to adapt it to the change detection factor.

think of it this way: the sleaze utility could be constantly changing the way in which it hides the decker from view. Then, the operation to see the decker easier (restrict) would have to adjust itself to combat this mutli-formed "defense" mechanism.

[Moon-Hawk]

I'm not sure you're arguing for or against me.
An Ongoing Operation is one where, once started, it can be forgotten and it will continue to run until it's completion, with NO EFFORT from the decker whatsoever. Like downloading a file. There's a test to start it, but once that test is made, all the decker has to do is wait for the d/l to complete.
A Monitored Operation is one that requires a free action from the decker every initiative pass in order to keep it working, since the situation is always changing, like editing the output of a slave camera in real-time.

I agree that the sleaze program, masking program, and detection factor are dynamic processes, that's why I think it should be monitored and require constant maintenance from the Restricting decker to keep it working, not just a simple test-and-forget Ongoing operation.