Sehr schön!
Die beiden äußeren Hebel haben die richtigen Proportionen im Bereich der Handfalle.
Wenn du viel Zeit hast, könntest du vielleicht den Federdraht noch etwas stärker machen, dann wärs perfekt.

Hallo Ronny,


bei den beiden inneren Hebeln habe ich versucht, die Handfalle in der angeklinkten Stellung darzustellen. Wenn Du genau hinsiehst, wirst Du erkennen, dass die Handfallenstange und damit die Verschlusssichel nach oben bzw. unten in die Mittelstellung verschoben sind. Die um die Handfalle und den Hebelgriff geschlossene Hand des Stellwerkswärters muss man sich dazu denken.

Ich danke Dir auch für Deine Hinweise zu den EZMG-Tischfeldern:

Diese Grafiken schlummern schon seit Jahren auf meiner Festplatte und ich habe mich bei ihrer Erstellung hauptsächlich auf das Buch "Eisenbahnsicherungstechnik" von J. Arnold u. a. verlassen. Es kann durchaus sein, dass da einige Proportionen nicht stimmen.
Welche Schriftart würdest Du denn nehmen? TGL-Normschrift habe ich leider nicht auf dem Rechner, deshalb habe ich die erstbeste serifenlose Schrift genommen...

Gruß
- Christopher

Um mal eine Rückmeldung zu geben was ich eigentlich mache: Momentan vorallem Arbeiten im Hintergrund, Editoren, und momentan denke ich über eine grundlegende Überarbeitung des Systems das die Grafik erzeugt nach, um einige Schwachstellen, die sich inzwischen gezeigt haben, zu beseitigen.

Also die Entwicklung geht weiter, aber es gibt momentan nicht wirklich etwas neues was ich präsentieren könnte, deswegen war ich in letzter Zeit etwas schweigsam.

Ach, jetzt sehe ichs auch ...

Zum Thema EZMG hast du ne PN von mir.

Heute auf nem Spaziergang habe ich mir ein paar Gedanken zum Thema EZMG gemacht - wenn ich nichts übersehen habe, dürfte ein EZMG mit der aktuellen Version von StellSi ohne grüßeren Aufwand möglich sein. ANhand des Beispiels EZMG möchte ich mal kurz skizieren, wie StellSi auf der Logikebene aufgebaut ist.
##### Allgemeines zu StellSi ######
Generell ist StellSi dreigeteilt in die Außenanlage, die Relaisanlage und den Stelltisch. Ich betrachte hier jetzt nur die Ebene der Relaisanlage.

Generell haebn wir in der Relaisanlage diverse "Logikeinheiten", "Relaisgruppen" genannt. Jede Relaisgruppe besteht intern aus Schnittstellen, Zuständen und Anweisungen. Die Anweisungen werden dabei momentan über eine einfache Skriptsprache definiert, als künftige Erweiterung sollte es aber auch möglich sein direkt Relaisschaltungen über einen Schaltplaneditor zu ermöglichen - aber die Zeit das zu entwickeln habe ich momentan nicht.

Die Schnittstellen dienen dazu, die einzelnen Relaisgruppen untereinander sowie mit den Elementen des Stelltischs und der Außenanlage zu verbinden. Zwischen den Schnittstellen werden "Signale" ausgetauscht, die aus einem Signalnamen sowie einem Signalwert bestehen - der Wert ist in der Regel eine Zahl, kann aber auch eine Zeichenkette oder ähnliches sein (für QT-Kundige: Ich arbeite hier mit einem QVariant).

Eine Schnittstelle ist dabei gleichzeitig Server und Client. Jede Schnittstelle kann sich als Client auf genau eine andere Schnittstelle verbinden, gleichzeitig kann eine Schnittstelle aber beliebig viele Verbindungen von anderen Schnittstellen entgegennehmen. Alle Verbindungen laufen dabei in beide Richtungen, für den Nachrichtenaustausch ist es daher unerheblich, in welche Richtung die Verbindung aufgebaut wurde.

Nehmen wir die Relaisgruppe1 mit der Schnittstelle "bla", die Relaisgruppe2 mit der Schnittstelle "blubb" und die Relaisgruppe3 mit der Schnittstelle "blabber". Die Schnittstellen blubb und blabber sind beide mit der Schnittstelle bla verbunden.

