Beiträge von Mullwark

Zitat von Quazar501

Steuerkreuz (K) erkennt KSP nicht.

Bei mir funktioniert es, wenn man es als analoge Achse auf der rechten Seite definiert. Links bei den Tastenzuweisungen geht es auch nicht. Obwohl ich es intuitiv eher als Tasten denn als Stick empfinde.

Danke, das werde ich mal ausprobieren.

Mein Steuerkreuz funktioniert übrigens bei KSP. Ist ein Logitech F710

Zitat von Einar32

1) Ja, das geht. Einfach unter dem Schieberegler für die Empfindlichkeit "Invert" abhaken.

Außerdem verwende ich einen Joystik. Viel realistischer!

Ich habe mich missverständlich ausgedrückt. Das man grundsätzlich die Belegung invertieren kann, war mir bekannt. Ich meinte, kann man es automatisch so konfigurieren, daß eine Rakete nicht invertiert ist und ein Flugzeug invertiert.

Ich habe mir ja bewußt ein Gamepad geholt, um beim Docking Rotation und Translation gleichzeitig nutzen zu können.
Joystick ist realistischer. Da stimme ich dir zu. Ein Gamepad hat 2 davon.

Moin Moin Kerbonauten,

da ich jetzt meine ersten Versuche im SPH beginne, komme ich mit der Tastatursteuerung für Fluggeräte an meine Grenzen. Also habe ich mir ein GamePad zugelegt mit dem Gedanken, Spaceplanes besser fliegen zu können und beim Docking eine bessere Kontrolle zu haben. Der erste Dockingversuch zeigte auch schon eine Verbesserung.

Allerdings tu ich mich mit der Tastenbelegung schwer. Ich habe zu Hause einen ferngesteuerten Heli und dachte mir, ich nutzte die gleiche Belegung. Das hat sich aber als unpraktisch herausgestellt. Deshalb habe ich jetzt folgendes konfiguriert:

NICK und ROLL auf dem linken Analogstick (equivalent zu einem Flugzeugsteuerknüppel).
YAW auf den unteren Schultertasten (sind keine normalen Tasten, eher mit einer Z-Achse vom Joystick vergleichbar)
Da habe ich das Problem, daß mein Nick beim Flugzeug bei der Steuerung einer Rakete mit Navball auf diesem invers erscheint. Kann man die Achse automatisch für Raketen und SpacePlanes umdrehen?
Beim Docking habe ich die Rotation dann auch auf dem linken analogen Stick, die Translation mache ich dann über den rechten analogen Stick. 2 Achsen bei drei Dimensionen reicht nicht, daher nutze ich die senkrechte Achse des Steuerkreuzes für Vor- und Rückschub.

Wie ist denn eure Padbelegung?
Gibt es da irgendwelche klug gewählten Standards?
Noch ist es neu für mich, ich gewöhn mich lieber gleich an eine sinnvolle Steuerung als später zu wechseln.

mullwark

Toll, ich bin extra hoch und hab geguckt. Himmel war bedeckt (Wilhelmshaven). grml. (Hier müsste eigentlich ein Kotzsmilie hin, aber den gibt es ja zu Recht nicht*)

* Ich glaube, Kerbals übergeben sich NIE. Wie oft wurden sie in die Gurte geworfen, mit G-Kräften malträtiert oder durcheinandergewirbelt, aber nie war irgendwas Ekliges in der Kapsel.

Spielst Du auf deutsch? Es gab da ein Problem, daß der Scientist übersetzt wird und dann das Schlüsselwort für das Spiel fehlt. Aktualisier mal die Mod.

Zitat von Troll

KSP für taschenrechner fehlt noch

Ja, genau, daß wäre was. Oder sie veröffentlichen den Quellcode, dann kann man das auch auf dem Abakus spielen.

Metten

klar, ne Rettungsmission. Da brauch ich keine Kralle, habe ja immer Dockingports dabei. Ich habe aber lieber nochmal neu die Landung auf Duna gemacht, u.a. auch, um zu wissen, ob die ursprüngliche Planung mit zwei gelichtzeitig gestarteten Schiffen und ihren Spritmengen hinhaut.

