Kerbal Mission Control - A new KSP Multiplayer (früher: KSPControl)

Ich möchte mich mit einer nicht ganz so kleinen Idee ins Forum zurückmelden.

Vielleicht kennen ein paar von euch den Artemis Spaceship Bridge Simulator. Grunprinzip ist einfach: Ihr steuert ein Raumschiff. Clue dabei ist, dass jeder Spieler eine andere Station auf selbigen Raumschiff besetzt und alle eng zusammenarbeiten müssen damit es klappt.

Ich habe vor auf Basis des Mods kRPC etwas ähnliches zu entwickeln. Der Mod ermöglicht es sehr einfach von verschiedenen Programmiersprachen aus direkt auf KSP zuzugreifen. Idee ist dabei, dass verschiedene Personen verschiedene Informationen von der Rakete bekommen und auch verschiedene Steuerungsmöglichkeiten haben.

So hat der Steuermann Zugriff auf den Navball und die Steuerung der Rakete, während ein Techniker Solarpanele, Batterien, Lichter, Generatoren und Landestützen.

Spieltechnische Umsetzung
Umgesetzt wird das ganze über ein Modulares System basierend auf Roles und Panels.
Ein Panel ist dabei eine Ansammlung von Anzeigen und Kontrollen. So kann es ein Panel mit dem Navball oder ein Panel für die Actiongroups geben. Diese Panel werden dann den entsprechenden Rollen zugewiesen, können aber individuell angepasst werden. So sind Mischrollen oder komplett neue Rollen möglich (oder man packt alle Controls in eine Rolle und hat ein völlig überladendes Fenster um KSP zu steuern)

Teschnische Umsetzung

Zentrales Element der Umsetzung wird ein sogenannter MQ-Server (Messagequeing) sein. Der Server erhält über kRPC alle wichtigen Daten und schreibt diese in die verschiedenen Kanäle des MQ-Servers. Die Clients melden beim MQ-Server Interesse an den für ihre Kontrollen benötigten Kanäle an (genauere Ausarbeitung folgt) und erhalten dadurch alle Infos die sie brauchen. Ihrerseits können sie Kontrollanweisungen in einen speziellen Command-Kanal schreiben welcher vom Server ausgelesen und über kRPC an KSP zurückgegeben wird.

Bisheriger Plan für die ersten Versionen ist eine reine Anzeige wichtiger Informationen sowie grundlegende Strukturen sein. Im weiteren werden dann weitere und komplexere Panels dazu kommen.

TODO

• Auswahl eines geeigneteten Embeded MQ Servers
• Testen von kRPC und dem Datenempfang
• Einrichten des MQ Servers
• Erstellen der grundsätzlichen Struktur für Server und Client.
• Erstellen erster Panels für Informationsanzeige
• Erstellen erster Kontrollpanels

Zitat von Mr. Maxwell

Auch Java?

Interessant dass du es ansprichst, weil ich hatte vor das ganze in Java zu schreiben. kRPC bietet Libaries in Java, C#, C++ und Python an. Theoretisch kann man mit jeder RPC fähigen Programmiersprache darauf zugreifen

Zitat von Mr. Maxwell

Wie sieht es im Konstruktionsmodus aus?
Ist es möglich sich dort die Aufgaben auch aufzuteilen?
So das z.B. ein Spieler das Servicemodul, ein Andere den Lander und wieder ein Anderer Spieler die Rakete baut?

Das geht mit kRPC leider nicht, da es keine Spiele miteinander verbindet sondern lediglich Befehle von außerhalb an KSP weitergibt. Man könnte sich das Vehicle Sharing von DMP anschauen.

Zitat von Mr. Maxwell

Das ist ja Super, dann kann ich mit Java auch bisschen daran rumschnipseln.

Hilfe ist natürlich immer gerne gesehen

Zitat von Thomas P.

Klingt cool, würde mich auf jeden Fall interessieren.

Und auch schön, dass das Projekt Anklang findet.

Ein erstes kleines Update:
Zum einen ist das ganze schon etwas schärfer geworden. Ich werde den ZeroMQ Server als Embedded MQ Service nutzen um die Kommunikation zwischen Server, Clients und KSP sicherzustellen. Desweiteren kommt GSON als Libary zum Einsatz um die KSP Daten zum Client zu transferieren.

Als ersten Test habe ich mit kRPC die Fluginformationen ausgelesen und einfach mal per Java Reflection in ein Fenster geworfen. Dazu kommt ein wenig Statistik in den ersten beiden Zeilen darüber wie oft ich dieses Fenster updaten kann.

