Logs for ShadowRN and Associated Mailing Lists

From:	Tzeentch tzeentch666@*********.net
Subject:	Virtual Realities 3.0: UMS (and converting VR1 node maps to VR2 rules)
Date:	Mon, 24 Jul 2000 19:07:16 -0700

Message no. 1 *Another part of the Virtual Realities 3.0 net.book looking for feedback.

UNIVERSAL MATRIX SPECIFICATIONS
UMS is the universal data communications protocol developed in 2039 to
exploit the amazing advances in both computer technology and infrastructure
realized after the Crash of 2029. Over a three month period, the UMS quickly
erncompassed every major standard of the time. Every year the specifications
became more all-inclusive, until by 2049 it was almost impossible to even
conceive of the dark times of data incompatibility that existed before UMS.

STANDARD FOR A NEW DAY
In addition to codifying the network protocols that are still used on the
Matrix to this day, the UMS also described standard data protocols for
everything ranging from home appliances to mainframe interconnects. With a
broad and extensible structure, UMS kickstarted the amazing growth of
telecommunications to the modern day.

ICS
Part of UMS's success was its implementation of the Identifier Code Series.
The ICS is an block of data that tells other machines how the system it
comes from works, what data formats it uses, and in the case of users with
virtual reality-interfaces, how to model the objects data in 3d and apply
behaviours to it. This ICS is sent as part of the initial "hand shake" of
data between two communicating devices. If the devices do not know how to
talk to each other then each one can load an interface driver on the other
machine so they can communicate. All of this is made possible by the broad
structure of the UMS.

NERPS
The ICS itself is not part of the low-level protocols that govern data
transfer on the Matrix however, that is handled by what is generally called
just the "stack" - a small suite of programs that intrpret and route data on
the Matrix through the "persona" - a helper application that loads onto the
host. The protocols technical name is New Environmental Routing Protocol
System (NERPS), and it is the most fundamental part of modern
telecommunications.

VIRTUAL REALITY IS ITS OWN REWARD
ICS is essentially a high-level "interpretive" standard, it is designed to
run on any architecture as long as the system possesses the necessary
interpetive software. In essence it is the future version of late 20th
century interpetive languages as Java, Jini, and certain scripting languages
such as Perl. When two devices that do not know how to communicate with each
other make contact, each machine can send an ICS packet to the other that is
stored in the other machines buffer and is executed. The two machines have
then essentially loaded an device driver that allows then to communicate
between each other. This is all handled automatically, and is the basis of
all modern computing devices. You simply plug a device (even if its brand
new) into a network and the network will automatically update itself to
communicate and use the device.

One use of the ICS was found to be virtual reality. Instead of data for
communicating with a device the ICS blocks were instead used to transmit
behaviors, iconography, and interface specifications for virtual
environments. At first, computers had to download the entire set of virtual
reality blocks then the specific data for the host. This proved to be highly
impractical, and soon most computers came built-in with the standard ICS
series for using virtual environments.

This high-level interface was based on much earlier work with the original
networking virtual reality modelling language VRML (Virtual Reality
Modelling Language). The Fuchi-developed EMS (Environmental Modelling
Script) proved to be highly superior to the other protocols competing for
the standard and it as adopted soon after.

EMS
Every object in a virtual reality is coded as an EMS "entity". For example,
in a virtual reality consisting of a room, a chair, and a lamp there will be
entities for the room itself, the ambiant light source, the lamp object, and
the light object tied to the lamp. Each object will have its icon, behaviors
(such as modelling the movement of the chair if it is pushed), and physical
properties (its surface texture, color, radiosity, sheen, etc). The systems
graphics rendering engine could then "draw" the scene and have every object
interact in at least a semi-realistic manner.

As time went on EMS became more advanced and was extended to allow for even
greater object detail, more capable enity programming, and even methods of
embedding simsense into the environment. The standard icongraphy set for the
Matrix was introduced by Fuchi in early 2041 as a way to bring
standardization to the various virtual reality user interfaces that began to
appear around that time, greatly easing user familiarity and ease of use.

Reality Filters
Since EMS is an interpretive system, it was not long before "hacked"
interpreters appeared. Many of these were hobbyist projects, and typically
only modified certain aspects of the EMS data they received - such as
rendering the entities as icons instead of 3d objects. More advanced
software quickly appeared on the scene, including software toolkits that
allowed users to modify every aspect of the interpreter to their liking.

As simsense (first as simsampling, then later as ASIST interfaces began to
hit the market) begain to be incorporated into the EMS standards the editors
changed along with the new technology, forming the basis for modern custom
interfaces.

Since EMS is essentially no different from a 20th century block of HTML code
it is typically a trivial matter to ignore the visual representations, or
assign a new one based on the underlying ICS data. This is anologous to
looking at the source code for a 20th century web page - its easy to ignore
bogus links or spot things that may be hidden after the data is interpreted
and rendered.

UMS COMPLIANT ICONOGRAPHY
Most grids and hosts are UMS complient, that is, they generally do not stray
past the basic EMS standards for Matrix icons. A typcal host will look much
like any other anywhere in the world. This is starting to change, but even
many sculpted systems still have old-style EMS compliant system maps for
users with old systems.

User Actions
By 2055 it had become painfully obvious that the old UMS standard for system
operations was broken. So by 2057 most hosts had switched over to the much
more user-friendly ESR (Extended Symbolic Representation) system that most
are now familiar with. But a few systems still use the old standard.

UMS HOSTS
Hosts that still use the old user-interface standard are typically known as
"sandpit" hosts, so named for the excess effort that is required to get any
work done on them. By and large they are very unpopular architectures since
even users with pared down interfaces must work there way slowly from node
to node in order to accomplish their tasks.