Kein großer Fail, aber ein dummer (Ich war es nicht, Luma Kerman ist geflogen).

Bemannte Mission nach Ike und Duna mit Luma, Jesuki und Svetlana Kerman an Bord.
Ich habe im gleichen Zeitfenster zwei Schiffe geschickt. Ein Lander mit einer interplanetaren Stufe nach Ike und eine zweite unbemannte IPS in einen äquatorialen Orbit um Duna um den Lander später zurück nach Kerbin zu bringen.

Hat auch alles super geklappt, der Lander landet auf Ike, sammelt jede Menge Forschung und dockt danach wieder an seiner IPS an, übernimmt Treibstoff und kommt damit auf einen niedrigen Orbit um auf Dunas Eiskappe zu landen. Der Orbit der verbliebenen IPS um Ike bekommt eine negative Periapsis.
Die drei Kerbonauten landen erfolgreich im Eis. Svetlana macht den Lander startklar, Jesuki forscht und Luma stellt eine Flagge auf und sammelt Eisproben.
Nach einem erfolgreichen Start und Austritt aus der Atmosphäre schwenkt Luma in einen Orbit ein, um einen Rendezvous mit der IPS für den Rückflug zu erreichen.
Blöd nur, daß die IPS in Rotationsrichtung um Duna kreist, der Lander aber mit einer 45°-Inklination gegen die Rotation fliegt. - Und nu? Der Sprit vom Lander ist aufgebraucht. Die IPS kann keine verschwurbelte 8 um Ike fliegen, dann reicht der Sprit nicht mehr für den Rücktransit.

Der letzte [F5]-Druck geschah vor dem Start auf Ike.

Zitat von KASA

dann müsste ich die Prozent aber in 64stel umrechnen,oder nicht ?

Ich habe jetzt nicht nachgezählt, ob die Tabelle 64 Elemente hat, aber ja, du hast nicht mehr 255 Schritte sondern nur so viele, wie Tabellenelemente.

Zitat

Kann ich irgendwie eine Tabelle erstellen und die Werte der Reihe nach aufrufen ?

Ja, du nimmst array, z.b. unsigned int fadingstep[0, 1, 2,...] und sprichst sie als fadingstep[x] an.

In dem Beitrag erwähnt der Schreiber, daß er mit den Werten nicht 100% zufrieden ist. Ggf. musst du da auch selber etwas herumprobieren.
Könnte sein, daß dir da die von dir gezeigte Kennlinie der LED hilft. Der Helligkeitszuwachs ist laut Grafik eben nicht linear. Da würde ich mit Excel bzw. OOCalc eine Wertetabelle erstellen und eine Regression machen lassen. Dann hast du eine Annäherung, die für die Anwendung genau genug sein müsste.

Das Grün und Rot unterschiedlich hell sind, ist normal. Da könntest mittels Poti das Hellere soweit reduzieren, bis es optisch passt und dann den Widerstand messen.

Die Formel unten würde ich erstmal außer acht lassen, wenn du eh mit einer Wertetabelle arbeitest.[/i]

Zitat von KASA

Im Moment
ist das dimmen nicht gleichmässig sondern am Anfang passiert nichts und bei der Hälfte geht es dann auf einmal fast komplett an...

Die Helligkeitswahrnehmung unserer Augen ist annähernd logarithmisch. Ich habe gelesen, daß es beim Dimmen von LEDs zu einem guten Ergebnis kommt, wenn man eine logarithmische Tabelle zugrunde legt. Habe aber bisher nur linear gedimmt und ein ähnliches Verhalten wie du wahrgenommen. Wie sich das beim Mischen von Rot und Grün verhält, kann ich nicht sagen.

Zitat von Troll

trotzdem noch nen delay(50); vor das if und das im if raus nehmen

schont die CPU

