Teamwork zwischen Decker und Rigger?

Nun, der Decker muss dazu über ein drahtloses Interface zur Drohne kommen. Wäre auf jeden Fall ne Spezialanfertigung, was das Fernsteuerdeck und den Empfänger der Drohne angeht (man sieht die Nuyenzeichen in den Augen deines Mechanikers leuchten). Einfacher wäre es, auf die Drohne nen Funkempfänger draufzuschrauben und sich dann nach den Regeln im Matrix zu richten.

Machbar wäre es sicher, Funk ist es ja sowieso.

Also der Decker sitzt drausen rum, der Rigger auch.
Rigger bringt Microdrohne in position an einem Jackpoint, und stöppselt sie ein. Dann macht Kollege Rigger ein Mittagsschläfchen wärend Decker über die Drohne deckt.

Die Idee ist genial...

Was braucht man alles um eine solche Microdrohne selbst steuern zu können? -> Cyberwaretechnisch gesehen, ich finde das ganze extrem gut.

Hmm, vielleicht war es ja auch anders gemeint: die Funkverbindung zwischen dem Fernsteuerdeck und der Drohne ist ja schon SimSinn.

Reicht es nicht, wenn am Fernsteuerdeck ein Jackpoint/FUP oder was auch immer drangebastelt wird und an der Drohne das Gegenstück?

Dann benutzt der Decker das Fernsteuerdeck als Funkinterface (spezialisiert auf die Drohne in der Netzwerliste).

Selbstverständlich ist die Drphne dann in Standby oder kann man die Leistung und Bandbreite entsprechend erhöhen (und wozu)?

Zwischenfrage: braucht man dazu (rein theoretisch) überhaupt einen Rigger? Es gibt doch so eine nette Rigger Protocol Emulation. Ist vielleicht nicht so effektiv wie ein "echter" Rigger, aber man bräuchte nur eine Person für die Aktion.

Hallo!

Ich denke auch, daß mit entsprechenden Programmier- und Elektronikkenntnissen ein Kanal des Fernsteuerdecks als Datentransferkanal genutzt werden kann.
Wenn ein Jackpoint angezielt wird, kann man ja einfach einstöpseln; das sollte auch per Protokollemulation gehen, mit einem Rigger dahinter auf jeden Fall.
Will man aber an eine "geschlossene" Leitung eine Datenwanze anbauen, ist das schon mit echten Händen sehr kompliziert. Ich würde das, denke ich, für eine Drohne mit Greifarmen wohl nicht erlauben. Wenn ein ehemaliger Chirurg mit einer ehemaligen Chirugiedrohne so etwas anstellt, ist das vielleicht eine andere Sache; für einen normalen Rigger aber dürfte das außer Reichweite sein.

Gruß

Quichote

"Machnog-Morb" schrieb:

Hmm, vielleicht war es ja auch anders gemeint: die Funkverbindung zwischen dem Fernsteuerdeck und der Drohne ist ja schon SimSinn.

Jupp, aber wenn ich nicht irre, sind es zwei total unterschiedliche Protokolle, SimSinn hin oder her.

SimSinn bezeichnet ja bloss die Technologie, die es Riggern mit ihren Fernsteuerdecks genauso wie Deckern mit Cyberdecks erlaubt, mit Hilfe der ASIST-Technik ihre Umgebung wahrzunehmen, und sich in sie hinein zu versetzen.

Oder habe ich das jetzt komplett falsch verstanden?

Wenn es aber absolut das gleiche wäre, dann wäre die Verwendung eines (Achtung: die Bezeichnung sagt viel aus!) "Rigger-Protokoll-Emulators" nicht vonnöten, weil es ja dann nix zu emulieren gäbe.

Der Emulator simuliert mit Hilfe der Rechenleistung (also per Software und nicht per Zugriff auf irgendwelche Decoder-Hardware) das Protokoll (die Sprache) eines Fernsteuerdecks, damit man als Decker auch in den Genuss kommt, mal ne Kleinigkeit zu riggen.
Nach dem gleichen Prinzip funktionieren doch auch die ganzen C-64, N64 und Playstation Emulatoren auf dem PC heute.

Ich kann jetzt nicht sagen, welche Nachteile man jetzt genau nach dem SR-Regeln in Kauf nehmen muss, sollte man dieses Verfahren anwenden. Aber in der Realität sind Emulationen/Emulatoren...

a) ... meistens langsamer, weil ein simuliertes, softwaregesteuertes Protokoll mehr Zeit zum berechnen braucht, wie ein Hardwaresystem, das die Daten praktisch in Echtzeit rausjagt...
b) ... nicht immer in Leistungs- und Funktionsumfang gleichwertig, weil viele Features, die von der Hardware unterstützt werden, ohne diese nur eingeschränkt oder gar nicht vorhanden sind...