Nodes
All systems of this type are built as "nodes" - discreet symbolic
representations of various system functions. These nodes are connected to
each other by datalines, which are simply reprsentations of data flow
between the systems.

System Operations
Because of the design of these systems it is not possible to perform every
system operation in a specific node. A user must be in the correct "part" of
the system in order to execute certain operations.

As a general rule, the standard Subsystem Tests do not apply in these kinds
of systems.

Connections
Because of the way systems of this type are laid out, some nodes cannot to
connect to other types of nodes. This was perhaps one of the biggest
limitations of the standard, and a primary reason it was abandoned.

Perception
Another odd part of the standard was the intentional "shortening" of
perceptions in the system. It was not possible to access systems as a whole
in the old standard. One could only "see" the nodes directly connected to
your own. Even systems running non-virtual interfaces are limited to
accessing one node at a time, like an old style dungeon-crawl game. Only a
successful Analyze Host operation from the CPU node will reveal the entire
"system map".

For this reason, on an unknown system the gamemaster should keep the actual
system map to himself. As the decker moves from node to node the gamemaster
reveals which nodes are connected - but that is all.

Movement
Switching to a connected node requires a Simple Action and a successful
Computer (Security Rating) Test. Failing this test has no effect unless the
host is running Probe IC (see Intrusion Countermeasures, below).

Range
For purposes of cybercombat programs can only target other personas or
software located in the same node.

IC
When the systems security tally rises enough to trigger IC, it will
automatically appear in the same node as the intruder. If there are multiple
intruders it will appear with the one chosen by the gamemaster. IC can move
from node to as a Free Action.

Security Deckers
Most security deckers will appear in the CPU node when they jack in. A
security decker can perform the Locate Decker operation from anywhere in the
host, and if successful will reveal the deckers location in the host.
Security deckers can change nodes as a Free Action.

NODES
The basic types of nodes are listed below. The description includes its
basic UMS iconography, system operations possible in the node, and what
nodes it can connect to.

Central Processing Unit (CPU)
Every system has only one CPU. It functions as the heart and brain of the
system.

Iconography: The CPU node appears as a huge octagonal room, built of circuit
boards, and pulsing with energy. Screens displaying the status of various
nodes throughout the system are placed throughout the construct.
System Operations: Any
Connections: The CPU can connect to any other node.

Dataline
Datalines are simply the representation of connections between nodes.
Essentially they "teleport" users between nodes. Datalines are not nodes and
it is not possible to be "in"a dataline for game purposes.

Iconography: Datalines appear as transluscent tunnels of energy, with
pulsing sparkles representing data travelling over the line.
System Operations: None
Connections: Datalines connect two nodes together.

Dataline Junction (DLJ)
A DLJ exists soley to route data to and from the various datalines that
connect to it.

Iconography: The DLJ appears as a a small yellow pyramid.
System Operations: None
Connections: A DLJ can connect to a SPU or CPU.

Datastore (DS)
Datastores hold information. They are the "library" section of the system.

Iconography: Datastores appear as a roughly rectangular area filled with
blocks of energy. With each block representing a datafile. Each block is
filled with swirling letters and numbers of various colors.
System Operations: Analyze Subsystem, Download Data, Edit File, Locate File,
Upload Data
Connections: Datastores can connect to other datastores, SPUs, or the CPU.

I/O Ports (I/OP)
An I/OP is a limited-access node that connects the host to various slave
devices. Most I/OP nodes represent connections for dozens, or even hundreds,
of individual devices. I/OPs can only control fairly simple devices (simple
terminals, soykaf makers, etc).

Iconography: The I/O port node is a pyramid-shaped white chamber. Typically,
the walls of the construct will have readouts and status displays for all of
the items that the node controls.
System Operations: Analyze Subsystem, Control Slave, Edit Slave, Locate
Slave, Monitor Slave
Connections: I/Ops can connect to SPU's, or rarely, to the CPU.

Sub-Processor Units (SPU)
An SPU is a "subdivision" of the host tasked with performing a limited array
of tasks. Some SPUs are simply "traffic cops" for multiple datalines while
others perform other functions on the host that may not be readily apparant.

Iconography: The SPU node appears as a large chamber filled with pulsing
banks of circuits and sizzling energy.
System Operations: Analyze Subsystem
Connections: SPUs can connect to any type of node.

System Access Node (SAN)
A SAN is the actual port that connects the host to the Matrix or another
host.

Iconography: SANs always apepar as doorways or access locks.
System Operation: Logon to Host (if connects to another system), Logon to
LTG (if it connects to an LTG or PLTG).
Connections: SANs can connect to an SPU, or rarely to an CPU

Slave Node (SN)
Slave nodes control complex physical processoes or devices, typically items
such as building elevator systems, factories, or security cameras.

Iconography: SNs appear as small, cubical rooms. The walls are covered with
various control terminals
System Operations: Analyze Subsystem, Control Slave, Edit Slave, Locate
Slave, Monitor Slave
Connections: SNs can connect to SPUs and the CPU

SETTING UP AN ARCHAIC UMS HOST

SYSTEM RATINGS
System Ratings are determined in the same way as for conventional hosts.

Converting from 2nd Edition/Virtual Realities 1.0
The systems security rating is equal to the original systems Security Code
and System Rating. If for some odd reason there are multiple CPUs in the
host then choose the higher rated CPU.

For example, a system with an Orange-7 CPU becomes an Orange-7 Security
Rating.

