Beiträge von Chase

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.

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

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.

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 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.

Also, ich habe gerade mal etwas nachgeschaut.

Genereller Konsens ist: Vorsicht ist geboten. Als Käufer kann man sich kaum strafbar machen. Was jedoch passieren kann ist das der Key oder sogar der Steam Account gesperrt wird. Bei großen Preisunterschieden sollte man vorsichtig sein (Was hier der Fall ist)

Daher würde ich Allans Vorschlagen und auf den Herbstsale warten.

Quellen:
http://www.gamestar.de/artikel…d-keyselling,3083223.html
(Hierbei ist zu beachten das GameStar einen Werbedeal mit MMOGA, einem Keyshop, hat und daher eventuell nicht daran interessiert ist Keyshops negativ zu bewerten. Das ist jedoch bereits am Anfang des Artikels ausgewiesen)

http://www.pcgameshardware.de/…r-im-Rechtstest-885809/5/

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.

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.

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.

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

@Troll Man kann entweder eine Tinkers Construction smeltery (auch automatisiert) nutzen oder man baut eine Anlage wo man Ore auf der einen Seite reinschmeißt und auf der anderen Seite die doppelte Menge an Ingots rauskommt (Leider haben wir kein Mekanism, sonst könnten wir das Zeug sogar verfünfachen)

Wegen der Lava können wir an anderes Projekt angehen, eine Pumpstation.

Folgendes: Man baue eine Pumpstation im Nether, welche da Lavaseen leerpumpt und die Lava in ein Teleporterpipe (oder Endertank) Pump, das teleportiert die Lava an die Oberfläche wo wir das eig in einen großen Tank im Dorf pumpen können. Von da aus, kann man dann Rohre zu den Schmelzöfen legen.
Energie können wir per Tessaract in den Nether bringen, dann lasten wir unsere Reaktoren auch mal ordentlich aus.

Da muss ich Idel zustimmen. In FTB-Infinity gehen dir eigentlich nie die Sachen zu tun aus. Man kann den technischen Weg gehen und Fabriken, Farmen und Lagersysteme entwerfen, man kann sich mit den 4 verschiedenen (sehr umfangreichen) Magiemods Thaumcraft, Blood Magic, Botania oder Witchery befassen, welche allesammt schonmal viele Stunden an Spielzeit erfordern. Man kann mit RFDimensions rumspielen und komplett neue Welten erschaffen oder man tötet den Enderdragon und fängt mit dem riesigen Draconic Evolution Pack an um zum mächtigsten Krieger des Servers zu werden.

Aber eine Anmerkung zum Server direkt:

Ich bin ehrlich gesagt dafür, dass wir versuchen den BigReactor, der gestern fertiggestellt wurde, abschalten und nur noch als Notversorgung behalten sobald der IC2 Reaktor läuft. Es ist eine heiden Arbeit so ein Teil zum Laufen zu bringen und ich finde wir könnten die Arbeit ehren indem wir den erzeugten Strom auch benutzen, den so praktisch BigReactors auch ist, es steckt nicht viel Arbeit hinter dem Bau und dem Betrieb eines solchen Reactors, vom Ressourcensammeln abgesehen.

@KCST Funktioniert aber fast gleich

Außerdem: Irgendwo weit von mir weg. Ich bin ein Naturverbundener Spieler

Von: Ceo@KerbAI.k
An: DasSchiff3@Jebbach.ag
Betreff: RE - Konstruktionsauftrag Trägerrakete
[hr]

Sehr geehrter Herr DasSchiff3,

Ich hoffe, dass ihre IT-Systeme bald wieder lauffähig sind und es keine allzugroßen Probleme bereitet. Desweiteren möchte ich ihnen Mitteilen, dass diese Verzögerung keine Änderung auf unserer Seite benötigt. Das Projekt befindet sich noch in einer frühen Konzeptionsphase, weswegen die Trägerraketen noch kein wichtiger Bestandteil des Projektverlaufs sind.

Mit freundlichen Grüßen,
Chase Kerman,
CEO KerbAI Inc.

Ich wäre einem FTB Server gar nicht so abgeneigt. Allerdings muss ich Allan zustimmen. Mobs sind, besonders im späteren Spiel absolut kein Problem mehr. Wenn man eine funktionierende Gemeinschaft ist, ist es wirklich einfach eine Stadtmauer zu bauen und ein großes Gebiet Mobfrei zu machen.

Sehr geehrter Herr DasSchiff3,

Für unser neues Projekt, das Kerbal Emergency Communication Network, benötigen wir noch eine zuverlässige Trägerrakete, welche die geplanten Sateliten in einen hohen Orbit transportieren können. Die genaueren Spezifikationen finden sie im Anhang. Wir würden uns freuen ein entsprechendes Angebot von ihnen zu erhalten.

