So, bevor das hier alles losgeht, möchte ich einmal das Entstehen dieses Textes ansprechen (warum erklähr ich später).
Nachdem ich mir die Shadwrun-Matrix durchgelesen und noch mal ausgiebig über William Gibbsons Büchern meditiert hatte, überlegte ich mir, wie ein solches System wohl zu realisieren sein könnte. Da ich Hobbyprogramierer bin entwickelte ich verschiedene Theorien, die zu so einem (oder so einem ähnlichen) System führen könnten.
Zuerst verfiel ich auf die Idee des areidimensionalen abbildens von Speichercode, doch die Idee verwarf  ich  schnell, denn sie hätte keine wirkliche Benutzervereinfachung mit sich gebracht.
Also kam mir die Idee des überintelligenten Interpreters, der Programme und andere relevante Objekte in von Menschen verständliche Icons darstellt. Das würde wirklich eine Erleichterung sein und wäre super Benutzerfreundlich.
In enthusiastischer Hast begann ich nun die Idee zu konkretisieren, ich klassifizierte die benötigten Icons, so dass sie praktikabel waren, ich überlegte wie man die Netzwerkprobleme lösen könnte und welche Art von Multitasking von nöten wäre damit einem die ganze Kiste nicht ständig um die Ohren fliegt.
Doch nach einigen Tagen Brainüberhitzung stellte ich fest, dass die Routinen des Interpreters ein (jedenfalls für mich) unlösbares Problem darstellten. Ich konnte einfach keinen Code schreiben (oder auch nur einen Ansatz finden) der Daten so effektiv und zuverlässig analysieren konnte. Tja, aus der Traum.
Also machte ich mich daran das Ganze für das Schadowrun-Universum aufzuschreiben (damit ich mir die ganzen Gedanken wenigstens nicht umsonst gemacht habe) und da isser.
Das ändert aber nichts an meiner Grundüberzeugung dass das ganze System irgendwie realisiert werden könnte. Wenn also jemand hierdurch Ideen bekommt oder sich irgendwie schon länger mit dem Thema rumschlägt soll er sich bei mir melden (Ich werd ihm wohl kaum eine grosse Hilfe sein, aber es würde mich interessieren):
[email protected]


>>>>>[Hoi NetFolks, ich hab mir mal die Freiheit genommen eine kleine Erklärung zu der heutzutage leider etwas zusehr abstrahierten Matrix-Technologie in Netz zu hängen. Die meisten Newbies die sich in unserem Shadowlandknoten rumdrücken können zwar ganz gut damit umgehen, wissen aber meistens nicht was sie da wirklich tun! Deshalb fangen wir mal n' bisschen geschichtlich
an...]<<<<<
        -SysOp Zero Total <23:13:54/02-08-58>
>>>>>[P.S: Weitere Daten über konventionelle Programmierung und Hintergründe, sowie über unsere neuste "Operation Mindfuck"-Variante findet ihr in dem dem Shadowladknoten der Schockwellenreiter]<<<<<
        -SysOp Zero Total <23:14:07/02-08-58>
 


EINE KLEINE GESCHICHTE DES (VIRTUELLEN) UNIVERSUMS

Alles fing mitte des 20. Jahrhundert an. Einzelne Computer wurden, um einen Informationsaustausch zu erhalten, über Telefonleitung verbunden. Da die Menge der Daten aufgrund der geringen Verarbeitungskapatzität der Prozessoren und des geringen Datendurchsatztes der Leitungen zunächst gering gehalten werden musste, waren die damaligen Betriebs- und Eingabegeräte durchaus geeignet die Datenmengen zu sichten, zu sammeln und zu verschicken.
Als Anfang der 1990er die Datenmengen wuchsen und auch immer mehr ungeschulte User am Computer arbeiten wollten, musste man die Eingabemittel vereinfachen und die eigentlichen Funktionen abstrahieren. Die daraus resultierenden
Betriebssysteme wie MacOS, Windows oder den graphischen Unix-Varianten namen die Informationen nicht mehr direkt an (über eine Texteingabe - getippt! Das muss man sich mal reinziehen), sondern über Symbole und auch die Programme waren nicht mehr reiner Prozessorcode, sondern trat nun in abstrahierte Kommunikation mit dem Betriebsystem.
Mit der zunehmenden Vernetzung der Welt wurden aber die Daten, die über das Netz geschickt wurden immer grösser, die Programme immer undurchsichtiger und ein neue Art von Computerfrust ging um - der Informationsüberlauf.
Die Daten waren zu vielschichtig und zu speziell und vor allem - es gab zu viel davon als das ein einfacher Mensch sie noch registrieren, geschweigeden benutzen konnte. Komplizierte Logik-, Such- und Sortierprogramme wurden  geschaffen, aber das grundsätzliche Problem blieb.
Die letzte Variante von Windows (Windows 2025) überlastete trotz der vielen Vereinfachungen die User dermassen mit Informationen, das die Effektivität der der Benutzer relativ zu den älteren Versionen sogar noch sank! Andere Konzepte wie Apples Macintosch hatten das gleiche Problem, konnten aber dank besserer Hardware ein stabileres und unkomplizierteres Konzept anbieten.
Das ging soweit, das Apple (die 2005 fast Konkurs angemeldet hätten) 2028  bei den PC's einen Marktanteil von 30% hielten.
Im Jahre 2023 wurde jedoch in Linux-Kreisen (Linux war in ein damals vor allem in Hackerkreisen verbreitetes Betriebsystem) die in den Cyberpunk-Büchern von William Gibson angekündigte Virtuelle Realität zum ersten mahl sinnvoll realisiert.
>>>>>[Wer ist dieser Gibson? Irgend ein Informatik-Prof?]<<<<<
        -Pandur <20:56:34/06-08-58>
>>>>>[Nein, Gibson ist ein Autor. Hat damals ziemlich revolutionäres Zeug geschrieben. Ist übrigens ganz empfehlenswert, in seinen damaligen 'Sience-Fiction'-Büchern trifft er die heutige Realität ziemlich genau.]<<<<<
        -Brother Data <00:03:07/08-08-58>