SUBSYSTEM RATINGS
These are determined as normal. Typically the systems rating for Access will
be equal to the original Access IC rating for the hosts SAN.

Converting from 2nd Edition/Virtual Realities 1.0
The gamemaster should consult the Host Rating Table (p. 205, SR3) and the
Assigned System Rating rules (p. xx) to determine the Subsystem Ratings of
the host.

INTRUSION COUNTERMEASURES
Intrusion Countermeasures work a bit differently on an old UMS host. With
the main differences being the requirement to track movement in the host.

PROBE
If Probe IC is running on the host, then an unsuccessful attempt to move to
another node triggers a Probe Test (conducted as normal). This is in
addition to Probes effects on system operations.

SCRAMBLE
Scramble on an archaic UMS host can be applied to a single node. The
gamemaster may also note that all nodes of a particular type are equipped
with Scramble.

SECURITY SHEAVES
Gamemasters may either use the printed guidelines for security sheaves given
on p. 211, SR3, or those listed under Security Sheaves, p. xx. Alternately
the gamemaster can ignore security sheaves and use the printed Matrix node
maps and IC.

USING VR1 MATRIX NODE MAPS
If the gamemaster wishes, he can use the original node maps as written. In
this case, use teh following notes as conversion guidelines.

Access
Typically the rating for the SANs Acess IC will be the rating of the hosts
Access Subsystem Rating. If doing a direct conversion, then use the SANs
Access IC rating for all Logon to Host attempts. If the program is crashed,
but not suppressed, it will increase the security tally to the level of
triggering a security alert at the beginning of the following Combat Turn.
If the Access IC is crashed and suppressed the intruder may perform an Logon
to Host operation with automatic success.

Barrier
For purposes of entering another node, add the Barrier ICs rating to the
hosts Security Rating for determining the target number to enter the node. A
failure on this test triggers an interrogation that is handled in the same
manner as for Probe IC (Barrier IC rolls its rating against the intruders
Detection Factor - each success scored by the IC increases the decker's
security tally by one). If a direct conversion, then ignore the previously
stated test to move from node to node. If the node being moved into does not
possess Barrier IC then the move is done without any test.

Probe
Unlike its modern counterpart, archaic Probe Ic is somewhat more
specialized. Once activated, it functions as Access IC - but all deception
programs have their target numbers increased by +2. If the program is
crashed, but not suppressed, it will increase the security tally to the
level of triggering a security alert at the beginning of the following
Combat Turn.

Trace
Ignore the variations.

Expert IC
Increase the rating of the IC by the level.

BUILDING VR1 MATRIX NODES
The rules given in VR3.0 for host creation do not cover such archaic systems
as those noted above. The gamemaster is the final arbiter of any such
attempt.

From:	Tzeentch tzeentch666@*********.net
Subject:	Virtual Realities 3.0: UMS (and converting VR1 node maps to VR2 rules)
Date:	Wed, 26 Jul 2000 12:36:11 -0700

Message no. 2 From: "Drew Curtis" <dcurtis@***.net>

First off, thanks for the feedback - I'll be incorporating it into the next
"build" of the manuscript.

> > UNIVERSAL MATRIX SPECIFICATIONS
> There isn't really a problem with this now, as far as the Internet is
> concerned. Sure you can't stick a Mac disk in a PC but you can easily
> xfer files over.

I was actually thinking of the various communications protocols. IE UMS is a
combination TCP/IP, UDP, SNA, X.25, NetBIOS, etc etc. It'll never happen but
it happens to match canon statements.

It's not necessarily hardware incompatibility, but the difference between
plugging into a token ring and Ethernet network.

> > STANDARD FOR A NEW DAY
> Unnecessary, it's already in place.

Not really. Or are you saying any old computer can understand Jini system
calls? Or Java without a JVM?

> > NERPS
> This makes sense. I've worked on VR in RL, all the multiuser VR
> simulations I've ever seen did all the perception-based computations at
> the client level. In general the server level manages traffic.

Of course in Shadowrun servers seem to be back into the bad old days of
clien-server architecture so it may well be logical in the SR universe to
have the servers do it all. Of course I don't buy it, and that would also
make explaining reality filters harder then it already is.

> > VIRTUAL REALITY IS ITS OWN REWARD
> Not really possible. Sure it could work but the problem you have is one
> of security.

<blink> This is Shadowrun man, have you checked out how the Matrix works?
It's one giant security hole to begin with! Applications running
uncontrolled on servers by any old fool who logs on, persona programs
loading onto the telcos network, etc.

<snip description of VLAN>

> You could definitely have a device add itself to an internal-only network
> because you control the routing internally. You can't have it add itself
> to the global Internet because you must have the permission of the
> company controlling your segment of the Internet, and they're not going to
> just give it to you without prior arrangement.

I'm not sure what you're arguing against here. I was a little loose with the
definition of "network" but I never said it broadcasted to the Matrix as a
whole.

> I suppose one way you might be able to do this is if there is unlimitted
> IP space you could give any given customer a block so large they'd never
> fill it, then you'd be fine. It wouldn't require any recognition by the
> upstream routers however because the entire block already routes.

In Shadowrun in order to communicate on the Matrix as a whole you need a
valid commcode (read ISP IP address) tied to a specific jackpoint
(location), which I guess you could define as an telco-recognized IP on your
own network. Hard to say how they route this traffic (its completely
ficticious!) but perhaps routers are so cheap its a $2 device built into
your homes network jacks that automatically route traffic from the Matrix to
the home network and back out (using the validated commcodes). The Matrix
should cover this a bit. fnord

