Beiträge von Freahk

@Tom
Kannst du beim portieren des Düsseldorfers den Stadtbahn Halt im Untergeschoss mit als Option einfügen?
Vielleicht kann man das ja sogar mit snap nodes so basteln, dass genau an den Stellen wo die Treppen zur Stadtbahn sind Snap nodes existieren, an denen man diesen Baustein anschließen kann. Dann bräuchtest du dazu auch keinen Platz im UI zu verschwenden und die die es nicht haben wollen, müssen den Stadtbahn Halt im Keller nicht anbauen.
Wenn das klappt wäre es auch im allgemeinen für Bahnhöfe im Keller praktisch die Maße solcher Schnittstellen zu definieren. Dann könnte man je nach Bedarf unabhängig vom Bahnhof über der Erde den passenden unterirdischen Bahnhof auswählen und dran kleben. Mal braucht man einfach nur einen "einfachen" U-Bahnhof knapp unterhalb der Erde, mal braucht man unter der Erde 2 Etagen die sich in einem bestimmten Winkel kreuzen und mal braucht man zwar nur eine Etage, die muss aber entsprechend tief liegen, um unter einer Straßenunterführung unter dem Bahnhof drunter her zu kommen.
Außerdem hätte man dann eine unabhängige UI für den Bahnhof über und unter der Erde und könnte dann ohne die eh schon volle UI des oberirdischen Bahnhofs zu verwenden die Anzahl der Gleise, die Gleislänge, ggF. die Art der Gleise (Normalspur/Schmalspur), eine Krümmung oder die Steigung der unterirdischen Gleise mit angeben.

Zitat von kwally2014

Aber zur Realität würde es wohl tatsächlich besser passen, wenn man als maximale Obergrenze "1850=ein Geschoss" nimmt und dann alle 20 Jahre ein Geschoss mehr erlaubt.

Das mag bis etwa 1900 ganz gut funktionieren.
Ich habe aber so meine Zweifel, ob es sinnvoll ist die maximale Häuserhöhe z.B. in den 1990ern auf 8 Stockwerke zu limitieren. Wenn ich mal so in die Deutschen Großstädte sehe... Da stammen Hochhäuser Häufig aus den 70ern und haben deutlich mehr als 7 Stockwerke.
Wenn man dann nach Amerika schaut wird das ganze noch viel deutlicher.
Sinnvoller wäre es vermutlich neben der Versorgung mit dem Nahverkehr auch die Einwohnerdichte eines Grundstücks in die Rechnung mit einzubeziehen.
Eine hohe Einwohnerdichte zieht die Attraktivität eines Gebäudes runter, wohingegen eine gute Verkehrsanbindung diese hoch zieht.
Somit würde auch die Idee der Städtezentren, die ich recht gut finde, nicht verloren gehen.

Ich habe aber das Gefühl, dass UG genau das mit der Unterscheidung zwischen Gebäudewert und Grundstückswert bereits tut. Die sollten blos ihre Formel nochmal etwas anpassen. z.B. so, dass in Frühen Jahren eine hohe Einwohnerdichte viel stärker negativ ins Gewicht fällt ls in späteren Jahren. Das würde dann dazu führen, dass die Städte in frühen Jahren erstmal in die Breite, und in späteren Jahren eher in die Höhe wachsen.

Kann ich machen. Musst dich aber etwas gedulden. Vor Freitag wird das nichts.

@Toms Bahnhofsscript ist aber imho recht intuitiv verständlich und du könntest dir recht einfach einen Liege ohne 2. Straßenanschluss basteln. Den Sinn dahinter sehe ich aber noch nicht, da dann entwder eine Hälfte des Bahnhofs fehlt und der abgeschnitten wirkt, oder du kaum Platz sparen wirst.

Dieses extreme Platz ausnutzen und Gebäude zwischenquetschen liegt hauptsächlich daran, dass es jetzt auch kleine Grundstücke gibt. Das finde ich an sich sogar recht gut. In TF fand ich diese recht großen freien Flächen an manchen Straßenecken echt unschön. Ich habe aber auch das Gefühl, dass TpF manchmal Häuser so baut, dass die sich mit anderen Gebäuden überschneiden, was bei deinem Screenshot so zu sein scheint. Das darf natürlich nicht sein. Sowas ist mir aber bisher erst recht selten passiert.

@Nordwestexpress Die Stadt kann nur über Gleise hinweg wachsen, wenn du die Straßenerbindung selbst baust. Ein Bahnhof mit zwei Ausgängen ist eben keine Straßenverbindung.

