Beiträge von Rutel

Hm. Eine Ferndiagnose ist mit den Infos nicht so ganz einfach. Hast Du Dich an die Hinweise zur Namensvergabe der Dateien, die ich map01.lua etc. genannt habe, gehalten? Die müssen hintereinander in der entsprechenden TpF2-Struktur sein. Ich hatte die Bestätigung, daß die Dateien dort alphabetisch nach Dateinamen sortiert sind (aber keine Garantie bekommen, daß es so bleibt).

(in irgendeinem Experimentierstadium hatte ich auch mal Probleme, wenn die Dateinamen nicht map01.lua ... sondern wimz01.lua hießen. Aber ich hoffe eigentlich, daß das gelöst ist).

Sind die falschen Bodentexturen stark (Faktor 1000 oder so) vergrößerte Varianten der normalen Bodentexturen, die man malen kann?

Edith: Hast Du bei angenommenen 16 Teilbildern für die einstelligen Nummern die 0 eingebaut (also map01.lua und nicht map1.lua)? Sonst funktioniert die alphabetische Anordnung natürlich auch nicht.

Du kannst auch mal nachschauen, ob alle Kacheln am Ende der Liste der Boden-Mal-Texturen im Spiel zu finden sind.

Eigentlich wollte ich sie dort nicht haben, aber bei den Spielstrukturen, die ich gekapert habe, ist es so. Ich konnte sie aber ans Ende verbannen, wo sie nicht stören sollten.

Über diese Idee hatte ich auch schon mal philosophiert. Für viele Spieler würde ein Fahrplan lästig sein, weil das Spiel zu einer Programmieraufgabe wird. Ein paar werden helle Freude daran haben, weil das Spiel zu einer Programmieraufgabe wird. Deshalb sollte der Fahrplan optional sein. Leider greift das stärker ins Wirtschaftsspiel ein, so daß vermutlich ein neues Balancing nötig wird: Mit Fahrplänen läßt sich eine Reise viel besser planen, weil sie vorhersehbar ist, und bei gutem Aufbau des Plans verkürzt sich auch die Reisezeit, wenn umgestiegen werden muß. Außerdem werden bei einem guten Fahrplan auch weniger Trassen für die gleiche Transportleistung gebraucht, weil die Züge sich nicht ständig gegenseitig ausbremsen. Das könnte man z. B. so ins Spiel einbauen, daß Fahrgäste etwas pingeliger sind und wegbleiben, wenn ein Fahrplan nicht eingehalten wird, aber der Fahrplan selbst auch bei der Reisedauerberechnung berücksichtigt wird und für größere Geduld sorgt (so daß man tatsächlich S-Bahnen alle 20 Minuten fahren lassen kann; oder wenigstens einstellbar). Dann braucht man nicht alle drei Minuten einen fast leeren Zug, was ja eigentlich ziemlich unrealistisch ist.

So weit ich weiß, hat das Spiel einen Maßstab von 1:1 für die Reisegeschwindigkeit, d. h. bei normaler Geschwindigkeit braucht ein Zug mit 60 km/h eine Minute für einen In-Game-km. Das spricht sehr für einen Fahrplan-Tag von 24 Stunden real = ingame. Das kann ja mit der Spielgeschwindigkeit verkürzt werden. Oder halt konfigurierbar.

Insgesamt fürchte ich, daß das für UG zu viel Arbeit für zu wenig Spieler-Begeisterung wird; sie müssen ja von dem Spiel leben, und das geht nur mittels verkaufter Einheiten. Aber vielleicht ist UG bereit, das nötige API dafür zur Verfügung zu stellen (Zugriff auf Timer, Züge, Interface, etc.) und es findet sich ein Modder, der bereit ist, sich mit den ganzen logischen und logistischen Problemen herumzuschlagen, z. B. was passiert, wenn am Rosenmontag der Zug, der um 11:48 in Düsseldorf losfahren soll, noch in Köln steht und sich den Zoch anschaut.

Ich spiele möglichst immer mit nativer Auflösung (1920x1200, Iiyama ProLite E2607WSD Monitor, Graka Nvidia GeForce 1060 GTX), wenn's geht. Ich habe das Moiré bisher nur hingenommen. Aber jetzt bin ich drauf aufmerksam geworden :-(.