> So what I'm saying is it's technically possible but not sure if it's
> workable. Again this may be because I know how it works currently and
> can't see beyond that, I'll admit.

Well I'll be the first to admit I'm throwing treknobabble at the problem in
order to at least be consistent where I violate all standards of logic or
technology ;)

> > One use of the ICS was found to be virtual reality. Instead of data for
> > communicating with a device the ICS blocks were instead used to transmit
> > behaviors, iconography, and interface specifications for virtual
> > environments. At first, computers had to download the entire set of
virtual
> > reality blocks then the specific data for the host. This proved to be
highly
> > impractical, and soon most computers came built-in with the standard ICS
> > series for using virtual environments.
> >
> Sure, but you'd still have to download other specs if they're not using
> the standards. I would think there would be too many possible
> conbinations. However if you assume that there's unlimitted bandwidth and
> unlimitted storage capacity, it wouldn't be any problem at all to download
> the specs right to the user. It would happen as fast or faster than a
> hard-drive access.

Obviously neither of those two exist, I'd even go so far as to say that by
2060 IRL we'll have systems that will make cyberdecks look like tinker toys
(minus simsense and probably 3d interfaces). I can't even begin to
contemplate the sheer power that clustered systems of 2060 will have.

> > This high-level interface was based on much earlier work with the
original
> > networking virtual reality modelling language VRML (Virtual Reality
> > Modelling Language). The Fuchi-developed EMS (Environmental Modelling
> > Script) proved to be highly superior to the other protocols competing
for
> > the standard and it as adopted soon after.
> >
> This is just my opinion but I doubt VRML will be the standard for any
> future VR. Bits of the theory might be borrowed but in general once you
> figure out what you want to do, you build a whole new language for
> it. VRML doesn't contain much in the way of innovation.

I never said it was an advanced VRML, they based EMS on it sure - but it
bears little resemblence other then an attempt to make VR programming
easier.

> > EMS
> They're not actually coded per se. Most VR simulations use CAD-based 3d
> objects and import them just like web-pages link in gif/jpg images. Once
> in the simulation they are manipulated. This may be completely different
> from how game designers do it, I don't have any experience there.

I'm approaching this from my experience with 3d apps like Maya. You build
the object in another app (if you want) then in layout you can assign
various properties and behaviors to the object so that its FAR easier to
animate (ie. assigning object A properties of a soft body with X and Y
subproperties).

I could be explaining it badly as well.

> In general, and this is just my own opinion, processes tend to drift
> toward entropy rather than toward standards.

Well, in the larger scheme I think data format standards are a given, either
mandated or de facto. We already know whatever standards the Matrix use are
at least de facto because EVERYONE uses them for almost everything. Even
your new Chimpokomon in SR has the capability to send and receive data over
the Matrix.

> What is more likely to
> happen is that a bunch of competing formats are released and one of them
> gets used more than the others. It happened with Beta/VHS, IBM/Mac/Amiga,
> and sound encoding (a la MP3s). No one declared MP3 to be the main
> standard to use, it was just declared as one standard of many and became
> more popular because more people used it. There were many reasons why
> this happened, but it wasn't because it was mandated by a standards
> organization.

Same with TCP/IP.

> An example of a market where this didn't happen is digital movie theater
> sound. There are still (and have been for years) three different digital
> sound formats (Sony's, THX, and I forget what the other one is). No
> standards organization has stepped in because it's not a vital issue to
> the general populace, and furthermore not everyone can tell the difference
> anyhow. I can't.

Well, in the case of the Matrix there are agreed on standards. We know this
because it says so (ie the brief discussion on UMS in VR1, etc)

> > Reality Filters
> Reality filters would run faster too, as less information would need to be
> transmitted. If bandwidth is unlimitted it won't make any difference
> however.

Well, if you set it up to just ignore the data then it probably would. If
you had the filter render everything in 2d or trideo that would cut out all
the overhead from simsense processing etc. Bandwidth is not unlimited in SR
though, so it could be an important point. Also note that in my technical
world view its the PERSONA program loaded onto the grid that converts the
data and sends it to the user for interpretation by the OS. You could set
the persona program (Sensor in this case) to filter out stuff right from the
beginning, you simply would never see it on your end (and cut down on
bandwidth). In SR this is represented by various deck modes and readjusting
your persona program ratings.

> > Since EMS is essentially no different from a 20th century block of HTML
code
> > it is typically a trivial matter to ignore the visual representations,
or
> > assign a new one based on the underlying ICS data. This is anologous to
> > looking at the source code for a 20th century web page - its easy to
ignore
> > bogus links or spot things that may be hidden after the data is
interpreted
> > and rendered.
> >
> Mostly correct. I won't nitpick.

Well its not exact ;)

> > Nodes
> This doesn't make sense necessarily. Here's a good example of why
> not: recall Jurassic Park where at the end the little girl is trying to
> shut down something using what she laughably calls 'unix'. It takes her
> forever to navigate through the VR-like operating system to get to the
> shutdown command, a good several minutes.

In Shadowrun that would take a few turns (maybe a minute or so max). Which
all things considering is insanely fast if there is anything in your way.

And nodes are SR canon, just look at SR2 or VR1.

> This was particularly funny because if you were actually running unix
> you'd just type the command and it would happen. Additionally, if you
> know where a file is on your hard drive, you just go there. If you know
> where a webpage is, you just go there. There's no need for links at
> all. The problem is this makes decking less like the dungeon-crawl type
> of fun the game designers were looking for. Sometimes reality should be
> thrown out the window for the sake of fun.

Exactly. Shadowruns Matrix is pretty laughable from a computer dork
perspective but it's the best computer system in a CP game (or other for
that matter) that manages to at least have some suspension of disbelief and
remain playable.

