![]() |
![]() |
![]()
Post
#1
|
|
Target ![]() Group: Members Posts: 11 Joined: 26-February 02 From: Columbia, SC Member No.: 1,146 ![]() |
Here's something I was toying with in my head. See if it makes sense to you folks.
***** SR 4 has abstracted the idea of a node to be independent of the physical architecture of the devices involved. A node could be one commlink, one area, or some virtual construct on the matrix. But the attributes for the node are still written as if it represents one single commlink or equivalent. You can increase the Response to make the node faster or boost the System to take advantage of higher Response and support more programs and subscribers, but you can't scale the changes to reflect a busy node that actually was used for real work by multiple users. For example, you can't, under the existing rules, ever have more than 12 active subscribers. That's great for your personal devices, a mom and pop business, or a designed security bottleneck, but it wouldn't even work for the accounting department at a mid-size corp office. You're stuck adding nodes instead of expanding the capacity of the virtualized one you have, and you end up back with a SR3 dungeon crawl between nodes to find anything. So, we increase the node's "Width". Shorthand for the old-style bandwidth, nodes with increased Width are commonly called wide or fat nodes. The rating could represent anything from an upgrade to a single device, additional devices slaved together, or even fractional capacity leased from somewhere else on the Matrix. Each increase in width acts as a multiplier to the maximum number of subscribers allowed and likewise increases the number of programs that can run without reducing Response. Nodes can have (System x Width) x 2 subscribers, and Response decreases for every (System x Width) programs running. By default all existing systems have Width 1. Each additional rating point costs the same as a Response increase at the existing Response rating of the node. Increasing Width of a node with Response 3 would then cost 1250:nuyen: per point, Response 4 costs 2000:nuyen: and so on. Buying Width at a different Response value causes the node to operate at the lowest of the available Response ratings. Increases to Width can be bought separately and incrementally, it isn't necessary to buy an entire new system with the desired rating. Multiple devices running the same System can be combined into one virtual node with a Width equal to the sum of the ratings of the devices used and a Response equal to the lowest rating involved. Adding devices to the virtual node requires Administrator access to both the node and the new device, and a System Reset of the new device. The loss of a device from an existing node merely decreases Width, the operating system automatically compensates for the loss of capability although the number of programs still running may now cause a decrease in Response. A small company wanting to be able to run 8 programs at rating 3 on their node would find it cheaper to buy Response, Width, and System at 3 each than to buy Response 5, Width 1, System 4 under the RAW. (Which would then run at Response 3 due to the number of programs running.) 1250:nuyen: x 3 for Response and Width + 600:nuyen: for System = 4350:nuyen: vs 4000:nuyen: for Response and 2000:nuyen: for System = 6000:nuyen:. Upgrading the RAW 5/4 system further to support more users and programs would require increasing System to 5 for 2500:nuyen: or even bumping Response to 6 for 8000:nuyen:. The wide node only has to add more width at 1250:nuyen: a point. Increased Width does not take up additional physical space (within reason). A commlink should easily be able to handle Width 3. Perhaps some capacity rating for the physical devices should be used to keep this reasonable (no Width 6 implanted commlinks running enough Agents for a baseball team). Yes, this means that experienced runners will have their gear running fast and fat, but it also means that there can be program space for extra IC on almost anything they face. |
|
|
![]() ![]() |
![]() |
Lo-Fi Version | Time is now: 27th May 2025 - 09:55 PM |
Topps, Inc has sole ownership of the names, logo, artwork, marks, photographs, sounds, audio, video and/or any proprietary material used in connection with the game Shadowrun. Topps, Inc has granted permission to the Dumpshock Forums to use such names, logos, artwork, marks and/or any proprietary materials for promotional and informational purposes on its website but does not endorse, and is not affiliated with the Dumpshock Forums in any official capacity whatsoever.