Beiträge von Cheesecake

[h1]2. Smartparts Teil 2: Beispiele für den Einsatz[/h1]

Für unseren Skycrane mit Rover werden wir nicht alle Bauteile benötigen. Daher werde ich jetzt bevorzugt nur noch die benötigten Teile näher beschreiben.
Wichtig für den späteren Einsatz werden: der Höhenmesser, der Timer und der Geschwindigkeitsmesser. Für unser kommendes beispiel nehme ich noch den Fuel Detector hinzu.
Um zu demonstrieren wie man nun mit SmartParts ein einfaches "Programm" erstellt, werden wir nun mithilfe der SmartParts und den ActionGroups das Staging der ersten Stufe durchführen, wenn deren Tanks leer sind. Zur Vereinfachung und weil es jetzt noch nciht ötig ist, habe ich ActionGroups ReExtended erstmal wieder entfernt. Die Stock-ActionGroups reichen erstmal aus.

Als erstes bauen wir uns eine einfache 2.stufige Rakete. Hierzu hab ich SSTU verwendet weil man da sehr flexibel ist beim Bau von Raketen, Landern und vielem mehr. Außerdem erlaubt uns SSTU in Verbindung mit Textures Unlimited unsere Bauteile farblich zu gestalten wie wir es wollen. Insbesondere aber die Reflections der Bauteile sind ein Augenschmaus.
Aber ich schweife ab. Bauen wir erstmal unsere Rakete. Ich nenne sie mal Jool A:

Ich hoffe die Putzfrauen haben das Metall nicht so sehr gewienert dass ihr geblendet werdet.

So, jetzt gehts an die SmartParts. Da unsere Rakete eigenständig die erste Stufe abtrennen und die zweite zünden soll, brauchen wir natürlich erstmal einen Auslöser.
Schritt 1: Die Stufentrennung soll eingeleitet werden wenn der Tank der ersten Stufe leer ist. Dazu befestigen wir erstmal einen Drainex Fuel Sensor am Tank der ersten Stufe und stellen diesen ein:

Um den Sensor einzustellen öffnen wir das Rechtsklickmenü. In der ersten Zeile wird die Ressource ausgewählt, welche überprüft werden soll. Der Sensor erkennt dabei automatisch die Ressourcen im Tank und bietet diese zur Auswahl. In unserem Fall LiquidFuel und Oxidizer. Da bei de gleichmäßig verwendet werden ist es hier im Prinzip egal welche der beiden man auswählt. Ich lasse es standardmäßig jetzt mal auf LiquidFuel.
In der zweiten zeile kann man die Prozentzahl eintragen, wann der Sensor auslösen soll. In unserem Fall soll der Tank leer sein, also 0%.
In der dritten Zeile sagen wir dem Sensor was er machen soll. Standardmäßig ist hier "Stage" eingestellt. Der Sensor würde also einfach beim erreichen von 0% die nächste Stage ausführen. Das würde zwar in unserem Beispiel auch funktionieren aber wir wollen es ja komplizierter machen.
Also ändern wir hier mal auf AG1.
Als nächstes überlegen wir uns was passieren soll wenn der Tank leer ist. Richtig, die Stufe soll getrennt werden. In den meisten Fällen ist es aber keine gute Idee die Stufe zu trennen und gleichzeitig die Oberstufe zu zünden. Das Endet gerne in einem Feuerball. Also bauen wir das Staging so dass die Stufe erst 3 Sekunden nach Ausbrennen der ersten Stufe getrennt wird. Und erst weitere 5 Sekunden später soll das Oberstufentriebwerk gezündet werden.
Folglich benötigen wir nun 2 Timer, einen mit 3 Sekunden und einen mit 8 Sekunden:

Der linke soll nach 3 Sekunden also die Trennung herbeiführen, welches wir mit AG2 realisieren, der rechte Timer soll anschließend mit AG3 das Oberstufentriebwerk zünden.