> > System Operations
> The way this works in RL is that the user must be the correct class of
> user. Doesn't matter where they are, if they don't have the correct
> permissions they can't do certain actions.

This is discussing VR1 style nodes BTW.

> > Connections
> > Because of the way systems of this type are laid out, some nodes cannot
to
> > connect to other types of nodes. This was perhaps one of the biggest
> > limitations of the standard, and a primary reason it was abandoned.
> >
> Can't see how this would happen. Again it's probably because I'm stuck in
> the world of how things work today, we're talking 60 years from
> now. Currently you can prevent users from going to certain places, but
> not connections.

Again, VR1. VR2 got rid of it (thank the gods).

> > Perception
> > Another odd part of the standard was the intentional "shortening" of
> > perceptions in the system. It was not possible to access systems as a
whole
> > in the old standard. One could only "see" the nodes directly connected
to
> > your own. Even systems running non-virtual interfaces are limited to
> > accessing one node at a time, like an old style dungeon-crawl game. Only
a
> > successful Analyze Host operation from the CPU node will reveal the
entire
> > "system map".
> >
> This wouldn't work, as in my Jurassic Park example above. We're talking
> about taking functionality that operates as fast as you can type and
> slowing it down to taking several minutes for no obvious practical
> gain. Again, that makes the game less fun so it's a toss up in my mind.

It does work in SR, practical or not (I'm going with NOT!) but its how the
MAtrix worked in SR before VR2. I'm just trying to explain it somewhat
logically <g>

> > Dataline
> > Datalines are simply the representation of connections between nodes.
> > Essentially they "teleport" users between nodes. Datalines are not
nodes
and
> > it is not possible to be "in"a dataline for game purposes.
> >
> I would add that you could also jump to any node down the line assuming
> you ditch the dungeon-crawl concept. In the interest of fun I'm not sure
> that I would.

Can't do that in VR1/SR2. Jumping nodes came around in VR2 and got rid of
node maps.

> > I/O Ports (I/OP)
> > An I/OP is a limited-access node that connects the host to various slave
> > devices. Most I/OP nodes represent connections for dozens, or even
hundreds,
> > of individual devices. I/OPs can only control fairly simple devices
(simple
> > terminals, soykaf makers, etc).
> >
> An I/O port could also be a datajack. It would be hard to restrict they
> types of objects cable to connect through them, networks generally don't
> care what's connected to them as long as whatever it is can communicate.

But bandwidth can be severely throttled or they could be confined to their
own piddly memory spaces and not allowed to play in the big sandbox (ie they
use something like java for all system interface tasks). That somewhat
explains the difficulty of logging on at the companies soda machine.

> Dunno if that helps, but there's what I think for what it's worth.

Actually that was great, hope to hear from you as I post additional
material. Note that nodes and the like is from Virtual Realities 1.0 and the
first two Shadowrun versions. Also note that in my little corner of
Shadowrun obviously bogus stuff doesn't exist (Sparky cough cough). I also
don't use the concept of IC damaging hardware since as explained it makes no
sense at all (why only damage the MPCP and not anything else? Why not have
persona programs loaded entirely into memory instead of using firmware?) But
I'm preaching to the heretics here ;)

Kenneth

From:	lbfb marvin@********.org
Subject:	Virtual Realities 3.0: UMS (and converting VR1 node maps to VR2 rules)
Date:	Wed, 26 Jul 2000 17:25:27 -0400

Message no. 3 On Wed, Jul 26, 2000 at 04:41:06PM -0400, Drew Curtis wrote:
> > In Shadowrun in order to communicate on the Matrix as a whole you need a
> > valid commcode (read ISP IP address) tied to a specific jackpoint
> > (location), which I guess you could define as an telco-recognized IP on your
> > own network. Hard to say how they route this traffic (its completely
> > ficticious!) but perhaps routers are so cheap its a $2 device built into
> > your homes network jacks that automatically route traffic from the Matrix to
> > the home network and back out (using the validated commcodes). The Matrix
> > should cover this a bit. fnord
> Yup, it does. I've seen it, I didn't like it. But as I said, just
> because it reflects real life more doesn't mean it's more fun in a game.

IIRC what's being talked about on this is basicly one of the things IPv6
does. In that something kinda like DHCP is built into the IP protocall, so
you plug your device into a network and the routers/whatnot give it an ip
and all that jazz. extrapolate this, and you could call the commcode as
some sorta ident mechinism by the telecos, and if something gets plugged
in and has a valid commcode the local net configs the device automaticly.

as for lots of IP addresses, there are a ton of extra ip addresses in the
IPv6 spec,from some faq: "an average of 2.2*10^20 addresses per square
centimeter"

personally i don't find it hard to believe that something akin to IPv6
will be implemented by 2060 (may take that long to just get ipv6
implemented, but that's another story)

> That makes sense. It would also mean a persona would borrow some of the
> node's processing cycles to do its thing, which is interesting.

There is something in VR2.0 about this i believe.....don't have the book
with me, and haven't looked through it in a while, but i beleive it was in
the section about how they determine who gets to fry your bod when you get
cought decking around.

--
byron thibodeaux jr.
marvin@********.org CS Junior, Georgia Tech

From:	Tzeentch tzeentch666@*********.net
Subject:	Virtual Realities 3.0: UMS (and converting VR1 node maps to VR2 rules)
Date:	Wed, 26 Jul 2000 15:53:01 -0700

Message no. 4 From: "lbfb" <marvin@********.org>
> IIRC what's being talked about on this is basicly one of the things IPv6
> does. In that something kinda like DHCP is built into the IP protocall, so
> you plug your device into a network and the routers/whatnot give it an ip
> and all that jazz. extrapolate this, and you could call the commcode as
> some sorta ident mechinism by the telecos, and if something gets plugged
> in and has a valid commcode the local net configs the device automaticly.

I haven't gotten to the IPv6 part of my Network Design book (egads!) All I
know of it is that my hard earned ability to calculate subnets by hand will
all be for not ;)

> as for lots of IP addresses, there are a ton of extra ip addresses in the
> IPv6 spec,from some faq: "an average of 2.2*10^20 addresses per square
> centimeter"

Well we're running out of addresses with normal IP :) VLANs and the like are
helping a lot though.

> personally i don't find it hard to believe that something akin to IPv6
> will be implemented by 2060 (may take that long to just get ipv6
> implemented, but that's another story)

lol. I think I'll integrate that into my alternate timeline. heh

> > That makes sense. It would also mean a persona would borrow some of the
> > node's processing cycles to do its thing, which is interesting.
>
> There is something in VR2.0 about this i believe.....don't have the book
> with me, and haven't looked through it in a while, but i beleive it was in
> the section about how they determine who gets to fry your bod when you get
> cought decking around.

your persona is loaded onto the grid when you log on. If you have an MSP
(Matrix Service Provided) you're authenticated there then logged onto the
telco grid (so you log onto the MSP grid then get shunted to the telcos).
Your personas Sensor sits in some dataspace and parses the data flowing
"around" it into machine code thats shunted to the users OS/MPCP. Thats then
rendered into something intelligable (icons, VR, whatever). If you log onto
another host your persona unloads from the grid, leaves a data redirect
("I'm going here now, please forward all packets..") and loads onto the new
host. Since your front-end is actually located on their server (in SR it
needs to be for tour Sensor program to function) you're technically
"trespassing" on their system. Since you can't be two places at once with
your persona (enter rant about frames here) it seems like a pretty logical
legal precedence.

At least thats my theory, YMMV.
Kenneth

From:	lbfb marvin@********.org
Subject:	Virtual Realities 3.0: UMS (and converting VR1 node maps to VR2 rules)
Date:	Wed, 26 Jul 2000 22:51:44 -0400

Message no. 5 On Wed, Jul 26, 2000 at 03:53:01PM -0700, Tzeentch wrote:
> I haven't gotten to the IPv6 part of my Network Design book (egads!) All I
> know of it is that my hard earned ability to calculate subnets by hand will
> all be for not ;)

yeah ;) and it'll become that much harder for folks to rember ip addresses
;)

