Beiträge von DH-106

Ein Kapitel "Fehlersuche" kann ich gerne mit reinschreiben. Aber dazu müßte ich erstmal wissen, welche hier aufgetreten sind und gelöst werden müssen.

Es wäre vielleicht elegant, wenn man diesen Thread hier gleich dazu hernimmt - wenn also jemand der Anleitung gefolgt ist, aber trotzdem kein Repaint am Ende rausgekommen ist, dann wüßte ich gerne, wo er steckengeblieben ist oder was statt dessen rauskam

danach habe ich jetzt schon eine ganze Zeit gesucht, aber es erst jetzt gefunden. Gelobt seien diese verschachtelten Menüs...

Danke für den Fingerzeig, es sieht schon viel aufgeräumter aus.

Noch eine vielleicht blöde Frage zu GIMP.

Manchmal passiert es, wenn man schnell irgendwo hin klickt, daß eine zwar schicke und schön gerade, aber dennoch ungewünschte Hilfslinie die Bilddatei quert. Man kann sie zwar ausblenden, aber gibt es auch eine Methode, sie wieder komplett zu entfernen?

Danke für die Hilfe...

While the Columbine is a beautiful aircraft and I have come across it a while ago while it was based at Avra Valley/Marana, I will skip that livery: it is not really an airliner and therefore not usable for ingame lines. I don´t really like to have military aircraft in my game and would find it slightly odd to have it turn up at a gate and pick up a load of travellers.

If, hypothetically, someone wanted to repaint the model into whatever other paint job he may fancy, including the Columbine, I will be happy to provide an unwrap and some other helpful layers to make it easier. The only limit here is the common, often mentioned one: the repaints will only be uploaded here and as dependant version of the original set

Diese Änderung überzeugt mich irgendwie nicht so recht. Seine Anpassung in der .mdl sieht so aus:

idleThrust = -170000,
maxPayload = 110000,
maxTakeOffWeight = 200000,
maxThrust = 180000,
timeToFullThrust = 40,
topSpeed = 270, 
weight = 20000,
wingArea = 90,

Das Flugzeug ist also voll beladen viel schwerer geworden, hat beträchtlich weniger Schub und auch weniger tragende Fläche als ein für Vanillaplätze angepaßtes Modell. Daß das die Startstrecke deutlich verlängert, ist offensichtlich. Wenn das das einzige Ziel ist und alles andere dem untergeordnet wird, dann mag das ok sein.

Aber: die Startstrecke ist nicht alles. Die Kombination von hohem Gewicht und wenig Schub führt dazu, daß das Modell viel schwerer beschleunigt und auch fast gar nicht steigt; es wird also wie eine schwangere Wanze in der Luft hängen und sich irgendwie zu seinem Ziel hungern - das erkennt man auch im Video, der Unterschied in der Steigrate ist deutlich erkennbar. Und für wirtschaftliche Spieler ist auch was mit dabei: die Betriebskosten errechnen sich aus Höchstgeschwindigkeit und Höchstgewicht. Die Kosten sind daher dieselben, aber durch die geringere Geschwindigkeit hat man viel seltener Einnahmen (das Flugzeug braucht halt länger von A nach B). Diese Änderung macht das Flugzeug daher unwirtschaftlich.

Und das optische Ergebnis ist auch nicht realistisch. Was er erreicht hat, ist ein Ergebnis wie das hier:

Ein kleiner Exkurs ist hier nötig: ein Start muß so berechnet sein, daß (unter anderem!)

1. vor einer Entscheidungsgeschwindigkeit (V₁ ) bei einem Triebwerksausfall der Start abgebrochen werden kann und man vor dem Ende der Bahn noch zum Stehen kommt.

2. nach V₁ der Start auch mit dem Triebwerksausfall fortgesetzt werden kann und man die bekannten 35 Fuß über dem Ende der Startstrecke (die nicht mit der Startrollstrecke verwechselt werden darf!) erreicht.

Das ist hier zweifellos nicht gegeben. Wenn ein Flugzeug mit allen Motoren gerade mal am Ende der Bahn rotiert und abhebt, dann kann etwas mit der

Berechnung des Starts nicht stimmen: mit einem Triebwerksausfall bei V₁ (es ist beinahe egal, welchen Wert man hier gewählt hat) würde es viel schlechter beschleunigen und hinten über die Bahn rausmarschieren, bevor die Abhebegeschwindigkeit erreicht wurde. Wenn man V₁ = V_R gesetzt hat (was auf langen Bahnen völlig legal sein kann), würde man in diesem Fall noch vielleicht 30 Meter zum Bremsen haben, bevor die Klippen und das Meer auf einen warten. Das kann hier also auch nicht sein...

