Beiträge von Paranoid

    Bei der Überarbeitung des Artikels "Raketensteuerung" und "Gravity-Turn-Manöver" kam mir ein wesentliche Gedanke warum die Effekte des Wiedereintritts noch nicht in KSP berücksichtigt wurden. Der Grund könnte an einer ganz anderen Stelle sehr unangenehm für viele Raketenbauer sein, nämlich beim Start. Jedem hier ist beim Start schon mal eine Rakete zerbrochen aufgrund von aufschwingenden Bewegungen der Nutzlast oder weil die strukturelle Integrität nicht mehr gegeben ist.
    SydamorHD hat ja schon festgestellt, das der Wiedereintrittseffekt dem Grunde nach simuliert wird, aber die Effekte viel zu schwach sind. Da habe ich mich gefragt was passieren würde wenn denn der Luftwiderstand und die Luftreibung realistisch umgesetzt worden wäre?
    Nun, die meisten hätten es bei Start ihrer Raketen sehr schnell gemerkt, denn die würden viel früher auseinanderbrechen, erst recht bei unverkleideter Nutzlast wie in KSP üblich. Das wäre aber für ein Spiel wie KSP der Todesstoß gewesen, da die meisten nach etlichen Anlaufversuchen keine Rakete in den Orbit bekommen hätten, zumindest keine die eine nennenswerte Nutzlast dabei hat :P
    Das war es auch was mich beim Start immer irgendwie gestört hat, da ich immer das Gefühl hatte den Orbit nicht effizient einzuleiten. Die Rückprojektion der Spieleengine ist an dieser Stelle zu schwach.
    Ich denke hier wird Squad einen Kompromiss eingehen müssen zwischen Spielbarkeit und Realismus und nicht versuchen die Realität 1 zu 1 zu kopieren. Das macht das Ganze nicht gerade einfacher dafür ein mathematisches Modell zu entwickeln, da die Effekte beim Wiedereintritt ja gewollt sind, aber bei Start für sehr viel Frust sorgen könnte. Es sei denn sie geben Über ein Leitsystem einen genauen Startkorridor vor den man abfliegen muß. Es bleibt aber das Problem des Luftwiderstandes der unverkleideten Nutzlast.

    @McFlyever, ich danke dazu muss ich nicht viel sagen, das sollte alles in den 5 Seiten drin stehen. Zu Anfang steht was zur "Versuchsbeschreibung" wo ich die Vorgehensweise beschrieben habe. Sollte dann noch was unklar sein, antworte ich gerne.

    Ich habe mal versucht mit den Boxen zu experimentieren und bekam kein Ergebnis. Folgender Code wurde nicht interpretiert:


    [box=rot,right] Beispiel [/box]


    Ich habe es mit "red" als Farbangabe versucht (in der Hilfe steht rot !!!!!) und auch nur über [box] Beispiel [/box]. es ist mir nicht gelungen eine Box zu erzeugen.

    Ich hatte ja erwähnt das ich zu den Aufbau der Raketenstufen eine Testreihe gemacht habe. Anbei lege ich die Versuchsbeschreibung. Das Ganze habe ich noch unter 0.17.1 durchgeführt. Das Fazit eine Kaskade mit einer Stufung aus jeweils 2 Raketentriebwerken und Tanks ist die effektivste Methode für den Raketenaufbau und brachte für die Testrakete mit 7 Triebwerken im Bündel in 4 Stufen einen (Versuchsreihe 4) Höhenvorteil gegenüber 7 Triebwerken im Bündel in 2 Stufen (Versuchsreihe 3) von 109 %, der Geschwindigkeitsvorteil liegt um 30 % höher. Das ist gewaltig.

    Für eine Anordnung von 9 Raketentriebwerken sollte das Ergebnis noch deutlicher ausfallen.


    Derzeit bin ich am überlegen das Ganze für die Version 0.18.1 zu wiederholen mit ein paar kleinen Änderungen um es evtl. etwas verständlicher zu machen.


    Quabit wollte darüber auch gerne ein Videoetutorial machen, da er bemerkte das andere Raketenkonstrukteure in ihren Videos dieses Know How noch nicht haben.


    Beides wird in das Wiki übernommen.

    Dateien

    • Testreihe.pdf

      (106,85 kB, 1.074 Mal heruntergeladen, zuletzt: )

    hm, das scheint mir wenig realistisch zu sein. Zu den ersten Kurven kann ich nur sagen, das das Verhalten nicht richtig simuliert wird. In der Atmosphäre (zumindest dort wo sich der Flugverkehr abspielt) gilt das Gesetz von Bernoulli. Das sagt, dass bei steigender Geschwindigkeit der Druck und die Temperatur fällt. Die Temperatur steigt aber. Oder spielt hier die Abstrahlungshitze der Triebwerke eine Rolle die ja anscheinend simuliert wird?
    War der Sensor vielleicht zu nah an den Triebwerken plaziert?


    Ok für das Fliegen mit einem Flugzeug ist der Druck wichtiger und die Temperatur spielt nur bei Vereisungsgefahr eine praktische Rolle.
    Die letzte Kurve sieht da schon besser aus, die Druck- und Temperaturzunahme sollte aber sehr viel deutlicher ausfallen. Es macht den Eindruck als würde die Luftdichte irgendwie nicht richtig umgesetzt, ist aber letztlich Spekulation. Hier gilt das Gesetz von Bernoulli nur noch bedingt, da hier die hohe Geschwindigkeit Reibungshitze erzeugt und dieser Effekt überlagert alles.
    Aber es ist zumindest schön zu sehen, das sich da überhaupt was tut und das die versuchen das schon mal mit zu simulieren :D . Und die letzte Kurve deutet zumindest schon mal darauf hin das man damit den Hitzeschirm der Kommandomodule beim Wiedereintritt braucht, aber dazu muss die Temperatur auf mehrere tausend °C steigen und nicht von -95 auf -20°C ist ist einfach zu wenig.

    Ich war mal so frei und habe an die Spielezeitschift Gamestar eine E-Mail mit folgendem Inhalt geschrieben, Quabit überlegte ja auch schon mal diese Seite ebenfalls bekannt zu machen.


    Hallo Redaktion,


    ich möchte an dieser Stelle auf ein Indie-Spiel (Sandbox) aufmerksam machen, was ihr Euch mal etwas genauer anschauen solltet. Für meine Begriffe hat es ein ähnliches Potential wie Minecraft, ist aber leider nicht so eingängig, da es technisch anspruchsvoller ist. Ich schreibe hier von Kerbal Space Program (https://kerbalspaceprogram.com/).
    Es ist zwar noch eine Alpha-Version aber schon sehr gut spielbar. Es gibt eine aktive Moddingscene und auch eine kleine deutsche Community unter http://kerbalspaceprogram.de.


    Viele Grüße


    Paranoid

    @McFlyever lies bitte mal die beiden Artikel RCS und SAS/ASAS. Das steht alles so drin wie man es für das Spiel gebraucht, aber halt etwas mehr als nur "Das SAS stabilisiert das Raumfahrzeug". Es kann ja sein das es Dich nicht interessiert wie es das macht, aber in TS wird ja ständig über Realtitätsbezug von KSP diskutiert. Ich denke die Tatsache das die NASA KSP auch nutzt, und sei es für die Erheiterung der Mitarbeiter oder wen auch immer - zeigt doch das man sich damit auseinandersetzt. Wäre KSP realer quatsch würde die NASA vermeiden das man KSP und NASA nur in irgendeinem Zusammenhang bringt. Ziel des Spiels ist ja neben dem Spaß auch ein Interesse an Raumfahrt zu wecken. Ich habe in den Artikeln versucht das aufzugreifen ohne daraus ein technisches Lexikon zu machen. Der Spielspaß soll ja erhalten bleiben. Daher steht auch nur in der Erklärung des Begriffs was zum technischen Hintergrund. Ansonsten stehen nur spielrelevante Dinge drin und ggf. ein Link wo man sich weiter informieren kann und das ist ja Sinn des Wikis.



    PS: Schaue mal ins Wiki der Entwickler, z.B. unter SAS da steht schon mehr zur Theorie drin. Auf vielen Seiten findet man sogar mathematische Formeln.

    @Mc?l?ever ja ich bin ja nicht blöd :D Natürlich weiß ich das es in KSP geht, mir geht es hier nur um eine Beschreibung im Wiki, da es ein inhaltlichen Widerspruch gibt.
    KSP will realitätsnah sein und ich versuche nur die Beschreibung im Wiki in Anlehnung an die Realität umzusetzen. Und Fakt ist das man ein reales Raumschiff ohne Düsen im Raum nicht steuern kann wenn das SAS deaktiviert wäre. Also kann es in Kerbal auch nicht aktiviert werden, sondern die Stabilisierungsfunktion des SAS wird über T eingeschaltet.
    Ich weiß das macht beim spielen keinerlei Unterschied, aber mein Anspruch ist es nun mal hier einen Realitätsbezug her zu stellen wo er vorhanden ist und ich werde in unserm Wiki auch zu den entsprechenden Themen das reale Wikipedia verlinken und die technischen Vorgänge nur ganz grob beschreiben um hier den realen Bezug herzustellen. Es soll Leute geben die interessieren sich für die reale Raumfahrt und Kerbel macht es für den Spieler erlebbar und da hat vielleicht der eine oder andere ein Interesse daran wie das in echt funktioniert. Dave wäre so ein Kandidat :love:
    Für den Artikel SAS habe ich z.B. den Artikel Stabilisation (Raumfahrt) bei Wikipedia gefunden. Den werde ich im Artikel SAS/ASAS auch verlinken.

    Bei dem SAS wird immer vom Einschalten gesprochen um eine Stabilisierung zu ermöglichen. Fakt ist aber das man ohne SAS bei ausgeschalteten Triebwerken gar nicht steuern könnte. Daher würde ich in dem Artikel das gerne etwas anders beschreiben. Mit T aktiviert man den Stabilisierungsmodus nicht aber das SAS. Wobei das SAS dann auf Einwirkungskräfte von außen reagiert (Drallstabilisation) das SAS bleibt dabei Ortsstabil. Man steuert ja das Raumschiff über die Bewegung des Trägheitsrades (Kreisel), da sich diese Kräfte dann ja auf die Zelle übertragen, also ist das SAS sehr wohl aktiv.

    Quabit , auch das 2. Tutorial ist Dir gut gelungen, wenn auch nicht so gut wie das Erste :P
    Durch das schneiden - Du erwähntest es gestern - wirkt es sehr gehastet. Aber inhaltlich wird alles klar und das ist die Hauptsache.
    Man sollte die Videotutorials auf jeden Fall auch im Wiki verlinken. Ich werde zumindest das Tutorial zum Flight Planer unter Steuerung verlinken und die Action Groups unter Raketenkonstruktion. Das ist eine sehr anschauliche Ergänzung.

    Ich fände der Artikel SAS / RCS sollte umbenannt werden in SAS/ASAS.


    Begründung:


    Das RCS habe ich schon in einem separaten Artikel ausführlich beschrieben und muss dann nicht nochmal im Wiki auftauchen. Der Begriff ASAS kommt in KSP vor, ist aber nirgendwo erläutert. Das es eine Variante von SAS ist wird dem Neuling erst später bewusst. Man sollte aber durchaus immer beides angeben, da die Begriffe zusammengehören aber unterschiedliche Varianten darstellen.
    Da der Artikel ebenfalls einer der kürzeren ist, würde ich ihn gerne bearbeiten und dann mit dem Thema Steuerung weiter fortfahren.

    Da KSP noch viele Änderungen und Erweiterungen erfahren wird würde ich gerne vorschlagen, das jeder Artikel der angelegt und überarbeitet wird einen Versionshinweis erhält für welche Version er gültig ist. Das resultiert auch aus eigenen Erfahrungen, da man als Benutzer des Wikis nicht wissen kann wann der Artikel verfasst wurde und wo die Inhalte Gültigkeit haben. Daher sollte jeder Artikel am Ende mit dem folgenden Hinweis versehen werden:



    Artikel gültig für Version 0.18.X


    Das wäre für uns auch gleich der Hinweis ob er bei einer neuen Version zumindest überprüft werden muss.

    Ok, die fehlenden Texturen sind tatsächlich ein Fehler, die habe ich auch, ich habs nur nicht bemerkt :whistling: Es liegt also nicht am Updater selber.
    Der Turm wird in der Übersicht aller Gebäude auch nicht angezeigt. Die Fragezeichen sind anscheinend auch nicht gewollt.