maybe we could define it as another industry consuming coal and producing nothing so it's not completely useless. Producing electricity would look pretty ugly because we would have to transport an "electricity" good with rail cars...
I don't know how far this is possible, but we could create transformers as a "station" with transmission lines as "rails" and create some special, invisible ost just visible an electricity icon or something like this, "trains" that can only carry electricity.
So far it is in fact possible.
The only problem that would it make looking ugly is that it's not possible (at least not in the rail configs) to define a "type" for the rail so we can't connect transmission lines to normal rails, which would look pretty ugly when a train travels on these "rails".
There are also some other problems like "what happens when you build it on the ground or as a bridge or even as a tunnel (earth wires). How can we make these look well."

I'll try a bit around with it in late February if some other people do also find this interessting and UG didn't give us a solution for mission scripts in normal games until late February.
I already got a small list of what to do in February but all of these things depend on mission scripts in normal games...

Ok.
Wenn ich das richtig verstanden habe ist das Problem für den Tag/Nacht Wechsel folgendes:
Wenn du es als Mod bastelst, bekommst du das Spiel in den Nachtmodus, bekommst aber das onUpdate Event nicht mit.
Wenn du im Szenario bist, kannst du zwar den Eventhandler für das Update Event erstellen, kommst aber nicht an die Config um die Helligkeit zu ändern?

Zitat von homiefoever

es gibt keine findbare Timeout funktion, die es ermöglichen würde eine funktion alle x sekunden auszuführen.

Stimmt, sowas hat lua leider nicht... zumindest nicht direkt. Es gibt da ganz viele mehr oder weniger (meistens eher weniger) schöne Wege das hinzubekommen.
Das Vorgehen ist dabei meistens:
Einen weiteren Thread, in Lua heißen die Coroutine, starten, in diesem Thread in einer Endlosschleife etwas machen und diese nach jedem Durchlauf "warten" zu lassen, wobei genau hier das Problem liegt...
Es gibt viele Möglichkeiten ein Lua Programm "warten" zu lassen und alle verwenden entweder nicht plattformunabhängige Systemaufrufe oder busy waiting oder irgendwelche libs, die auch wieder nicht Systemunabhängig funktionieren...

Zitat von homiefoever

Laut Urban Games ist es technisch nicht möglich in einem mod (sprich mod.lua) in einem freien Spiel auf mission scripts zuzugreifen

Schade...
Besonders schade, dass ich das jetzt erst lese. Ich versuche schon seit Tagen in ner Mod an die UI aus den Szenarios ran zu kommen