Wichtig bei den Höhenmessern, Geschwindigkeitsmessern und Timern ist natürlich dass ihr diese an der letzten Stufe verbaut. Wären die beiden Timer in unserem Beispiel z.B. an der ersten Stufe dann würde Timer 1 zwar noch die Stufe trennen aber Timer 2 könnte die Oberstufe nicht mehr zünden da er mit der ersten Stufe abgetrennt wurde. Ausnahmensind aber halt die Fuel Sensoren. Diese werden ja sowieso nicht mehr benötigt.

Jetzt geht es an die Actiongroups. Ich fasse aber erst nochmal zusammen: Der FuelSensor löst AG1 aus, Timer 1 die AG2 und Timer 2 die AG3.

Um nun alles zu verbinden wechseln wir in die ActionGroups.
Dort editieren wir ertmal die AG1 (Custom1). Nachdem der Tank leer ist sollen ja die beiden Timer aktiviert werden. Also wählen wir die beiden Timer aus und legen in AG1 "StartCountdown". Damit werden beide Timer sofort gestartet.

Nach 3 Sekunden soll Timer 1 dann AG 2 aktivieren, womit die Stufe abgetrennt werden soll. Also klicken wir unseren Decoupler zwischen den Stufen an und wählen "Decouple" in AG2.

Im letzten Schritt soll dann mit AG3 das Oberstufentriebwerk gezündet werden. Also wählen wir das Triebwerk und dann "Activate Engine".

Somit haben wir das Staging nun fertig. Beim Start könnt ihr euch nun voll auf den Gravityturn konzentrieren und müsst nicht mehr ständig auf den treibstiff gucken und auch keine Leertaste für das Staging mehr drücken.

Alternativ kann man anstatt der AGs auch einfach auf Stage stellen und dann immer jeweils die nächste Stage ausführen. Ich finde AGs aber flexibler da man hier auch noch weitere befehle hinzufügen kann.

Noch eine kleine Anmerkung: Die Timer können auch über das Staging aktiviert werden. In den Bildern kann man die Symbole dazu rechts im Staging, Stage 0, sehen. ich aktiviere meist einen Timer direkt mit dem ersten Triebwerk, welcher dann 2 Sekunden später die Launchclamps auslöst.

So, erstmal genug für heute. Morgen gehts weiter.

Nein, es wird nicht nur Deutsch reingepatcht. Es wird die Unity-Engine gewechselt und vieles andere mehr. Ob und welche Mods aus der 1.3.1 noch in der 1.4 laufen hängt davon ab in wie weit Squad mal wieder die Mod-API ändert. Das sehen wir erst wenn die 1.4 raus ist. Bisher haben die Modder soweit ich das mitbekommen habe noch keine Vorabversion bekommen.

Heute fange ich mal mit dem ersten Mod an:

[h1]1. Smartparts Teil 1: Allgemeines zur Mod[/h1]

Was sind SmartParts? Im Grunde handelt es sich hier um Sensoren, welche per Rechtsklickmenü eingestellt werden können. Die meisten davon sind selbsterklärend. So gibt es bspw. einen Timer welcher nach einer eingestellten Zeit eine ActionGroup auslösen kann. Das gleiche kann auch der Höhenmesser. Hier kann man einstellen ob das Ereigniss immer, nur beim Ascent oder beim Descent stattfinden soll. Bspw. könnte man hier das Absprengen der Fairings auslösen sobald man 100 km Höhe erreicht hat.