Der Screenshot sollte normalerweise erst mal Deine Auflösung fixieren (auch, wenn in dem, was Du gepostest hast, sich die Auflösung noch mal geändert hat). Das Moiré-Muster entsteht ja auch nicht durch die Diagonale, sondern die Auflösung - und auch die maximale Auflösung des Monitors. Ein Monitor hat ja immer eine native Auflösung, und trotzdem kann man andere Auflösungen (meist kleinere) einstellen, um z. B. alte Spiele mit 1024x768 auf einem 1920x1200-Monitor noch spielen zu können. Das gibt schlimmstenfalls noch eine dritte Musterquelle. Aber Du scheinst ja mit der nativen Monitorauflösung angefangen zu haben.

Edit: Hab 'n bißchen rumgespielt: Die Moiré-Muster bekomme ich auch, und zwar bei nativer Auflösung. Und die Idee mit den LOD-Stufen hat einen Haken: Dadurch, daß im flachen Winkel der Schotter von den Schwellen verdeckt wird, ist die Lokführer-Ansicht ganz anders als die von oben. Deshalb sind vor allem die Holzschwellenschienen in weiterer Entfernung aus Führerstandsicht viel zu hell. Dieses Problem kann wohl nur UG lösen.

Eine gute Lösung habe ich leider nicht, aber ich kann erklären, was passiert - vielleicht hilft das ja jemandem:

Du erhältst durch die Überlagerung des Schwellenrasters und des Monitorrasters übergeordnete Strukturen. Das ist der Moiré-Effekt. Deswegen hat das Anti-Aliasing auch eine Wirkung. So etwas kann man im normalen Leben sehen, wenn man sich z. B. einen Maschendrahtzaun durch ein Fliegengitter oder eine geeignete Gardine anschaut.

Gerade habe ich doch eine Idee: Vielleicht kann einer von den Schienen-Freaks herausfinden, ob man mit den LOD-Stufen etwas machen kann?

Die TpF(1)-Version 1.0 ist jetzt fertig und hochgeladen.

oberhausener68 : Da bekommt der alte Kalauer Pf-Erd ja noch einmal eine ganz neue Bedeutung!

Das ganze Städtewachstum bei T(p)Fn beruht auf Nachhelfen (ohne Editor ...); bei TpF2 ist man meiner Erfahrung nach aber schneller an der Grenze, aber Faktor 3 bis 5 gegenüber der Anfangseinwohnerzahl ist drin. In TpF2 wird es sogar im Städtefenster gezeigt: Jeden mit ÖPNV möglichst überall hinbringen, gute Fahrmöglichkeiten mit PKW, Städte möglichst gut versorgen, und das mit möglichst wenig Emissionen. Letzteres verleitet mich (wie die Staus im Vorgänger) zu verstärktem Tunnelbau unter den Städten.

Ich habe mich noch nicht ernsthaft mit den Schwellenwerten und wie sie von Kartengröße/Städtezahl abhängen beschäftigt. Vielleicht tut sich da auch einiges (z. B. daß mehr Städte zu größeren Städten führen).

Ich mache undogmatisch mal dies mal das, je nachdem, wie die Stadt aussieht. Und ich nehme in der Stadt auch Verluste hin, solange die Sims im Zug genug zahlen.

Das ist leider im Endspiel mit wenigen Städten ein Problem, weil die Städte nicht groß genug werden für die riesigen Fahrzeuge, wenn die dann auch noch ein einem relativ engen Takt fahren sollen.

Die 100%-Auslastung stimmt gerade in Städten nicht ganz. Denn die meisten Sims wollen zum/vom Bahnhof. Und viele von denen, die in der Stadt bleiben, sind zu Fuß oder mit dem eigenen Fahrzeug schneller (in jüngeren Jahren habe ich in Köln innerhalb der dichten Bebauung regelmäßig die Straßenbahn versägt und bin nicht sonderlich riskant gefahren). Deswegen habe ich auch geschrieben, daß eine Linie, die den Bahnhof nicht berührt, nahezu sinnlos ist. Du hast also in Bahnhofsferne eigentlich immer leere Plätze - oder Du hast näher am Bahnhof lange Wartezeiten.

