Beiträge von WernerK

Zitat

Ich vermute, dass es ein Synchronitätsproblem gibt beim Aktualisieren der GUI und der anderen Spielelemente.

Zwischendurch hatte ich noch einen anderen Verdacht: Es könnte sein, dass nicht nur versucht wird, GUI-Elemente zu löschen, die noch benutzt werden, sondern auch der umgekehrte Fall, dass irgendwo GUI-Elemente nicht zerstört werden, obwohl es notwendig wäre, und das in so großem Stil, dass es den Speicher überschwemmt.

Was sagt der Absturz denn? Wenn die Fehlermeldung so aussieht, wie ich unter #42 dokumentiert habe, ist es das UI.

Irgendwo habe ich mal gelesen, die Version 1.2 + letztem Patch liefe recht gut. Zumindest das GUI könnte dort etwas stabiler laufen, aber das habe ich nicht getestet, und ich denke auch nicht, dass das Speicherproblem da raus ist. Ich benutze momentan - mit Kopfschmerzen - die Version 1.3 von MarkMcWire mit den (immer noch) angepassten Einträgen in der sav.lua und nehme auch sonst fast alle Einträge dort vor. Das klappt auch. Dennoch bin ich schon fast an dem Punkt angelangt, wo ich am liebsten etwas eigenes schreiben möchte.

Tolle Sache. Da hast du dir ja sehr viel Mühe gemacht.

Ich entwickle gerade eine eingleisige Blocksicherung für Trams. In Kürze wird die erste öffentliche Beta erscheinen. Es fehlen aber für die künftige Weiterentwicklung noch Signale. Da bin ich auf Unterstützung der "Blender-Artisten" angewiesen, da mein Schwerpunkt die Skriptprogrammierung ist, und ich noch keine Erfahrung mit Blender habe. Kurzum: Hat jemand Lust, Straßenbahnsignale zu bauen? Für die ersten Versuche benötige ich eigentlich nur zweibegriffige Balkensignale, wie sie auch an Straßenkreuzungen stehen und ansonsten Verkehrsampeln entsprechen. Also nur Fahrt und Halt, aber jeweils in separaten Konstruktionen. Es könnte konfigurierbare Varianten mit oder ohne eigenen Mast geben, so dass sie auch gleich an Oberleitungsmasten montiert werden können. Sollte jemand schon Ampeln gemoddet haben, wäre es recht einfach, sie entsprechend zu modifizieren.

Alternativ oder zusätzlich wären auch Rot-Grün-Signale denkbar, ggf. auch für Aufhängung im Oberleitungsbereich.

Wer Interesse hat, kann sich hier oder per PN melden.

Ich tippe mal, diese Datei fehlt oder ist beschädigt, warum auch immer: res/textures/terrain/nep_albedo.dds

Vielleicht noch einmal neu herunterladen/neu installieren?

Das dürfte auch für alle anderen Fälle gelten, in denen irgendwas von oben beladen wird.

Zitat von BR462_DesiroHC

Er hat sich danach ein paar Sekunden nicht bewegt und war dann plötzlich wieder normal.

Sowas passiert normalerweise nach Bau-Aktivitäten.

Damit wäre es aber nicht getan. Man bräuchte für den Übergangsbereich zwischen horizontaler und seitlich geneigter Straße noch eine künstliche Fahrbahn als Modell. Außerdem würden an der Kreuzung die Autos teilweise durcheinander hindurchfahren - so wie bei den Terminals.

(Falls Interesse an einer weiteren Diskussion besteht, sollten wir im Modding-Bereich des Forums einen eigenen Thread anlegen.)

Auch da könntest du die Fahrzeuge nicht seitwärts kippen, allenfalls die Lanes treppenförmig versetzen, wobei die Fahrzeuge dann mit einem Reifen im Asphalt stecken würden. Müsste man halt abwägen, ob das noch tolerierbar wäre. Fußgänger sind ja auch manchmal im Gehweg einbetoniert.

Dazu müssten die Einmündungen ja in der Längsachse gekippt werden. Mit viel Aufwand wäre das schon möglich, man bräuchte dazu nur ein komplett neues Spiel, und dieses Feature könnte man auch noch für Gleisüberhöhungen nutzen. Realistischer wäre, die noch nervigeren und eigentlich vermeidbaren Buckel bei Übergängen zwischen Straßen unterschiedlicher Breite zu beseitigen. Dazu bräuchte man nur spezielle kippbare Konstruktionen, eine Art Adapter, ginge auch ohne CommonAPI. Hatte ich sogar mal mit geliebäugelt, aber ich habe momentan andere Baustellen.

