Beiträge von Rutel

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


    Bei einem Wendepunkt ist es wahrscheinlich (aber nicht garantiert), daß es relativ gut paßt. Es paßt schlecht dort, wo sich die Steigung stark ändert, also die Schienen besonders eng (auf- oder ab-)gebogen sind. Und wenn die Steigung abnimmt, hast Du einen Buckel und kannst mit einem Durchhängen der Oberleitung auch nichts wollen, das wird nur schlimmer.


    Man kann einen zu großen Abstand zwischen Stromabnehmer und Oberleitung auch dahin deuten, daß der Übergang zwischen den Steigungen zu heftig ist. WernerK mit seinen realistischen Gleisparametern läßt grüßen ... :-)

    F11: Die Oberleitungsmod entspricht in sofern der Zaunmod, als daß die Masten den Pfosten entsprechen und beide, Zaun und Fahrdraht, zwischen den Pfo- bzw. Masten gerade sind. In beiden Fällen ist es das technisch bzw. physikalisch einzig richtige. Wenn sich die Steigung arg ändert, mußt Du tatsächlich engere Mastabstände nehmen. Realistischerweise müßte sich der Stromabnehmer an die Oberleitung anpassen, nicht umgekehrt. Aber sowas würde ziemlich auf die Performance gehen.

    TT junkie: Die Kabelspannung bezieht sich meines Wissens (und auch sinnvollerweise) nur auf das Tragseil, also das obere. Das hängt in der Realität tatsächlich weniger durch als bei vielen Modelleisenbahnen oder bei TpF(2). Aber man hat sich an letzteres gewöhnt, also wird beides mehr oder weniger angeboten.

    Leider habe ich keine Zeit, das auszuprobieren. Aber mal als Idee in die Runde geworfen, könnte man

    • einer .mdl einen TransportNetworkProvider verpassen. Ist als flexibel einsetzbare Mod nervig, weil man entweder Infos von der .con in die .mdl transferieren muß, was geht aber haarig ist, oder für jede einzelne Kreuzung eine eigene .mdl basteln muß
    • einer .con mittels result.edgeLists und result.runways Lanes verpassen. Ich weiß nicht, ob das nur für "stations" und "depots" geht, die gegen den Construction Mover immun sind, aber das Wiki schreibt "constructions can have streets and tracks too" zwar unter Stations aber ohne Einschränkungen.

    In beiden Fällen ist das Problem, daß mindestens eine Straße seitlich geneigt ist. Das wird eine Straße nicht vertragen, aber möglicherweise eine .con oder .mdl. Das muß also noch innerhalb der .con oder .mdl korrigiert werden. Und die Terrainanpassung dürfte auch noch lustig werden, aber mindestens bei einer .con könnte eine Chance da sein. Also jedenfalls ein Haufen Arbeit. Und das Resultat ist eben eine Konstruktion, die wie eine Straße aussieht, und keine Straße.

    Ich sach mal unverbindlich:

    Transport ist der Anteil, der durch Dein Transportnetzwerk geht. Versand sind die Waren, die tatsächlich angekommen sind, werden also deutlich später verbucht als Produktion oder Transport.

    Den Eindruck hatte ich mindestens.

    @Passalski: Hätt' sie es mal getan, hätte sie Weihnachten '89 überlebt. So hat sie nicht mal ein Rezept hinterlassen.


    "Marie Antoinettes Schlankheitsrezept: Torte"

    Ach,waren das Zeiten.

    Aus der Erinnerung hatte ich damit kein ernstes Problem gehabt. Aber vor dem letzten Update. Schau mal, ob es nicht ein unsichtbares, aber anklickbares Dingsda gibt, das Du löschen kannst.


    Deine Signatur erinnert mich immer an den Witz

    Otto (mit oder ohne von) Habsburg läuft im Europaparlament durch die Gänge und findet ... niemanden. Nach langer Suche trifft er doch auf jemanden, der erklärt: "Wissen Sie nicht, daß Europameisterschaft ist?" "Wer spielt denn?" "Österreich - Ungarn." "Gegen wen?"

    Danke Dir für die Antwort. Auch wenn sie bei dem Zustand der Dokumentation viel experimentelles Programmieren erfordert (experimentell habe ich vorhin herausgefunden, daß die .con bei jedem Klick im Konfigurationsfenster aufgerufen wird, was mir vom Aufbau der .con her völlig unverständlich ist - da hätte ich gedacht, daß sie pro Exemplar genau einmal aufgerufen wird). Ich fürchte, da habe ich interessantere Dinge zu tun, mit denen ich meine Zeit totschlagen kann.

    Bei meinen Quertragwerken würde ich gerne mehr Konfigurationsmöglichkeiten in der Construction anbieten. Das würde bei einer konventionellen Auswahlfenster zum Auswählen der Optionen den Rahmen hoffnungslos sprengen, denn ich hätte dann für jeden Aufhänger eine Reihe Auswahlmöglichkeiten. Als Beispiel nehme ich Position grob, Position fein, Richtung, Isolatorfarbe. Mal 14 Gleisen gäbe das 56 Elemente, das sind zu viele. Was ich mir als Komprimierung vorstelle, ist

    a) eine Gleisauswahl (1 bis 14) über eine Reihe Buttons oder einen Schieberegler

    b) nur vier Buttons darunter, nämlich, wie oben Position grob, Position fein, Richtung, Isolatorfarbe.

    Wenn man jetzt in der Gleisauswahl ein anderes Gleis auswählt, müßten sich die vier Elemente (wohl 2 Schieberegler, 2 Reihen Buttons) unten ändern, und zwar nach der Konfiguration für das gerade frisch ausgewählte Gleis. Wenn Gleis 3 auf Position 4 m 35 cm einen braunen Isolator hat und der Halter rechts an den Fahrdraht kommt, müssen genau diese Informationen in die Elemente geschrieben werden, wenn man Gleis 3 auswählt, egal was beim Gleis vorher war.


    Weiß jemand wie das geht und kann das erklären? Ich habe bisher etwas mit dem onValueChanged-Callback beim Schieberegler herumgespielt, aber mir ist z. B. völlig unklar, ob und wie man die tatsächlichen Werte ändern kann. defaultIndex wird ja wohl nur beim erstmaligen Erstellen der Construction ausgelesen. Oder geht das besser in der updateFn?

    Vielleicht etwas klarer: Jedes Objekt hat einen Ursprung (der, den Du aus Mathe vom Koordinatensysem her kennst) bzw. Fußpunkt. Beim Skalieren werden alle Abstände zu diesem Fußpunkt skaliert. Der ist also der einzige Punkt, der beim Skalieren stehen bleibt. Wenn der außerhalb Deines Modells ist, sieht es bei der Skalierung auch nach einer Verschiebung aus. Etwas trickreicher sieht es aus, wenn Du die beiden folgenden Situationen betrachtest - aber es ist eigentlich genau das gleiche Phänomen:

    Ist der Fußpunkt in der linken unteren Ecke, steht die vergrößerte Tür einseitig nach rechts und oben über.

    Ist er in der Mitte, steht die vergrößerte Tür gleichmäßig nach allen Seiten über.


    Ich weiß im Moment nicht, ob sich bei Dir die Verschiebung, die Du erwähnt hast, vor oder nach der Skalierung auswirkt. Wenn vor, müßtest Du die Verschiebung um den Skalierungsfaktor verkleinern; vorausgesetzt, der Fußpunkt sitzt richtig. Dein Problem läßt sich aber immer durch die geeignete Verschiebung lösen.

    Gibt es eigentlich eine Möglichkeit, Teilmodelle so aus Blender zu exportieren, daß der Koordinatenursprung in FBX durch die lokalen und nicht die globalen Koordinaten gegeben ist? Ich versuche gerade, mich mit dem Lampen-Magapack zu beschäftigen, das eine Unzahl Lampen an verschiedenen Positionen in Blender hat. Ich würde gerne vermeiden, die alle von Hand verschieben zu müssen.

    Eine Lösung habe ich im Internet im Zusammenhang mit der Unreal Engine gefunden, aber da ist der Trick, entsprechende Optionen beim Import in die Unreal Engine zu setzen. Das geht mit dem Model Editor anscheinend nicht.

    So, wie es aussieht, muß ich mir auch bei dieser Lösung wirklich scharfe Kanten abschminken (da muß höchstwahrscheinlich UG noch eine Menge programmieren, bis das geht, bzw. man muß Platten benutzen, die schmiegen sich aber nicht ans Gelände an). Aber was mir ähnlich stark fehlt: Es gibt einige Bodentexturen mit Vorzugsrichtung (Furchen im Ackerboden, Pflanzreihen, ...). Da stört mich immer, daß die zwangsweise parallel zu den Mapkanten sind. Siehst Du, VacuumTube, eine Chance, innerhalb Deiner Figur die Texturen auch gedreht aufzubringen? Ob mit Rotatlonsparameter oder parallel zur ersten Kante, die man definiert, wäre mir egal. Man kommt mit beidem zum Ziel.


    Und zu der Frage nach den wichtigen Mods: Wahrscheinlich alle :-) . Ich nutze zur Zeit einige von Mariotator und die Tropical-Texturen von Ingo-1111, bin aber etwas geizig mit dem RAM. Kann man an die Texturen-Liste rankommen? Dann brauchst Du keine Sonderlösung für jede neue Texturenmod.

    Gut, das Stehenbleiben der Fußgänger ist nicht realistisch. Daß die so hirnlos auf die Straße rennen, daß die Autos nicht mehr vor und zurück können, schon eher ...

    Deshalb gibt es an Karneval in Köln auf (mindestens) einer Strecke seit ~10 Jahren keinen Straßenbahnverkehr mehr, nachdem im Jahr davor die Durchschnittsgeschwindigkeit bei 0,5 km/h lag.

    Noch so 'ne Frage von mir: Hast Du eigentlich einen Trick für den Graben neben der Bahnstrecke? In TpF2 war's einfach: Straße daneben bauen, absenken bis zum Gehtnichmehr, Straße abreißen, fertig. Das ist ja nicht mehr so einfach.

    Ansonsten sind alle 14 Brücken derzeit aus Vanilla Materialien erstellt. Das ist natürlich wieder gut für die Performance. Dennoch werde ich zum ersten Mal in meinen Modellen mit LoD-Stufen arbeiten.

    Damit es nicht zur Verwirrung führt: LoD-Stufen und Vanilla-Materialien verbessern beide die Performance, haben aber nichts miteinander zu tun. LoD-Stufen sorgen dafür, daß bei weit entfernten Objekten weniger Tris (Dreiecke, aus denen das Modell zusammengesetzt ist) berechnet/getestet werden müssen. Vanilla-Texturen belegen kein zusätzliches Video-RAM, so daß weniger Daten hin- und hergeschaufelt werden müssen, wenn man viele Mods hat (hoffe ich mindestens).

    Du kannst m.W. generell nicht den Straßen die Möglichkeit entziehen, das Terrain anzugleichen. Du kannst aber den Böschungswinkel auf 90° stellen. Das löst wahrscheinlich die eine Hälfte Deiner Schwierigkeiten, weil Du mit dem Geländetool dann jede gewünschte geringere Neigung selbst basteln kannst.

    Da Wasser immer bergab fließt, habe ich das Planieren auch immer als Feature angesehen. Ein leichtes Gefälle von Hand zu planieren ist zum Junge-Hunde-Kriegen.

    Die Pfeiler, die es nicht gibt, werden meistens mittels der Blöcke von JoFried und anderen gebaut. Da das alles nicht original aussieht, schlage ich vor, daß Du Dir ein Pfeiler-Design überlegst, das etwas zu groß ist, so daß Du die automatisch erstellten Pfeiler ebenfalls "einpacken" kannst. Das geht meistens gut, weil die normalen Brückenpfeiler alle eher schlank sind. Viele Strompfeiler sind auch so lala stromlinienförmig und müssen gar nicht genau so aussehen wie die an Land. Es gibt auch Mods mit Brücken ohne Pfeiler, und die meisten "normalen" Steinbrücken sind sowieso eine Katastrophe. Ziemlich wortwörtlich, weil sie sofort einstürzen würden, wenn man die in der Realität baute. Es gibt ein paar Mods mit vernünftigen Bögen.


    Unter anderem wegen der von Dir erwähnten Probleme mit Brückenpfeilern habe ich keine breiteren Bäche/Flüsse als 10 m vorgesehen. Die unpassend geringe optische Tiefe ist ein weiterer Grund. Aber das bekommt nur UG oder vielleicht jemand wie eis_os bzw. jemand anderes aus der NEP²-Truppe hin. Ich verstehe dafür zu wenig von den Shadern. Man müßte ein eigenes Material Wasseroberfläche definieren, das erstens den nötigen Brechungswinkel erzeugt und dann dahinter Shader für Absorption in Wasser statt in Luft benutzt (diese möglichst konfigurierbar für unterschiedlich sauberes Wasser). Und das dann so, daß das im Spiel verstanden wird.


    Mit den Fahrspuren habe ich herumexperimentiert. Du landest da - mindestens mit den TpF2-Versionen von vor ein paar Jahren - bei einem Absturz des Spiels, sobald Du oder das Spiel eine Verbindung zum Bach baut. Du kannst mal rumexperimentieren, aber verwende keine Stunden darauf, falls es bei Dir auch abstürzt. Falls das nicht mehr passiert, wäre ich an der Info interessiert ...

    Die Farbprobleme kommen aus dem automatischen Verhalten von TpF2 - steile Böschungen werden steinig, das ist Deine weiße Linie. Einen Überlapp gibt es zwischen angrenzenden Farbflächen (fast) immer. Deshalb sind bei den automatischen Landschaften von TpF2 die Flußufer sandig - das gilt aber nur für die offizielle Wasserlinie bei 0 m.

    Die Möglichkeiten, die sich bieten, sind Handarbeit:

    - Das Ufer mit geeigneten Pinseln nachbearbeiten. Dazu gibt es von Ingo-1111 Pinsel, die unter tropisch laufen, eine Reihe davon passen aber auch gut ins gemäßigte Klima. Auch bei Mariotator gibt es brauchbare Bodentexturen. Wenn ich es richtig im Kopf habe, kannst Du mit gedrückter SHIFT-Taste auch unter meinen Wasserstraßen den Grund ändern. Die Wasseroberfläche bleibt erhalten.

    - Der Hauptweck von Bäumen (vor allem teilversenkten als Büsche) und Steinen: Unzulänglichkeiten verdecken. Bei Steinen brauchst Du die No-Collision-Mod. Damit kannst Du auch bei meinen Bächen die Gleichförmigkeit aufbrechen.

    Das ist für einen Bach natürlich eine Haydnarbeit, aber ich glaube, so lassen sich unabhängig vom gewählten Ansatz brauchbare Ergebnisse erzielen. Und ja, rundum glücklich bin ich mit keiner Wasser-Lösung. Übrigens auch nicht mit der Tiefenwirkung.

    Ich sehe das Problem oft weniger darin, mal eine Brücke horizontal zu bauen, als darin, daß man dazu gezwungen wird, durch viele Mods übrigens. Jede Horizontale ruiniert den Übergang zwischen verschiedenen Höhenstufen. Das ist übrigens eine Frage der zweiten und nicht der fünften Nachkommastelle, und die ist relevant. Wenn es mir der Rest wert ist, passe ich sie so an, daß ich Brücken, Rampenverkleidungen etc. scheren kann. Aber es wäre schön, wenn es Allgemeingut würde: Hochbahnen und Brücken sind normalerweise nicht horizontal und Stufen oder Drehungen sind häßlich (Stufen wegen der Stufe an sich und weil immer irgendwo etwas richtig falsch hervorguckt - Drehungen wegen der nicht senkrechten Wände und in Kurven wird das ungebührliche Hervorgucken noch abstruser). Verzerrte Ziegel sind es zwar auch, aber bei <5° fällt es noch nicht so auf. Also brauchen wir Scherung und nicht Drehung.

    Laut Wiki gibt es einen Parameter size01 in particleSystem.emitter, der die anfängliche Partikelgröße in m angibt. Ich nehme an, Du hast ihn schon ausprobiert. Tut der nicht?