Bei Zügen lohnen sich Ringstrecken weitaus mehr, unter der Voraussetzung, daß Du mehr als drei Städte im Ring hast.

Für Luftlinie wird bezahlt, das ist klar. Es gibt trotzdem Fälle, in denen ein Kreisverkehr profitabel ist. Beispiel:

Wenn ich eine relativ große Stadt mit Bahnhof am Stadtrand habe, baue ich oft zunächst zwei Linien: Eine gerade durchs Stadtzentrum und eine, die jeweils ein paar Straßen vom Stadtzentrum entfernt die Außenbezirke erschließt. Das sieht dann ungefähr aus, wie eine dreizinkige Gabel. Wenn man jetzt die beiden äußeren Zinken verbindet, ergeben sich für wenig mehr Strecke oft noch sinnvolle Verbindungen für die Sims - dafür müssen diese Zinken aber in unterschiedliche Gebietsarten enden. Noch klarer bei einer sehr großen Stadt, in der fünf Zinken sinnvoll sind; dann kann man die äußeren sogar durchs Stadtzentrum verbinden. Natürlich wird kein Sim diese Strecke für die Reise vom Bahnhof zur Stadtmitte nutzen, aber von den außenliegenden Wohnbezirken in die Innenstadt oder ins Industriegebiet dahinter schon. Als einzelne Strecke hätte eine Verbindung, die nicht am Bahnhof vorbeigeht, meist keinen Sinn.

Im Einzelfall muß man schon mal ausprobieren, was sinnvoll ist.

Schnurgerade Strecken in die Außenbezirke ... könnte man tatsächlich mal versuchen. Dann müssen schon zu Spielbeginn die Ausfallstraßen gebaut werden.

Neckartenzlingen

(Nordhausen gibt es.)

DH-106:

Auch an der Normalmap sollte es nicht liegen. Das was nach dem smooth aus Blender kam, war tatsächlich Mist, aber ich habe sie hinterher noch mal bearbeitet und sie hat meistens RGB 128/128/255 (bis auf da, wo ich sie z. B. bei Nieten anders haben will). Sie ist auch die gleiche wie auf dem Ponton links; wenn es an der Normalmap läge, hätte ich dort also das gleiche Problem haben müssen. Die scharfen Kanten habe ich per Skript gesetzt:

Edit: Gerade getestet: .dds ist unschuldig, ich habe das gleiche Problem mit .tga.

Bauer33333:

Auf kleinerer Skala ist Rost immer ja/nein, wenn man mal von Ausblühungen unter der Farbe absieht. Und je nach Beanspruchung oder Bearbeitung gibt es auch großformatige Flecken. Konkret habe ich mich an einem Ponton in Mainz orientiert, der diese Streifen hat:

Das Schatten-Problem, das ich in meinem ersten Post angesprochen hatte, löste sich teilweise, nachdem ich die Sichtweiten der LOD-Stufen vergrößert hatte.

Nachtrag: Beim Edge Split modifier gehe ich erst mal davon aus, daß er mir die UV map ruiniert. Wenn ich Transform->Shading->Smooth anwende, passiert genau das, was nach dieser Diskussion passieren muß: Es bekommen alle Flächen use_smooth auf True gesetzt. Damit ist zwar die Kante weg, aber genau in die falsche Richtung: Ich habe überall viel zu viel Gloss. Die drei Texturen sind unverändert.

Das unerwünschte Gloss wird (wie die erwünschte Veränderung durch die Normalen) über die .msh.blob transportiert - ich habe es jetzt auch extra nachgeprüft, indem ich nur die .msh- und .msh.blob-Dateien in die alte Fassung ohne smooth geändert habe: Gloss weg, Mesh-Knicke da. In der .msh (lesbare Textdatei) steht das Zeug nicht drin, also muß es in der .msh.blob sein - die .msh brauche ich aber wegen unterschiedlicher Offsets.

Hab' mal wieder was zu berichten und eine Frage:

Mit externen Rosttexturen bin ich immer noch nicht glücklich geworden. Ich finde, egal was ich mache (auch kleiner skalieren), sehen sie immer aus wie das aufgenähte Fell eines Kampfbibers, der verloren hat. Zu klein darf es auch wieder nicht sein, weil man sonst nur noch die Kacheln sieht. Den Aufgenäht- Eindruck habe ich etwas durch Verstreuen der Pixel im Alphakanal reduzieren können.