Insgesamt gibt es folgende Sensoren und andere Bauteile:
- Timer - löst nach einer voreingestellten Zeit eine Actiongroup aus
- Altimeter - löst in einer voreingestellten Höhe eine Actiongroup aus
- Speedometer - löst beim über-/unterschreiten einer eingestellten Geschwindigkeit eine Actiongroup aus
- EC Level Detector - löst eine Actiongroup aus wenn der Strom unter ein bestimmtes Level fällt
- Ressource Level Detector - löst eine Actiongroup aus wenn sich die Menge einer Ressource ändert oder unter/über einen bestimmten Level fällt/steigt. Im gegensatz zum FuelSensor, welcher nur beim Part funktioniert wo der Sensor angebracht wurde, kann man den Ressource Level Detector so einstellen dass er entweder das Part überwacht wo er angebaut ist, die aktuelle Stufe oder das gesamte Schiff.
- Fuel Sensor - löst eine Actiongroup aus wenn der Treibstoff unter ein bestimmtes Level fällt. Überwacht nur das Part wo es angebaut ist.
- Communication Net - löst eine Actiongroup aus wenn die Verbindung zum CommNet verloren geht oder wenn diese wieder aufgenommen wird.
- Prox-Pro Proximity Sensor - löst eine Actiongroup aus wenn ein anderes Schiff, welches ebenfalls einen Prox-Pro besitzt, in die Nähe kommt. Die Entfernung kann eingestellt werden. Bsp. können damit Solarpanel eingefahren werden wenn man in die Nähe einer Raumstation kommt damit diese nicht beim Docking stören.
- Radio GAGA - Hier können Kanäle eingestellt werden und dann können Informationen zwischen zwei Schiffen auf gleichem Kanal ausgetauscht werden. Bsp. kann man beim Anflug auf eine Raumstation diese automatisch auf das anfliegende Schiff ausrichten.
- KM Fuel Controller - diesen kann man für die External Fuel Ducts, die Treibstoffleitungen, nutzen und diese damit steuern, also unterbrechen oder freigeben
- Fuel Flow Breaker - diese können per Actiongroup den Fuelflow unterbrechen. Vorhanden in 4 verschiedenen Größen von 1,25-3,75
- V1 Valve - Hiermit kann Treibstoff abgelassen werden, falls man beim Rückflug zu viel hat. Die Ausströmgeschwindigkeit kann eingestellt werden.
- V2 Valve - - Hiermit kann Treibstoff abgelassen werden, falls man beim Rückflug zu viel hat. Die Ausströmgeschwindigkeit kann eingestellt werden. Im Gegensatz zum V1 strömt hier der Treibstoff radial aus.

Alle Bauteile sind im Bereich Command and Control zu finden. Ebenso sind die Bauteile mit Action Groups ReExtended und TweakScale kompatibel.

Hier eine Übersicht der Parts und wie die Menüs aussehen:

Hast du auch den richtigen Deutsch-Patch? Auf jeden Fall immer drauf achten dass deine mods aktuell sind.

Allein am ModuleManager lags bestimmt nicht. Aber: manche Mods benötigen andere Mods zum funktionieren. Wirft man dann einen raus kann das zu Problemen führen und dir die Log vollhauen. Daher wollte ich auch die Log haben.
Bei Performance Problemen gucke ich immer erst wie groß die Log ist. bei 4 nach KSP-Start mach ich mir noch keine Sorgen. Hat die Log aber nach 10 minuten schon 15-20 MB dann sollte man mal reingucken. Isses noch mehr dann stimmt definitv was nicht. In der Regel wird die Log dann dermaßen vollgespamt dass auch Ingame alles im Zeitlupentempo geht.
Alternativ drücke mal Ingame AltGR + F12. Das öffnet die Konsole. Wenn da alles rot ist dann weißt du dass die Log vollgehauen wird.

Zur besseren Übersicht wurde das Thema zweigeteilt: ein Thema wo ich die Mods vorstelle und ein Thema wo diskutiert werden kann. Den Diskussionsthread findet ihr hier:

An dieser Stelle noch ein Dankeschön an Quabit der die Bereiche schnell getrennt hat,woeller3, welcher den Link zu diesem Thema im Diskussionsthread eingefügt hat und alle anderen welche mich auf Fehler und Verbesserungen hinweisen.

Nun zum eigentlichen Thema.
Da einige schon danach gefragt haben wie man bspw. einen Rover mithilfe eines Skycranes auf Duna landet ohne Funkkontakt zu haben und ohne kOS oder Mechjeb, gehe ich hier mal ein Tutorial an wie man so etwas (und einiges mehr) angeht.