Relaisgruppe1 sendet jetzt das Signal "ichbintoll" über die Schnittstelle bla hinaus - worauf die Schnittstellen blubb und blabber dieses Signal empfangen. Die Schnittstellen setzen dann ihren eigenen Namen als Präfix vor den Signalnamen, und übergeben dann das Signal an die Relaisgruppe. Konkret bekäme jetzt zum Beispiel die Skriptengine von Relaisgruppe3 das Signal "blabber:ichbintoll" mit dem Wert 1 übergeben. Die Relaisgruppen 2 und 3 führen jetzt die zu dem Signal gehörenden Anweisungen aus - und können ihren Zustand ändern, oder eben auch selbst weitere Signale rausschicken.

Die Schnittstelle bietet als zusätzlicen Service drei verschiedene Arten an:
-Reines Signal, wie oben beschrieben
-Wertsetzen: Das Signal samt zugehörigem Wert wird zwischengepuffert in der sendenen Schnittstelle. Wird eine neue Verbindung von zu dieser Schnittstelle erstellt, sendet die Schnittstelle automatisch alle zwischengepufferten Signale ab. Genauso wird, wenn eine Verbindung zwischen zwei Schnittstellen entfernt wird, ebenfalls auf diesen Puffer zugegriffen, und die selben Signale noch mal gesendet - jetzt allerdings mit 0 als Wert. Auf diese Art wird eine Art Steckerverbindung simuliert, die zu jedem Zeitpunkt zu Laufzeit der Simulation eingesteckt/ausgesteckt werden kann
-synchroner Aufruf mit Wertrückgabe: Die beiden Varianten oben arbeiten asynchron - das Senden eines Signals blockiert nicht, sondern das Signal wird in einer Warteschlange eingereiht. Der synchrone Aufruf funktioniert nur in einer Richtung - nämlich von der "Client"-Seite zu der "Server"-Seite einer Schnittstelle. Dieser Aufruf wird nur selten benötigt.

Des weiteren gibt es ein Verschlussregister, das im Zusammenhang mit dem EZMG ebenfalls eine Rolle spielt:
Hier werden Fahrstraßen angelegt, und entsprechend definiert was was verschließt. Die Besonderheit ist, dass hier verschiedene Verschlußlevels möglich sind - was beim EZMG dann auch eine Rolle spielt. Generell fordert eine Relaisgruppe beim Verschlußregister den Verschluß einer Fahrstraße an, und bekommt dann von der Fahrstraße das Verschlußlevel zurück. Das Verschlußregister ist Vermittler und fragt wiederum bei den Einzelelementen den Verschluß an, und bekommt von den Einzelelementen das Verschlußlevel zurückgemeldet.