Es ist aber nicht weiter problematisch, dass man an game.config nur in einer mod ran kommt, da man ja in Szenarios trotzdem mods verwenden kann (siehe urbangames_campaign_*_mission_*_1 Mods im mods Ordner von TpF.

Die hinterlegten maps in den Kampagnen sind doch auch nur normale savegames oder?

Dann müssten wir jetzt nur noch eine mod bauen, die nach dem erzeugen der map automatisch die Karte speichert und das savegame in einen szenario Ordner verschiebt. Das drum herum was man für die Szenarios benötigt muss da natürlich auch erstellt werden aber das dürfte auch kein Problem sein und schon können wir mit dieser Mod eine map erzeugen in der vollständiger Zugriff auf jegliche missions scripts zuzugreifen und hätten somit die volle modbarkeit.

Das einzige was daran für den user verwirrend sein könnte ist, dass er die Map dann quasi doppelt erstellen muss: Einmal "normal" mit allen Mods die er haben möchte und der scenarioMaker mod und danach nochmal als Kampagne, damit alle Scripts verfügbar sind. Die Savegames kann man ja später dann ganz normal laden. Das geht ja bei den normalen Szenarios auch.

Ich setz mich mal ran und probiere ein wenig aus

In deer Realität steht an solchen Gleisen häufig eine Rangierlok.

Wenn ich deine Frage richtig verstanden habe dann ja.
In einem Bahnhof kann ein Teil der Gleise enden und ein anderer Teil durchführen.

Zitat von Licaon

wozu programmierbare Signale, bzw was willst du programmieren?

Zitat von Licaon

Sehe hier gerade dein Problem nicht.

Ich verstehe den Wunsch schon. Ist dir das noch nie passiert, dass das recht einfach gestrickte Signalsystem immer fröhlich langsamen, noch stehenden Zügen von einer Nebenstrecke grün gibt und die bereits rollenden Züge auf der Hauptstrecke damit ausbremst?
Genau sowas könnte man damit selbst in die Hand nehmen. Dennoch finde ich ingame programmierbare Signale nicht unbedingt die beste Lösung. Optimalerweise kann man beim modden das Verhalten der Signale mit einem Script steuern und muss die passenden Signale dann einfach ingame platzieren. Ansonsten wird es für den durchschnittlichen TpF Spieler schnell zu kompliziert und frustrierend, da er keine Ahnung hat wie man diese Signale vernünftig programmiert und auch keine Lust hat erstmal SignalScript (eine fiktive Scriptsprache) zu lernen.
Eine einfachere Lösung wie Prioritäten wären aber auch schonmal ein guter Anfang.

Zitat von eg3

Es kann und darf nicht sein, dass die Performance umgekehrt proportional zur Anzahl Bewohner abnimmt.

Naja aber so ist es nunmal. Etwas anderes zu erwarten wäre auch völlig unlogisch. Je mehr Einwohner, desto mehr gibt es nunmal zu berechnen und desto besser die Performance? Merkste denke ich selbst... Da kann UG auch nichts dran machen. Bei OTTD und Simutrans ist das auch so. Da fällt es nur nicht so stark auf, da die Berechnungen weniger kompliziert sind. Ich kann aber aus eigener Erfahrung sagen, dass mein Simutrans Server mit einer zugegebenermaßen recht großen map und vielen Einwohnern zwei Kerne meines kleinen i7-2600K fast vollständig auslastet. Und das für so ein Urlat game und kompiliert ohne UI. Der mact also wirklich nur die Simulation und die Synchronisation mit dem clients.

Zitat von fantomas741

Ich bin nach wie vor der ansicht das Sims zusammenfassen mehr Performance benötigt als sie als einzel Agenten laufen zu lassen

Ohne die Sourcen zu kennen kann man dazu nicht wirklich eine Aussage treffen. Prinzipiell dürfte es aber durchaus einen deutlichen Performancegewinn geben, da eben nur ein Sim aus der Gruppe eine Wegsuche machen muss und auch sonst so ziemlich alles was an Sims simmuliert wird nur ein Mal geschieht.
Am Verkehrsaufkommen ändert das aber trotzdem nichts. Das heißt also man wird trotzdem mehr Züge, mehr Busse, mehr Fahrzeuge im allgemeinen, mehr Infrastruktur (d.H. auch mehr Knoten und Kanten für die Wegfindung der Fahrzeuge), einschließlich mehr Stationen (d.H. mehr Knoten für die Wegsuche der Sims) benötigen. Dazu wird man vermutlich auch noch mehr Linien (d.H. mehr Kanten für die Wegsuche der Sims) erstellen.
Heißt also, dass zusammenlegen zwar ein bischen bringen kann, die Anzahl der Sims aber vermutlich nur einer von vielen Faktoren ist, die die Performance im lategame runter ziehen.

Zitat von Hendi

Ich hatte die Zusammenfassung bisher eher so verstanden, dass z.B. 2 Sims dann einfach die selbe Wegfindung haben

Da gibt es mehrere Möglichkeiten wie genau man das umsetzen könnte. Einer meiner Vorschläge war es, wie du schon sagtest, einfach mehrere Sims die in einem Haus wohnen so zusammenzufassen, dass beide die gleichen Ziele Teilen und immer gemeinsam reisen.
Und nein, das ist nicht das gleiche wie die Polulation zu verringern, denn bei geringerer Polulation ist auch die Anzahl der Häuser und die Nutzung der Linien geringer. Beim zusammenlegen geht es eben darum im lategame große Städte mit viel Verkehr haben zu können und dabei die Performance ohne zu große Komprimisse ein wenig zu schonen.

Und wenn ich dann eine Güterhauptstrecke für den schnellen Güterverkehr (so 120 km/h) für ein paar langsamere S-Bahnen mitnutzen möchte, haben die langsameren S-Bahnen, die noch dazu viel schneller beschleunigen können vorfahrt und bremsen den prinzipiell schnelleren Güterzug aus?
Ich bin in diesem Fall dagegen zwischen Güterverkehr und Personenverkehr zu unterscheiden. Lieber mehr (beliebig viele?) Prioritätsstufen einführen.
Dann kannst du es ja für dich selbst so handhaben, dass der Güterverkehr eine Priorität zwischen 1 und 10 bekommt und dein Personenverkehr Prioritäten zwischen 11 und 20.
Hinzu kommt, dass solche Prioritäten wohl an eine Linie gebunden sein sollten, um nicht jedem Zug einzeln eine Priorität egben zu müssen. TpF weiß aber garnicht, ob eine Linie eine Personen oder Güterlinie sein soll.
Bevor due Fahrzeuge einsetzt weiß es nichtmals, ob die Linie eine Bus, Tram oder Zuglinie ist, vorrausgesetzt alle ausgewählten Stationen haben für alles eine Haltestelle.

Dafür gabs die Kollision von Zügen wenn man beim umbauen nicht aufgepasst hat
Aber mal ernsthaft: Bei so Spielen wie OTTD mit den Klötzen ist es auch viel einfacher zu prüfen ob etwas kollidiert oder nicht. Jeder block ist eben ein Block mit einer bestimmten ganzzahligen Koordinate. Entweder da ist schon was drauf, dann kann man da nicht bauen oder der Klotz ist frei dann ist alles gut.
Jeder der sich schonmal auch nur am Rande mit Kollisionserkennung befasst hat weiß wovon ich rede. Wenn man die Welt in feste Raster einteilt kann man ganz einfach sagen ob da schon etwas ist oder nicht, denn man ordnet einfach der Koordinate etwas zu. Da braucht man keine Kollisionsabfrage im eigentlichen Sinn.
Wenn alles rechteckig ist und die Rechtecke auch noch entlang der gleichen Achse ausgerichtet sind, ist es trivial. Wenn Diese Rechtecke beliebig gedreht werden können ist es noch immer einfach. Wenn man dann Vierecke ohne rechte Winkel nimmt, bleibt es recht einfach. Wenn man jetzt konexe Polygone nimmt steigt der Rechenaufwand deutlich, wenn die auch noch konkav sein können, funktionieren so einige Vereinfachungen nicht mehr und man muss noch mehr rechnen.
Und TpF? Naja vermutlich bestehen die Shapes da aus Bezierkurven. Dann wirds noch viel lustiger. Entweder man rechnet viel rum und alle beschweren sich, dass sie kein Gleis von einem Ende der Map ziehen können ohne, dass es beim Gleisbau laggt, oder man prüft eben nicht ganz so präzise, ob etwas kollidiert oder nicht.

OTTD ist ja auch ein quasi 1:1 Nachbau von Transport Tycoon, der nur eben open source ist und einige (größtenteils optionale) Erweiterungen mitbringt.
Simutrans finde ich persönlich auch sehr gut gelungen, legt den Schwerpunkt aber auch anders als bei TTD.
Und was TF und TpF angeht... beide legen den Schwerpunkt ganz wo anders als OTTD und sind, wenn überhaupt, eher mit Simutrans vergleichbar.
Ich mag alle 4 Titel, wobei TF bei mir seit TpF nicht mehr gespielt wird. OTTD spiele ich auch schon seit einer ewigkeit nicht mehr.
Bei TpF gefällt es mir besonders gut, dass ich eben nicht nur rechtwinklige Gleisstücke mit fester Steigung bauen kann, sondern einfach ziemlich genau so wie ich eben bauen möchte.
Bei Simutrans gefällt mir die Performance und der Multiplayer besonders gut.

Entweder es muss eine alternative UI her oder aber man fügt den Bahnhof mehrfach mit jeweils unterschiedlichen Gleiskonfigurationen ins Spiel ein oder man gibt sich mit den wenigen Einstellungen zufrieden und betet, dass UG hier mitliest und in einem Patch die UI erweitert. Andere Möglichkeiten sehe ich da aktuell nicht.
Bei den zusammengesetzten Constructions wie z.B. den Flughäfen im Standardspiel kann man afaik auch nicht einzelne Teile upgraden ansonsten wäre das eine Option...

Aktuell versuche ich ein wenig mit der UI aus den Szenarios zu spielen. Da gibt es noch so einige Stolpersteine die ich irgendwie umgehen muss. Da die Klausuren aber näher rücken ist da vor Mitte Februar nicht viel zu erwarten.

@GamingPotatoes
Wenn du diese Option nicht haben willst, kannst du dich auch ein wenig durch Toms Script wühlen und aus den langsamen, geteilten Gleisen durchgängige machen. Wirf mal einen Blick auf die tom_standardstation_plus.con und halte dort mal nach "transitTrackSplitPatformLayout" ausschau.
Der Rest dürfte selbsterklärend sein...

man kann aber mit nicht all zu viel Aufwand TpF Modelle nach TF portieren.

@eg3 Man könnte in TpF solche Suventionen auch scripten.
Ich bin aktuell dabei herauszufinden in wie fern man solche Scrips allgemein für beliebige Karten, also nicht wie bei den Kampagnen an eine bestimmte Karte gebunden, erstellen kann.
Sowas macht aber eigentlich erst dann wirklich Sinn, wenn man die Strecken ausschreiben könnte und diese auch an eine KI vergeben werden können. Ob das scriptbar ist weiß ich aber noch nicht und selbst wenn es scriptbar ist, glaube ich nicht, dass ich die Zeit habe das umzusetzen.

The tunnel wall materials are defined for each track type.
See the attributes "tunnelWallMaterial" and "tunnelHullMaterial" in the track configs.

Zumindest meistens hängt die an der Decke. Manchmal auch an der Wand oder an Masten. Siehe Berlin Hauptbahnhof da gibt es gleich alle drei Varianten im Tiefbahnhof.
Es dürfte aber in dem Fall auch kein Problem sein entsprechende Masten zu basteln und im Modell zu platzieren.

Jap das stimmt. Keiner regt sich nicht auf. Da ich nicht keiner bin, werde ich mich jetzt tierisch drüber aufregen!

Ne mal ernsthaft: kann jedem mal passieren und ist nicht weiter wild.