Als erstes brauchen wir einige Mods:
SmartParts
Action Groups ReExtended
VerticalVelocity
ModActions
LandingAid
KAS

Die Mods funktionieren alle in 1.3.1, auch wenn einige schon etwas älter sind.

Im nächsten Abschnitt werde ich Euch dann nach und nach erklären wozu die einzelnen Mods gut sind und wie man diese zusammenbringt damit sie (teil-)autonom funktionieren. Ziel ist es eine Sonde mit einem Rover nach Duna zu schicken. Dort wird die Sonde in die Atmosphäre eintreten, den Hitzeschild und die Backshell (Kapsel) abwerfen, einen Skyrane bis auf 10 Meter runterfliegen lassen, per Seil einen Rover absetzen und den Skycrane anschließend vom Rover wegkatapultieren, damit der Rover nicht beschädigt wird. Dabei werden wir ab Eintritt in die Atmosphäre bzw. schon vorher keine Taste mehr anrühren. Das läuft alles autonom.

So, als erstes ist auf jedenFall schonmal dein ModuleManager veraltet. Die Version 2.8.1 ist schon fast aus der Steinzeit. Derzeit sind wir bei 3.0.4.
Ansonsten ist dein GameData soweit sauber. Ich gehe dann mal davon aus dass da in den einzelnen Ordnern kein Chaos herrscht.
Generell ist das was woeller sagt in deinem Fall der richtige Ansatz: Partmods rausnehmen. Ich stelle mir immer ein Savegame zusammen. Anschließend schaue ich was ich gerade in der Karriere benötige. Alles andere wird dann rausgenommen und in einen separaten Ordner gespeichert. Die Mods kommen dann bei Bedarf wieder hinzu, wofür dann meist andere Mods weichen müssen.
Ich gehe mal davon aus dass dein GameData mehrere GB groß ist. Allein die NearFuture-Mods sowie die USI-Mods dürften zusammen schon mehr als 1 GB haben.
Was ebenfalls etwas auf die Leistung geht sind Poods Skyboxes. In Anbetracht der ganzen Partmods dürfte das aber vernachlässigbar sein.
Wenn du dich etwas in die Ordnerstrukturen der Mods reinguckst kannst du auch einzelne Parts einfach löschen. Meist braucht man von einem Mod nur einige Teile. Allerdings solltest du dann wissen was du tust.

Zitat

Wobei die ja von CKan automatisch installiert wurden. Ich würde mal Blauäugig sagen "Was soll da schon schief gehen?"

Oh, da kann ne Menge schief gehen. CKAN ist leider nicht unfehlbar. In der Regel funktioniert es aber bei einigen Mods hat es in der Vergangenheit zu Problemen geführt wenn man diese per CKAN installiert hat. Das kuriose ist dass CKAN von den gleichen Quellen herunterlädt als würde man es manuell laden. Und auch nach dem Installieren sieht alles identisch aus. Aber das Funktionieren ist dann eine andere Sache. Einige Modder haben ihre Mods daher schon wieder von CKAN entfernen lassen.