###### Implementierung des EZMG #######
Allgemein gilt: Ich richte mich nicht zwangsläufig danach den virtuellen Nachbau genauso aufzubauen wie das Original - ich ahme nur das Verhalten nach.
Für die Kernkomponenten des EZMG habe ich folgende Relaisgruppentypen angedacht:
-Weichengruppe (Interne Zustände: Verschlußlevel
-Fahrstraßengruppe (Interne Zustände: Verschlußlevel
-Einfahrsignalgruppe
-Ausfahrsignalgruppe

Die schwarzen Fahrstraßentasten wirken dabei auf die Fahrstraßengruppe, die farbigen Signaltasten (die ja auch die Fahrstraße festlegen) auf die Signalgruppen.

Außerdem wird ein Verschlußregister angelegt, das zum einen alle Weichengruppen enthält, zum anderen aber auch alle Fahrstraßengruppen. Bei den Fahrstraßengruppen wird im Verschlußregister jeweils ein "Verschlußstück" eingetragen, das gleichzeitige Einfahrten in das selbe Gleis verhindert. Darüber hinaus sollte auch die Gleisfreimeldung dort eingetragen werden.

Mit einem Druck auf die Fahrstraßentaste wird die Fahrstraßengruppe aktiv, und fordert vom Verschlußregister die ihm zugeordnete Fahrstraße in Level 1 an. Das Verschlußregister leitet die Anforderung an die Weichengruppen weiter. In der Weichengruppe wird überprüft, dass das Verschlußlevel <= 1 ist, und wenn das der Fall ist wird der Weichenumlauf angestoßen und das Verschlußlevel auf 0 gesetzt. Sobald die Weiche umgelaufen ist, wird an das Verschlußregister die neue Lage und das Verschlußlevel 1 gemeldet. Wenn alle Weichen in der korrekten Lage sind und Level 1 gemeldet haben, geht auch an die Fahrstraßengruppe die Meldung, dass die Fahrstraße mit Level 1 eingelaufen ist. Sobald eine der Weichen die Endlage verlässt (sei es durch Auffahren, sei es durch UMstellen auf andere Fahrstraße) meldet die Weiche das Verschlußlevel 0, und die Fahrstraßengruppe bekommt ebenfalls das Verschlußlevel 0 gemeldet, und speichert das ab.

Fahrstraßen sind wie im Original nicht gerichtet. Die Fahrstraßengruppe hat daher zwei Parameter, mit der man sie mit einer Einfahrsignalgruppe und einer Ausfahrsignalgruppe verbinden kann. Mit einer Einfahrsignalgruppe sind jetzt also mehrere Fahrtstraßengruppen verbunden. Nehmen wir jetzt mal an, der Bediener drückt die grüne Taste für die Einfahrzugstraße. Die Einfahrzugstraßengruppe sendet daraufhin an alle Fahrstraßengruppen das Signal, dass die Einfahrzugstraße eingestellt werden soll - es reagiert darauf aber nur die Gruppe, die das Verschlußlevel 1 hat.

Diese Gruppe fordert jetzt vom Verschlußregister ein höheres Level an - und hier unterscheiden sich jetzt Einfahrzugstraße und Ausfahrzugstraße und Rangierstraßen.
Für die Rangierstraße wird Level 2 für Fahrtrichtung Strecke, Level 3 für Fahrtrichtung Bahnhof verwendet, für die Ausfahrzugstraßen Level 4 und für die Einfahrzugstraßen Level 5.
Die Gleisfreimeldung wird dabei nur bei Level 4 und 5 berücksichtigt, der Ausschluß von anderen Fahrstraßen nur bei Level 3 und 5. Hier bin ich mir allerdings noch nicht ganz ganz sicher ob das Level 3 so funktioniert - ich habe das Verschlußregister nämlich unter der Voraussetzung Programmiert, dass ein höheres Level bedeutet, dass alles was in einem niedrigeren Level gesichert ist auch im höheren gesichert wird - ggf. ist hier noch eine kleine Anpassung nötig.

Das Verschlußlevel wird jeweils in den Weichen gespeichert, und so ein Einstellen einer anderen Fahrstraße verhindert.

###### Schlußwort ######
Ich habe vor das EZMG auf jeden Fall umzusetzen - der Aufwand dürfte sich sehr in Grenzen halten, und ich mag die EZMGs eigentlich recht gern. Allerdings - momentan arbeite ich wie gesagt an den Editoren, die das Erstellen neuer Bauformen vereinfachen sollen, deswegen ist das vorerst zurückgestellt. Wie lange es dauert den Editor fertigzustellen weiß ich noch nicht, das kann durchaus jetzt noch zwei oder drei Monate dauern - die Arbeit ist zwar nicht unbedingt kompliziert, aber leider ziemlich zäh, da habe ich grade etwas Motivationsprobleme :-)
Außerdem stellen sich bei der Arbeit am Editor auch Schwachpunkte am Grundkonzept heraus, die behoben werden müssen, und teilweise habe ich auch neue Ideen, die auch UMbauten an der Simulation verlangen. Wie lange das dauert, kann ich momentan nicht vorhersagen - und ich bin auch etwas unzufrieden mit dem Editor selber, der ist viel zu komplex und unübersichtlich - aber da dieser wahrscheinlich nur von wenigen Personen (u.U. sogar nur von mir - wobei ich den schon öffentlich zugänglich mache) genutzt wird, liegt das Hauptaugenmerk halt nicht unbedingt auf intuitiver Bedienung.

Ich habe ja schon länger nichts mehr geschrieben, so dass es vermutlich mal Zeit für eine Aktualisierung wird.

In letzter Zeit gibt es nicht so viel wirklich interessantes zu berichten, zum einen, weil ich etwas Zeitmangel hatte, zum anderen, weil viel Arbeit unter der Haube zu erledigen war, die einfach für die Zukunft nötig wurde.

Trotzdem tut sich inzwischen einiges. Sehr erfreulich ist schon mal, dass sich inzwischen zwei Leute gefunden haben, die beim Erstellen neuer Stellwerksbauformen mithelfen. Veröffentlichbares ist da noch nicht dabei, aber das was es bisher schon gibt sieht schon sehr vielversprechend aus - und zeigt, dass das Konzept der Trennung zwischen Kernprogramm und stellwerksbezogenen Skripten/Oberflächengrafiken sich bewährt.

Auch wenn es mir unverständlich ist, wie man es schafft, ohne Anleitung mit den grauenhaften Editoren von StellSi zu arbeiten, habe ich von jemand andere auch schon einen ordentlichen Satz SuH1912er-Stellwerke erhalten, die nach Gleisplänen aus dem Berliner Raum erstellt werden, wobei die Stellwerke selbst mangels Daten leider nicht dem Original entsprechen. Des weiteren ist ein Stellwerk aus dem Hamburger Raum mit ein paar Besonderheiten in Arbeit, das wirklich genial aussieht.

Mit mechanischen Stellwerken tut sich momentan noch nichts - aus dem einfachen Grund, dass ich mich nicht in der Lage fühle, entsprechend gutaussehende Hebel zu zeichnen.

Des weiteren gibt es inzwischen auch Töne, wobei das noch mehr provisorisch ist, und weiter ausgebaut werden muss. Momentan in Vorbereitung ist Rangieren, was gerade bei mechanischen Stellwerken den Betrieb vermutlich deutlich interessanter machen dürfte.

Wann es wieder eine öffentliche Version geben wird weiß ich noch nicht, es fehlen doch noch einige Sachen, die ich da noch gern mit drin hätte. Ich hoffe aber, in absehbarer Zeit eine Version herauszubringen, wo es dann auch erste sinnvoll spielbare Stellwerke geben wird.

*jubel*

Ich freu mich drauf, was neues zu sehen.

...eine Seite vorher gab es doch einen guten Entwurf von Christopher Spies.



Gruß
Christian

_________________
E-Mail: wietzoreck@web.de

http://www.facebook.com/groups/zechen.und.zechenbahnen

Ja, aber ein Weichenhebel ergibt noch kein vollständiges Stellwerk :-)