Mit freundlichen Grüßen,
Chase Kerman,
CEO KerbAI Inc.

Anhänge: Spezifikationen.txt

KerbAI meldet sich zurück

Nachdem sich die KerbAI Inc. fürs erste aus der Öffentlichkeit zurückgezogen hat um an verschiedenen Projekten zu arbeiten (und um seinen PR-Manager zu feuern)

Jedoch gibt es keine schönen Nachrichten. Die anhaltenen Spannungen zwischen der Inselkette und dem Festland im Zuge der Kanama-Kriese zwingen auch KerbAI zum handeln. Die Geschäftsführung distanziert sich entschieden von jeder kriegerischen Handlung und ruft die Regierungen zur Besinnung.

"Ein Krieg würde nicht nur den Wirtschaften beider Länder empfindlich schaden, sondern auch eine Katastrophe für das Kebaltum und die kerbelsche Raumfahrt bedeuten", erklärte CEO Chase Kerman während einer Pressekonferenz. Auch wies CEO Chase alle Vorfürfe ab, nach denen KerbAI geheime Waffenprogramme für die Regierung betriebe. "Die einzigen Waffen in meinem Unternehmen sind die Kervguns in der IT und die Mitarbeiter des Ingenieurwesens"

Da ein ausgewachsener Krieg jedoch nicht mehr ausgeschlossen werden kann hat KerbAI beschlossen eigene Vorbereitungen zu treffen. In einem Treffen mit den großen Hilfsorganisationen Kalteser und dem KRK wurde das Vorgehen im Kriegsfall diskutiert und wie die Zivilbevölkerung effektiv geschützt werden kann. Dazu erklärte KerbAI die Erarbeitung zahlreicher neuer Projekte für unbenannte Hilfsfahrzeuge um Güter in umkämpfte Gebiete zu bringen. Die Fahrzeuge sollen, ganz nach Philosophie des Unternehmens, unbewaffnet und autonom aggieren und unter dem Schutz der Kerbagener Konferenz stehen.

Ich habe einen Fehler beim Auflisten der Eigenschaften gemacht. Der FL-T400 hat 180l Liquid Fuel und 220l Liquid Oxygen. Das scheine ich irgendwie verdreht zu haben. Aber die Rechnung ist ja richtig.

Die Erdbeschleunigung ist nur einberechnet da beim Angeben des spezifischen Impuls sie im amerikanischen System herausgerechnet werden. Damit man wieder die ordentlichen Werte erhält muss man sie wieder dazu rechnen. Also das G in der Formel, kommt von der Art wie der spezifische Impuls (ISP) berechnet wird und hat nichts direkt mit der Formel zu tun.

Ich werde das ganze nochmal durchrechnen um zu schauen, dass ich wirklich keine Fehler drin habe.

Edit:
Ich habe das ganze mal nachgestellt. Zum einen ist mir aufgefallen, dass ich die falsche Excel-Funktion genutzt habe (es war zu dem Zeitpunkt das beste was ich hatte), aber selbst mit der richtigen Log Funktion (diesmal von C#) komme ich auf 2 unterschiedliche Ergebnisse.

Da ich diesmal dein Ergebnis als Probe hatte bin ich mir sicher, dass der Code deiner Gleichung richtig ist.

Hier das Ergebnis:
Raketengrundgleichung: 2101,71925170473m/s
Toablagleichung: 1073,39292773882m/s
(Ja, C# ist sehr genau)

Und wen's interessiert. Der Code

Du hättest vielleicht erwähnen sollen, das deine Gleichung nicht den Treibstoff allgemein sondern ausschließlich den Liquid Fuel nutzt

Für mich zum Beispiel heißt Treibstoff Fuel+Oxidizer.

Außerdem komme ich bei meinem Rechenbeispiel irgendwie nicht auf das richtige Ergebnis...

Einfache Rakete:
MK1-Kommandpod, FL-T400 und LV-T45

Wichtige Eigenschaften:

Mit der Raketengrundgleichung bekomme ich folgendes raus:
Formel:

Rechnung:
912,765m/s = (370s * 9,81 m/s) * log10(4,55/2,55)

Deine Formel:
(Ich habe die Formel etwas umgestellt, damit ich alles in eins bekomme)

Rechnung:
2471,579m/s = ((180l / 12,72l/s) * 200kN) / (4,55 * log10(4,55/2,55))

Hi,

Ich wollte mich nur kurz Informieren ob der Server noch steht und ob da noch was los ist. Da ich wieder angefangen habe KSP zu spielen fände ich einen DMP im Karierre Modus durchaus interessant.

Auch würde mich interessieren auf welcher Version der Server läuft