Realistisch würde das Flugzeug etwa auf 2/3 bis 3/4 der Bahn abheben müssen.

Feluno, es geht doch nichts über ein Dach aus flüssigem Quecksilber

What the... this allows for circling the entire Central Park without repeating a single building. You are outdoing Yourself again here.

Noch ein Bild

Leider ist auch hier wieder das Problem mit der komprimierten MG-Map aufgetaucht. Seit der letzten Revision tut sich das Spiel relativ schwer mit den Randbereichen zwischen blankem Metall und angestrichenen Bereichen, die werden sehr stark gerastert. Hier sind noch ein paar Experimente nötig, schlimmstenfalls muß ich wieder wie bei der Il-12 ein DDS-Format wählen, das diesen Effekt vermeidet, aber nur mit neueren Spielversionen läuft.

Nicht optimal, aber eine andere Lösung habe ich noch nicht finden können...

Aber zunächst kommen noch ein paar Anstrichvarianten dazu. Die Anstriche aus den 1950ern sind oft sehr strukturiert; BOAC und TWA fallen hier mit ihren sauberen, klaren Linien sehr aus dem Rahmen. Air France mit der geflügelten Garnele, Western mit dem Indianerkopf oder KLM mit einem erschreckend detaillierten Segelschiff des Fliegenden Holländers werden vermutlich ein wenig länger brauchen...

...könnte sein, daß ich an die Transformationsmatrix für das Asset noch mal ran muß...

Solche Animationen wären in TPF2 auch relativ einfach von Hand zu schreiben, wenn man das möchte. Wenn die Achsen der Schraube und des Ruders korrekt liegen (ich glaube, die Ruderachse muß parallel zur Z- und die der Schraube parallel zur Y-Achse stehen), werden sie dann einfach mit einer Matrix zurechtgedreht und über ihre Sequenznummer mit der Animation belegt.

Und die Türenanimation wäre auch leicht gemacht. Daß man das Anheben/Absenken des Schiffs vielleicht auch über diese Türenanimation hinbekommt, halte ich für relativ wahrscheinlich.

Was genau brauchst du denn animiert? Schrauben und Ruder können relativ unproblematisch vom Spiel prozedural animiert werden, wenn dir das genügt.

Das wäre plausibel. Oder man schweißt einfach ans Ofenrohr oben eine Windfahne an, daß es sich automatisch aus dem Fahrtwind raus dreht und ein wenig Saugwirkung entwickelt.

Die Geschichte der Waggonheizung hat einige Umwege gemacht, wie ich sehe... gerade habe ich Kopfkino von einem Beamten, der winters mit einer Karre voller glühender Kohlen den Bahnsteig entlangschiebt und alle paar Meter in die Seitenklappe vom Waggon eine Schaufel reinwirft...

Ein sehr schickes Wagenset, wie immer. Wendezugtauglich ist der aber nicht mit dem unidirektionalen Ofenrohr, oder?

Stimmt schon - aber daß ein Navigator, der mit dem Rechenschieber und einem Tafelwerk aus einer gekoppelten Position erst die erwarteten Höhen und Azimuthe mehrerer Sterne vorberechnen muß, bevor er sie dann mit dem Sextanten "schießt" und aus den genauen Werten dann die Position berechnet, für einen noch so genauen Standort mehrere Minuten braucht, liegt auch in der Natur der Sache. Wenn er das dann nicht auf einem Ozeanschiff, das mit vielleicht 15 Knoten unterwegs sein mag, sondern in einem Flugzeug, das mit 300 oder mehr Knoten unterwegs ist, macht, dann ist die Position binnen 5 Minuten schon um 25 Meilen zurückgelassen worden, wenn sie soeben erst bestimmt wurde.

Wenn man das mit heutigen kombinierten Navigationssystemen vergleicht, die aus GPS, Trägheitsnavigation und automatisch genommenen Peilwerten von DMEs und VORs kontinuierlich eine gemischte Position berechnen, und das je nach Qualität der Eingangssignale mit einer 95prozentigen Toleranz von weit unter einer Meile, dann ist das schon ein gewisser Fortschritt.

Aber das soll nicht den Respekt für die Astronavigation schmälern, geschweige denn für diejenigen, die diese schwarze Kunst noch gelernt haben (ich hatte dazu leider nie die Gelegenheit) - es ist keine kleine Herausforderung, auf einem um die eigene, 23.5° aus der Vertikalen gedrehten Achse drehenden, dabei noch präzedierenden, um die Sonne auf einer elliptischen Bahn kreisenden, annähernd kartoffelförmigen Planeten (die Erde ist bei weitem keine Kugel!) aus einer Peilung verschiedener leuchtender Punkte die Position auf seiner Oberfläche zu bestimmen und dieser Berechnung sein Leben und das der Passagiere anzuvertrauen.