Seit März hört man nichts mehr vom Zusi 3 Stellwerk. Sicherlich wird sich in der langen Zeit viel getan haben, daher die Frage was gibt es neues zu berichten?

März 2013 :-)

Puh... :-)

Also generell - dass das Konzept von StellSi (was ja nur eine Möglichkeit für Zusi3-Stellwerke ist, gab oder gibt ja auch noch andere Projekte) funktioniert, sieht man daran, dass es inzwischen über 100 Stellwerke gibt, die basierend auf dem SuH1912 erstellt wurden. Das sind allerdings relativ einfach aufgebaute Stellwerke. Nähere Informationen gibt es auf der Homepage von StellSi, es empfiehlt sich dabei insbesondere auch in das Forum in den Downloadbereich zu schauen.

Große Flexibilität ist aus Sicht der Entwicklungszeit aber auch ein Fluch - das erschwert natürlich einiges auch deutlich, was viel Zeit kostet.

Vom eigentlichen Programm her hat sich in letzter Zeit nicht viel getan, was man groß ankündigen kann - wir machen aber zahlreiche Umbauten im Hintergrund, die für die Zukunftsfähigkeit wichtig sind. Damit haben wir momentan zwei Entwicklungsstränge, der große Umbau-Branch dürfte wohl vor über einem Jahr abgespalten worden sein, ist aktuell aber (noch) nicht verwendbar, weil die komplette Außenanlage neu programmiert wurde.

Ich selber hatte leider in letzter Zeit wegen der Diplomarbeit nur wenig Zeit, hoffe jetzt dann aber wieder mehr Zeit für die Simulation zu finden.

Bei der Anbindung an Zusi gibt es aktuell nicht viel neues - die Anbindung von Stellwerksimulationen hat aktuell einfach von Zusi-Seite her keine Priorität. Da wird es natürlich frühestens weitergehen, wenn die erste Vollversion von Zusi 3 soweit läuft.

Gibt es Neuigkeiten über die Anbindung von Stellsi mit Zusi 3?

_________________
Gruß Auel

Hallo Auel,

noch nicht, es ist aber weiterhin konkret geplant, und wir von StellSi stehen mit Carsten deswegen auch immer mal wieder in Kontakt - wie jetzt dann auch beim Zusitreffen. Also kommen wird es definitiv, aber gut Ding will Weile haben, zumal es sicherlich auch noch einige größere Probleme zu überwinden gibt.

Grüße
Boris

