Beiträge von Paranoid

Jip bei mir zickt das auch rum, mal funktionierts, mal nicht. Habe aber bisher noch nicht soweit testen können um eine verlässliche Aussage zu machen was geht und was nicht.

So, auch in der 2. Ausgabe nach meiner E-Mail ist in der Gamestar nichts zu lesen. Aber ich habe folgendes gefunden. Es gibt eine Seite die sich mit Spielen unter Linux beschäftigt und die haben sich wahrscheinlich nach der Ankündigung das KSP auf Linux portiert wird die Mühe gemacht einen kleinen Artikel zu schreiben.

Mit 0.19 werde ich nochmal einen Anlauf starten. Diesmal werde ich gezielt an einen Redakteur schreiben, bin mir aber nicht sicher welcher der richtige Ansprechpartner ist.

Eben und es waren ja schon mehrere Ressourcen angekündigt. Um den Spielspaß zu erhalten macht es daher Sinn, das man die Ressourcen auch abbauen kann.

Zitat von Mc?l?ever

Roverwheels, endlich^^ Finde die sind längst überfällig...

Wenn die nur Räder als Parts einbauen wird es aber sehr schwierig einen kompakten Rover zu konstruieren der auch noch in eine 2,5 m Stufe passt ohne das es eine Beule/Ausladungen gibt. Aber schauen wir mal. Damit bleiben sie wenigstens ihrer Philosophie treu, keine großen Baugruppen ein zu bauen also z.B. einen kompletten Rover zu integrieren. Dafür sollte es im VAB dann aber auch die Möglichkeit geben Baugruppen separat zu verwalten, zu gruppieren und zu speichern. Ist damit "-Parts organisieren" evtl. gemeint?
Ich fände es auf Dauer sinnvoll wenn die dann noch mindestens eine Dritte Partgröße integrieren würden wie sie das Hoomer-Addon z.B. schon mitbringt. Also 3,5 oder 3,75 m Parts. Das entspricht z.B. auch in etwa der Größenordnung einer Ariane 5 (3 bis 5,4 m Durchmesser) eine Ares 5 geht sogar bis 10 m Durchmesser.
Bei solchen Größenelementen (vor allem Triebwerke und Tanks) steigen auch die Möglichkeiten sinnvolle Raketen zu bauen die man dann nur noch verkleiden können muss.

Ja in dem Video wird das deutlich, aber dennoch scheinen sich beide untereinander zu beeinflussen.

Zitat von Mc?l?ever

Kann ich das jetzt so verstehen, das wenn eine Kollisionsabfrage o.a. fehlschlägt, dann diese Zahlen mit Absicht angezeigt werden?

Keine Ahnung

Aber man kann sich das so vorstellen, das der ursprüngliche Programmalgorithmus der ausgeführt wurde als Dein Kerbel Kopfüber auf die Oberfläche fiel nicht unterbrochen wurde als er den Boden berührte, z.B. weil es eine bestimmte Konstellation verschiedener Variablen und Algorithmen gibt, die Programmtechnisch nicht sauber aufgefangen wurde. Daher hat der Algorithmus einfach weiter gerechnet und das mit falschen Werten die normalerweise nicht im Spiel vorkommen, wie Z.B. eine negative Höhe über Grund, der Kerbel liegt ja dann auf einmal unter der Oberfläche, oder was auch immer. Die Grafikengine kommt damit ebenfalls nicht zurecht und zeigt in diesem Fall dann halt nichts an, also einen schwarzen Bildschirm. Der Höhenmesser bekommt nun auch falsche Werte. Die 666666 sind wahrscheinlich ein Maximalwert oder eine bestimmte Schwelle in der Programm-Engine oder so.

Zitat von Quabit