Praktisches Beispiel ist AppleTalk. (Kommunikation zwischen Win und Mac - PCs...) Dauert auf jeder Seite länger als ein direkter Zugriff auf einen Netzwerkcomputer mit dem gleichen OS, und dem gleichen Netzwerkprotokoll.

In der SR-Realität darf man darüberhinaus nicht vergessen, dass ein Rigger eine Rigger-Kontroll-Einrichtung implantiert hat, wenn er was taugt. Ein Decker bekommt höchstens -1, weil er eingestöpselt ist, auf Steuerpool muss er sowieso verzichten.

Hallo!

Das war, denke ich, ein Mißverständnis ...
Natürlich folgen Rigger und Decker völlig anderen Protokollen. Ein Verwenden des einen für das andere ist daher nur unter Erschwernissen und verlangsamenden Emulatoren möglich (die darüber hinaus fehleranfällig und instabil sind, außerdem den aktuellsten Protokollen hinterherhinken und überhaupt nicht toll).
Man kann also nicht so ohne weiteres aufeinander aufsatteln.

Trotzdem aber besteht zwischen Drohne und Rigger ein dreibandiges Funkdatennetz, das volldigital ist und außerdem reichlich Bandbreite aufweist. Es ist also aus logischer Sicht nicht unbedingt erforderlich, eine separate Funkdatenstrecke mit eigener Hardware aufzubauen. Wenn der Rigger zeitweilig auf eines seiner Bänder verzichtet, kann man "einfach" in dieselbe sendende und empfangene Hardware ein anderes Protokoll laden, das Band (oder auch zwei) für die Matrix nutzen und bei Bedarf wieder umstellen. Das sollte auch ohne große Hardware-Umbauten gehen und vor allem eine Frage der Firmware sein.

Den Sensor-Kanal würde ich dabei aber unangetatstet lassen; den sich mit verdutztem Blick bückenden Wachmann sollte man vielleicht noch sehen. Wie das mit der sich danach rapide nähernden Stiefesohle ist, soll jeder selber entscheiden ...

Gruß

Quichote

Hab ich also doch richtig getippt.

Nur um es noch einmal deutlich zu sagen:
Diese Einschätzung kommt aus Logik und Dramaturgie und dem Geist der Regeln, all diesen weichen Faktoren halt. Den Buchstaben der Regeln allerdings ist nichts Entsprechendes zu entnehmen.

Gruß

Quichote

Jetzt habe ich endlich auch kapiert, was Du meinst.

Steht auch nicht irgendwo, wofür die einzelnen Bänder verwendet werden, bzw. ob es für die volle Leistung bzw. Reichweite nötig ist, alle drei simultan in Betrieb zu haben?

Selbst wenn, mit ein bisschen Aufwand ist es sicherlich möglich, das Signal über die gleichen Bänder zu übertragen. Die Kosten für die Geräte werden wahrscheinlich etwas höher sein, aber wahrscheinlich nicht grundsätzlich unmöglich, wenn man mit etwas Performance-Einbussen leben kann.

Dazu müsste das Signal (theoretisch, nicht nach den offiziellen SR-Regeln) beim Verschicken zusammengeführt und beim Empfangen wieder mit einem Splitter getrennt werden, damit sich beide Datenströme nicht gegenseitig in die Quere kommen. (So ähnlich funzt DSL doch auch, nur das das DSL-Signal die analogen Telefonsignale nicht beeinträchtigt, weil sie auf einer komplett anderen Frequenz laufen. )

Coole Sache. Mein Char Mister L ist Decker/Rigger.
Das probier ich aus...

Guten Morgen!

Die drei Bänder sind im Rigger erklärt; viel Geheimnis ist aber nicht dabei.
Eines ist für das SimSinn-Feedback für den Rigger, eines für die Steuerung der Drohne und eines für die Sensoren, wenn ich mich recht erinnere (da wie immer ohne Buch.)
Das ist natürlich, wenn das so stimmt, ein wenig inkonsistent, weil Sensorensignale ja auch in das Simsinn-Signal eingehen können und die Steuerung dort heraus ebenfalls laufen kann.
Logisch also wäre es, daß diese drei Kanäle je nach Modus unterschiedlich beansprucht werden. Im Kapitänsmodus wird der SimSinn-Kanal ziemlich frei sein und nur standby-Signale senden, während im eingesprungenen Modus der Sensorenkanal auf den Simsinn-Kanal aufgeschaltet werden müßte.
Bezüglich Reichweite etc. werden die drei Bänder nicht getrennt behandelt; sie verwenden auch spieltechnisch alle dieselbe Hardware. Allerdings kann man sie im Kontrolkampf einzeln angreifen und übernehmen, insofern also wohl auch einzeln belegen, umlegen, aussteuern ...

Gru0

Quichote

