The following question has come up recently: Do the persona and utility programs of a Decker run on his Deck or on the host he is currently on?
A number of rules point to the latter, notably the fact that you have to upload utilities to your icon with your I/O speed before you can use them, and the Bandwith rules in Matrix (I interpret Bandwith to be the commands you send to your utilities, and the feedback you get from them).
However this raises several questions: If the programs are actually executed by the host the decker is on, what do you need active memory for? Thereīs no reason why you shouldnīt be able to upload stuff (including utilities) from storage memory (maybe with a small buffer in active memory).
Same goes for the persona programs: If they are run by the host, why do you need programs and even specialised hardware on your deck to run them?
More problems: If your Icon and assorted programs run on the host, they have to be uploaded first (as detailed in the swap memory system operation).
If that is so, wouldnīt you have to wait several combat turns when you initially log on to the matrix, because you have to upload your entire active memory plus the persona programs to the first host you log on (presumably the LTG)?
Also, if you go from one host to the next, all that stuff would have to be passed along. While this usually wonīt be a problem, since Iīll assume that the bandwith with which host are connected to each other usually makes this delay negligable, it could become relevant if there is a lot of traffic between the hosts, limiting the bandwith available for Icon uploads.
And if you want to fix these problems by ditching the concept of active memory and instituting delays during the initial log-on, you run into another problem: What is the size of the Persona programs?
Full Version: What runs the persona and utilities?
the persona and utility programs on your deck insert instructions into the host's processor queue. you need active memory because the utilities need space on your deck in which to run, and generate those instructions.
the above was pulled straight from my butt, with no stops at any sourcebooks.
the above was pulled straight from my butt, with no stops at any sourcebooks.
Yeah, what MFB said.
Persona programs are etched into firmware chips on the deck, so there's definitely on-deck support for the programs.
The size of the Persona programs is described in Matrix. IIRC, it's (Rating squared) x3 (Sensors, Evasion) or x4 (Body, Masking). Might've mixed those up.
Persona programs are etched into firmware chips on the deck, so there's definitely on-deck support for the programs.
The size of the Persona programs is described in Matrix. IIRC, it's (Rating squared) x3 (Sensors, Evasion) or x4 (Body, Masking). Might've mixed those up.
my explanation also handily explains why you don't have to wait a few combat turns after you log onto a host, waiting for your active memory and persona progs to catch up: the progs and active memory stay right there on your deck, inserting instructions into the processor queue as needed. by logging on, your persona becomes a program that the host is running. this program is in contact with your deck, recieving instructions and sending status updates and data as needed back.
this explanation contradicts the book, however. check out the Swap Memory operation; according to it (and the Ongoing Operations section of SR3), you do indeed have to upload utilities to your persona. personally, i'd errata that section to read that, instead of uploading the program to the persona, the program is simply configuring itself for use on the system that the persona is currently on. that still leaves the question of why the decker doesn't have to wait for all his programs to reconfigure themselves when he logs onto a new system. hmm.
this explanation contradicts the book, however. check out the Swap Memory operation; according to it (and the Ongoing Operations section of SR3), you do indeed have to upload utilities to your persona. personally, i'd errata that section to read that, instead of uploading the program to the persona, the program is simply configuring itself for use on the system that the persona is currently on. that still leaves the question of why the decker doesn't have to wait for all his programs to reconfigure themselves when he logs onto a new system. hmm.
A while ago on the previous incarnation of the Forums I posted something that might be interesting in terms of perspective:
| QUOTE |
| When I first described the Persona to a newbie decker with an IT background, he turned to me and said "Yeah, I get it, it's basically a cross between a current day OS and a browser. It's a "mobile" Operating System which interfaces with whatever hardware it's logging into." |
I've used it ever since. The Persona like a browser is your e-presence, it interfaces with the software and firmware on a remote server/Host you are logging onto at any given moment and there is a constant information exchange going on between your computer and the remote one since the Matrix is much more reactive and dynamic than current websites (however, unlike a browser you can't have several of them running because a human can only mentally process one ASIST feed) and like an OS it houses all your programs and software in Active Memory, allocating processing space and translating your DNI commands into code.
that's a good analogy. still leaves the question of why you have to take the time to upload your progs if you do it in the middle of a matrix run, but not when you first log onto the host. to be honest, i'm not sure there is a way to explain away that particular bit of insanity.
it happens in the background, you basicly have the proggies loaded into active when you hit go and then they are properly loaded over along with the icon of the persona (in a fact the server part of them a loaded over, they hide inside the persona icon trying to make life easyer for the decker) before you see the first logon prompt pop up. its mutch like a boot today, you can have diffrent programs load into a ready mode before you hook up...
the persona chipsand the mpcp sort tu the signals comeing from the host, takeing away some of the workload for the decker. the utilitys hide inside the icon when laoded over and when you swap memory your basicly telling the host "wait i forgot about part of the icon". the icon is the graphic (and more) id of the connection and prosesses fired up to allow you onto the host (same way as some server software today spawn a new copy of itself in memory to handle more connections).
only real diff is that the bod chip are a lot smarter about keeping connections alive then the current tcp protocol:) so when you dump out its not so mutch your computer that goes down but your connection, and as connection is everything to a deck you get booted back to the real world (hard!)...
the sensor chip sorts tru signals trying to pick up stuff like new icons poping up, telling you about important ones and hideing useless ones...
evasion well that one is like a cross betwen a firewall and a antiviral program, it trys to analyze the data and blunt attacks...
as for masking, it trys to confuse the host by replying all over the palce to id querys but lets the important ones tru to other stuff...
basicly persona chips are filters, trying to help a overworked decker
as for the utilitys, they are similar to trojan software today (and allso root kits), you have a server part that you try to sneak into the host, and a client part that runs on your deck. (some are purely clientside tho, like medic and other). if you have the hosts ok do to a command then you can do it, no roll needed and no questions asked. if you dont then you kick your utils into action and try to get them to do the job insted of the native code on the host while at hte same time tryign to fool the host into thinking "hey,your useing native code".
so the whole stuff is abstract but try to stack some details on to it (not to mutch as that breaks the illusion, many threas on the old forum proved that. the principles are there but not the direct actions) and its easy to see what the decker is doing when you roll the dice...
this is my personal take on things, feel free to disregard, rip apart, or whatever else you want to do with it...
the persona chipsand the mpcp sort tu the signals comeing from the host, takeing away some of the workload for the decker. the utilitys hide inside the icon when laoded over and when you swap memory your basicly telling the host "wait i forgot about part of the icon". the icon is the graphic (and more) id of the connection and prosesses fired up to allow you onto the host (same way as some server software today spawn a new copy of itself in memory to handle more connections).
only real diff is that the bod chip are a lot smarter about keeping connections alive then the current tcp protocol:) so when you dump out its not so mutch your computer that goes down but your connection, and as connection is everything to a deck you get booted back to the real world (hard!)...
the sensor chip sorts tru signals trying to pick up stuff like new icons poping up, telling you about important ones and hideing useless ones...
evasion well that one is like a cross betwen a firewall and a antiviral program, it trys to analyze the data and blunt attacks...
as for masking, it trys to confuse the host by replying all over the palce to id querys but lets the important ones tru to other stuff...
basicly persona chips are filters, trying to help a overworked decker
as for the utilitys, they are similar to trojan software today (and allso root kits), you have a server part that you try to sneak into the host, and a client part that runs on your deck. (some are purely clientside tho, like medic and other). if you have the hosts ok do to a command then you can do it, no roll needed and no questions asked. if you dont then you kick your utils into action and try to get them to do the job insted of the native code on the host while at hte same time tryign to fool the host into thinking "hey,your useing native code".
so the whole stuff is abstract but try to stack some details on to it (not to mutch as that breaks the illusion, many threas on the old forum proved that. the principles are there but not the direct actions) and its easy to see what the decker is doing when you roll the dice...
this is my personal take on things, feel free to disregard, rip apart, or whatever else you want to do with it...
well, the thing is, you can't just hide a program inside another program and have the whole thing not become bigger. if it takes time to load new programs in the middle of a run, it should take the same amount of time to load those programs when you log onto the host. if you've got to move fifty barrels of root beer across the state, it doesn't matter if you've got them in the back of your truck where everyone can see, or if you're hiding the barrels beneath a bunch of empty boxes--it will still take the same amount of time to move those barrels from one place to another.
When going over the Matrix related source material, I get the impression that the original intention of the writers was the "progs run on the host" version.
The fix is easy enough, simply figure out a way to determine the size of persona programs (the programming rules in Matrix can do that, I think), have the upload the entire Icon at start of the matrix run, and ditch the concept of active memory.
Game Balance wise, this doesnīt present to much of a problem. Active Memory usually accounts only for a raction of a decks cost. Persona programs would hencforth be just that, programs, albeit pretty fragging expensive programs.
A consequence would be that decks would be little more then laptop computers with a souped up communication interface. The cost of a Deck would be concentrated in itīs software, which makes it a bit more difficult for the GM to take away the deckers stuff, if so inclined, since itīs a trivial matter to keep backups.
OTOH, the delay between jacking in and logging on could make for some dramatic scenes as the rest of the team tries to holdof The Goons ™ while their nethead jacks in to close the security doors. Also, every now and then (read: when the GM feels like it), there are going to be delays when switching hosts.
There is a caveat, though: A hen-or-egg problem. If persona and utilities run on the host, how is the decker going to hack the host he initially logs on to?
The alternative is to go with the "programs run on the deck" option. This would leave most of rules the way they are. The "swap memory" system operation can either be dropped entirely, letting the decker swap utilities at will (making them somewhat like physad abilities, rulewise), or replaced with the "load program" operation, which would describe how long it takes to load a program from storage memory. Also, the bandwidth rules from Matrix would no longer be viable, IMO, since while both persona and utilities certainly do generate a lot of data-traffic to the host, the amount would vary drastically depending on the type of the utility and whether the utilility is actually doing something which most utilities do only some of the time (e.g. browse, attack). All this would make the used bandwidth a pain to compute, more effort then its worth.
Your thoughts?
The fix is easy enough, simply figure out a way to determine the size of persona programs (the programming rules in Matrix can do that, I think), have the upload the entire Icon at start of the matrix run, and ditch the concept of active memory.
Game Balance wise, this doesnīt present to much of a problem. Active Memory usually accounts only for a raction of a decks cost. Persona programs would hencforth be just that, programs, albeit pretty fragging expensive programs.
A consequence would be that decks would be little more then laptop computers with a souped up communication interface. The cost of a Deck would be concentrated in itīs software, which makes it a bit more difficult for the GM to take away the deckers stuff, if so inclined, since itīs a trivial matter to keep backups.
OTOH, the delay between jacking in and logging on could make for some dramatic scenes as the rest of the team tries to holdof The Goons ™ while their nethead jacks in to close the security doors. Also, every now and then (read: when the GM feels like it), there are going to be delays when switching hosts.
There is a caveat, though: A hen-or-egg problem. If persona and utilities run on the host, how is the decker going to hack the host he initially logs on to?
The alternative is to go with the "programs run on the deck" option. This would leave most of rules the way they are. The "swap memory" system operation can either be dropped entirely, letting the decker swap utilities at will (making them somewhat like physad abilities, rulewise), or replaced with the "load program" operation, which would describe how long it takes to load a program from storage memory. Also, the bandwidth rules from Matrix would no longer be viable, IMO, since while both persona and utilities certainly do generate a lot of data-traffic to the host, the amount would vary drastically depending on the type of the utility and whether the utilility is actually doing something which most utilities do only some of the time (e.g. browse, attack). All this would make the used bandwidth a pain to compute, more effort then its worth.
Your thoughts?
actually, now that i think about it, the second option is perfectly viable with no rules changes at all. er, well, one.
it's simple: the I/O speed dictates the rate of data transfer both outside and inside the deck. why this should be, god only knows; it's not like your LAN card somehow acts as a bus. you could add "bus" as a necessary component to cyberterminal construction, same cost as I/O. this would mean that programs transfer from storage to active memory at the I/O speed; the only change would be that they wouldn't be subject to bandwidth changes.
it's simple: the I/O speed dictates the rate of data transfer both outside and inside the deck. why this should be, god only knows; it's not like your LAN card somehow acts as a bus. you could add "bus" as a necessary component to cyberterminal construction, same cost as I/O. this would mean that programs transfer from storage to active memory at the I/O speed; the only change would be that they wouldn't be subject to bandwidth changes.
my point was that the decker preloadsbefore strarting the run, basicly you just skip the swpa memory operation as he does that looking at the login prompt of the ltg he is hooking himself upto. the gm can just vave hishandand say that it takes so and so time to fire up the connection and presto your problem is coverd, no hard and fast rules are needed...
like i said in that other post (or tryed to say), try not to let real world get in the way of the fun ok?
like i said in that other post (or tryed to say), try not to let real world get in the way of the fun ok?
right, except there are times when speed matters. say your decker is trying to hack a maglock slave, while his buddies hold off the advancing team of secguards, y'know? a little reality-bending to appease the rules--or vice-versa--is fine, it's expected. but you shouldn't have to do it as a matter of course.
Iīm starting to lean towards the "runs on deck" option, simply because it seems to disturb the canon rules less. I wonder if itīs really necessary to come up with a "bus speed". While it sound straightforward enough, if you consider the average utility size and the I/O speed of a shadowrunning-worthy deck, you discover that loading a utility takes about 1 second on average.
So, for simplicityīs sake, I suggest the following: Loading a utility is a simple action (as usual), and it becomes available on the next Initiative Pass. Thatīs it.
Having the utilities run on the host opens another can of worms: If the utilities run on the host, why would there by ANY limit on the collective size of the utilities you run?
If anything, you would have to hack the amount of active memory the host allocates to you... which would require us to come up with completly new rules, something Iīd rather avoid if possible.
So, for simplicityīs sake, I suggest the following: Loading a utility is a simple action (as usual), and it becomes available on the next Initiative Pass. Thatīs it.
Having the utilities run on the host opens another can of worms: If the utilities run on the host, why would there by ANY limit on the collective size of the utilities you run?
If anything, you would have to hack the amount of active memory the host allocates to you... which would require us to come up with completly new rules, something Iīd rather avoid if possible.
i suppose an argument could be made that you need to have the base program in active memory for error-checking purposes, but even that's kinda weak--you should still be able to unload a prog from active memory but have it remain on the host, albeit at the risk of having the program crash unexpectedly.
if the decker have to jack in to fix a maglock then why not just pry open the case and hotwire it? the rules are in the books...
first thing you do when you need a onsite decker is to break into some office or other and then have him jack in there under guard, you do not bring him along to have him jack in left, right and center while under fire. its a waste of time and puts the decker at risk...
first thing you do when you need a onsite decker is to break into some office or other and then have him jack in there under guard, you do not bring him along to have him jack in left, right and center while under fire. its a waste of time and puts the decker at risk...
that's a good plan, but there are any number of pithy adages about plans not working they way they're intended to. the number of reasons why a decker might find himself jacking in under fire to kill a maglock are legion.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.