Die Zahlen wurden einfach aus dem Objekt gelesen, mit einem Namen versehen und an einen String gehängt welcher dann ins Fenster projiziert wird. Also keine große Formatierung im Hintergrund und ich bin soweit mit Average Ops zufrieden.

Ziel ist es am Ende 10mal pro Sekunde alle Daten in die Que hängen zu können, damit die Clients sie erhalten können.

Nachdem es etwas ruhig geworden ist kann ich jetzt nach einigen Tagen Arbeit verkünden das die erste Hälfte der Basis fast komplett steht.

Ich kann jetzt effektiv Daten aus KSP herausziehen und sie an meine Clients senden. Das wird über eine zentrale Messageque gemacht welche dann über Filter in verschiedene Kanäle aufgeteilt wird.

Bisher geplant sind die Kanäle:
Flight - Fluginformationen, größtenteils für Atmosphärenflug (Implementiert)
Orbit - Informationen über den Orbit des Fahrzeugs
Science - Informationen über alle verfügbaren Experimente
Ressource - Ressouceninformationen
Engineering - Informationen über Stromerzeugen und Verbrauch sowie den Status verschiedener Teile
Communication - Informationen über am Fahrzeug verfügbare Antennen

Für das Layout des Clients habe ich mir überlegt, dass ganze wie ein modulares Panel aufzubauen. Also besteht das komplette GUI aus einem standartisierten Raster (momentan 200 mal 200 Pixel pro Zelle) und jedes Programpannel muss sich an dieses Raster halten.

Leider sind die von Java angebotenen Layouts entweder zu starr (Box Layout) oder zu flexibel (GidBagLayout) entsprechen werde ich da wohl oder übel etwas herumbasteln müssen.

Dennoch funktioniert der Grundstock bisher sehr gut, und selbst mehrere Anwendungen welche die gleichen Infos brauchen sind kein Probleme

Sobald ich das ganze System noch etwas aufgeräumt und viele Altlasten der Entwicklung entfernt habe, werde ich den Code auch auf Github veröffentlichen.

Lang lang ist's her... Also etwas weniger als 3 Wochen. Aber es gibt Neuigkeiten.

Ich bin ein ganzes Stück weitergekommen, habe verschiedene Dinge verfeinert, das MessageSystem modernisiert und durch einen Rückkanal erweitert. Jetzt können die Clients auch Nachrichten an den Server schicken. Das ist nicht nur Grundstock für das Kontrollsystem, sondern wird später auch für zahlreiche Dinge seitens Programmtechnik verwendet (Ich denke an Dinge wie Einloggen, Rollenanfragen evt. einen Chat und ein Aktionslog)

Aber ihr habt richtig gelesen, Kontrollsystem. KSPContol ist endlich in der Lage auch Dinge zu kontrollieren. Das System ist dabei relativ einfach. Der Client sagt welchen Wert er auf was setzen will und Server sagt dann ja oder nein (Spoiler, Momentan sagt Server immer ja)
Mit diesem System kann man dann von einfachem Ausfahren von Solarpanelen bis zur analogen Joysticksteuerung theoretisch alles ermöglichen.

Ich habe es für den Anfang bei einfachen Grundfunktionen belassen um das System selber auszuarbeiten.

Spoiler anzeigen

Neben den beiden einfachen Anzeigepanels gibt es jetzt auch eine Reihe von Buttons mit denen man verschiedene Funktionen steuern kann.
Hierzu noch ein paar Anmerkungen:
1) Aus unbekannten gründen lassen sich die Beine nicht separat steuern. Wenn man jedoch die Steuerung für Gear benutzt fahren auch die Beine ein und aus
2) Mir ist wohl bekannt, dass das GUI noch einige Probleme hat, Verschobene Texte, nicht richtig ausgerichtete Gitterelemente. Darum werde ich mich jedoch später kümmern

Und am Ende noch die Antwort auf eine Frage die ich mir selbst gestellt habe.
Wie sieht es jetzt eigentlich mit Verbindungen aus?

Zum jetzigen Zeitpunkt sieht es wie folgt aus:
Der Computer auf welchem auch KSP ausgeführt wird muss die Serversoftware gestartet haben. Das möchte ich ungern ändern, da die Serversoftware selber kaum Performance verbraucht und man dadurch später über die Serversoftware auch verschiedene Dinge einstellen oder Dinge wie einzelne Spieler für die Kontrollen zu sperren durchführen kann.

Problem dabei: Wenn man über das Internet spielen will, muss der Server ins Internet sichtbar sein oder eine VPN Software wie Hamachi ist nötig. Ungünstig.
Da kommt jedoch wieder eine Stärke der Message Infrastruktur zum Vorschein. Ich arbeite nebenbei daran einen sogenannten Message Proxy zu entwickeln. Diesen kann man dann auf einem externen Server laufen lassen und er macht nichts anderes als Nachrichten von Client und Serverseite entgegenzunehmen und weiterzuleiten.