Ich habe zu diesem Thema mal was geschrieben. Es lässt sich auch die Con-Umwandlung im ConstructionMover generell abschalten. Würde ich dringendst empfehlen, wenn man's nicht unbedingt für Spezialzwecke benötigt, z.B. Feinjustierung von Oberleitungsmasten.

Ja. Es kommt vom Spiel. Modder brauchen alleine schon deshalb eine zunehmend zugemüllte Konsole, um mehr Spaß beim Suchen eigener Fehlermeldungen zu haben. Bei der Fahrplan-Mod kam es sogar bei jedem Tick. Es erscheint allerdings auch in Verbindung mit echten Fehlermeldungen.

Gibt ein Update mit Zwischenstand.

Und wieder mal ein neues Update. Nach endloser Wurschtelei scheint es jetzt rund zu laufen. Jetzt fehlt nur noch das Anzeigefenster ...

Es sollen halt vorbildgetreue Gleise mit vorbildgetreuem Mindestradius sein, wobei das in der praktischen Anwendung dennoch meistens weniger ist als die Gegebenheiten beim Vorbild. Ich kann verstehen, dass das so gehandhabt wird, zumal wir ja doch auf einer virtuellen Anlage etwas mehr Platz haben als auf dem berüchtigten Märklin-Anfangsoval. Wer die ganze Welt auf 16 x 16 km quetschen will, kann eigentlich gleich die Vanilla-Gleise verwenden. Ok, das ist meine harte, aber rein subjektive Meinung. Im Übrigen gelten die Mindestradien beim Vorbild selbst dann, wenn ausschließlich langsam gefahren wird. Ausnahme sind Klein-, Industrie- und Straßenbahnen. Genau dafür gibt es dann ja z.B. meine Kleinbahngleise, die sogar optisch kompatibel zu NEP sind, sofern NEP zusätzlich installiert ist.

Warum sich manchmal dennoch kleinere Radien realisieren lassen? Es gibt zwei Mindestradien in den Gleisparametern, und der kleinere ist möglich

• wenn du ohne Limit-Check baust (z.B. mit Build With Collision)
• bei Verbindungsgleisen
• bei parallelen Innenkurven

Bei NEP ist allerdings der Unterschied zwischen den beiden Parametern sehr groß - vermutlich hat man einfach den kleineren von Vanilla übernommen.

Naja, ist auch nicht so wichtig, bin auch nicht so in der Materie drin. Wäre vielleicht noch eine Chance gewesen.

Hat die Schrift eine eigene mtl-Datei? Dann könnte man evtl. was mit polygon_offset machen.

Du kannst ja mal ausprobieren, ob diese Parameter bei den Wasserstraßen funktionieren. Momentan komme ich wegen anderer Projekte nicht dazu. Eventuell könnte ich dann die Maximalsteigungen der Straßen anpassen, wenn auch nicht sofort. Allerdings hätten zu hohe Werte den Nachteil, dass es sich nicht mehr feinfühlig mit dem Steigungspfeil regulieren ließe. Bis 40% wäre sinnvoll, aber alles darüber halte ich eher für fragwürdig. Fast senkrechte Steigungen sollte man dann doch besser mit den Tools realisieren, zumal die Prozentwerte zur Senkrechten hin immer stärker ansteigen, und dann nützen auch kleinere Pfeil-Schritte nicht mehr.

Ich habe in der Filebase ein Demo-Savegame für eine eingleisige Blockstrecken-Sicherung für Trams hochgeladen. Das Projekt ist schon zwei Jahre alt und eigentlich auf eine Bitte von Sabon hin entstanden. Da ich aber immer mehrere Dinge gleichzeitig auf Halde liegen habe, ist es erst in den letzten Tagen richtig in die Gänge gekommen. Getreu dem Gesetz von Murphy wird es auch diesmal wieder eine zeitgleiche Doppelentwicklung geben , da eis_os an einer ähnlichen Sache arbeitet. Macht aber nichts, dann gibt es eben zwei Lösungen, vermutlich eine mit und eine ohne CommonAPI. Es zeigt aber auch, wie sehr euch das Thema Tram am Herzen liegt, so dass ich mir eigentlich wünsche, es gäbe noch eine dritte Lösung, und die käme dann von UG.

Pantograf: Nein, die ETS-Geschichte hab ich noch nicht vergessen, aber die Blocksicherung brauchen wir ja auch. Und das Gleisverbinder-Tool. Und die Böschungsstraßen. Und noch mehr Masten.

Das sieht sehr schön aus - und der Rauch ist völlig realistisch ...