Beiträge von Ehrler

Interessant zu wissen wäre, ob der angekündigte Performancepatch Savegame-Kompatibel ist. Hat sich da schon mal jemand zu geäußert?

Möglicherweise verwendest du zu viele Haltestellen und zu lange Routen, sodass die Sims zu Fuß schneller am Ziel sind. Ggf. erreichen deine Sims über die Routenführung auch nicht alle Stadtteile optimal bzw. müssen oft umsteigen.

Ich habe mir gerade dein neues Video zum Tal bei Kapfenberg angeschaut. Es ist sehr beeindruckend, was du mit dem neuen Kameratool und deiner Liebe fürs Detail aus dem Spiel rausholen kannst. Es macht mir großen Spaß deine Anlage anzuschauen, eigentlich schon mehr als selber zu bauen.

Im Tal haben mich die zum Teil sehr geringen Abstände zwischen den Zügen überrascht. Ich hätte gedacht, dass die dir Probleme machen würden, da es ja, sobald ein Zug hält, beinahe sofort zu einer Kettenreaktion kommt. Insbesondere zwischen Güter- und Personenzügen, z.B. ab Minute 7:23.

Zitat von lange

[...], wenn es für Train Fever und/oder Transport Fever m-Wagen geben würde.

Schon klar Nutzen kannst du sie trotzdem.

Aber die gibt es doch?

m-Wagen 1954 (Repaint)

m-Wagen 1959

m-Wagen 1963

Zu den Dampflokomotiven habe ich eben einen sehr schönen Kurzfilm auf Youtube entdeckt, der auch auf technische Details eingeht. Insbesondere zu Anfang werden auch die verschiedenen Modelle und den Zuggarnituren vorgestellt. Der Rest ist aber auch sehr interessant

Deutzer Dampfer

Es gibt Neuigkeiten. Urban Games, in Person von Tom, hat auf meine Anfrage reagiert und meine überstellten Dateien ausgewertet. Vermutlich hat deine Mod mit dem Fehler nichts tun, sondern die Ursache ist auf meine Änderungen zurückzuführen.

Laut Tom versucht auf meiner Karte eine Stadt ein Gebäude upzugraden. Die Stadt kann jedoch keinen passenden Haustyp finden bzw. bauen. Tom gab mir weiterhin den Hinweis, dass für jedes Jahr und jede Grundstücksgröße ein passendes Gebäude vorhanden sein muss. Ich vermute daher, da ich ja die Epochen B und C weit nach hinten verschoben habe, dass die Spielmechanik mit fortgeschrittenen Datum größere Gebäude bauen möchte, die in Epoche A gar nicht existieren. Insofern scheint es nicht nur eine Abhängigkeit zur aktuellen Epoche zu geben, sondern ebenfalls zum aktuellen Datum.

Wenn das nicht von Urban Games selbst behoben wird (im Rahmen der Optimierung der Modbarkeit) bzw. aktuell erst einmal für mich, versuche ich gerade einen Workaround zu entwickeln. Entweder die zusätzlichen, datumsabhängigen Gebäudegrößen in den Epochen B und C zu löschen oder neue Gebäude, Dummys etc. in die Epochen B und C einzubauen, sodass dieser Fehler nicht mehr auftritt.

Frage an euch: Ist das Hardcoded? Wenn nicht, in welchen Dateien kann ich meine vorgeschlagenen Änderungen vornehmen?

Zitat von Grimes

Und is ja nicht so als ob ich heute irgendwie Modding Technisch total ausraste

Ich glaube, wir haben alle nichts dagegen, wenn du weiterhin ausrastest

Vielen Dank für die Silberlinge!

Hallo Atomic Dad,

ist bisher auch nur eine Vermutung. Ich habe auch Urban Games angeschrieben und gefragt, ob die mit dem Fehler was anfangen können.

ich habe die Datei mal dem Anhang beigefügt, aber als .txt. Die .lua kann ich hier nicht hochladen. Ich habe nur die Jahreszahlen in den Zeilen 146 und 147 geändert. Zur Zeit probiere ich ein drittes Projekt, aber dieses mal ohne Änderung der townbuildingutil.lua. Weiterhin habe ich deine Custom-Version des Epochen-Mods nun auf die Jahre 1910-1974 eingeschränkt, bleibe also definitiv nur in Ära B. Mal sehen ob das was bringt.

