It seems to me that there's a catch 22 with commlinks when you are running multiple programs.

According to the SR4 rulebook, "A System program is limited by the Response rating of the device it is on; a System run on a device with a lower Response rating functions at the Response rating instead" (SR4, 213).

A page earlier, the book says, "Response may be affected if you run too many programs. For every x number of programs you have actively running, where x = System rating, your Response is reduced by 1. So if you’re running 10 programs with a System 5, your Response will be reduced by 2" (SR4, 212).

Let's say you have a commlink with Response 3 and System 3. Let's say you are running 4 programs. 4 programs is greater than the system rating by 1, which causes the commlink's Response to be reduced by 1, to 2. As per my first quote, System is limited by Response. So, System is now reduced to 2 because of the reduced Response. Begin catch 22.

Because of the reduced System (to rating 2), you can now only run 2 programs before you start to suffer a reduction in Response. Since you are running 4 programs, that's twice your current System rating, which means your Response gets reduced a by a total of 2, becoming a rating of 1. Since System is--once again--limited by Response, System now becomes 1. I assume that 1 is the lowest rating possible, so we end here.

Now, all of your programs are running at rating 1 because of the reduced System rating. All this because you are running a mere 1 program over the limit of when Response reduction begins.

Am I missing something here?!?!?!

Wow Ranger, you are a rules pimp! I'll look for something saying "This is reduction to Response is calculated from the System rating when Response is normal." I really don't expect to find anything though.

The way the program caps work is, to my mind, not sensible and leads to issues or misunderstandings such as this one. My argument for removing the response/system based caps is that in the majority of cases a better program doesn't require faster cycling or a more robust/functional operating system, a better program can compensate for these issues with better predictive programming, feature emulation and fault-tolerance. I don't believe this will change in the world of 2070 because better programs will still be needed by digital specialists and they'll be willing to pay top nuyen for them. Hackers will also value giving their toaster the capacity to browse the matrix even with a crippled OS, because hackers - by their very name - value cool tricks and clever subversions of inbuilt limitations. The rules already indicate areas where speed is important by including the response rating in tests, capping the program rating by system which is in turn capped by response is just double-dipping on the response reduction.

I ought to state my qualifications for stating these things; I'm a CompSci undergraduate, I know what a good program can do.

That sounds cool to me. Response limiting program really just prevents Hackers from having another die at char gen. After about 1-2 runs, getting the new response chip is no big deal and those who were smart and got rating 6 programs at char gen will be hacking at full force in no time.

How about just calculate the response reduction based on original response, not modified response. It might not say so explicitly, but it makes more sense, no?

The SR4 FAQ has this to say on the matter ...

Thanks everyone for your replies.

Fortune: Thank you for finding that. I guess I need to go study the FAQ it carefully.