Von Parts und der 0.40

Jetzt mit Titel!

So, ich versuche euch jetzt ungefähr Wöchentlich auf dem laufenden zu halten was gerade passiert und in der letzten Woche ist einiges Passiert:

Fangen wir an mit Parts. Das Partproblem hatte ich schon eine ganze Zeit. Warum Problem? Einfache Sache: kRPC hat keine Möglichkeit einen Part eindeutig zu identifizieren. Es gibt defacto momentan keinerlei eindeutige ID auf einem Vessel.
Also wenn es etwas nicht gibt: Selbermachen. KSP hat nämlich so eine ID in form der Part.FlightID. Was ich also machen musste war eine Möglichkeit zu finden an diese ID von außen heranzukommen, der Plan war einfach:
Ein Partmodul entwickeln das nichts anderes macht als beim ersten initialisieren die FlightID des Parts in ein Modulfeld zu schreiben. Einfacher gesagt als getan.
Nachdem ich dann etwas über eine Stunde versucht habe die KSP Libaries in Visual Studio ans laufen zu bringen und es endlich geschafft hatte dauerte die eigentliche Entwicklung etwa 20 Minuten. Am Ende noch einen ModuleManager Patch, der das Modul einfach an jeden Part ranklebt den KSP zu bieten hat und voilà, eine PartID, öffentlich verfügbar.

Dann muste ich noch einmal fast alle Datenklassen umschreiben damit ich die Parts ordentlich verwalten und initialisieren kann. Punkt ist: Es geht

Also, erster Teil des Titels abgeschlossen, auf zu Nummer Zwei: Während ich am entwickeln war wurde insgeheim kRPC Version 0.40 released, welche nicht nur die Kompatibilität mit 1.3.1 herstellt (mir war jetzt kein Punkt im Changelog bekannt der das nötig machen würde, aber okay) und ein paar nette neue Features ermöglicht, welche zum momentanen Zeitpunkt mein Programm richtung Nirvana schicken. Also downgrade auf die 0.39 und kein offizieller Support für die 1.3.1. Vielleicht schaue ich mir das ganze nochmal zu einem späteren Zeitpunkt an, aber momentan Stand ist folgender: KSPControl Version 1.0 wir nicht für die Version KSP 1.3.1 herauskommen und auch nicht kRPC V0.40 unterstützen!

Edit: Das Ding mit dem FX
Es ist etwas passiert!
Oder um genauer zu sein, ich habe erfahren das mit Java8 Swing als Standard für Desktopentwicklungen abgelöst wird. Ich lese mich gerade in den Nachfolger aka. JavaFX ein und es sieht gar nicht so schlecht aus. Daher werde ich schauen ob ich den Client auf JavaFX umstelle, was zum Beispiel das erstellen eines eigene UI Designs deutlich einfacher macht (und sind wir ehrlich... das Standard design sieht halt bescheiden aus)

Lang ist her und unter neuem Namen
Lange ist es und ich konnte mein Versprechen der Wöchentlichen Updates direkt nachdem ich es gemacht habe nicht halten. Grunde dafür sind einfach: Ich war eine Woche in Cardif, Wales unterwegs und bin danach Kopfüber in das Oberstufenprojekt meiner Berufsschule geschmissen worden, was mich wieder 2 Wochen gefesselt hat. Nun ist Ende November und seit letztem Mal kann ich keine Neuerungen angeben.
Dieser Zustand wird auch erst mal weiter Bestehen, da ich Anfang Dezember umziehe und danach schon Weihnachten vor der Tür steht. Daher werde ich wohl dieses Jahr nicht mehr dazu kommen große Änderungen am Programm zu machen.

Aber als kleine Ankündigung, damit der Post hier nur schlechte Nachrichten sind.
Der Name KSPControl ist mir spontan eingefallen und hat mir die ganze Zeit die ich daran gearbeitet habe nicht wirklich gefallen. Daher musste ein neuer Name her und dank ein paar Vorschläge, sowie meiner eigene Intuition ist es jetzt Offiziell.
KSPControl wird unter dem Namen Kerbal Mission Control oder KMC erscheinen
Grund für diesen Namen ist, dass der Spielaufbau wie ich ihn mir vorstelle mich stark an das tatsächliche Mission Control der NASA erinnert. Daher, Name genommen, Kerbal drangeklatscht und fertig ist das Branding.