Hallo Conecto,

mit dem Schönbau-Modus ist in dem Fall vmtl. genau das gemeint, was du gerade an Mods angefragt hast. Mit einem Kostenlos-Mod rückt der wirtschaftliche Sinn des Spiels nämlich in den Hintergrund. Weiterhin kann man seinen persönlichen "Schönbau-Modus" natürlich weiter optimieren. Beispielsweise mit dem von dir erwähnten entfernen oder präziser, dem verlängern der Lebensdauer ins Unendliche und der Verfügbarkeit der Fahrzeuge direkt am Anfang des Spiels.

Anbei eine kleine Zusammenstellung der Mods, die ich nutze:

Kostenlos-Mod: Standard von Urban Games. Sollte von Anfang an mit installiert sein.

Endlose Lebensspanne für Fahrzeuge

Alles Verfügbar ab 1850

Alternativ kannst du auch den Epochen-Mod nutzen, wenn du zum Beispiel gerne im Dampflok-Zeitalter spielst. Du stellst eine von-bis-Zeit ein und bekommst nur die Fahrzeuge angezeigt, die es in der gewählten Epoche auch gab. Die Fahrzeuge sind dann ebenfalls sofort verfügbar und werden auch nicht mehr aus dem Spiel genommen.

Epochen-Mod

Gruß,
Ehrler

EDIT: Da waren wohl einige schneller als ich

Öfter mal was neues...

Ich habe nach den oben beschriebenen Fehler meine erste Map aufgegeben und eine neue angefangen und bereits 13 Jahre (8.000 ms) gespielt und einige Städte angebunden jedoch noch keine Industrien. Mit der neuen Map habe ich jetzt wieder exakt den gleichen Fehler. Die ersten Jahre absolut keine Probleme und dann zu irgend einen Monatswechsel macht es "zack" und das wars. Ab diesem Zeitpunkt stürzt das Spiel bzw. dann das Savegame ständig ab.

Neben vielen Mods habe ich selber einige Änderungen vorgenommen. Neben mehr Bäumen, weniger Städte etc. habe ich allerdings ebenfalls die drei Epochen des Spiels modifiziert. Die Aktivierung der Epochen B und C habe ich in das Jahr 4000 und später verschoben um dauerhaft mit Gebäuden und Fahrzeugen der Epoche A spielen zu können (passt halt besser zu den 50er und 60er Jahren). Weiterhin nutze ich zusätzlich den Epochen-Mod von @Atomic Dad für eine eingeschränkte Fahrzeugauswahl. Ich vermute, dass möglicherweise die Mod und meine Änderungen nicht passen. Allerdings wundert es mich, dass ich immer einige Jahre ohne Probleme spielen kann
Langsam nervt es mich jedenfalls zunehmend, dass ich Schönbau im fortgeschrittenen Stadium betreibe und dann dieser Fehler erscheint.

c:\build\transport_fever\steam\transport_fever_release\src\game\procedural\buildingtyperep.cpp:71: class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > __cdecl `anonymous-namespace'::GetCandidates(const class std::unordered_map<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct BuildingType,struct std::hash<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,struct std::equal_to<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,struct BuildingType> > > &,const class ConstructionRep *,int,int,int): Assertion `!result.empty()' failed.

Vielen Dank, Yoshi. Das war der Fehler. Es funktioniert jetzt so, wie ich mir das vorgestellt habe

Danke für den Hinweis. Ich habe einen Lexikon-Eintrag von Mediziner gefunden und mich daran orientiert. Verwendet habe ich jetzt DXT3 und es hat soweit funktioniert.

Allerdings habe ich jetzt das Phänomen, dass ich die neue Textur nur in sehr niedriger Entfernung sehen kann. Ab ein paar Metern Entfernung scheint sich die alte darüber zu legen, obwohl ich diese aus der .dds entfernt habe. Ich habe davon einen Screenshot angehängt. Bei dem Objekt handelt es sich übrigens um den Bahnhof Windsheim 1976 für Transportfever, dem Repaint von Trunky, das von Maverick portiert worden ist. Ich versuche mit diesem Repaint jetzt selbst für meine privaten (!) Zwecke ein zusätzliches Repaint mit der alten Bahnsteigstextur vom Bahnhof_1900 zu erstellen.