Das Problem war - die Virtuelle Realität (VR) war total unkompatibel und damit für die Softwaregiganten Microsoft und Apple unbrauchbar. Man hätte sämtliche Programme quasi wegwerfen und neue schreiben müssen, ja das gesamte World Wide Web hätte total neu aufgebaut werden müssen (Mit neuen Protokollen, neuen Inhalten und teilweise sogar neuer Hardware).
Doch dann kam der Crash von '29. Am 8. Februar 2029 wurde die Welt von einem Computervirus ungeheuren Ausmasses heimgesucht. Das gesamte Internet brach zusammen und kurz darauf auch das Milnet. Sämtliche konventionellen Versuche
das Virus zu finden und zu isolieren waren erfolglos, aber die Linux-Hacker, die ihre inkompatible Software damals noch mit Cyberhelm und Datenhandschuh steuerten, schufen in Denver mysteriöser weise ein Virusfreien Datenraum, den  sie Nexus nannten. Im Nexus, der vollständig auf einem 'Linux VR' genannten Protokoll basierte waren sie der Virus entgegengetreten und hatten es besiegt.
>>>>>[Protokoll? was is'n das?]<<<<<
        -Total Hi <07:45:21/06-08-58>
>>>>>[Ein Protokoll ist ein vorher zwischen beiden Computern vereinbarte (oder vorgegebenes) statische Sprache. Der Begriff wurde in den '30ern von 'DynTrans' abgelöst (Dynamic Transmission - Dynamische Übertragung), das eine intelligentere, dynamische Weiterentwicklung des veralteten Protokolls ist.]<<<<<
        -Doc Hint <18:23:43/06-08-58>
>>>>>[Häh?]<<<<<
        -Total Hi <23:06:01/07-08-58>
>>>>>[Der Doc meint, das ein Protokoll eine Art 'Sprache' zwischen zwei Computern ist, mit der sie sich unterhalten. Früher lief so etwas immer ziemlich gleich ab, es gab vorgeschriebene Muster, an die sich beide Seiten halten mußten. Heute ist das alles ein wenig komplizierter geworden und heisst eben 'DynTrans'. Dasselbe in Grün also.]<<<<<
        -FastJack <??:??:??/??-??-??>
Der Präsident der USA (United American States - umfasste damals UCAS, CAS, NAN, CAL,Tir und einen Teil der Cariebean League) befahl den Einsatz eines Geheimdienst-Teams, das den Virus in der Virtuellen Realität bekämpfen sollte. Erfolglos.
Die Beamten waren nicht in der Lage den Physischen Druck eines Kampfes in der Virtuellen Realität zu überstehen. So beschloss der Präsident eine Gruppe der besten und unberechenbarsten Hacker der Welt zu rekrutieren, ein Kader von
32 Männern und Frauen bestand das Training geistig unversehrt. Das Team wurde mit dem gerade erfundenen DNI (Direktes Neurales Interface) ausgestattet und starteten im August den ersten koordinierten Angriff.
Nach 18 Minuten waren vier Hacker tot. Der Grund war, das das Virus gelernt hatte auf das DNI der Hacker zuzugreifen und ihm sein Gehirn im wahrsten Sinne des Wortes zu 'grillen'.
Das Virus hatte aber nicht nur das gelernt. Es hatte einige wesendliche Konzepte von 'Linux VR' auf allen befallenen Computern installiert und so eine Art weltweite VR geschaffen. Auf Basis dieser VR mussten die Systembetreiber feststellen, das die Hacker sich (genau wie das Virus) von den konventionellen Sicherheitsprogrammen nicht aufhalten liessen.
Als 2031 die letzte bekannte Viruskonzentration von den sieben überlebenden Hackern gelöscht wurde, waren die grossen, weltweiten Telekomunikationsnetze zerstört.
Die Konzerne versuchten die Technologie zwar weiter geheim zu halten, aber 2034 brachte Matrix Systems den ersten Cyberterminal für den 'Grauen Markt' heraus, und als Fuchi schliesslich nachzog erhob sich wie Phönix aus der Asche
ein neues Netz, das auf Virtueller Realität aufbaute, das hauptsächlich aus neuen, schnellen Glasfaserverbindungen bestand und das zu den alten Standards nicht mehr kompatibel sein musste. Man nannte dieses neue Netz MATRIX.
Einen Knotenpunkt in diesem neuen Netz nahm der Denver Nexus ein, der als erster virusdesinfizierter Punkt eine strategisch wichtigen Punkt beim Neuaufbau der Netze innehatte. Er ist bis heute in der Hand von Deckern.
Die VR löste viele Probleme. Die User konnten nun durch starke Vereinfachungen auf eine erheblich grössere Menge an Daten zugreifen und dieser Prozess wurde wesentlich schneller. Die Techniken die hinter der Matrix stehen haben sich in den letzten 30 Jahren stark verändert, aber die wichtigsten Funktionen von 'Linux VR' wurden beibehalten.
>>>>>[Heisst das, dass Linux VR heute immer noch in der Matrix funktioniert?]<<<<<
        -Pandur <21:05:15/06-08-58>
>>>>>[Bingo!]<<<<<
        -FastJack <??:??:??/??-??-??>
 

>>>>>[So und jetzt weiter mit den Grundlagen der Matrix. Das meiste ist zwar auf die erste Linux VR Version bezogen, zeigt aber die grundlegenden Konzepte, die auch noch heute gelten - nur unendlich komplexer.]<<<<<
        -SysOp Zero Total <23:16:35/02-08-58>

GRUNDLAGEN

-----Warum überhaupt?
Das Problem bei dem Benutzen von hochkomplexen Programmen ist die Interaktion mit der Maschine. Früher wurden solche Probleme durch ellenlange Befehlsketten oder eine Unzahl von Icons gelöst. Heute aber können wir die Befehle direkt vom Hirn in den Comp schicken und ersparen uns damit viel Zeit und Mühen.
Diesen Ansatz könnte man (bedingt) aber auch ohne eine VR verwirklichen, warum also eine zusätzliche dreidimensionale Umgebung?
Ganz einfach: Unser Gehirn kann zwar zweidimensionale Zusammenhänge begreifen, aber so richtig gut reagieren tut es nur in einem 'normalen' dreidimensionalen Raum, und es ist auch ziemlich anstrengend immerzu 'Öffne Datei soundso' und 'Starte Programm soundso' zu denken. Es dagegen mit den eigenen Händen zu machen (so erscheint es wenigstens in der VR) erscheint dagegen fast einfach.

-----Wie denn?
Das Geheimnis zur Matrixnutzung heisst 'Interpreter'. Ein Interpreter interpretiert die Gedanken und Handlungen des Users und versucht aus dem Input eine sinnvolle Aktion auf dem Computer zu machen. Auf der anderen Seite analysiert der Interpreter aber auch die bestehende Hard- und Software und bildet passende 'Icons' in einem dreidimensionalen Raum ab. Das Aussehen der Icons wählt der Interpreter so aus, das der User möglichst schnell den Sinn des dargestellten Programmes mit dem Icon assoziieren kann. Ein gefährliches Programm wird also als eine Waffe angezeigt, ein schützendes wie ein Schild, ein Werkzeug-Utility wie ein Werkzeug (z.B. ein Schraubenschlüssel), u.s.w. .
Beeinflussen kann man diese Icons ebenfalls indem man sie der sogenannten 'Metamophorik' entsprechend benutzt (das 'benutzen' ist als Kombination aus virtueller Bewegung und gedanklichen Befehlen gedacht).
Die dreidimensionalen Positionen der Icons in der Matrix hat nichts mit ihrem physischen Standort oder ihrer Position im Speicher zu tun, die Position ist nicht physisch, sondern logisch. Das heisst, wenn ein Dateiwürfel in einem Verzeichniswürfel ist, dann bedeutet das nicht, das sich die Datei in einem physikalischen Bereich befindet, der als das Verzeichnis bezeichnet wird, die tatsächliche Position der Datei auf dem Datenträger ist uninteressant.
>>>>>[Ausser für die Leute die ihren eigenen Prozessorcode auf dem Host laufen lassen (Hähähä)...]<<<<<
        -Brother Data(03:12:34/08-08-58)
Das sich die Datei 'in' dem Verzeichnis befindet bedeutet dass sie diesem Verzeichnis logisch zugeordnet ist.

Es gibt vier grundsätzliche Klassen von Icons:
1. Aktive Programme ('Aktive Icons')
Jeder User, der sich in die Matrix einloggt erzeugt ein aktives Icon. Er hat also Programmcode im Speicher, der aufgeführt wird. Heutzutage sind alle Systeme mit echtem, hardwareorientiertem Multitasking ausgestattet, das ihnen erlaubt viele Programme gleichzeitig laufen zu lassen. In ein einem solchen Icon kann (normalerweise) kein anderes Icon sein. Es repräsentiert keinen Speicher, sondern nur aktiven Programmcode (der natürlich Speicher belegt).
2. Passive Daten ('Passive Icons')
Jedes Datenpakt, das nicht als Programm aktiv ist, ist ein passives Icon. Es verbraucht zwar Speicher in dem entsprechenden Host Icon, aber keine Rechenzeit. Passive Icons können sich nicht selbst bewegen, sondern werden von aktiven Icons aus der Ferne bewegt (dargestellt durch einen hellen Lichtstrahl, auf dem das passive Icon in das Host Icon zu seiner neuen Position
bewegt wird (oft ziemlich schnell)). Die Bewegung entspricht nicht der tatsächlichen Geschwindigkeit (die ist nahezu 'sofort') sondern ist für die Orientierung des Users notwendig, der sonst gar nicht mehr in der Lage wäre die ablaufenden Operationen zu überblicken.
>>>>>[Ich hab so ein Datenpaket mal mit der 'Hand' abgefangen, man muss verteufelt schnell sein, aber man kann die DInger fangen. Aber laut der Beschreibung müsste dass nicht gehen. Wieso tut es das dann?]<<<<<
        - Caleidoscope(05:12:11/7-8-58)
>>>>>[Das liegt am Verbindungsaufbau zu entfernten Hosts. Der Interpreter zeigt den Datentransfer bereits an wärend der Host noch eine Verbindung sucht. Wenn man dann schnell ist kann man den das Datenpaket abfangen indem man sich selbst als Addresse angibt. Man muss schon schnell schalten damits klappt und man wird auch selten auf so einen Effekt stossen, da die Anzahl der Relais-Hosts meist so niedrig ist dass die Verbindung da ist bevor du drei denken kannst. Caleidoscope hatte viel Glück und ein selten langsames Datenpaket.]<<<<<
        - Fastjack(??:??:??/??-??-??)
>>>>>["Relais-Host"?]<<<<<
        - Total Hi <07:49:01/06-08-58>
>>>>>[Guck weiter nach unten.]<<<<<
        - SysOp Zero Total <14:19:57/06-08-58>
Will man solche Daten lesen, muss man ein 'Lesen-Utility' benutzen, dann erscheint an der Oberfläche des Dateiblocks (oder auf der Seite des Datei-'Buches') der Dateiinhalt.
Zu dieser Icon-Klasse gehören auch die Nachrichten, die das System in kleinen Nachrichtenfenstern anzeigt. Ein Text wird als Textstring in den Speicher gestellt und als Fenster mit dem String als Inhalt als Icon dar gestellt.
3. Speicher zur Verfügung stellende Objekte ('Host Icons')
Jeder Host (wie immer er auch in der Matrix aussieht) gehört zu dieser Klasse von Icons. Diese Icons repräsentieren keine wirklichen Programme, sondern physikalischen, von Prozessoren bearbeiteten Arbeitsspeicher. So etwas kann
eine Festplatte sein (also ein Datenspeicher(DS) - obwohl um genau zu sein repräsentiert er nur die HD-Verwaltungseinheit und den ihr zugeordneten  Arbeitsspeicher, die HD selbst ist zwar Formal auf ein Host-Icon, allerdings können sich in ihr nur Passive Icons und Logische Icons aufhalten), oder ein Prozessor mit Arbeitsspeicher (also ein SPU oder CPU). Solche Icons können wie ein einzelnes riesiges Icon aussehen, sofern sie logisch zu einem Komplex verbunden sind.
In solche Icons kann man sich hineinbegeben und in ihnen können aktive Icons sich aufhalten (deren Programmcode sich dann in dem Speicher des Host Icons aufhält und von den Prozessoren des Host Icons ausgeführt wird). Aber auch alle anderen Arten von Icons können sich in Host Icons aufhalten (einschliesslich Host Icons).
4. Logische Strukturen ('Logische Icons')
Logische Strukturen sind nicht direkt im Speicher vorhandene Strukturen, wie z.B. ein Verzeichnis. Obwohl das Verzeichnis eigentlich nicht existiert, hat es ein Icon in dem sich Dateien aufhalten können (obwohl es keinen Speicher zu Verfügung stellt). Solche logischen Icons dienen hauptsächlich der Organisation und und der Orientierung innerhalb des Hosts (oder heutzutage dem Dekor). Allerdings trifft man auch ausserhalb von Host Icons auf  Logische Icons, z.B. sind die Gitterböden in den RTGs und LTGs solche logischen Icons, oder auch die Verbindungen zwischen den Hosts (obwohl die ein physisches Gegenstück haben (die Glasfaserkabel) stellen sie doch keinen Speicher da und sind somit logische Icons).

Generell kann man bei Icons sagen, das je grösser sie sind, desto grösser ist auch das Programm/die Datei/der Speicher (das gilt natürlich nicht für Logische Icons).
Auch die Gestalt des Icons ist stark von dem darzustellenden Objekt abhängig. Ein Programm das der Interpreter als gefährlich einstuft könnte als Messer dargestellt werden, ein noch gefährlicheres als Pistole.

-----Wieso kann man dann seine eigenen Icons kreieren?
Weil oft schon eine kleine Änderung im Programm eine Änderung des Icons bedeutet und und diese Änderungen nach einem logischen Prinzip verlaufen, kann man ein so Programm schreiben, das es ein spezielles Icon hat.

-----Wo ist der Interpreter?
Der Interpreter ist eine Software, die direkt auf dem MPCP läuft. In der heutigen Zeit der modellierten Systeme ist es üblich, das wenn man einen neuen Host betritt, man einen neuen Interpreter übermittelt bekommt, der das verschiedene Aussehen der Systeme macht. Deshalb bekommt man auch ein anderes Symbol wenn man sich in ein modelliertes System begiebt. Die einzige  Möglichkeit das zu umgehen ist seinen eigenen Interpreter fest mit dem MPCP zu verdrahten (das nennt man 'Realitätsfilter'). Das hat aber Vor- und Nachteile.
Der Vorteil ist, das man sich an seine Metapher gewöhnt und so jede Bedeutung sofort kennt. Dadurch reagiert man natürlich effektiv schneller.
Andererseits hat es einen Grund das es modellierte Systeme gibt. Denn jedes System ist anders und der systemeigene Interpreter ist natürlich hundertprozentig auf das System abgestimmt. Wenn man also seine eigenen Interpreter
benutzt, kann es passieren das Befehle missverstanden werden, so dass die MPCP das zusätzlich überprüfen muss und damit Geschwindigkeit einbüsst (also eine niedrigere Stufe hat). Und für die Systembetreiber ist das kein Problem, da sie ja ihre Metapher benutzt wird.

-----OPTIONALE REGEL-----
Ein Decker, der sich in einem System befindet, das die Metapher hat, an die er gewöhnt ist, erhält den gleichen Bonus wie wenn er einen Realitätsfilter hätte, aber nicht die Nachteile. Seinen Realitätsfilter brauch er dann natürlich nicht einschalten (es würde ihm auch nichts mehr bringen).
--------------------------------
-----Programmcode
Das System, dass jeder seinen eigenen Code mitbringt, hatte einiges für sich (und es wurde um einiges Absturzsicherer als der Kernel nicht mehr alles machen musste) doch es traten schon bald Probleme auf. Denn als das Entsetzen nach dem grossen Crash verflog, übergingen viele Firmen ihr schnellgegebenes Versprechen nach einer 'allgemeinen Standatisierung' aller Systemteile und der freie Wettbewerb begann von neuem - mit allen Tricks. Und so wurden die Computersystme wieder unkompatibel.
Doch das durfte in der Matrix, die ja nach dem 'jeder bringt gefälligst seinen eigenen Code mit'-Prinzip funktioniert, nicht sein, konnte doch der eine Host nicht entziffern was der andere da für guten Code hielt. Man griff dann zuerst auf das bewährte Onion-Modell zurück - eine Schicht baut auf die andere auf. Teilweise exestiert dieses Modell heute immer noch.
Real funktioniert das Onion-Modell von Linux-VR (die hatten schon immer auf unkompatible Hardware gesetzt) mit folgenden Schichten:
--Host-Code--
Code Nr. 1 und 2 werden nur auf dem Host gefahren und nicht über irgendwelche Leitungen geschickt (normalerweise wenigstens).
1. Maschienencode
Das ist ist der Code den der Prozessorcode selbst verarbeitet, sozusagen das Kernstück von allem. Er wird konventionell mit einem 'Assembler' in Textform geschrieben und danach in Machienensprache übersetzt. Diese Arbeit machen heute hauptsächlich Computer, da kaum noch jemand Assembler kann und die Zusammenhänge langsam zu komplex für Menschliche Hirne werden.
2. Betriebsystemcode
Nun ist jeder Prozessor anders und so braucht man eine standatisierte Befehlsebene, auf die der konventionelle Matrixcode zugreifen muss. Dies stellen die Betriebsysteme zur Verfügung. Sie 'übersetzen' den abstrahierten Programmcode auf ihre individuelle Hatdware und verwalten so etwas wie Icons und Speicherplatz.
Betriebsysteme werden konventionell programmiert, aber es gibt neuerdings auch Ansätze selbst das virtuell zu machen.
--Paket-Code--
Code 3-6 sind in Paketen enthalten, die über die Leitung gehen und stellen den eigentlichen Programmcode enthalten.
3. Transfercode
Der Transfercode steht jedem Codepaket voran, es sagt wer das Paket ist, wem es gehört, wo und wann es ausgeführt werden soll und schliesslich (meistens) wo es herkommt.
>>>>>[Also wo es herkommt sagten im eigendlichen Sinne nur die legalen Terminals - *echte* Cyberdecks fälschen diese Signatur natürlich.]<<<<<
        -Pandur(21:12:11/6-8-58)
Für den effektiven Datenverkehr ist diese 'Absenderadresse' allerdings nicht relevant, da jeder Host nur den Host kennt der in der Verbindungskette am nächsten kommt. Diese Verbindungsketten sind zwar nicht die eigendliche Operation 'Falsche Datenspur auslegen', aber kann einen ähnlichen Effekt erreichen.
>>>>>[Macht es nicht Leute, es macht einen ARSCH langsam!]<<<<<
        -Iron Eagle(02:09:56/12-8-58)
-----OPTIONALE REGEL-----
Der Spieleleiter bestimmt beim einloggen über wieviel 'Relais-Host' das Signal geht. Die Anzahl sollt von der Kompliziertheit der Verschachtelung des Systems abhängen (also wie Paranoid war der Systemdesigner als er diverse Sicherheitsknoten ect. angelegt hat). Innerhalb eines kartographierten Systems sollte die Anzahl der Hosts auf der kürzesten Verbindung plus etwaige Gitter-Hosts ausserhalb des Systems gelten.
Beispiel:
Doggy loggt sich über einen Telekom (NA/UCAS-SEA-0153-BIGLINE:T00012) in einem Hotel (oder so etwas ähnliches) in den Seattler Redmond Barrens ein (üble Gegend - übles Netz), das Hotel hat einen davorgeschalteten Security-Host (NA/UCAS-SEA-0153-BIGLINE (der stellt sicher dass niemand böses sich an den Hotelinternen Diestleistungsprogrammen zu schaffen macht (üble Gegend, aber gutes Hotel))). Er loggt sich von dort aus zuerst ins Redmond LTG (NA/UCAS-SEA-0153), ins Seattler RTG ein (NA/UCAS-SEA) und dann ins UCAS-RTG (NA/UCAS). Jetzt macht er einen kleinen Abstecher nach Denver zu ein paar virtuellen Freunden, aber das ist irrelevant, da er danach is NA/UCAS RTG zurückkehrt und somit für seine nachfolgenden Verbindungen diese Hosts nicht verwendet werden müssen. Doggy will ins Host-Netz von Chibba-Cooperatives, einem Gemüsehersteller mit Haupsitz in FDC. Er loggt desshalb ins RTG von Zentral-UCAS ein (NA/UCAS-NCE) und dann ins LTG von FDC (NA/UCAS-NCE-0014)
Danach lässt er seine Deckerkünste spielen um durch den obligatorischen Security-Host (NA/UCAS-NCE-0014-CHIBBAHQ) in ein dahinterligenden Buchhaltungs-Host (NA/UCAS-NCE-0014-CHIBBAHQ:SELL) zu gelangen. Da hier aber nicht viel interessantes liegt geht er zurück zum NA/UCAS-NCE-0014-CHIBBAHQ und von da aus über einen weiteren Security-Host (NA/UCAS-NCE-0014-CHIBBAHQ:MANG) in einen Host des mittleren Mangement (NA/UCAS-NCE-0014-CHIBBAHQ:MANG:MID).
So. Hier isser nun. Auf seiner Reise hierher hat er viele Hosts besucht, aber für den Verbindungsaufbau kommen nur die dierekten Verbindungen notwendingen Hosts zur gelteung:
CYBERDECK -> NA/UCAS-SEA-0153-BIGLINE:T00012 -> NA/UCAS-SEA-0153-BIGLINE -> NA/UCAS-SEA-0153 -> NA/UCAS-SEA -> NA/UCAS -> NA/UCAS-NCE -> NA/UCAS-NCE-0014 -> NA/UCAS-NCE-0014-CHIBBAHQ -> NA/UCAS-NCE-0014-CHIBBAHQ:MANG -> NA/UCAS-NCE-0014-CHIBBAHQ:MANG:MID
Das Cyberdeck und der End-Host gelten nicht, also liegen 9 Hosts dazwischen.
So genau wie in dem Beispiel muss man es natürlich nicht immer treiben, der Spieleleiter sollte meisten grob schätzen wieviele Hosts bis zum SAN des kartographierten Systems liegen.Von da an sollte er aber zählen. Aber auch dass muss er nicht, wenn er das vorher mit den Spielern klargemacht hat. Die Spieler müssen auf alle Fälle die Enscheidung des SL anehmen, egal wie unrealistisch diese auch sein mag.
So, und nun zu dem Effekten einer solchen 'langen Leitung': Die Anzahl der dazwischenliegenden Hosts geteilt durch 5 (abgerundet) senkt die Reaktion des Deckers um 1 und erhöht die Maximalsuchzeit von Aufspühr-ICE (das ist der Wert durch den die Anzahl der Erfolge des ICE geteilt werden um die Zeit zu ermitteln die es braucht um dich zu finden, im Grundbuch (VR2) waren es konstant 10 Runden) um 1.
Beispiel:
Doggy hat 9 Relais-Hosts, 9:5 = 1,8 ; abgerundet 1. Seine Reaktion ist also um 1 vermindert und wenn ein Aufspühr-ICE seinen Hotelplatz aufspüren will, muss es nun seine Erfolge durch 11 Runden (10+1) Teilen.
---------------------------------
--Programm-Code--
Code 4-6 ist der eigendliche Programmcode, also der Code der auch ausgeführt wird.
4. Konventioneller Matrixcode
So, hier haben wir den ersten wirklich universellen Code. Das ist dass was wir in unseren Icons zum laufen bringen, es ist wirklich universell einsetzbarer Code, den das Betriebsystem dann in Prozessorbefehle übersetzt. Ganze konventionell programmierte Programme und Module deklariert man dann als virtuelle 'Objekte' mit denen man dann in der Matrix was anfangen kann.
Konventioneller Matrixcode wird, wie der Name schon sagt, konventionell geschrieben und ist dementsprechend schnell, aber auch komplex. Aufgrund dieser Komplexität und Unübersichtlichkeit werden die meisten Matrixprogramme nicht mehr 'geschrieben' (was bei grösseren Projekten fast unmöglich wäre) sondern virtuell 'gebaut'.
>>>>>[Hey, ihr ganzen Newbies - DAS  ist es was ihr lernen müsst wenn ihr wirklich verteufelt gute Utilitys schreiben wollt! Sie sind kleiner, schneller und können auf grundlegendere Funktionen zurückgreifen. Aber sie sind natürlich anspruchsvoller.]<<<<<
        - Doc Hint(18:37:54/6-8-58)
5. Virtueller Matrixcode
Und auf dieser 'virtuellen' Ebene bewegt sich der Virtuelle Matrixcode. Er besteht nur noch aus Modulen und Objekten, die zusammengesetzt werden und über deren eigendliches Funktionsprinzip man sich keine Gedanken machen muss. mit diesen Objekten kann man dann in der Matrix hantieren und so stellen sie das erste Codekonstrukt da, das  ein Teil der Matrixwelt ist.
--Visualisierung--
Code 6 ist das was der User effektiv sieht und mit was er umgeht.
6. Icon
Das Icon ist das Endprodukt und wie es in der Matrix aussieht. Utilities und Programme bestehen zwar aus Virtuellen Matrixcode, können aber nur als Icon verwendet werden. So ist das Icon die offensichtlichste und letzte Schicht.
>>>>>[Ach scheiss auf den Dreck von 'konventionellem Code' und 'virtuellem Code'! Das Icon ist das wichtige! Das müsst ihr aus der Matrix blasen und nicht seinen wie auch immer geschreibenen Code!]<<<<<
        - Grount(16:32:19/8-8-58)
>>>>>[Schon wieder so eine dumme Dumpfbacke. Hey Grunz halt einfach die Klappe wenn Decker reden ja? Dann fliegen nicht so viele Fliegen rein. Und es kommt nicht so viel Müll raus.]<<<<<
        - Iron Eagle(02:14:43/12-8-58)

Jede dieser Schichten bestitzt noch einmal Unterschichten und so weiter, aber wer das genauer wissen will soll sich gefälligst die entsprechenden RFC's angucken, dafür legen wir sie schliesslich auf die Shadowland-Hosts.

----- Der Fluch des 'selfoptimized programming'...
Nur überschlug sich die Technologiekurve nach einiger Aufbauzeit einfach. Programme wurden schon vor ihrer Installation oder kurz danach ungültig, weil sie dem neusten Standart nicht mehr gerecht wurden und die neusten Funktionen des Konventionellen Matrixcodes nicht nutzen. Das städige automatische Updaten führte '42 beinahe zu einer weiteren Katastrophe, als viele der grossen Hosts schon wieder veralteten Code updateten. Als man das Netz wieder zum laufen gekriegt hatte, setzten sich einige hochbezahlte Spezialisten hin und erarbeiteten eine Lösung: Das 'selfoptimized programming'.
Verinfacht könnte man sagen, dass sie eine Programmierung schufen, die sich ständig selbst an die Umgebung und an die Gegebenheiten anpasst. Diese wurde dann in sämtliche Betriebsysteme integriert. Das führte nicht nur zu einer Beendigung des ständigen Updating-Problems, sondern auch zu einer wesendlich effizienteren Ressourcenverwaltung. So weit, so gut.
Nun war allerdings das rätselhafte Phänomen zu beobachten, dass je besser die VR wurde, desto besser wurde auch in Verarbeitung der VIRTUELLEN Prozesse. Wohlgemerkt der virtuellen, nicht der realen, was heisst dass der Comp zwar langsamer läuft, aber die Daten intern besser steuert. Absolut hirnrissig eigendlich, aber vielleicht ist das der Grund warum das Universum dreidimensional ist. Egal.
Wie dem auch sei, je grösser der Arbeisspeicher wurde und je schneller die Prozessoren die diesen barbeiteten, desto perfekter formte sich die Matrix, desto realistischer kahm die einem vor.
Der vorläufige Höhepunkt dieser Entwicklung führte zu den legänderen UV-Hosts.

----- ... und was es aus braven Systemen machte.
Der erste UV-Host trat '52 im Haupttiefenkern des Nexus auf, für 23 Sekunden verwandelte sich die virtuelle Realität im Hauptspeicherbereich total. Sämtliche Persona-Icons verwandelten sich plötzlich in ihre wirklichen Benutzer und ihre Utilitys in (jedenfalls in der VR) reale Objekte, die eigentlich nichts mehr mit den symbolischen Programmen zu tun hatten, sondern die man wie normale Gegenstände anwenden musste. Die physikalische Metahper des Hosts blieb weitgehend erhalten, aber die Effekte fühlten sich an als sein sie Echt! Die typischen Deckertricks funktionierten nicht mehr. Die SysOps des Nexus waren schockiert.
Aber in den letzten Jahren sind solche Hosts immer häufiger geworden, sie treten auf wenn genug Rechenleistung und Arbeisspeicher vorhanden ist, ob nun durch gezieltes zusammenbauen oder durch Systemfluktuationen.
Rein technisch funktioniert die UV-VR nach einem Zwei-Wege-Prinzip. Das normale (Ein-Wege-)Prinzip läuft so: Der Brainoutput kommt vom Gehirn und wird vom DNI ans Cyberdeck weitergeleitet, in dessen Interpreter es in virtuelle Signale umgewandelt wird. Diese werden zum Host geschickt und agieren da. Wärend dieser ganzen Zeit kontrolliert das DNI den Körper des Deckers und tut das, was das Gehirn normalerweise macht.
Beim Zwei-Wege-Prinzip läuft die Sache anders. Nach einer Initialisierungsphase schickt das DNI seine Daten nicht mehr an den Interpreter, sondern an den UV-Host! Der Host interpretiert dann und schickt DNI-Daten zurück, die das DNI dann an Gehirn und Körper verteilt. Natürlich wird der Host den natürlichen Körper des Deckers abbilden, denn für diesen Körper kommen ja die Kommandosignale vom Hirn an. Nun hat das aber böse Auswirkungen für den eingestöpselten Decker.
Wird sein virtueller Körper verletzt, so meldet der Host das dem Hirn. Das wiederum nimmt das für bare Münze und leitet Gegenmasnamen ein. Der Host leitet diese an den Körper weiter, nur sind dummerweise diese 'Gegenmasnamen' fast immer genauso gefährlich.
Wenn im Virtuelle Körper Organe flöten gehen schickt der Host diesen natürlich auch keine Signale mehr (Bei einem Herztreffer würde das Herz nicht mehr schlagen... für den Host exestiert es ja nicht mehr, warum sollte er also weiter 'Herz schlage' Signale schicken).
Die erreichte Qualität ist so hoch, dass nur Heisse ASIST's überhaupt in den eigendlichen Cyberspace gelassen werden, alle anderen müssen draussen per Menüsystem (wie archaisch) ihre Operationen tätigen.

-----OPTIONALE REGEL-----
Beim Übertritt in ein UV-System ist der User für 2 Runden bewegungs- und handlungsunfähig. In dieser Zeit initialisiert und analysiert der Host seinen Input. Ist der User in einem Nicht-UV-System, dass sich dann in ein UV-Host verwandelt, so tritt dieser Effekt nicht ein, der Host versucht ein 'schnelles Initialisierung'. Das führt nur dummerweise zu try-and-error-Fehlern, weshalb die Person einen Schock von 10T Betäubung. Sollte ein Decker gewaltsam ausgestöpselt werden, so erleidet er einen 12T Batäubungs-Auswurfschock.
EIN USER DER IN EINEM UV-HOST IST KANN NICHT 'ELEGANTES AUSLOGGEN' AUSFÜHREN UND SICH AUCH NICHT PER HAND AUSSTÖPÜSELN. ER MUSS WARTEN BIS IHN JEMAND AUSSTÖPSELT ODER EINEN LEGALEN SAN-KNOTEN FINDEN UM DEN HOST WIEDER ZU VERLASSEN.
---------------------------------
>>>>>[Böööse Sache wenn man kein darauf vorbereitetes Bodenteam hat. Und selbst mit kann einem der Auswurfschock letzendlich doch noch den Rest geben. Böse Sache das...]<<<<<
        -FastJack(??:??:??/??-??-??)
>>>>>[Gebt dem Kerl 'ne Pille und eine Freikarte ins Altersheim. Wenn er nicht mehr Decken kann, soll er den Platz den jüngeren überlassen, die wenigstens noch was riskieren!]<<<<<
        -Grount(16:41:31/8-8-58)
>>>>>[Und dabei schnell sterben.]<<<<<
        -Pandur(05:51:34/17-8-58)
 

>>>>>[Ich denke das war genug Stuff über den technischen Background der Matrix, ich denke wir machen jetzt weiter mit dem offensichtlichsten: Dem Icon und seinem Zusammenhang mit der Hardware des Users.]<<<<<
        -SysOp Zero Total <23:23:15/02-08-58>

ICON+HARDWARE

Die meisten User kennen ihre Icons, sie sind schöne bunte Objekte die das tun was man von ihnen erwartet. Doch das muss nicht so sein. Sieht man sich das Icon unter der Schicht des virtuellen Objektes an, so stösst man auf einige interessante und lebensnotwendige  Bestandteile die mit der Hardware in euren (realen) Händen verknüpft sind. Desshalb gehen wir jetzt mal die verschiedenen Eigenschaften eines Icon im Matrixslang durch (die offiziellen Bezeichnungen benutzt heutzutage keiner mehr, ausser dem Uniprofessor, denn selbst die Experten sind auf den einfacheren Slang umgestiegen):
-----Personaprogramme
1. MPCP
Das grundlegenste Personaprogramm ist das MPCP (Master-Persona-Control-Program), es verwaltet alle anderen Personaprogramme und tritt in dierekten Kontakt mit dem Interpreter auf dem heimischen Cyberterminal. Da die Geschwindigkeit des Icons und der Umfang der uf dem Host lafenden Programme stark von der Verarbeitungsgeschwindigkeit der Terminal-CPU (Central-Processing-Unit: der Hauptprozessor) abhängt, da das Deck alles nachvollziehen muss, was der User in der Matrix macht (aus diesem Grund muss auch jedes Utility das in der Matrix genutzt wird im heimischen Arbeistspeicher vorhanden sein), hängt die Effektivität des MPCP (auch des Online-MPCP!) sehr stark von dessen Speed ab.
Ein schnelles MPCP (das also eine hohe Stufe hat) wird von einem entsprechend schnellen Prozessor beackert und kann entsprechend umfangreiche Programme laufen lassen (also: die eine hohe Stufe haben).
2. BOD
Bod ist eine ziemlich komplizierte Angelegenheit, da vor '42 niemand ein Bod-Programm laufen hatte (also alle mit Bod 0 rumgezischt sind) und die Matrix auch ohne dieses gut funktioniert. Allerdings war das decken damals eine ziemlich riskante Sache, auch für legale User. Das Problem bestand darin, dass durch zufällige Netzfluktuationen oder Programmfehler (ja, auch Microsoft hat damals noch Programme verkauft) häufig kleine Fehler im Code entstanden und das gesammte Icon dadurch abschmierte. Normale Icons hat das nicht gestört, der SysOp hat einmal lat geflucht und das Programm neu geladen. Allerdings wenn ein Mensch am Output des Icons hängt, dann wird die Sache etwas hässlicher. Die Icons stürzten nämlich nicht einfach ab, also das System erkannte sie nicht einfach als gibt-keine-Rückmeldung-ist-wohl-tot, sondern ab und zu, wenn das MPCP verschrottet wurde, schickte es äusserst gefährlichen Datenmüll. Als die Systeme komplexer wurden passierten solche kleinen Fehler immer häufiger, und so, als '42 das selfoptimized programming erfunden wurde, schufen die Designer ein neues Personaprogramm, den Bod, das für die Reperatur solcher Kleinschäden zuständig war. Effektiv machte sich das vor allem im Matrixkampf bemerkbar, da die meisten Angriffsprogramme Fehler in das Icon einschleusen (je besser das Programm desto schwerwiegender die Fehler), kann ein gutes Bod-Programm viele Angriffe zumindest abschwächen, indem es vor den beschädigten Bereich ein  Link legt. Dadurch werden die Bereiche zwar unbrauchbar (was auch ganz schön gefährlich sein kann wenn man Pech hat), aber das Icon kann weiterlaufen (wenn auch oftnicht mehr so gut vie zuvor).
Icons mit Bod 0 haben diesen Selbstreperaturmechanismus nicht und stürzen ab, sobalt ihnen IRGENDEIN Schaden gemacht wird (also auch wenns ein Leichter ist). Bei Persona-Icons ist allerdings Bod > 0 gesetzlich vorgeschrieben, wenn man Bod 0 hat brauchen die Krankenkassen nicht zu zahlen.
>>>>>[Also das gilt natürlich nicht für Doc-Wagon oder ähnliche Rundumservice-Anbieter. Sie kommen immer, und wenn du einen ordendlichen Vertrag hast oder gut zahlen kannst helfen sie sogar.]<<<<<
        -Doktor Lucius Shiwan (19:31:57/9-8-58)
3. SENSOR
Sensor ist das älteste und grundlegenste Personaprogramm, denn mit ihm kann das Icon die Matrix wahrnehmen. Es berührt fragt Systeminformationen ab und schickt diese an den Interpreter, der dann, je nach Güte des Sensor-Programmes, mehr oder weniger gut enscheiden kann was er da  und ob er überhaupt etwas sieht. Das heisst aber nicht das jedes Aktive Icon automatisch einen Sensor braucht. Es gibt auch Icons die so etwas überhaupt nicht nötig haben, eine an den Computer angeschlossene Kafeemaschiene zum Beispiel, sie hätte zwar ein Matrixicon mit Befehlsempfangsoftware, aber die eigentliche atrix müsste es nicht wahrnehmen. Die meisten Perepheriegeräte sind so angelegt, man beinflusst sie in dem man das System dazu bringt ihnen entsprechnde Kommandos zu schicken (also man würfelt gegen die Perepheriestufe des Systems).
>>>>>[Man kann auch versuchen das Icon selbst anzugreifen, aber das führt meist nur zum Absturz des Icons. Das allerdings kann man sehr gut machen, da es keinen Bod hat.]<<<<<
        -Brother Data(3:25:23/8-8-58)
Sensorsysteme kann man verwirren, wenn man ein Schleicher fährt oder die natürliche Maske benutzt meldet sich das Icon falsch an, als ungefährliches Objekt, und somit würde der Sensor in den Systemtabellen nur ein uninteressantes Icon finden. Neue, bessere Sensor-Programme haben allerdings auch eine Speicherscan-Funktion, und wenn sie eine Diskrepanz zwischen der Anmeldung und dem vorgefundenen Code feststellen melden sie das dem Icon. Je besser die Programme sind, desto besser können sie das Unterscheiden.
-----OPTIONALE REGEL-----
Wenn ein Decker einen Schleicher fähr muss er sagen als was harmloses er sich denn hier Tarnen will. Die Ähnlichkeit der Berschreibung mit dem tatsächlichen mitgeführten Utilitycode (und natürlich mit den Handlungen) modifiziert den Entdeckungsfaktor. Generell kann man sagen, dass er um 1 sinkt wenn der Code nicht so recht zu dem beschriebenen Icon passen würde und um 2 wenn überhaupt kein Zusammenhang besteht. Er kann auber auch um 1 steigen, wenn die Beschreibung besonders perfekt passt.
Beispiel:
Crowd deckt sich in ein Mitsuma Low-Security-System ein. Eigendlich kein Problem denkt er, hauptsache er wirbelt keinen Staub auf. Sein normaler Entdeckungsfaktor ist 5, und er beschreibt bei der Anmeldung im System sein Iconaussehen als "kleines Angestellten-Icon der mittleren Gehaltsklasse". Wenn er nun sehr unpassende Utilitys läd (wie zum Beispiel 'entschärfen', 'Entschlüsselung', 'Täuschung', u.s.w.; 'schwindel', 'kommleitung', u.s.w. wären noch erlaubt) sinkt sein Entdeckungsfaktor um 1, Bei extremen Änderungen (Angriffsprogramme, 'schwarzer Hammer', u.s.w.) sogar um 2. Das gleiche gilt wenn er sich auffällig, bzw. extrem Auffällig benimmt. Wenn er sich jedoch besonders unaufällig verhält und nur Utilitys bei sich hat, die der brave Sarariman auch normalerweise bei sich trägt (also: 'lesen/schreiben', 'schmöker', 'analyse'), kann sein Entdeckungsfaktor um 1 steigen.
------------------------------------
4. MASKE
Die ganzen legalen Terminals und Decks haben natürlich kein Maske, sie haben noch nicht einmal Steckplätze dafür.
>>>>>[Allerdings kann man einen Speicherbank-Platz so neu verdraten, dass er einen auf einem Adapter steckenden Masken- oder Ausweichen-Chip aufnehmen kann. Die gaze Sache ist aber zeimlich umständlich und dauert selbst bei halbwegs gutem Werkzeug und Material gute 8 Stunden.]<<<<<
        -FastJack (??:??:??/??-??-??)
Maske ist ein Prog, der sich erst unter falschem Namen beim System anmeldet und dannach die Verarbeitung der zum System ein- und ausgehenden Daten übernimmt. Ein anderes Icon wird vom System natürlich auch anders behandelt, und so muss er alles was das Icon machen will und alles was der Host darauf antwortet zuerst einmal übersetzten. Ausserdem versucht Maske den Code im Icon so zu gruppieren, dass er den Analyse-Programmen nicht auffällt und möglichst zum vorgetäuschten Icon passt. Das ist eine ziemlich komplizierte Aufgabe, weshalb das Maske-Programm einen nicht unerheblichen Speicher- und Rechenzeitverbrauch hat.
5. AUSWEICHEN
Im Matrixkampf wird oft einfach blind auf vom Icon belegten Speicher geschossen, dort werden die Daten zufällig oder nach einem beabsichtigten Muster verändert (berühmt wurde der 'Spring immer wieder auf dieselbe Position'-Befehl, bei dem das Icon ein und den selben Befehl immer wieder wiederholt und somit nicht abstürzt, sondern der Code bewegungslos im Host verbleibt - man kann ihn nachher prima analysieren und so auf den Eindringling schliessen).
>>>>>[Diese Dinger funktionieren wirklich gut, aber dem meisten Weissen ICE ist es relativ egal wen es da rausschmeisst, solang er raus aus dem System ist. Graues Ice interessert sich viel öfter dafür, aber an nicht sehr wichtigen Stellen verzichten auch sie darauf. Und wenn Schwarzes ICE einen erwischt ist es ihm sowieso egal wie deine augebrannte Hülle hiess.]<<<<<
        -Pandur(21:28:43/6-8-58)
Gegen dieses blinde feuern kann man relativ wenig tun (zumal wenn es von Hochprioritätsicons wie ICE abgefeuert wurde), also verfiehlen die Decker auf die Idee ihren physikaliscen Platz im Speicher zu wechseln. Ganz ähnlich wie 'Spiegel' es bei Köderoperationen macht, kopiert Ausweichen den Icon-Code an eine andere Stelle und legt den Icon-Link in den Systemtabellen auf den neuen Code. Dabei ändert sich die virtuelle Position nicht, das heisst das Icon bleibt das alte, es hat ja mit der physikalischen Position nichts zu tun. Viele Decker triggern ihr Ausweichen-Prog aber, das heisst sie fahren ihr Ausweichen nur dann, wenn sie in der virtuellen Realität auch 'ausweichen'. Ausserdem wird von den Interpretern ein solcher Vorgang als ein 'ausweichen' dargestellet, damit der User weiss was passiert.
Aber eine solche Speicherverschiebung ist auffällig, denn normale Icons tun so etwas nicht (jedenfalls nicht physikalisch, virtuell können sie sich natürlich ständig bewegen).
-----OPTIONALE REGEL-----
In der Runde in der ein Decker ausweicht (also ein Kampfmanöver macht) sinkt sein Entdeckungsfaktor in dieser Runde um 2. Nach der Runde ist er wieder normal.
ICE oder Kampfprogramme können so ausgestattet werden, dass sie die nach dem eigentlichen 'Absturtz' eines Icons dessen Codeconstrukt als Passives Icon weiserlaufen lassen. Dieses kann dann analysiert werden, allerdings ist die Möglichkeit aus diesem Codekonstrukt ein lauffähiges Programm zu extrahieren sehr eingeschränkt, zum Programmklau eignet es sich also nicht, da das Angriffsprogramm so viele Teile beschädigt, dass man aus diesen keinen ordendlichen Code mehr Rekonstruieren kann, zur Wiedererkennung des Codes reicht es aber allemal.
---------------------------------
----- Das ASIST
Zum Interprter ist vorer schon eine Menge gesagt worden, deshalb wollen wir uns hier mit der Hardware-Komponente des Interpreters beschäftigen - dem ASIST-Interface.
Das ASIST kann in drei verschiedenen Modi laufen, die das DNI auf total verscheidene Art und Weise anspricht.
1. Schneckenmodus
Wie kaum anders zu erwarten kann man das ASIST auch auschalten. Der Output wird dann auf dem Monitor oder auf einem Cyberhelm dargestellt und der Input kommt per Tastatur oder per Datenandschuh rein. Archaisch, aber Menschen ohne DNI kann nicht anders in die Matrix.
2. Kühles ASIST
Bei einem Kühlen Deck wird das RAS (retikular aktivierender System Override - das System das die Befehle an den Körper herausfltert) auf eine niedrige Stufe gestellt, so dass man den Körper mit grosser Konzentration noch bewegen kann (mit einem +8 Midestwurf), und das DNI wird in den 'Traum-Modus' geschaltet. Hierbei werden Gehirnfunktionen, die beim Träumen die Bewegung des realen Körpers verhindern, zum steuern in der Matrix missbraucht. Das Gefühl ist ein typisches Traum-feeling, alles ist ein bisschen Irreal und auch etwas unklar. Ausserdem ist das Gehirn in diesem Zustand nicht so reaktionschnell wie im 'wachen' Zustand, dafür muss aber das DNI die Körpersteuerung nicht übernehmen, wodurch Schwarzes ICE keinen körperlichen Schaden anrichten kann.
>>>>>[Naja, Theoretisch....]<<<<<
        - Kalim(02:01:34/11-8-58)
Insgesammt fährt man mit einem Kühlen ASIST etwas langsamer aber dafür um einiges sicherer.
3. Heisses ASIST
So hier haben wir nun das Schmuckstück der Sammlung, jeder wirkliche Decker fährt ein heisses ASIST. Hierbei wird das RAS voll aufgerissen und das DNI übernimmt statt dessen die Steuerung des realen Körpers. DAS IST GANZ SCHÖN GEFÄHRLICH WENN SCHWARZES ICE AUF DAS DNI ZUGREIFT!!! Das ICE hat das DNI und damit den Körper dadurch total in der Hand und kann so ziemlich machen was es will, und das heisst in den meisten Fällen den Burn-out.
Der Vorteil dieses Tores in die Matrix ist die totale Geschwindigkeit. Das Gefühl das alles was man denkt sofort umgesetzt wird ist einfach bombastisch und da der Decker 'wach' ist und das DNI meist im Notfall seine Adrenalinpumpe ganz schön anschmeisst, ist er auf einmal so schnell wie seine Gedanken. Und das ist ganz schön schnell.
Diese Art die Matrix zu bereisen ist mit Sicherheit die gefährlichste aber auch die beste!
----- Härte
Härte ist ein reines Hardwareprogramm, dass beim Cyberdeck eintreffende Kommandos auf ihre schädlichkeit hin überprüft. Je besser die Härte ist, desto besser kann es die eintreffenden Daten analysieren und schädlichen Code ausfiltern.

UTILITYS

----- Panzerung
Panzerung ist eine Weiterentwickelung von Bod, nur geht es nach dem Prinzip 'Besser den Angriff abwehren bevor er da ist' vor. Dafür muss man wissen wie die Speicherübertragung in der Matrix passiert. Zuerst wird da eine sogenante 'Pipe' festgelegt, in der das Ziel und die Quelle definiert wird. Dies ist eine Systemvaariable und der nachfolgende Tranfer wird ebenfalls vom System durchgeführt. Natürlich wurde das so eingerichtet damit man nicht Müllcode in anderen Icons ablegt, aber ein Angriffsprogramm zeichnet sich ja gerade dadurch aus dass es diese Beschränkung umgeht.
Und hier kommt das Panzerung-Utility zum Einsatz. Das Panzerung-Programm versucht nun das Ziel dieser Pipe zu ändern (nämlich vom Icon fort), aber das kann es erst wenn die Pipe exestiert, das heisst eine geringe Datenmenge wird immer das Icon schädigen, aber eine gute Panzerung kann ihn so schnell stoppen, dass das Bod-Programm den Schaden schnell wieder korrigieren kann. Gute Angriffsprogramme bauen aber ständig neue Pipes auf und so wird die Panzerung, die jede Pipe versucht auszuschalten, bei zunehmender Qualität der Angriffsprogramme immer unwirksammer.