Öh, nö, tut es nicht. Die delay() muss in die if-Abfrage, denn sicherlich wird in der loop später noch mehr abgearbeitet, und die Verzögerung ist nur notwendig, wenn die Taste gedrückt wird. Sonst klettert die MCU ja jeden Schleifendurchlauf ins Hamsterrad. Außerdem stinken delay()-Funktionen. Ok, ich nutze sie auch gelegentlich, aber nicht in oft wiederkehrenden Funktionen. Da würde ich wärmstens empfehlen, sich mit einem Timer und seinem Overflow-Interrupt eine Tasterabfrage zu basteln.

Ich programmiere selber 8bit-AVRs, allerdings nicht Arduinos sondern direkt in C mit dem avr gcc. Deshalb kenne ich die Aduino Lib nicht. Aber vielleicht kann ich ja trotzdem etwas helfen.

Ich finde die Idee mit der Duo-LED ziemlich cool. Bestimmt besser als eine LED-Reihe oder so, wobei ich intuitiv doch lieber eine dreistellige 7-Segment-Anzeige mit "echten" % favorisieren würde. Aber egal, erstmal was zu deiner Rechnung:
Du nimmst ein float, stopfst da die aktuellen Prozent rein und skalierst sie auf 8Bit für den Analogen Ausgang, korrekt?
Und wenn du den Tank von 100% bis 0% leerbrennst, durchläuft die LED drei mal den Durchgang grün->rot? Mein erster Gedanke, dir läuft da irgendwo eine Variable über oder die Rechnung ist nicht korrekt.

Ich glaube, es hakt an der Rechnung. Ist das richtig, VData.LiquidFuelS ist dein aktueller Spritstand und VData.LiquidFuelTotS die Gesamtkapazität? Wenn ich für
Fpercent = (VData.LiquidFuelS*VData.LiquidFuelTotS)/100;
beispielsweise (50*100)/100 rechne, kommt noch 50 raus. Wenn ich (500*1000)/100 rechne, nicht mehr. Mach das mal so:

Damit hast du dann die korrekten Prozent.

Wozu eigentlich mit Fließkommaarithmetik arbeiten? So genau kann man das auf der Duo-LED garnicht sehen. Da kannst du auch geschickt umstellen und ohne Komma rechnen, analog wird es eh ein 8bit unsigned int. Sparrt ne Menge Ressourcen. Versuch das mal so (vorrausgesetzt, analogWrite() kommt damit klar):

BTW, schreibt man bei Arduino floats mit einem Komma? Ich hätte 2.55 erwartet, nicht 2,55.

Zum SAS will ich auch nochmal was loswerden:
Ich wundere mich, warum du überhaupt integer für den SAS-Status brauchst, wenn du einen Schalter hast. Der digitale Input- Pin hat doch immer den aktuellen (Soll-)Zustand anliegen.
Ich würde den einfach via Timerinterrupt alle 10ms einlesen (Zum entprellen). Ist er HIGH, ist SAS an, ist er LOW ist es aus.
Dann hast Du doch sicher irgendwo eine LED, die das anzeigt. HIGH an, LOW aus, oder so.
Somit zeigt der Eingangspin am Schalter immer den Sollzustand und der Ausgangspin an der LED den Istzustand. Unterscheiden sie sich, muss ein 'S' seriell gesendet werden. Einfach die beiden Hardware-Pins maskieren und vergleichen.

Schau dir ein paar Let'sPlay-Videos auf Youtube an. Da siehst Du...
- a.) wie Raketen aussehen, die es zu ihren Zielen schaffen und
- b.) wie man diese startet und sie in einen Orbit fliegt.

Ohne jetzt deine Raumschiffe zu kennen kann ich nur vermuten, aber ich hatte das am Anfang auch. Für die untere Atmosphäre helfen regelbare Steuerflossen. Bei der oberen sind Schubdüsen mit Vektorsteuerung nötig. Das LV-T30 hat das nicht, das LV-T45 schon. Besonders lange Raketen neigen auch zum Kippen, gerade, wenn sie einen ungünstigen Schwerpunkt haben. Aber versuch es mal mit beweglichen Steuerrudern und deer LV-T45.