Ich bin was Texturen angeht übrigens blutiger Anfänger... Aber ohne es zu probieren lernt man nun mal auch nichts.

Ich vermute gar keine, da Standardeinstellung. Welche ist Empfehlenswert?

Hallo,

ich greife das Thema mal auf, da ich ein ähnliches Problem habe. Ich versuche mich ebenfalls an ein Repaint, bei dem ich eigentlich nur ein Textur in der vorhandenen .dds ändern möchte (Ordnerstruktur und Pfade habe ich schon angepasst). Hierfür habe ich in der .dds die bestehende Textur ausgeschnitten und eine Textur aus einer .tga aus einem TrainFever Mod kopiert und in der .dds eingefügt und hoch skaliert, so das es passt. Gespeichert habe ich ich die Datei wieder als .dds und habe die bestehenden MipMaps übernommen.
Im Spiel stürzt das Spiel jedoch bei der Auswahl des Bahnhofs ab. In der stdout steht folgende Fehlermeldung:

Assertion `compress == gli::is_compressed(texture.format())' failed.

Was ist das Problem. Stelle ich mir die Anpassung der .dds zu einfach vor und ich muss noch weitere Punkte beachten? Ich nutze übrigens Gimp mit dem dds-plugin.

Hallo zusammen,

ich bespiele zur Zeit eine neue Karte und bin bereits sehr weit fortgeschritten. Bis vor einigen Saves auch vollständig ohne Probleme. Allerdings kommt es seit einigen Saves mittlerweile zu unregelmäßigen Abstürzen. Manchmal zum Monatswechsel, manchmal auch mitten im Monat. Anfangs dachte ich, bei beschleunigter Zeit geht mein PC in die Knie, aber ich habe die Abstürze auch ohne beschleunigte Spielzeit und laut Task Manager auch genügend freie Kapazitäten.
Interessant ist auch, dass ich bspw. ein Save habe, das drei Tage später zum Monatswechsel abstürzt und das auch tut, wenn ich es nochmal lade. Manchmal jedoch auch wieder nicht und ich kann ein bis zwei Monate weiterspielen. Momentan hangle ich mich von save zu save. Vielleicht kann ja jemand von euch was mit dem Problem anfangen oder aus meiner stdout.txt die richtigen Schlüsse ziehen.

Danke vorab.

Ehrler

EDIT: Ich habe mal etwas herumprobiert mit meinen alten Saves und ich muss meine Aussage präzesieren, dass die Abstürze unregelmäßig auftreten. Die Abstürze beginnen scheinbar erst mit dem Beginn des Jahres 1985 (direkt zum 1.1.) und anschließend zum Monatswechsel. Wie ich bereits oben geschrieben habe, komme ich mit Glück rund ein bis zwei Monate weiter. Zum Monatswechsel gibt es einen Ruckler. Ist er kurz geht es weiter. Ist er länger, dann stürzt das Spiel ab. In der stdout scheint es ja um die folgende Zeile zu gehen, aber ich werde nicht schlau draus.

c:\build\transport_fever\steam\transport_fever_release\src\game\procedural\buildingtyperep.cpp:71: class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > __cdecl `anonymous-namespace'::GetCandidates(const class std::unordered_map<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct BuildingType,struct std::hash<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,struct std::equal_to<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,struct BuildingType> > > &,const class ConstructionRep *,int,int,int): Assertion `!result.empty()' failed.

Ich hatte erst gestern einen ähnlichen Fall. Allerdings nur im Zusammenhang mit der neuen BR52 von @Grimes. Alle anderen Sounds liefen wie gewohnt weiter. Ein Neustart des Savegames hat Abhilfe geschaffen.

Ah, das ist ja schade. Danke für den Hinweis.

Hallo Grimes,

hast du zufällig einen Link zum realworldmod parat? Ich finde den leider nicht und würde mir den gerne mal anschauen.

Danke Wicked für die Vorlage des Skripts! Ich habe Fred´s Mod eben in einer guten Stunde angepasst und sie läuft.

Deine Probleme mit den abgeschnittenen Höhen habe ich übrigens nicht. Ich habe exakt dein Skript verwendet und keine Probleme.