1. Datenwanzen sind Geräte, die an Verteilerbuchsen/etc. einen illegalen Jackpoint erzeugen - durch anstöpseln. Datenleitungen selbst können in SR nicht angezapft werden. (Es sind LWLs - viel Spaß)
2. Der 'Geist der Regeln' ( :-& ) sagt, das die Protokolle nicht austauschbar sind.
3. Es gibt keinen Sensorkanal. Es gibt den Kommandokanal (Steuerung), den SimSinnkanal (Video, Audio, SimSinn) und den Systemkanal (Netzwerk, Zusatzkrams). Der einzige Kanal wäre also der SimSinnkanal, jeder andere nur im Schneckenmodus - wenn es ohne weiteres möglich wäre, siehe 2.
4. Also beginnt ein Rigger munter sein Deck und die entsprechende Drohne zu zerbasteln, auf die Gefahr hin das garnichtsmehr richtig tut, anstatt einer Drohne mit mechanischem Arm ein Kästchen mehr (Funkinterface) mitzugeben, das der Decker selbst noch anderweitig nutzen kann (Selbst aufbauen, einem Kollegen mitgeben)? Selbst schuld.

Genau - selbst schuld. Also lass uns doch...

Übrigens: wie hoch ist die Austreibungsschwierigkeit bei diesem ominösen Geist der Regeln? Wenn ich treffe, will ich versuchen ihn auszutreiben...

Aber damit ist schon ziemlich klar, wo man dran rumbasteln muß...

Bei der Drohnenmethode treten allerdings Probleme auf:

Was für eine Gerätestufe hat die Drohne? Denn die ist nötig für die Energiestufe (maximale Reichweite), und den maximalen Datendurchsatz.

Der Rigger muß sich den SimSinnKanal auf den SystemKanal mappen, sonst ist er blind und taub. Das beinträchtigt aber sein gesamtes Netzwerk...

Hallo!

Ich denke, daß man für eine solche "Umbaumaßnahme" nicht einmal nennenswert "Elektronik-B/R" braucht. "Protokoll" ist ja nichts anderes als die (i.d.R.) zwei "Kommunikaltionslayer" oberhalb der physikalischen Ebene. Bei einem aktuellen PC wäre das also der Treiber der Netzwerkkarte/Windows und danach das Netzwerkprotokoll. Wenn ich meinen Rechner nun von TCP/IP auf ein anderes Protokoll (beispielsweise Win-Spezifisch oder wasweißich) umstellen will, geht das mit der selben physikalischen Ebene (Netzwerkkabel). Ich muß lediglich ein neues Protokoll laden und mounten.
Analog dazu wäre die Funkwelle der physikalische Träger. Die Bauteilkommunikation an der Drohne und der Fernsteuerung sind Protokoll-Layer 1, und Layer 2 wäre dann das Riggerprotokoll.
Dieses Protokoll läuft vermutlich auf einem bauteileigenen Prozessor, an den man als "doppel-Boot-System" ein zweites Protokoll anflanscht. Heißt: ein neuer Speicherbaustein und einmal an der Firmware schreiben, also ganz klassisch maschinennah programmieren. Beide Protokolle bekommen dann noch einen "dismount"-Befehl. Natürlich muß der jeweilige Kanal bei Umstellung neu gebootet werden. Mit den paar Sekunden hat dann auch der Spielleiter genug Möglichkeiten, Spaß zu haben.
Aber die Frage bleibt: welche Bandbreite mag der SimSinn-Kanal haben?

Eigentlich zweitrangig, welche Bandbreite. Geht man von 100% bei der alleinigen Nutzung aus, bleiben einem auf jeden Fall nur höchstens 50% bei der simultanen Benutzung eines Kanals/Bandes von zwei Usern.

Ich könnte mir darüberhinaus aber vorstellen, dass der SimSinn-Kanal die grösste Bandbreite haben muss (...sind ja schliesslich Multimedia-Daten...), im Gegensatz zum Netzwerk-Band, durch die hauptsächlich kleinere Steuerdaten fliessen müssen.

"Rotbart van Dainig" schrieb:

Bei der Drohnenmethode treten allerdings Probleme auf:

Was für eine Gerätestufe hat die Drohne? Denn die ist nötig für die Energiestufe (maximale Reichweite), und den maximalen Datendurchsatz.

Der Rigger muß sich den SimSinnKanal auf den SystemKanal mappen, sonst ist er blind und taub. Das beinträchtigt aber sein gesamtes Netzwerk...

zu 1.) Seit wann haben denn Drohnen eine Gerätestufe? Ich dachte das Fernsteuerdeck war für die Reichweite des Netzwerks verantwortlich (Ausnahme: Relaisdrohnen)?

zu 2.) Stimmt. Man kann eben nicht alles haben. Ich freu mich trotz dieses Nachteils schon auf meine neue Hacker-Drohne, demnächst irgendwann...