Alles klar, klingt schon mal ganz gut.
Ist auch schon bekannt welche Funktionen es später mal haben wird z.B. Kommunikation zwischen Zusi Tf und Stellsi Fdl,... ?

_________________
Gruß Auel

Nein, das ist noch nicht bekannt, bei unseren Diskussionen am Zusitreff ging es jetzt mehr um grundlegende Fragen, zum Beispiel das Thema was passiert, wenn der Stellwerkssimulations-Fdl aus welchem Grund auch immer aus dem Spiel fällt (Laptopakku leer, Netzwerkverbindung ausgefallen, Eltern haben den Stecker des PC gezogen, ... ), oder umgekehrt, was passiert wenn ein Stellwerkssimulations-Fdl neu in das Spiel kommt, und das Stellwerk von Zusi übernimmt. Andere Themen sind zum Beispiel wie ein Signal in Zusi angesteuert werden kann (Auswahl der richtigen Kombination in der Signalmatrix) etc.

Ab jetzt mal meine persönlichen Gedanken zu dem Thema:

Eine Kommunikation zwischen dem Spieler in Zusi und dem Spieler der Stellwerksimulation wird es sicherlich geben müssen, spätestens wenn Befehle erteilt werden müssen geht es ohne Kommunikation ja nicht mehr. Eine textbasierte Kommunikation würde ich von unserer Seite her jetzt auch mal als sinnvoll betrachten, z.B. für die Nachricht "dauert noch etwas". Am schönsten wäre es natürlich wenn man eine Sprachkommunikation hinbekommen würde, wobei das gleiche auch ja auch bei Netzwerkspiel in StellSi ohne Zusi interessant wäre. Technisch ist das auch gar nicht so das Problem, die Frage ist vorallem auf welchem Weg die Sprachdaten von dem einen Spieler zum anderen kommen.

Für Sprachkommunikation gibt es genauso wie für das eigentliche Netzwerkspiel verschiedene Möglichkeiten:
1) Jeder Spieler richtet sich eine Portfreigabe ein, die Programme der Spieler kommunizieren ohne Server direkt.
2) Es gibt einen wie auch immer gearteten zentralen Server, der im wesentlichen Vermittlungsaufgaben übernimmt. Keine Portfreigabe nötig. Über ein Holepunching-Verfahren, das über den zentralen Server vermittelt wird, werden direkte Kommunikationskanäle zwischen den Spielern erstellt, so dass die Kommunikation zwischen den Spielern ohne Serverbeteiligung abläuft.
3) Alle Nachrichten gehen über einen zentralen Server

Variante 1) sehe ich etwas kritisch, da Einstellungen am Router etc. für manche technisch nicht so versierte Nutzer u.U. ein Hindernis darstellen. Diese Variante ist aus Entwicklungssicht aber vermutlich die einfachste.
Variante 2) wäre evtl. möglich, die Frage ist halt ob man das Holepunching einsetzen will und kann.
Variante 3) ist für den Spieler die bequemste, hat aber den Nachteil dass man einen Server benötigt, und u.U. einiges an TRaffic auftreten kann bei der Sprachkommunikation, das müsste man mal abschätzen wie problematisch das wirklich ist. Außerdem muss ein zentraler Server gewartet werden, muss sehr sicher gegenüber Hackerangriffen ausgeführt sein etc.

Die Frage wäre auch, ob man unbedingt selber das Rad neu erfinden muss. Fürs erste würde es sicherlich reichen, wenn man Skype, Teamspeak, Mumble oder was auch immer hernimmt. Die haben auch Erfahrung darin, sich durch eine Firewall zu tunneln. Das ist dann zwar nicht die perfekte Zugfunk-Simulation, aber zumindest eine in anderen Multiplayer-Spielen tausendfach erprobte Technologie.

_________________
Wie baut man Zusi3-Addons? - Mein Youtube-Kanal: youtube.com/echoray1

Die Grundfrage ist halt was geeignet ist. Ich bin jetzt kein Computerspieler, daher fehlen mir die praktischen Erfahrungen, hatte Teamspeak jetzt aber doch eher als Telefonkonferenzsoftware verstanden, wo ein Team gemeinsam spricht?