> > as for lots of IP addresses, there are a ton of extra ip addresses in the
> > IPv6 spec,from some faq: "an average of 2.2*10^20 addresses per square
> > centimeter"
> Well we're running out of addresses with normal IP :) VLANs and the like are
> helping a lot though.

yeah...that's why the adress space is going from 2^32 to 2^256 ...though
i'm sure folks were saying stuff like i'm saying when the address space
was set at 2^32....still, short of wide scale nano or a start to space
colinaziation i don't see us filling up that address space.

<snip>
> At least thats my theory, YMMV.

that was the gist of the vr2 stuff. since your personna is running on
the host system, you are persacutable under the laws of whever you are
mucking about. So get burned on Ares's hosts and by and about your only
hope is that they get tied up getting permission to come waste your
meat....and pray they don't have runners/black ops ready to go.

--
byron thibodeaux jr.
marvin@********.org CS Junior, Georgia Tech

From:	Wordman wordman@*******.com
Subject:	Virtual Realities 3.0: UMS (and converting VR1 node maps to VR2rules)
Date:	Thu, 27 Jul 2000 12:20:30 -0400

Message no. 6 >> UNIVERSAL MATRIX SPECIFICATIONS
>> until by 2049 it was almost impossible to even
>> conceive of the dark times of data incompatibility that existed
>> before UMS.
>>
> There isn't really a problem with this now, as far as the Internet is
> concerned. Sure you can't stick a Mac disk in a PC but you can easily
> xfer files over.

But can you use them. Tried opening a Word 2000 file in a non-Word
application?

Also, it is true that you can't stick a Mac disk in a PC, but you can stick
a PC disk into a Mac. This is because Apple has taken the time to translate
the PC format, out of business necessity. For everyone but the market
leader, it would be better if everyone could automatically read everyone
else's disks.

One other thing about having UMS incorporate all of the major standards of
the day: some of the major standards suck. RTF, for example, is a major
standard, but it is so poorly defined that no two products will display (or
in a lot of cases, even successfully import) an RTF file.

> > STANDARD FOR A NEW DAY
> > the UMS also described standard data protocols for
> > everything ranging from home appliances to mainframe
> > interconnects.
> >
> Unnecessary, it's already in place.

No it isn't. Can your TV can talk to your stereo? Mine can, because they are
all Sony components, but I can't talk to my Kenwood cassette deck. It could
talk to a Kenwood receiver, but not a Sony receiver. Why? Data
incompatibility. Now, can my computer control my television or VCR? No. It
can be made to, but only by using one of a number of systems, most of which
cannot talk to each other.

> > NERPS
> > ... a small suite of programs that intrpret and route data on
> > the Matrix through the "persona" - a helper application that
> > loads onto the host.

This is sort of similar, in principle, to Microsoft's named pipes. Sort of a
meta protocol which basically just figures out what protocol to use to talk
to a given system/device.