Tari Tara, Lassen wir den Unsinn
Über 2 Monate hat ein Update auf sich Warten lassen. Aber das Projekt ist nicht tot. Dank Umzug, Weihnachten, Neujahr und einem gehörigem batzen Stress auf der Arbeit bin ich weder im Dezember noch im Januar zu irgendwas gekommen, aber nun kann ich euch die die Fortschritte des JavaFX Umstiegs präsentieren. Ich bin inzwichen mit dem neuen Client an einem Punkt angekommen wo der alte aufgehört hat und sogar etwas weiter.

Es fehlt noch alles an Design, das ganze ist etwas Kahl und es gibt noch kleinere Bugs, aber immerhin schon ordentlich Funktionalität.

Es gibt inzwischen Kontroll und Anzeige Panels, alles funktionstüchtig.
Die Panels lassen sich auf der Oberfläche verschieben (Leider auch übereinander)
Über ein einklappbares Seitenpanel, lassen sich neue Elemente auf die Oberfläche hinzufügen

Spoiler anzeigen

Ich suche Designer für das Programm
Auch wenn das Programm noch einige Dinge nicht beinhaltet wäre es schön jemanden zu finden, der mit mit dem Design helfen kann.
Der Vorteil an JavaFX ist, dass es CSS als Stylesprache benutzt, daher sollte es für einen Webdesigner kein größeres Problem sein sich daran zu gewöhnen.

Also, wie sieht das ToDo jetzt aus?
Hohe Priorität

• Verhindern, dass sich Panels überlappen
• Parts implmenentieren
• Update auf neuste Version

Mittlere Priorität

• Eingabe der Server IP beim Programmstart (bisher ist diese Fest im Programm hinterlegt)
• Neue Panels einbauen

Niedrige Priorität

• Unterschiedliche Sprachen unterstützen
• Panelconfigurationen speichern und laden
• Spielen über einen dedizierten Server ermöglichen
• Design verbessern

Zitat von funkheld

Hört sich gut an.
Kannst du mal bitte eine erste Demo hier reinstellen?

Ich mache versuche mit Python und krPC.
Weil das Python dort die tiefste Schnittstelle hat im krPC.
Die anderen dort angebotenen Sprachen sind nicht so intensiv.
Ich als Anfänger habe mich schnell mit Python und krPC angefreundet.

Danke.
Gruss

Alles anzeigen

Ich kann mal versuchen eine lauffähige Version zu kompilieren. Kann aber momentan durch die Anzahl an Libaries noch keine Versprechen machen, dass ich es dieses Wochenende schaffe

Zitat von funkheld

Habe jetzt auch mal dieses krPC mit 4 Servern geöffnet um wie bei Artemis 4 Räume zu simulieren von wo aus verschiedne Systeme der Rakete gesteuert und überwacht werden.
Habe erstmal 1 Purebasicprogramm mit 4 Clienten erstellt um das zusammenspiel selber einmal zu kontrollieren.

Habe 4 Pythonprogramme , für jeden Raum 1 erstellt . jedes Pythonprogramm hat immer nur ein TCP-Server für die Verbindung nach Purebasic und 1 Clienten zur Verbindung nach den krPC-Server. Die Pythonprogramme sind sehr klein und sehr Leistungsfähig im Netzwerk.
Die Fehlersuche ist spielerisch einfach, sogar für mich als Anfänger und man braucht sich bei den Einzelprogrammen nicht mit Threads herumärgern, die doch beim Netzwerkbetrieb die Nerven rauben können.

Der krPC-Server-1 sendet/empfängt zum Python-Client-1 und der Python-Server-1 im gleichen Pythonprogramm hat Verdindung zum Purebasic-Client-1 wo er die Daten hinsendet oder von wo er auch die Daten bekommt.

Das Purebasicprogramm ist der Hauptbildschirm, wo die Daten dann Spielerisch mit einer schönen Grafik dargestellt werden von den 4 Raketenräumen..
Die Leistung von Purebasic schafft es sogar leicht alle 4 Clienten super schnell zu bedienen.

Wenn einer dieses Freebasic nimmt kommt er wahrscheinlich auch zum Ziel.

In C++ oder C oder Jave würde ich so etwas es nicht schaffen.

Gruss

Alles anzeigen

Schön zu hören, dass es dir so einfach gefallen ist. Ich habe mich gegen Python entschieden, da ich schlicht mit Java besser klar komme und mehr Erfahrung habe. Auch finde ich die Java Client-Libary eigentlich Umfangreich genug.

Von Fehlersuche kann ich dir ein Lied singen. Inzwischen läuft das Programm über mehrere Zwischenmodule, einige davon Asynchron oder über tiefere Funktionen im Java Framework. Da wird es teilweise schon happig einen bestimmten Datensatz zu verfolgen.