Hier sind noch zwei Bilder vom Modell - ich finde, daß die Constellation schon eine der stilvolleren Methoden war, basierend auf solchen Navigationsmethoden zu reisen Es ist exportiert und vollständig animiert, also kommt als nächstes die Normalmap drauf...

---

Nachtrag: Hier sind die ersten Bilder aus TPF2. Das Modell hat jetzt die Anfänge einer Normalmap drauf und auch einige erste allen Anstrichen gemeine Details. Die Normalmap und die ersten Details entstehen ziemlich parallel in dieser Phase. Daß die ersten Passagiere noch auf stählernen Sesseln reisen, werden sie verkraften; der Innenausstatter wird erst an die Arbeit gehen,wenn außen alles soweit erledigt ist.

Morgen gehts mit den Anstrichdetails weiter, vielleicht wird auch schon eine vorläufige MG-Map fertig.

Aber 180 Grad ist was anderes als einfaches Spiegeln. Drehen ist Spiegeln um X und Y

Aber nur um eine Millisekunde, das zählt quasi gar nicht

Wenn du ein Modell anhand einer Abwicklung anstreichst, dann stimmt die .tga mit der Abwicklung überein; die .dds ist immer vertikal gespiegelt.

Wenn du einen Repaint auf Basis einer .dds machst, ihn aber als .tga speicherst, ist es genauso "falschrum". Das heißt also: Wenn du jetzt eine Texturdatei als .tga gespeichert hast und es so aussieht wie auf dem Bild, dann hast du zwei Möglichkeiten. Entweder du spiegelst das Bild vertikal und speicherst es als .tga, oder du läßt es so wie es ist, aber speicherst es als .dds (DXT1 mit Mipmaps).

Dann sollte es funktionieren.

Das wird ganz schnell zu einer klassischen Optimierungsaufgabe mit n Variablen, wobei n die Zahl der zu beliefernden Industrien ist.

Wenn die Höchstmenge der pro Zug zu transportierenden Waren G ist, dann muß die Kapazität K je Ware so adaptiert werden, daß der Profit P maximiert wird. Für einen Zug gilt also G = K₁ + K₂ + K₃ +... + K_n mit P_K1 + P_K2 + P_K3 + ... + P_Kn = max.

Und dann bestückt man den Zug entsprechend mit Waggons, um die für das Optimum nötigen Waren mitnehmen zu können.

Die meisten Modelle haben nicht nur ein Material, sondern bestehen aus soliden Teilen, einigen durchsichtigen Teilen, vielleicht ein paar Lichtern und so weiter. Das führt dazu, daß auch meist verschiedene Materialien verwendet werden müssen, die natürlich alle auf ihre zugewiesenen Texturdateien zugreifen müssen.

Es gibt hier nun mehrere Möglichkeiten, wie man vorgehen kann. Man könnte die leuchtenden Teile gemeinsam mit allen anderen auf eine große UV-Map werfen und ihnen dann nur über das Material die Leuchtkraft zuweisen. In diesem Fall würde man dem EMISSIVE-Material die gleiche Albedo-Map wie den soliden Teilen, diesmal aber als "map_emissive", zuweisen. Diese Datei ist mindestens 1024 Quadratpixel groß, meistens deutlich mehr. Oder man baut eine separate, kleine Texturdatei mit vielleicht 256 Quadratpixeln und läßt die leuchtenden Teile ihre Farben von ihr abgreifen.

Im ersten Fall würde man die große Albedo-Map sowohl im "Emissive" als auch im allgemeinen Material anfordern, sie also zweimal laden lassen. Im zweiten Fall hat man zwei verschiedene Texturdateien, die nicht miteinander in Verbindung stehen.

Was ist hier ressourcensparender? Lädt das Spiel eine zweimal angeforderte Texturdatei tatsächlich zweimal, so daß sie zweimal Speicherplatz einnimmt? In diesem Fall ist die Lösung mit einer kleinen zweiten Texturdatei sicherlich besser. Oder schafft es das Spiel, eine einmal geladene Texturdatei nur einmal im Speicher zu haben, aber für zwei Materialien zu verwenden? Wenn das so wäre, dann wäre die gemeinsame UV-Map und die doppelte Verwendung der Albedo nicht unvernünftig.

Yoshi ?

Bei sowas ist ein Screenshot hilfreich zur Fehlersuche