Erstmal: welche 1.3 hast du? 1.3 oder 1.3.1?
Hardware ist OK, meine ist fast identisch.
Dass es bei einer größeren Anzahl an Mods auch schonmal im Hauptmenü ruckelt ist normal. Insbesondere gehen Partmods sehr auf die Performance und davon hast du eine Menge und teilweise auch recht große. Ich denke dass das Problem an der großen Masse an Mods liegt.
Ich persönlich habe zwar noch mehr Mods, aber davon sind weniger Partmods. Die meisten sind bei mir Tools.
Mach mal bitte einen Screenshot von deinem GameData. In der Liste sind zwar die Mods drin aber nicht wie sie genau im GameData installiert sind. Ebenso wäre es gut wenn du die KSP-Log und die output_log.txt hinzufügst.
Um generell noch etwas Performance rauszukitzeln und RAM zu sparen (in DX9 haut KSP dir schnell mal deine 16GB Speicher voll) sollte man entweder mit DX11 oder OpenGL starten.
Dazu einfach eine Verknüpfung auf dem Desktop anlegen, Rechtsklick -> Eigenschaften und dort beim 'Ziel' hinten eine Leerstelle und dann -force-d3d11 oder -force-openGL eintragen. Dadurch kommt KSP locker mit 3-4GB aus. Allerdings gibt es vereinzelt Mods die mit DX11 Probleme haben. Ich persönlich habe bspw. 3 Verknüpfungen auf dem Desktop liegen. Eine ohne Parameter (DX9, DX11 und OpenGL. So kann man KSP so starten wie man es braucht.

Beim löschen von mods am besten auch die ModuleManager Dateien in GameData löschen bis auf die .dll. Da werden nämlich auch informationen gespeichert. Kaputt macht man sich mit dem löschen nichts. Also keine Sorge. Im Root-Verzeichnis von ksp befindet sich auch eine partdatabase oder so ähnlich. Die ebenfalls mal löschen. Auch hier kann das bedenkenlos gemacht werden.

Oh, das wäre natürlich wichtig gewesen zu schreiben dass du Mechjeb aktiviert hast.
Welchen Teil von Mechjeb hattest du denn gerade genutzt/aktiviert?
Mechjeb funktioniert bis auf einige Module eigentlich sehr gut, vorausgesetzt man nutzt ihn richtig und stellt ihn richtig ein.
Da du ihn bei der Landung eingesetzt hast kann ich schonmal sagen: Mechjeb und Landungen sind keine gute Idee. Da zickt er rum.
Alles andere sollte soweit funktionieren. Nutze den aber praktisch gar nicht mehr, weswegen ich dazu nicht viel sagen kann.

OK, ich werds mal versuchen. Am besten mit meinem Skycrane als Beispiel. Mal gucken wann ich Zeit und Geduld dafür habe.

Jup, sind sie. Kann ich gerne machen wobei die SmartParts fast schon selbsterklärend sind. Komplizierter sind da schon Vertical Velocity und insbesondere ModActions. ModActions ist deswegen aber interessant weil man fast alle Aktionen per ActionGroup steuern kann, selbst den Schub der Triebwerke, SAS und vieles mehr. Wenn man mal den Bogen raus hat gehts dann recht leicht von der Hand.

Ja, wobei MJ da glaub ich noch etwas schlimmer ist als VV. Außerdem kann man MJ nicht über ActionGroups steuern.
Mit VV kann man auch ne konstante Sinkgeschwindigkeit einstellen. Wenn man also mit 100m/s sinken möchte kann man das genauso eistellen wie mit 1m/s.

Zitat von woeller3

Achte auf den Screenshot Cheese, da ist noch ein Stück zum runterscrollen. Ich denke MM ist drin.

Stimmt. Daher schrieb ich da drüber dass ich den ganzen Modordner sehen müsste weil er im ersten Screenshot nicht ganz sichtbar war.

Zitat von mabehe

den mudulmanager habe ich gezogen, und werde ihn gleich installen

Wenn ich mir die Mods so angucke fällt mir aber keiner ein der das genannte Problem mit den Triebwerken verursachen könnte. Mir ist sowas eigentlich noch nie vorgekommen.
Was die AtmosphereCurve angeht: In deinem Beispiel von die Tage wird davon aber nur der ISP beeinflusst. Das Triebwerk liefert trotzdem Schub. Würde also nicht erklären warum das Triebwerk abschaltet. Bei RealEngines isses was anderes. Da isses etwas komplexer. Aber der ist hier nicht installiert und der beeinflusst auch keine anderen Triebwerke.

Alternativ kann man auch Diazos Vertical Velocity nutzen. Das führt den Suicidburn automatisch aus. Nutze ich gerade für meinen Skycrane. Das gute daran: das läßt sich auch über Actiongroups steuern und man kann die Zielhöhe eingeben. Mein Skycrane soll ja z.B. nicht landen sondern 10 Meter über dem Boden schweben.
Nachteil: kommt manmit zu hoher Geschwindigkeit rein dann neigt VV dazu etwas zu spät zu bremsen und man knallt mit etwa 30-40m/s auf den Boden.
Daher führe ich einige hundert Meter über dem Boden dann meist nen kurzen Burn durch um auf 100-200m/s abzubremsen. Dann funktioniert VV sehr gut. In Verbindung mit Diazos Modactions, SmartParts und den ActionGroups (am besten auch Diazos ActionGroups extended --> gibt ne neue Version von Linuxgurugamer) kann man so sogar ein vollkommen autonomes landen "programmieren". Wenn mein Skycrane mit Rover fertig sit versuche ich mal nen Video davon zu machen.

@woeller3
Ne, das dürfte zumindest auf andere Triebwerke (außerhalb NearFuture) keine Auswirkungen haben. In der config stimmen die partnamen nicht mit den Stock-Triebwerken überein.

@mabehe
Ich hab mir jetzt nochmal deinen 2ten Screenshot mit deinen Mods angeguckt. Ohne jetzt auf dein eigentliches Problem zu gucken sind da ein paar Fehler drin bzw. fehlt was:
1. wenn du Mods installierst dann MUSS ModuleManager installiert sein sonst funktionieren die Mods bzw. Configs nicht richtig. Aktuelle Version ist 3.0.4. Hier der Link dazu. Die .dll direkt in GameData speichern, ohne Ordner. Beim ersten Start von KSP danach legt MM 4 weitere Dateien im GameData an.
2. Der Ordner Lunokhod gefällt mir nicht so richtig. Es gibt meines Wissens nach nur einen Lunokhod-Mod von BobCat. Dieser ist einerseits schon extrem alt und wurde seit KSP 0.90 nicht mehr geupdatet (die Luna-Landeinheit funktioniert soweit, wenn man von den explodierenden Zusatztanks absieht, beim Rover selbst weiß0 ich es nicht aber allein die Räder dürften nicht mehr funktionieren) zum anderen hatte dieser Mod eine andere Ordnerstruktur. Da gab es keinen Lunokhod-Ordner in GameData.
Ich vermute mal dass es sich bei deinem Ordner da um ein craftfile handelt. Das gehört aber nicht in GameData sondern in dein SaveGame oder in den Ordner Ships im KSP-Rootverzeichnis.
3. für das launchersPack benötigst du noch Firespitter, möglicherweise auch für einige andere Mods. Nur wenn dieser installiert ist funktioniert TextureSwitching (bei der Falcon aus dem LaunchersPack kann man z.B. das SpaceX-Logo ausblenden, den Triebwerksblock von weiß auf schwarz ändern oder beim Haupttank die Texture abändern damit die Stufe aussieht wie nach einem Wiedereintritt.
4. Der Ordner RCS105180 ist sicherlich kein Mod und muß aus GameData raus. Beim Ordner UBPP bin ich mir nicht sicher was es ist, könnte aber UranianBlues Planetpack sein. Das ist dann korrekt.

Am wichtigsten ist aber Punkt 1: ModuleManager!!!

Man kann die auch im Root-Verzeichnis von ksp in den Ships-Ordner packen. Dann sind die in jedem savegame verfügbar. Da sind auch die Stock-crafts drin.

Jup. Hab nen erstes Konzept im Kopf. Jetzt muss ich es nur noch bauen und von der Startbahn kriegen.

Hm, ich hätte ja Osmium genommen aber bleibe auch OK.
Mit schweben da nämlich 2 Sachen vor. Ein kleinstes SSTO mit höchster Nutzlast und dann so nen Riesending. Aber beides noch nicht getestet.

Nuja, ich dachte evtl. an eine Kombination. Und ja, das landen wäre schwerer aber dafür hab ich auch schon ne Idee.
Bei der Nutzlast: weiß halt nicht wie ich 500+ Tonnen in so ne kleine cargobay reinkriegen soll.
Aber gut, da lass ich mir was einfallen.