Dockingports haben sicherlich auch keine Gravitation, die werden einfach im Programmcode mit applyForce() (oder wie der Befehl in Unity/C# auch immer heißen mag) in die Richtung des Ports gedrückt.

Nun das ist doch eine Simulation von Gravitation in Form einer Funktion oder?

Wäre es denkbar das diese Funktion mit anderen Parametern (Masse, Schwerpunktlage, Entfernung etc.) auch die Gravitation zwischen Himmelskörpern und Parts simuliert?
Oder wurde dafür ein eigenes Modell, eine eigene Funktion in KSP von Squad implementiert?

Dave meinte die Tage das die Entwickler am nächsten Livestream am Mo 28.01. die neuen Features für 0.19 verkünden wollen, da die Besprechung des Teams erst vorgestern zur Zeit des Livestreams statt
gefunden hat und deshalb kein Livestream statt fand. Also mal Montag um 20:00 Uhr im Lifestream vorbei schauen.

Nein, soetwas ähnliches ist mir auch schon passiert, wenn auch nicht so sehr deutlich. hier scheint die Kollisionsabfrage im Spiel ausgesetzt zu haben. Das kenne ich aber auch bei anderen Spielen den Begriff Clippig-Fehler kennen sicher die Meisten. Die fehlerhafte Kollisionsabfrage gehört aber auch dazu.

Also um es mal vorweg zu schicken, die Berechnung von Gravitationswellen ist so komplex und aufwendig das sie in einem Spiel wie KSP sicher nicht umsetzbar ist. Es wird hier sicher nur das Newtonische Gravitationsgesetz berücksichtigt. Ob das nun der genauen Formel folgt oder in KSP eine Annäherung im Verhalten daran hat, ließe sich experimentell in KSP ermittel z.B. über Fallversuche auf Kebal. Aber das würde vielleicht auch zu weit führen. Generell betrachtet ist die Gravitation zwischen Bauteilen auch real betrachtet sehr gering. Ob man in der Raumfahrt dazu Beobachtungen gemacht hat, ist mir unbekannt. Hat jemand von Euch dazu mal etwas gelesen oder gehört?

Die Tatsache das sich zwei Dockingports untereinander anziehen und diese anfangen zu tanzen wenn man nicht genau gerade dockt zeigt aber auch das das Spiel definitiv eine Art von Gravitationssimulation enthält die zwischen Bauteilen berechnet wird. Das Verhalten kann man ja auch im Spiel vergleichen wenn man nicht sauber mit einer Mun-Fähre auf dem Mun auf setzt (Hier Gravitation zwischen Himmelskörper und Part), da der Lander dann auch auf der Oberfläche tanzt und ggf. sogar umkippt wenn der Massenschwerpunkt nicht mehr stimmt. Im übrigen ist es mir auch schon beim Docking passiert das sich ein bereits gefangenes Bauteil durch das zu heftige schwanken wieder los gerissen hat.

Aufgrund der Tatsache das die Bauteile in KSP als Objekt mit Eigenschaften belegt wurden (Stichwort Objektorientierte Programmierung) und der Programmcode die Simulierung von Gravitation bereits enthält wäre es eine Programmzeile die Berechnung von Gravitation unter Raumfahrtteilen zu aktivieren. Der einzige Grund dies nicht zu tun ist eine Kosten-Nutzen-Analyse. Was bringt es und wie viel Performance kostet es. Die Tatsache das KSP auch meinen neuen High-End-Rechner mühelos in die Knie zwingt veranlasst einen dazu sich Gedanken über die "Simulation" zu machen. Von Quabit wissen wir, das Squad eine ältere Unity-Engine für KSP einsetzt die Multicores noch nicht richtig unterstützt. Aber ist das der alleinige Grund für komplette Aussetzer zwischendurch?
Sicher gibt es noch eine Menge Optimierungspotenzial in der Programmierung und das werden die auch sicher vor dem endgültigen Release noch angehen müssen.

Aber die Bewegung im Video verhält sich ganz genau so als wäre Gravitation vorhanden. Es als Bug abzutun ist eine leichte Behauptung. Ich würde dann zumindest soweit gehen und sagen ein Bug in soweit, das hier die implementierte Simulation der Gravitation aktiv war, auch wenn es für alle anderen Parts nicht der Fall ist. Denn wie kommt eine solche Bewegung ansonsten zustande?

Zitat von Mc?l?ever

@Dave: Thx fürs Bild, warum benutzt du keine großen Jumbo-Tanks - so wird die Rakete wesentlich stabiler...?

Ich vermute mal weil die Triebwerke bei den Jumbotanks schneller überhitzen wie auf den Modultanks, daher nutze ich die Tanks auch fast ausschließlich.

Also erst einmal Respekt vor der Konstruktion

Ich stelle immer wieder fest das mir durch mein Berufsleben schon viel Phantasie verloren gegangen ist. Ich wäre gar nicht auf die Idee gekommen sowas auf eine Rakete zu bauen

Aber ich würde mich McFlyever anschließen, es sieht nett aus, ist aber weder spielbar von den Frames, noch hat es - leider - eine tatsächliche Funktion im All.

Zitat von Andromega

Die eine Sonde besteht aus mehr Teilen, wie die andere. Das bedeutet, dass sie mehr Masse hat. Mehr Masse bedeutet auch mehr Gravitation. Folglich müssten sich die beiden Sonden um einen Schwerpunkt bewegen, der wesentlich näher beim mehrteiligen Objekt liegt.

Genau Andromega und genau dieses Verhalten beobachte ich bei den beiden Satelliten in dem Video. Der Drehpunkt liegt ganz klar nahe an dem größeren Satelliten oder sogar schon innerhalb des größeren Objektes.

Zitat von richard

TROMMELWIERBEL ich habe die lösung gefunden ich habe den report durch gelesen und habe das gefunden das der unity web player geupdatet- gebraucht wierd
Download:http://unity-web-player.softonic.de/
Ich hoffe es klapt dan war bei mir hald so

Was hat der Unity-Web-Player damit zu tun?
Es ist korrekt, das KSP mit auf der Unity-Engine basiert. Der Unity-Web-Player ist aber nötig für Spiele die im Browser ablaufen. Bei mir ist er z.B. nicht installiert und KSP läuft. Ich vermute mal das die Unity-Engine Teil des KSP-Progammcodes ist, zumal man KSP nicht installieren muss. Die Unity-Engine steckt also irgendwo im KSP-Verzeichnis. Wenn Du den Web-Player hast dann vermutlich wegen eines anderen Browserspiels das auf der Unity-Engine beruht.

Es ist definitiv kein Bug so wie ich die KSP-Engine verstehe.

Die Entwickler haben versucht die Gravitation zu simulieren. Jedes Teil hat in KSP bestimmte Eigenschaften, so auch eine Masse. Die wird ja im VAB auch angegeben. Diese Masse wirkt sich beim Start und im Weltall über ihre Anziehungskraft und Ihre Massenträgheit aus. Die Massenträgkeit der Bauteilgruppen habt Ihr sicher schon viel früher bemerkt, nämlich das sich eine kleine Rakete z.B. mit dem RCS schneller beschleunigen und bremsen lässt wie eine Große. Das die Bauteile einzeln berechnet werden sieht man auch daran das eine abgetrennte Stufe beim Aufschlag auf z.B. Kerbal meist nicht komplett zerschellt, sondern auch hier spielt die "Aufschlagtoleranz" eines jeden Bauteils eine Rolle. Sehr oft überleben z.B. die RCS-Düsen. Die haben eigentlich eine Aufschlagtoleranz von 9 m/s und müssten eigentlich immer zerschellen. Da die Düsen aber z.B. an einem Tank sitzen der zuerst aufschlägt, so läuft das im Programmalgorihtmus vermutlich so ab:

Die Baugruppe Raketenstufe schlägt z.B. mit 500 m/s mit einem Tank zuerst auf der Oberfläche auf. Die Aufschlagtoleranz des Tanks ist überschritten, also explodiert der Tank. Der Tank ist nun nicht mehr da, daher stehen alle Bauteile des Tanks an der Stelle in der Luft wo sie angebaut sind. Sie fallen nun auf die Oberfläche. Prallen diese Bauteile auf die Oberfläche wird für jedes einzelne Bauteil geprüft ob die Aufschlagtoleranz überschritten wurde oder nicht. Bauteile die bei der Explosion des Tanks unten angebaut waren aber die Oberfläche noch nicht berührt haben überleben den Absturz wahrscheinlich, da sie aufgrund der geringen Fallhöhe die Aufschlagtoleranz nicht überschreiten, sofern sie nicht noch von einem anderen Bauteil tödlich getroffen werden.
Ich nehme an der Fehler entsteht dadurch das die Aufschlaggeschwindigkeit der Baugruppe nicht an die Einzelteile weiter vererbt wird, wenn das Bauteil nicht mehr da ist, wo sie angebaut waren. Wäre das der Fall, müsste immer alles explodieren, es sei denn die Fallgeschwindigkeit der Baugruppe ist niedriger wie die höchste Aufschlagstoleranz eines Bauteiles. In KSP haben die Kommandopods die höchste Aufschlagstoleranz und somit die höchste Überlebenschance wenn sie nicht direkt aufschlagen, sondern z.B. noch hinter einem anderen Bauteil sitzen (Dazu verweise ich auf die Screenshots von Quabits Bruchlandung auf Jool). Ich vermute das diese Berechnung eine mathematische Vereinfachung der Engine ist um KSP noch spielbar zu halten, denn sonst gäbe es nur noch Diashow in KSP. Als Außenstehender kann man das aber auch als Bug bezeichnen.

Die Berechnung der einzelnen Anbauteile ist auch der Grund warum selbst mein neuer Core i7 Prozessor beim Annähern meiner Raumstation an 2,3 km quasi still steht bis alles geladen und verarbeitet wird. Ab einer Distanz von 2 km berechnet die Engine die physikalen Gesetzmäßigkeiten. Je mehr Einzelobjekte sich nähern, je mehr muss gerechnet werden.
Ist die Eigenbewegung (Fluchtbewegung) zweier kleiner Massen sehr gering beeinflussen sie sich gegenseitig und werden z.B. angezogen oder umkreisen sich. Ich habe das selber noch nicht beobachtet, aber es verwundert mich letztendlich nicht.

Die Dockingports bilden im übrigen eine Ausnahme. Deren Anziehung aufeinander ist sehr viel größer als bei allen anderen Bauteilen. Damit ist das Docking auch erst wirklich möglich. Die Tatsache das das Docking noch nicht sofort erfolgt, sondern die beiden Teile umeinander "tanzen" zeigt, das hier die gegenseitige Anziehung simuliert wird.

Interessant wäre es wie sich die Teile verhalten wenn man sich mal für kurze Zeit aus den 2 km entfernt und dann wieder zurückkehrt. Ich vermute mal das sie dann der letzten Bahn folgen, da die Massenanziehung über 2 km Distanz nicht mehr berechnet wird, wohl aber die Bahnbewegung. Ein Experiment hierzu wäre hilfreich.

wie jetzt, ich dachte Du hast den Lifestream verpasst????

Na ist doch klar, mit den großen Feststoffboostern braucht man keine ausgeprägte ballistische Kurve fliegen. Die ist insgesamt flacher und damit auch schneller zu erreichen.

@McFlyever, habe hier noch zwei Screens einen kurz vor dem aufsetzen, einen bei 3:31 also nach dem Aufsetzen.

Ich baue gerade an einer Duna-Mission mit einem Mutterschiff aus 5 Modulen. Mit 2 Hbitatmodulen, zwei Satelliten, einer Landefähre und einem Rover.
Es gab viele kleinere Probleme zu meistern, wenn es fertig ist, gibts ein Bericht. Film werde ich aber wohl nicht machen.

So Leute nun mache ich Euch mal neidisch

Mit diesem simpelsten Gefährt Marke "Banal 2100" aus Komandomodul, ASAS, 2 Decouplern und 2 kleinen Boostern.
[absatz][/absatz]
Grüßt Bill seine zurückgebliebenen und ertrukene Kammeraden ca. 75 bis 100 m neben der Landebahn. Die Landung erfolgte nach 3 Minuten und 27 Sekunden
Dave der Zocker ist mein Zeuge, ich hatte vergessen das der Cowndown nach dem Ausstieg neu anfägt zu zählen. Auf dem Missionsbericht steht Ausstieg nach 4 Minuten, geladet bin ich aber nach 3:27.
[absatz][/absatz]
Und hier der dazugehörige Missionsbericht.
[absatz][/absatz]