Die Fahne werde ich wohl stecken müssen; mal sehen, was bei der Konversion für TpF2 möglich ist.

Und jetzt meine Frage:

Im rechten Ponton ist im gebogenen Abschnitt ein Glanz, der nicht von der Textur kommt. Ich habe ihn, seit ich in Blender die entsprechenden Flächen als smooth markiert habe. Wie kann ich den Glanz wegbekommen ohne das smooth zu verlieren?

Was vielleicht damit zusammenhängen könnte: Ich habe die Texturen seit kurzem im .dds-Format, davor war es .tga.

Zum Vergleich ist auf dem linken Ponton die gleiche Textur. Das Problem tritt rechts an allen vier Seiten auf, und die seitlichen Enden greifen über die gleiche .mtl auf genau die gleichen Bereiche der gleichen Textur zu (ist 'ne Menge Arbeit reingeflossen, die UV-Maps aufeinander zu legen). Ich habe auch bei allen drei Farbvarianten das gleiche Problem - sie greifen aber auf die gleiche metal-gloss-ao zu. Jedenfalls gehe ich davon aus, daß das übers mesh kommt. Die Normalen zeigen in Blender alle brav nach außen.

Mir schießt gerade so eine dumme Idee durch den Kopf, die aber wohl nur bei einigermaßen ebenen und geraden Straßen zieht, und außerdem für jede Straße eine Sonderanfertigung ist:

In der Art der Mauern/Klötze von JoeFried könnte man eine "Mauer" bauen, die Bürgersteig und Bordsteinkante enthält und so im Boden versenkt wird, daß sie die Veränderung des Straßenrandes kaschiert. Um dem z-Fighting zu entgehen, müßte man einen unmerklichen Hügel bauen (hoffentlich reichen da wenige cm oder mm) und kann dann vielleicht sogar eine Bordsteinabsenkung einbauen, die eigentlich gar keine ist. Hm. Wenn's um y rotierbar ist, geht das sogar bei Steigungen.

Das ist ein interessanter Vorschlag. Immerhin gibt es ja Straßen-Mods mit ziemlich schmalen Straßen. Es dürfte aber zwei Probleme geben:

- Die Bürgersteige der Straßen werden bei Straßeneinmündungen immer abgebogen (zumindest bei TpF1, ich glaube aber nicht, daß TpF2 da anders ist). Das sieht ziemlich häßlich aus.

- Performance: Nach den bisherigen Diskussionen habe ich den Eindruck, daß die Wegsuche für Leute und Privat-PKWs den größten Teil der CPU-Load ausmachen und der wesentliche Punkt ist, warum die Performance bei größerer Bevölkerung einbricht. Mit jeder Einfahrt fügt man für jeden Verkehrsteilnehmer, der testweise an der Straße vorbeiläuft, einen zusätzlichen Knoten zum Prüfen hinzu. (Anders gesagt: Schönbaumäßig ist die Änderung der Fahrzeuggenerierung von TpF1 zu TpF2 ein Schuß in den Ofen - es sei denn, jemand knackt den Trick, wie man einen Auto-Besuchermagnet ohne Straße hinbekommt.)

@Marcolino: Komplett unnötig ist eigentlich keine Mod. Auch wenn ich mir nicht jede auf den Rechner ziehen würde. Aber die Geschmäcker sind unterschiedlich.

Bei Kirchen liegt die Sache aber tatsächlich etwas anders als bei den meisten anderen Gebäuden - Ausnahme sind natürlich auch wegen der Funktionalität die Bahnhöfe; Schlösser liegen auf der Kippe: Bei Kirchen ist der Aufbau so fix, daß das Einrasten wirklich hilft. Bei Schlössern wird man wahrscheinlich die Fummelei mit dem Hinsetzen für die größere Freiheit in kauf nehmen. Reihenhäuser mit Einrasten sind problematisch, weil das absolut gerade Straßen ohne Steigung voraussetzt.

Ansonsten: Mir ging es darum, eine Idee in die Welt zu setzen, nicht jemanden dazu zu verpflichten, sie zu verwirklichen.

Für diese Idee wird "unvollständig" ein Ehrentitel sein. Ist es nämlich mit Absicht. Aber vielleicht hat jemand, der schon Erfahrung mit modularen Bahnhöfen etc. hat, Lust, das an einem oder zwei selbstgewählten Beispielen umzusetzen. Ich fürchte, ich habe auf absehbare Zeit keinen Nerv dazu.

Die meisten Kirchen, die zwischen 800 und 1920 gebaut wurden, folgen einem so klaren Schema, daß es sich vermutlich für das modulare System eignet. Es gibt Langhaus mit Mittelschiff und Seitenschiff(en), Querhaus, eventuell mit Seitenschiffen, Vierung, Chor, Türme, ... . Ein Bild aus der Wikipedia:

Interessant ist die Frage der Größen: Für ein Baukastensystem sollte es sicher erst einmal eine einheitliche Entwurfsgröße geben (z. B. daß das Mittelschiff zunächst 8 m breit ist). Dann wäre es natürlich schön, wenn man die modulare Kirche als ganze skalieren könnte. Und es wäre interessant, auch die einzelnen Module gegeneinander zu skalieren, aber da ist die Frage, wie weit es zu Problemen kommt (wohl beim Zusammentreffen von Lang- und Querhaus). "Kann nicht bauen" wäre ein Problem, "unpassende Größe" nicht. Beide Nürnberger Hauptkirchen sehen so aus, also ob sich zwei Architekten nicht einig gewesen wären. Als Module würde ich relativ kleine, aber sinnvolle Einheiten vorschlagen, wie z. B. ein einzelnes Joch des Mittel- oder Seitenschiffs, Turm, Portal mit erstem Joch, Sakristei, eine Apsis, ... .

Jedes einzelne Modul sollte ein in sich geschlossenes "Gebäude" darstellen, damit sich von außen keine Löcher ergeben. Das führt natürlich zu einem relativ fürchterlichen Inneren, aber das haben die Kirchengebäude-Mods mindestens aus TpF1 auch. Und natürlich braucht es eine anfängliche Dokumentation, damit jemand anders eine andere Kirche, die im Original andere Abmessungen hat, zum Baukasten hinzufügen kann.

Das Ziel ist, mit möglichst wenig Aufwand zu einer großen Variabilität der Kirchen zu kommen: Bei romanischen Kirchen dürften die einzelnen Module ziemlich zwanglos austauschbar sein (die Architekten haben ja selbst so gearbeitet). Aber es gibt auch genügend Beispiele von Kirchen, bei denen aus finanziellen Gründen anstelle eines kompletten Neubaus nur ein gotischer Chor an ein romanisches Langschiff gesetzt wurde. Für so etwas bräuchte es dann keine neue Mod mehr.

Hallo nochmal,

Naiv wie ich nun mal bin, habe ich jetzt nach einiger Zeit eine lustig flatternde Fahne, aber leider nur in Blender. Ich bekomme sie nicht nach TpF. Bevor ich weiter Zeit in eine unmögliche Sache verschwende: Geht das überhaupt?

Die Animation der Fahne erzeugt in Blender ein Mesh, das sich über die Zeit ändert. Die Lexikoneinträge und anderen Beiträge, die ich bisher gelesen habe, beschäftigen sich aber ausschließlich mit starren Meshes, die bei der Animation unterschiedlich positioniert werden. Mit bones habe ich mich nicht beschäftigt, weil die für mein Problem die Nachteile beider Ansätze vereinigen. Ich kann mich auch nicht an eine Situation irgendwo in TpF erinnern, in ein Mesh innerhalb einer Animation verändert wird.

Geht das, was ich vorhabe? Wenn ja, hat jemand Tips oder Links auf Anleitungen? Oder kann ich nur die Tris einzeln animieren (was ich sicher nicht machen werde)?

Exakt flach bekommst Du hin, wenn Du ein 16-bit-Graustufen-Bild mit einer einigen Farbe/Graustufe erstellst und das dem Spiel als heightmap anbietest. Wie das geht, findest Du im Lexikon.

Bei einer eigens importierbaren Karte (Du bist bei TpF1?) kannst Du auch in der map.lua den Parameter range verändern.