Die Anforderung bei Eisenbahnsimulationen ist ja eher, dass man selektiv zu wechselnden Gesprächspartnern eine Verbindung aufbaut. Skype wäre aus Entwicklungssicht natürlich das angenehmste, weil die Serverfrage damit gelöst ist. Aber nehmen wir an, wir haben (im Luxusausbau des Multiplayerspiels) 10 Lokführer und 10 Fahrdienstleiter im Spiel, dann muss jeder Fahrdienstleiter mindestens jeden Lokführer und jeden Nachbarfahrdienstleiter in seiner Kontaktliste haben. Um eine Verbindung aufzubauen muss er erstmal herausfinden, welcher Skypename zu der Zugnummer gehört, die er erreichen möchte. Beim Zusispieler bimmelt dann Skype, also muss Zusi verlassen werden um abzunehmen. Während Skype benutzt wird muss aber gleichzeitig (sofern der Zug noch fährt) die Sifa bedient werden, da eine Pausenfunktion bei Multiplayer natürlich nicht möglich ist. Sofern ich da nicht noch eine hilfreiche Skypefunktion übersehen habe halte ich Skype daher leider für nicht so wirklich geeignet, zumindest nicht wenn man das Szenario "mehrere Leute die sich nicht kennen spielen gemeinsam eine Stellwerksimulation", was zumindest für StellSi durchaus ein relevantes Anwendungsszenario ist.

Damit eine telefonische Kommunikation wirklich klappt braucht es in meinen Augen eine gewisse Unterstützung durch die Simulation selbst. Das Problem kann man ja bei stellwerksim.de beobachten - hier gibt es mit Stitz ein eigenes Kommunikationssystem, für das man sich aber gesondert registrieren muss, und bei dem das eigentliche Programm extern läuft. Genutzt wird es wenig, was vermutlich anders wäre, wenn man nur auf "Anrufen" klicken müsste, und der Rest läuft automatisch.
Integration heißt ja nicht zwingend das Rad neu erfinden, eine Fernsteuerbarkeit eines parallel laufenden Voip-Clients oder eine Einbindung einer Library mit einigermaßen sinnvoller API durch die Simulation würde ja schon ausreichen.

Am interessantesten finde ich daher Mumble, bin nur leider bisher noch nicht dazu gekommen mir das näher anzusehen. Durch die angenehme Lizenz der Grundsoftware (BSD, wobei man da aufpassen muss, weil manche Libraries unter anderer Lizenz stehen oder sogar mit Patenten behaftet sind) ist es potentiell schon mal ein vermutlich relativ aussichtsreicher Kandidat für eine spätere Integration, und soweit ich das bisher überblicke ist das auch als sehr offenes System gestaltet. Sofern von den oben genannten Linzenzproblemen her möglich wäre z.B. die libmumble hier möglicherweise interessant näher anzusehen.

Und ja, mir ist schon bewusst, dass vor einer integrierten VoIP-Kommunikation noch genug andere wichtigere Aufgaben anstehen, die äußerst herausfordernd sind, deswegen wird VoIP sicherlich nicht an erster Stelle stehen, und ob so etwas in Zusi überhaupt je Thema wird kann ich natürlich auch nicht sagen. Zumindest in StellSi selber (das ja auch als Standalone-Stellwerksimulation betrieben werden kann) halte ich es für die Kommunikation mit Nachbarfahrdienstleitern aber durchaus für ein nicht ganz unwichtiges Feature in der weiteren Zukunft.
Die Gedanken über die verschiedenen Arten der Kommunikation (Direkt per Portforwarding/IP-Adresseingabe der Mitspieler, Direkt aber über Serververmittlung/Holepunching, oder über zentralen Server) stellen sich aber ja nicht nur bei der Audiokommunikation, sondern auch für das ganz normale Netzwerkspiel.

Habt ihr euch mal VatSim angeschaut? Ist zwar eigentlich für den Funk in Flugsimulatoren gedacht, aber ermöglicht auch die Kommunikation über Kanäle (Frequenzen), einzeln sowie auch gruppenweise. Funktioniert seit Jahren tadellos mit diversen Clienten, die dann im Hintergrund laufen. Wenn ich mich recht entsinne ist das ganze auch öffentlich dokumentiert, ansonsten könnt ihr auch die Jungs vom Swift (Open Source Pilot Client) fragen, da gibt's auch ein paar deutsche Stimmen im Team.

Danke für den Hinweis, werde ich mir falls es mal so weit ist mal ansehen.

Kommunikation per Sprache wird in der Prioritätenliste aber sicherlich nicht allzu weit oben stehen, das ist ja mehr ein "nett zu haben".