> > VIRTUAL REALITY IS ITS OWN REWARD
> > When two devices that do not know how to communicate with each
> > other make contact, each machine can send an ICS packet to the
> > other that is stored in the other machines buffer and is executed.
> > The two machines have then essentially loaded an device driver
> > that allows then to communicate between each other. This is all
> > handled automatically, and is the basis of
> > all modern computing devices.

This would almost definitely _not_ be implemented this way, because it is
really, really insecure. It acts as a very good vector for a virus. Any
system where one machine can inject arbitrary code into another system and
have that system execute it is begging for trouble.

> > You simply plug a device (even if its brand
> > new) into a network and the network will automatically update itself to
> > communicate and use the device.

A less problematic, but not perfect, model for this sort of thing is
implemented by Apple's FireWire support. When you plug a FireWire device
into a Mac, if no device is available, information about the device is sent
to Apple over the net. Apple's computers know where to find drivers for the
specific device and ask if you want to download it (usually the
manufacturer's site). If you do, the driver is sucked down, installed, and
you're good to go. This all happens within about 10 seconds. (BTW, you can
do this whole thing, including plugging in the cable, without rebooting.)

Security-wise, this is a bit better, because it gives the user the ability
to deny the transfer. Unfortunately, it requires trust in Apple and the
manufacturer, and assumes an uncompromised communication channel.

> You could definitely have a device add itself to an internal-only network
> because you control the routing internally. You can't have it add itself
> to the global Internet because you must have the permission of the
> company controlling your segment of the Internet, and they're not going to
> just give it to you without prior arrangement.

This really isn't a problem, assuming a big enough address space, the
_manufacturer_ of the device could hard code the address into the device
itself. The manufacturer would take the address from a huge pool of
addresses that it owns. This is similar to the unique 12 digit hex numbers
every Ethernet card is given.

> They're not actually coded per se. Most VR simulations use CAD-based 3d
> objects and import them just like web-pages link in gif/jpg images. Once
> in the simulation they are manipulated. This may be completely different
> from how game designers do it

It is. Most objects that do anything interesting have custom code.

> What is more likely to
> happen is that a bunch of competing formats are released and one of them
> gets used more than the others. It happened with Beta/VHS, IBM/Mac/Amiga,
> and sound encoding (a la MP3s). No one declared MP3 to be the main
> standard to use, it was just declared as one standard of many and became
> more popular because more people used it. There were many reasons why
> this happened, but it wasn't because it was mandated by a standards
> organization.

MP3 is also one of the few instances when a standard was chosen that was
picked largely due to its quality. VHS, for example, is hideously bad
compared to Beta (or pretty much any other system, as far as audio quality
is concerned). It got picked because it was good for the _producer_ (making
VHS is much cheaper), not the consumer.

Also, some good standards are abandoned just because they are controlled by
idiots. The GIF format, for example, is probably on its way to (slow)
extinction due to the moronic patent enforcement of its creator.

> Microsoft behaves similarly. The
> reason this is done is because if your format becomes the global standard,
> anyone using it needs to pay you a royalty and/or buy your stuff to use
> it. Thus, it is to any corporation's advantage to attempt to create their
> own standard independent of any global standard.

Fortunately, this is mode of thought is starting to die, at least in
computers. Companies are beginning to realize that closed standards are
ultimately less profitable than open standards, at least for some things.
Think, for example, how much money would have been _lost_ if everyone who
used HTML had to pay royalties. The Web would be much smaller, at the very
least. Sure, the company controlling HTML might have made some money on the
royalties, but they probably could have made a bunch more on selling, say,
web servers under an open HTML standard. Open standards tend to mean a given
company gets a smaller percentage of the market, but the market itself
becomes _huge_, and the resulting small percentage yields more profit than
total control of the smaller market would have. Computer corporations, even
Microsoft, are starting to realize this (witness Microsoft's embrace of XML
over the last year or so).

> No one has ever mandated
> an operating system standard for example,

This is true...

> and no one ever will.

...but this may not be.

The Crash of '29 might make a unified operating system (or, at least, a
kernel) economically practical. The Crash acts as a huge "reset button" for
the computer industry, because a bunch systems had to be rebuilt from
scratch to fit the new Matrix. Done correctly, this could have created an
open standard for operating systems from the very beginning.

Imagine, for example, that a the IPv6 standard gets finalized and everyone
loves it. Then somehow, it is transmitted back in time to the people who
invented TCP/IP in the first place. Armed with this standard, they might
decide to start with this standard from the beginning. This might (again,
_might_) have eliminated the need for competing communication protocols, and
_everything_ would now be using TCP/IP.

This is not very likely, but the Crash can make it conceivable.

> Reality filters would run faster too, as less information would need to be
> transmitted. If bandwidth is unlimited it won't make any difference
> however.

Just a note: nothing in computers will _ever_ be "unlimited". Computers will
always expand to push capacity. Remember about four years ago when a 1Gb
drive seemed like all you'd ever need for the rest of your life?

> > Nodes
> > All systems of this type are built as "nodes" - discreet symbolic
> > representations of various system functions. These nodes are
> connected to
> > each other by datalines, which are simply reprsentations of data flow
> > between the systems.
> >
> This doesn't make sense necessarily.

It is also the second worst thing about FASA's vision of the Matrix (the
first being the notion that the Matrix exists solely as a playground for
deckers). The whole concept of "nodes" and so on is just foolish. No
rational human would ever build a system like this.

How to print a document in modern times:
1) Setup connection to printer. (Usually done only once.)
2) Open document.
3) Select print.
4) Pick the printer you want to use and start the job.
5) Walk to printer get printout.
Elapsed time: maybe 10 seconds.

How to print a document in the Matrix:

1) Open document into Active Memory on your deck.
2) Move from your deck to the I/O to which it connects.
3) Move from the I/O node to some other node, probably an SPU.
4) Figure out which of the data lines in the SPU leads to the printer (or
some other node which then leads to the printer).
5) Move to printer node.
6) Issue a command that tells it to print your document.
Elapsed time: several minutes.

All of this idiocy stems from the primary flaw with FASA's Matrix rules: The
starting point for the design of the Matrix was to simulate how deckers
would break into computers. Instead, the starting point really needs to be
how a virtual reality system would _look_ and be used by real people.

Thinking along these lines does not need to be very deep. Just think about
what you would like to see in a VR interface, even a little, and you will
pretty quickly realize that it is nothing like FASA's version of the Matrix.

This might sound like minor quibbling, but in reality, this one fact makes
the running the Matrix nearly impossible. As a GM, you have no rational
basis for describing _anything_ about the Matrix, because you are trapped in
a ridiculous scheme that no one would ever use.

A long time ago, I wrote alternate Matrix rules, pretty much half-baked.
They are probably still in the rec.games.frp.cyber somewhere.

In my opinion, a Matrix host should be described the same way a D&D dungeon,
or a corporate facility is. It should have a standard floor plan map, with a
description of what each area is for. Finding a file in a data store might
be very similar to rifling through someone's desk in the real world (with
the exception that a decker would be able to just ask the desk to lead her
to the right place).

In role-playing games, all spaces are virtual realities. The fact that some
of them happen to exist inside computers should change how we, as gamers,
describe them.

> > Connections
> > Because of the way systems of this type are laid out, some
> > nodes cannot to
> > connect to other types of nodes. This was perhaps one of the biggest
> > limitations of the standard, and a primary reason it was abandoned.

Again, if you replace this with the "use a floor plan" system, you can see a
better way. A virtual space may be constructed such that you can only reach
certain rooms from other rooms. This does not, necessarily, mean that the
functionality of a system is denied to you because you don't happen to be in
the same room.

For example, say you had a site that was set up to look like a house. You
might be able to reach the bedroom only by taking the stairs, but you could
probably tell the _house itself_ that you wanted a certain document printed,
regardless of where you were in the house. You can imaging system where you
would not even have to do that, but instead your print metaphor silently
interfaces with the house and lists available printers for you
automatically.

One last thing: very few people (percentage wise) really _need_ a virtual re
ality interface to do computing. The people that do are largely determined
by occupation. Very few people ever deal with enough complexity in computing
to require VR to make it easier to work with. Being a computer programmer,
for example, I might have a really good use for VR. An accountant _might_
need VR, although she might _choose_ to use it even if she doesn't really
_need_ it. Someone writing a letter (by far the most common action on a
computer) really has next to no use for VR. In many cases, the extra
complexity of VR might actually be a hindrance. If you can find my article
(mentioned above), it lists the only people I can think of who really need
datajacks (I can't remember them all at the moment).

Wordman

From:	Gurth gurth@******.nl
Subject:	Virtual Realities 3.0: UMS (and converting VR1 node maps to VR2rules)
Date:	Thu, 27 Jul 2000 19:42:33 +0200

Message no. 7 According to Wordman, at 12:20 on 27 Jul 00, the word on the street was...

> MP3 is also one of the few instances when a standard was chosen that was
> picked largely due to its quality. VHS, for example, is hideously bad
> compared to Beta (or pretty much any other system, as far as audio quality
> is concerned). It got picked because it was good for the _producer_ (making
> VHS is much cheaper), not the consumer.

Another major reason VHS got picked because JVC (who designed VHS) didn't
mind porn movies being distributed on VHS, while whoever made Beta (can't
remember) and V2000 (from Philips) did object to that.

> Just a note: nothing in computers will _ever_ be "unlimited". Computers
will
> always expand to push capacity. Remember about four years ago when a 1Gb
> drive seemed like all you'd ever need for the rest of your life?

The rule with computers is very simple: more capacity only means something
will fill it.

> It is also the second worst thing about FASA's vision of the Matrix (the
> first being the notion that the Matrix exists solely as a playground for
> deckers).

That is soon to change, though.

--
Gurth@******.nl - http://www.xs4all.nl/~gurth/index.html
Sloan Poa!
-> NAGEE Editor * ShadowRN GridSec * Unofficial Shadowrun Guru <-
-> The Plastic Warriors Page: http://plastic.dumpshock.com <-

GC3.1: GAT/! d-(dpu) s:- !a>? C+@ UL P L+ E? W(++) N o? K- w+ O V? PS+
PE Y PGP- t(+) 5++ X+ R+++>$ tv+(++) b++@ DI? D+ G(++) e h! !r(---) y?
Incubated into the First Church of the Sqooshy Ball, 21-05-1998

From:	Wordman wordman@*******.com
Subject:	Virtual Realities 3.0: UMS (and converting VR1 node maps toVR2rules)
Date:	Thu, 3 Aug 2000 11:48:51 -0400

Message no. 8 > on 7/27/00 11:20 AM, Wordman at wordman@*******.com e-scribed:
>
>> This would almost definitely _not_ be implemented this way,
>> because it is
>> really, really insecure. It acts as a very good vector for a virus. Any
>> system where one machine can inject arbitrary code into another
>> system and
>> have that system execute it is begging for trouble.
>
> Like ActiveX?

Perfect example, except in the hardware situation discussed above, the user
generally has an option to turn off the ActiveX system. This sort of
"opt-out" was not a part of the original post.

Mailing List Logs for

Further Reading

Disclaimer