Beiträge von Sherlock Holmes

Ja, das hab ich schon verstanden. Nur muss ja laut deinem Script, damit das funktioniert, mit jedem Klick die Variable "Dienstplan Seite" immer um eins erhöht werden. Das musst du so ja noch im Script umsetzen, oder?

Was genau verstehst du jetzt nicht? Ich muss sagen, ich habe etwas derartiges auch noch nie umgesetzt. Was ich jetzt geschrieben habe, ist lediglich das, was mir zunächst mal aufgefallen ist. Also vielleicht verstehe ich dich auch falsch...

Ich glaube auch nicht, dass es möglich ist. Das Debug-Fenster zum Beispiel zeigt im Reiter "Stations" auch nur Abfahrten innerhalb der nächsten 60 Minuten an.

Ist halt wieder so ein typisches OMSI-Ding. Abfahrtszeiten in mehr als 60 Minuten wurden für den Lieferumfang nicht benötigt, da der Anzeiger, der am U-Bahnhof Ruhleben hängt, eh nur zwei Abfahrten anzeigt. Also wurde es auch nicht umgesetzt. Das soll kein Vorwurf sein - man kann oder will als Entwickler schließlich nicht sämtliche Eventualitäten vorausahnen, die Modder mal benötigen könnten. Genausowenig gibt es einen Anspruch der Modder darauf, dass alles umsetzbar sein muss.

Da muss man m. E. einfach Abstriche machen. Den Aufwand für das feste Eincodieren (besonders, wenn man - so wie ich - den DFI-Anzeiger an zahllosen Haltestellen platzieren möchte) rechtfertigt das Ergebnis meiner Meinung nach in keiner Weise, besonders, wenn dann Busse von der Anzeige verschwinden, bevor sie abgefahren sind (was beim von mir nachgestellten Modell in der Realität nicht der Fall ist).

Man könnte es zwar vielleicht - genau hab ich mir das jetzt nicht überlegt - so umsetzen, dass alle Abfahrten bis 60 Min über GetArrBusTimeDiff, und alle darüber aus einer fest integrierten Liste genommen werden, aber das wäre erstens nochmal sehr kompliziert und aufwendig, und zweitens bleibt das Problem, dass das dann nur für eine konkrete Haltestelle funktioniert (oder interpretiere ich das "fest eincodieren" falsch?)

Genauso muss man ja bereits - zumindest wenn das reale Vorbild eine Echtzeitfunktion unterstützt - auch dort Abstriche machen. Schließlich zeigt eine reale Anzeige bei einem 10 Minuten verspäteten Bus nicht 10 Minuten lang "sofort" an, sondern passt die Zeitprognose "in x Minuten" dynamisch an, sodass erst "sofort" (o. Ä.) angezeigt wird, wenn der Bus auch wirklich in weniger als 1 Minute erscheint.

Mir ist kein DFI-Anzeiger in OMSI bekannt, der das umgesetzt hat, und ich weiß auch nicht, ob die Verspätung von KI-Fahrzeugen überhaupt ausgelesen werden kann, was ja dafür notwendig wäre. Außerdem würde es sicherlich negative Einflüsse auf die Performance haben.

Kurzgesagt muss man sich glaube ich in OMSI einfach damit abfinden, dass DFIs nur in Teilen realistisch umgesetzt werden können. Dinge, die einem im normalen Spielablauf kaum auffallen, wie eben die Zeitspanne, die der Anzeiger abdeckt, oder eben das realistische Verhalten der Zeitprognose (OMSI ist nicht dazu gedacht, dass man sich an die Haltestelle stellt, und schaut, ob die DFIs alles richtig anzeigen) sind kaum bis gar nicht umsetzbar...

Ich habe in meinen DFIs auch eine Anzeige eingebaut, die von OMSI in der Form nicht vorgesehen wurde. Einige Linien/Ziele werden mit einem Symbol markiert. Die Zuordnungslogik der einzelnen Symbole ist fest ins Script integriert, sodass die Anzeiger auf anderen Karten nicht sinnvoll eingesetzt werden können. Wenn man nun bestimmte, von OMSI nicht vorgesehene Anzeigen einbauen möchte, die man dann sogar für jede einzelne Haltestelle oder gar jeden Fahrplanwechsel aufwendig abändern muss, braucht man dazu Ausdauer und Motivation in einem Maße, das mir bei weitem abgeht

Wenn sich aber doch eine etwas weniger aufwendige Methode, das umzusetzen, findet, bin ich natürlich auch daran interessiert.

Grüße

Was genau klappt denn nicht? Nur der Texturwechsel, oder auch dass der Plan aus der Ablage genommen wird?

Ist das denn dein komplettes Script, was du zuletzt gepostet hast?

Du brauchst natürlich noch einen Abschnitt, der dafür sorgt, dass mit jedem Klick auf den Dienstplan die Variable "Dienstplan Seite" mit 1 addiert wird, (und am Ende auch wieder zurückgesetzt wird).

Der Eintrag in der model.cfg sollte so reichen, da gehört nicht für jede Textur ein eigenes Mesh hin. Du willst die Textur schließlich auf ein und demselben Mesh austauschen.

Damit der Dienstplan "bewegt" werden kann, musst du die entsprechende Variable "dienstplan_vis" natürlich auch noch in die varlist eintragen.

Das wären mal so ein paar Sachen, die mir auf den ersten Blick auffallen.

Wagen300 Möglicherweise hilft es, wenn du Texturen der Größe 2^x*2^y (x,y = ℕ) verwendest.

Normalerweise sollte es bereits reichen, wenn du die Variable in die Stringvarlist einträgst.

Jane_TW 722 Moin, erstmal danke für dein positives Feedback. Genau das ist mein Ziel, dass man vieles (am besten natürlich alles) auf den ersten Blick wiedererkennt, ohne nachlesen zu müssen, was das jetzt sein soll.

Zum Thema weitere Linien: Du hast das richtige Stichwort schon genannt. In ferner Zukunft möchte ich natürlich die Karte ausbauen, und so viele Linien wie möglich umsetzen. Das hängt aber alles davon ab, wie sich die Umstände bei mir privat entwickeln, wie es mit dem Bau des Neuners weitergeht, und wie sich meine Motivation entwickelt. Jetzt hat auf jeden Fall erstmal die Fertigstellung des Abschnitts Stadtmitte - Sickenhausen Auchtert Priorität. Bevor es dann an den Bau einer weiteren Linie zu denken gilt, möchte ich eigentlich auch zumindest bis nach Altenburg zu Ende bauen, damit der Standard-Linienarm vollständig befahrbar ist. Und am liebsten wäre mir es natürlich, auch noch zum BZN zu kommen.

Danach ist theoretisch alles offen. Der 9er teilt sich bekanntlich kaum Abschnitte mit anderen Linien, sodass eine weitere Linie sowieso fast eine komplett neue Strecke bedeuten würde. Sicher ist auf jeden Fall jetzt schon, dass es nicht der 3er werden wird, weil der einfach so unfassbar lang ist, dass mir das 'ne Nummer zu groß ist. Lieber möchte ich was in Angriff nehmen, was ich auch irgendwann zu Ende bringen kann. Deshalb möchte ich als nächstes lieber eine kurze Linie bauen. Ich liebäugle da schon etwas mit dem 81er (also dem nach dem alten System), weil ich die Ringelbachstraße persönlich ganz hübsch finde und das auch mal eine komplette Innenstadtlinie wäre, ganz im Gegensatz zur 9. Daneben ist auch der Vierer eine Linie, mit der ich viel Positives verbinde. Sicherlich werde ich in die Entscheidungsfindung aber auch Communitywünsche miteinfließen lassen.

Was auch relativ sicher ist, ist, dass es wohl eine Linie nach dem alten System sein wird. Ich möchte meine Kapazitäten lieber darauf verwenden, das wiederaufleben zu lassen, was ich über Jahre hinweg kennen- und schätzen gelernt habe, als das, was man derzeit schon in der Realität hat, auch noch virtuell umzusetzen. OMSI liefert ja auch Spandau 1989-1994 mit, und nicht Spandau 2007 oder so.

Das alles ist aber noch Zukunftsmusik und noch keine belastbare Ankündigung. Im Moment heißt die Karte auf jeden Fall noch für einige Zeit "Reutlingen - Der Neuner" und dementsprechend ist auch der Fokus beim Bau ausgerichtet.

So, das war jetzt mal wieder eine ausführliche Antwort

Ich hoffe, sie war auch zufriedenstellend.

Bis bald!

Mari2004us Oh, danke für die Info, da muss irgendwas schiefgelaufen sein. Jetzt sollte es gehen, oder?

Hallo zusammen!

Zunächst einmal herzlichen Dank für die Antworten von euch (ehemaligen) Reutlingern, die sich auf die Karte freuen! Es motiviert ungemein, zu wissen, dass die Karte, an der man baut, bei anderen für Vorfreude sorgt, weil sie die Strecke und die Stadt ebenfalls kennen

Update zum aktuellen Baufortschritt

Dementsprechend bin ich in den letzten Wochen, anders als erwartet, auch sehr gut vorangekommen. Ich konnte zahlreiche neue Objekte und Gebäude modellieren und verbauen, sodass sich deren Gesamtzahl (Variationen nicht miteinberechnet) nun auf 54 Stück beläuft! Daneben wurden kleinere Korrekturen und Ausgestaltungen an der Karte durchgeführt. Die Bebauungsdichte nimmt damit stetig zu. Die Abschnitte

- Stadtmitte - Hauptbahnhof,

- Emil-Adolff-Straße - Hst. Sickenhäuser Str.

sind nahezu vollständig bebaut und bedürfen lediglich noch der Vervollständigung durch Verkehrszeichen oder einige wenige Gebäude.

Dazu ist auch ein erstes Stück am Ortseingang von Degerschlacht, genauer der Bereich Fußball-/Tennisplätze bis Osianderstr. Ecke Schwindstr. zu Teilen bebaut.

Am Straßenverlauf hat sich diesmal dagegen nichts getan, er reicht immer noch bis zum Ortseingang Sickenhausen.

Bilder

Diesmal kann ich euch gleich vier neue Bilder präsentieren.

Den Anfang macht ein Abschnitt, den ich bereits im zweiten Bild des ersten Posts präsentierte. Und so sieht es dort mittlerweile aus.

Weiter geht es aus dem rechten Bildrand des ersten Bildes heraus in die Straße "Unter den Linden". Die dortige Haltestelle ist, neben dem ZOB, einer der zwei wichtigsten Knotenpunkte, welche die Linie 9 anfährt. Hier ist der Umstieg zwischen dem SPNV in/aus Richtung Tübingen HBF und Stuttgart HBF und den Stadtbuslinien 2, 3/31, 4, 5/155, 9, 10/7611 und X3 möglich. Eine - bis zum 9.9.2019 bestehende - Reutlinger Besonderheit im Gegensatz zu vielen anderen Städten ist die Trennung von Zentraler Bushaltestelle und HBF. Der Hauptbahnhof ist über zwei verschiedene Haltestellen (Unter den Linden und Listplatz) erreichbar, während sich alle Buslinien am ZOB "Stadtmitte", einige hundert Meter weiter, treffen.

Jenseits der Bahnbrücke fehlen noch unzählige Gebäude, dieser Abschnitt ist noch völlig unfertig.

Am Hauptbahnhof befinden sich auch die neuen Reutlinger DFI-Anzeiger, welche jetzt originalgetreu umgesetzt wurden, nachdem sie zuvor noch durch hässliche Dummy-Objekte ohne echte Texturen dargestellt wurden. Darauf zu sehen sind die "Reutlinger Orientierungshilfen" für den Stadtverkehr. Um kognitiv eingeschränkten Personen das Finden des richtigen Busses zu erleichtern, erhielt jedes Ziel ein leicht merkbares, farbiges Symbol, welches auf den "Linienmännchen" am ZOB, den Matrizen der Busse, sowie eben hier auf den neuen DFI-Anzeigern zum Vorschein kommt. Umgesetzt wurden aus Performance-Gründen nur die wichtigsten acht der insgesamt ca. 16 Symbole.

Wir verlassen den innerstädtischen Bereich und kommen nach Degerschlacht, wo Performanceprobleme keine große Rolle spielen. Wir blicken hier Richtung Ortsausgang. Der Neuner fährt hier in Blickrichtung in die Stadtmitte, entgegen kommen die Touren Richtung Sickenhausen/Altenburg/Rommelsbach. Zu sehen ist links die Randbebauung der Reutlinger Gemeinde, rechts die Asylbewerberunterkunft und hinter den zahlreichen Bäumen die Fußball-/Tennisplätze. Natürlich fehlen hier noch ein paar Dinge, wie Beschilderung oder der rechtsseitige Gehweg.

Als kleines Extra-Gimmick, damit sich Ortsfremde räumlich besser zurechtfinden, stelle ich diesmal auch eine Karte zur Verfügung, auf der der aktuell umgesetzte Linienverlauf und die Positionen der geposteten Bilder eingetragen sind. Quelle

Legende:

Feedback:

Ich bitte wie immer darum! Besonders Ortskundige können am besten Hinweise geben, wo noch das eine oder andere Detail fehlt, damit die Szenerie realistisch wirkt. Ortsunkundigen dürfte die gepostete Karte helfen, sich bei Bedarf per Google Streetview ein Bild von der Realität zu machen.

Das war's für heute.

Auf bald und bleibt gesund!

Sherlock Holmes

Ich kann mich allen anderen nur anschließen, wirklich toll, wie du die Radverkehrsinfrastruktur umsetzt, ich kann deinen Enthusiasmus bei dem Thema auch gut verstehen!

Nur eine kleine Sache würde an der umzäunten Haltestelle wahrscheinlich viele Fußgänger (die ja bekanntlich am liebsten Luftlinie laufen würden, und das auch tun, solange sie über Hindernisse wie Grünstreifen oder eben Geländer hinwegkommen) stören. Und zwar, dass man gezwungen wird, einen beachtlichen Umweg zu laufen, wenn man zum unteren Bildrand will, oder von dort zum Bus möchte. Da würde ich als potentieller Bürger der Stadt doch dafür plädieren, noch einen Überweg ans andere Ende des Bussteiges zu platzieren Aber das ist nur die Sicht eines stinknormalen Fußgängers, die Expertise und Entscheidungsfreiheit liegt natürlich bei dir

Ansonsten wirklich top, ich finde es super, wenn man nicht einfach durch Standard-Straßen fährt, sondern man überall planerisch durchdachte Verkehrsleitkonzepte erkennen kann! Der nicht unerheblich größere Aufwand lohnt sich hier auf jeden Fall!

Na ich würd' sagen, die erste Anforderung ist, damit die Autos rot bekommen, wenn ein Zug kommt, und die zweite, damit bei den Autos rot bleibt, falls der Zug länger braucht, als die eingeplante Rotzeit der Autos zuließe.

So hallo, ich habe mich mal einige Stunden dahintergeklemmt und bin zu folgendem Ergebnis gekommen:

Folgendermaßen dürften deine Probleme gelöst werden:

Zunächst würde ich eine Änderung in der .osc-Datei empfehlen:

{frame}
    (L.S.Time) 54000 >
    (L.S.Time) 79200 < &&
    {if}
        (L.L.Timer) (L.S.Timegap) + (S.L.Timer) s0 1 <
        {if}
            1 (S.L.STD_an)
        {else}
            l0 2 <
            {if}
                0 (S.L.STD_an)
            {else}
                0 (S.L.Timer)
            {endif}
        {endif}
    {else}
        0 (S.L.STD_an)
        0 (S.L.Timer)
    {endif}
{end}

Es muss also lediglich die String-Variable STD_an in eine einfache Variable umgewandelt werden.

Dann muss in der .sco-Datei noch einiges geändert werden:

[groups]
1
Gruppe1

[friendlyname]
Objekt1

[script]
1
script\scriptname.osc

[varnamelist]
1
script\Objekt1_varlist.txt

[mesh]
Objekt1.o3d

[visible]
STD_an
1

[matl]
Lampe aus.tga
0

[matl_lightmap]
Licht.bmp
ungültigervariablennameoderleerzeile

[nocollision]

[fixed]

[mesh]
Objekt1.o3d

[visible]
STD_an
0

[fixed]

[nocollision]

Wir haben jetzt hier also zwei Mesh-Einträge. Der eine verfügt über eine Lightmap, die du noch erstellen musst. Auf dieser sollten die Stellen, die im Sekundentakt hell und wieder dunkel werden, weiß sein, der Rest schwarz.

Der andere verfügt über keine Lightmap, stellt also den Zustand dar, wenn alle Lampen aus sind. Er ist (via [visible]-Befehl) immer dann sichtbar, wenn die lokale Variable "STD_an" den Wert 0 besitzt, also zwischen 22 und 15 Uhr, und dazwischen alle 2 Sekunden. Andernfalls ist das erstgenannte Mesh sichtbar.

Bei dieser Vorgehensweise wird die Stringvarlist nicht mehr benötigt. Die Variable STD_an, die ich jetzt namentlich einfach mal übernommen habe, muss aber natürlich noch in die Varlist eingefügt werden.

Ebenso wird die Textur "Lampe an.tga" nicht mehr benötigt, sie wird funktionell durch die Lightmap ersetzt.

Dass ich aufgrund Unwissenheit oder fehlender Übersicht noch einige Dummy-Namen in der .sco habe, die noch entsprechend abgeändert werden müssen, dürfte sich von selbst verstehen

Ich habe das Ganze natürlich auch wieder in mein gutes altes Wohnhaus implementiert und spaßeshalber die Lightmap komplett in Weiß getaucht, sodass jetzt das ganze Haus im Sekundentakt leuchtet: Das funktioniert sowohl bei Tag, als auch bei Nacht prima, und nachts gehen sogar noch die Lichter an den Fenstern an

Möglich wäre aber natürlich auch, wie bei dir benötigt, eine partielle Beleuchtung.

Beweisfotos : Und an... Und aus...

Uuund an... Uuuund aus!

Ich hoffe, das hilft dir weiter bzw. es ist das, was du erreichen wolltest. In jedem Fall ist dadurch immerhin das hässliche Texturnachgelade eliminiert.

Beste Grüße,

Sherlock Holmes

Jetzt fällt mir gerade auf, dass du ja willst, dass die beiden Lichter-Reihen abwechselnd leuchten, und nicht nur jedes Zweite immer an und ausgeht. Ich hatte mich jetzt ganz an dem GIF orientiert und dachte, das sei bis auf die weißen Nachlader schon das gewünschte. Dann muss man das ganze natürlich noch etwas abwandeln...

{frame}
    (L.S.Time) 54000 >
    (L.S.Time) 79200 < &&
    {if}
        (L.L.Timer) (L.S.Timegap) + (S.L.Timer) s0 1 <
        {if}
            1 (S.L.Lights_left)
            0 (S.L.Lights_right)
            1 (S.L.STD_an)
        {else}
            l0 2 <
            {if}
                0 (S.L.Lights_left)
                1 (S.L.Lights_right)
                1 (S.L.STD_an)
            {else}
                0 (S.L.Timer)
            {endif}
        {endif}
    {else}
        0 (S.L.Lights_left)
        0 (S.L.Lights_right)
        0 (S.L.STD_an)
        0 (S.L.Timer)
    {endif}
{end}

[groups]
1
Gruppe1

[friendlyname]
Objekt1

[script]
1
script\scriptname.osc

[varnamelist]
1
script\Objekt1_varlist.txt

[mesh]
Objekt1.o3d

[visible]
Lights_left
1

[matl]
Lampe aus.tga
0

[matl_lightmap]
Licht_links.bmp
ungültigervariablennameoderleerzeile

[nocollision]

[fixed]

[mesh]
Objekt1.o3d

[visible]
Lights_right
1

[matl]
Lampe aus.tga
0

[matl_lightmap]
Licht_rechts.bmp
ungültigervariablennameoderleerzeile

[fixed]

[nocollision]

[mesh]
Objekt1.o3d

[visible]
STD_an
0

[fixed]

[nocollision]

Das wäre dann auf die Schnelle mein neuer Vorschlag, hoffe ich hab keinen Fehler gemacht

LG

Zitat von Schleswig-Holstein

Du definierst in EINER Anforderung einen Punkt von wo nach wo gejumpt werden soll. Nicht zwei unterschiedliche Anforderungen.

Also wenn ich es richtig verstehe, möchte Philipp0349 ja gar nicht jumpen, sondern stoppen. Er möchte, dass, wenn keine Bahn kommt, die Ampel für Autos auf Grün stehen bleibt (stoppt). Wenn dann eine Bahn kommt, es also auf TL Nr. 0 eine Anforderung gibt, soll das ganze soweit weiterlaufen, bis die Ampel für Autos auf Rot steht, und die Bahn freie Fahrt hat. Dann soll erneut gestoppt werden. Wenn die Bahn den Übergang passiert hat, also keine Anforderung mehr auf TL Nr. 0 besteht, läuft das ganze wieder weiter und stoppt erneut, wenn die Autos wieder grün haben (bis die nächste Bahn kommt) usw... Soweit die Theorie. Oder verstehe ich da was falsch, Philipp0349 ? Man könnte das Ganze anstatt mit einem/-r Stopp/Pause natürlich auch mit einem Jump lösen, sodass nicht wirklich gestoppt wird, sondern ein kurzes Intervall von z. B. einer Sekunde immer wieder durchlaufen wird, bis der Zug kommt. Das kommt am Ende fast aufs Selbe hinaus (wobei ich nicht weiß, ob das Stoppen evtl. sogar Performancefreundlicher ist).

Jedenfalls funktioniert es in der Praxis ja offenbar nicht so, wie man es sich vorgestellt hat.

Um das Problem etwas einzugrenzen, könntest du dem Kreuzungsobjekt ja mal ein Anforderungs-Signal oder eine Standard-Spandau-Busampel zuweisen und sie auf die Bahn-Ampelphase zuweisen. Dann könntest du sehen, ab wann die Kreuzung eine Anforderung der Bahn registriert. Oder hast du das schon gemacht? Ich habe jedenfalls im Thread noch nichts darüber gelesen.

Eventuell - ich habe noch nie mit Anforderungen für Bahnen gearbeitet, weshalb ich das ganze weder bestätigen noch in Zweifel ziehen kann - hängt das ganze aber auch einfach hiermit zusammen. Leider hat tempo1 nicht näher ausgeführt, warum es nicht funktioniert. Löst eine Bahn überhaupt keine Anforderung aus? Das würde die Vorgänge an deiner Ampel nicht erklären, denn dann müsste die Auto-Ampel einfach immer auf grün stehen bleiben. Löst eine Bahn vielleicht IMMER eine Anforderung aus, egal wie weit sie noch (oder schon wieder) entfernt ist? Das würde die Vorgänge an deiner Ampel erklären. Vielleicht wendest du dich mal direkt an ihn.

LG

Sherlock Holmes

Wenn mich nicht alles täuscht, schon. Hier mein verwendetes Script:

{frame}
    (L.S.Time) 54000 >
    (L.S.Time) 79200 < &&
    {if}
        (L.L.Timer) (L.S.Timegap) + (S.L.Timer) s0 1 <
        {if}
            "Wohnhaus1.dds" (S.$.STD_an)
        {else}
            l0 2 <
            {if}
                "Wohnhaus1_night.dds" (S.$.STD_an)
            {else}
                0 (S.L.Timer)
            {endif}
        {endif}
    {else}
        "Wohnhaus1.dds" (S.$.STD_an)
        0 (S.L.Timer)
    {endif}
{end}

Bei mir hat's auch erst nicht funktioniert. Das lag dann aber nur daran, dass ich beim [matl]-Eintrag was vertauscht hatte, was dann auch der Logfile entsprechend entnommen werden konnte (Error in Line xy), sodass ich es beheben konnte.

Bamp

Nabend,

ich kann das leider nicht nachvollziehen. Ich konnte auch nach mehrmaligem Betrachten keinen "Fehler" in dem Script finden. Genausowenig konnte ich einen relevanten Unterschied zu dem Script finden, was fOcUs04 gepostet hat.

Ich habe mir also mal probeweise dein überarbeitetes Script angeeignet, und lediglich die Texturnamen entsprechend verändert, sodass eines meiner Szenerieobjekte jetzt zwischen 15 und 22 Uhr im Sekundentakt zwischen der Tag- und der Nachttextur wechselt. Es funktioniert tadellos:

Am Script kann's also eigentlich nicht mehr liegen. Zeigt die Logfile denn immer noch nichts brauchbares an?

LG

Sherlock Holmes

Zitat von Matthias_M

Soll das was du erreichen möchtest bei genau 1= passieren und nach 1 dann die ganze Zeit das was bei 2= passiert?

Dann würde ich es so schreiben:

(L.L.active) 1 =

{if}

(L.L.Timer) (L.S.Timegap) + (S.L.Timer) 2 <

{if}

"Lampe aus.tga" (S.$.STD_an)

{else}

"Lampe an.tga" (S.$.STD_an)

{endif}

{endif}

Und falls nicht, was soll den passieren wenn 2= überschritten wurde?

Alles anzeigen

Ich verstehe es so, dass das Script erreichen soll, dass im Sekundentakt zwischen der An- und Aus-Textur gewechselt wird. Daher der Timer, der beim Erreichen von 2 wieder auf Null gesetzt werden soll. Solange er zwischen 0 und 1 liegt, soll wohl die Aus-Textur angezeigt werden, und solange er zwischen 1 und 2 liegt, soll die An-Textur angezeigt werden.

Hmmm, also ich hab ja wirklich auch nicht so viel Ahnung, aber musst du nicht der Variable "Timer" bei der Script-Initialisierung einen ersten Wert zuordnen, bevor du sie im {frame}-Abschnitt das erste Mal aufrufen kannst? Oder wird das automatisch auf Null oder so gesetzt?

Und auch über den Timegap weiß ich nicht mehr, als das, was im Wiki steht. Zum Beispiel weiß ich nicht, wie genau er die Zeitspanne zwischen zwei Frames angibt, ich gehe aber davon aus, dass die kleinste gültige Ziffer wenigstens Zehntelsekunden angibt, denn wären es ganze Sekunden, wäre das ganze ein wenig witzlos und unbrauchbar. Dementsprechend könnte ich mir vorstellen, dass es vorkommen kann, dass die Zeitspannen zwischen mehreren Frames dergestalt sind, dass der Timer nie genau auf 1(s) oder 2(s) kommen wird. Was bei 1s noch weniger tragisch wäre, weil "nur" die Textur nicht getauscht würde, wäre bei 2s fatal, weil dann nicht einmal der Timer zurückgesetzt werden würde, ewig weiterliefe und somit nie wieder ein Texturtausch stattfände.

Ich könnte mir also vorstellen, dass es an dieser Stelle besser wäre, mit < für den Texturtausch und > für die Rücksetzung des Timers zu arbeiten.

Ich hoffe mal, das hilft dir irgendwie weiter. Ich bin mir leider absolut nicht sicher, weil ich mich erst ein Mal (für ein DFI-Script) mit dem OMSI-Scriptsystem auseinandergesetzt habe, was jetzt auch schon wieder über ein Jahr her ist. Sowas wie Timegap oder lokale Variablen habe ich dazu nicht bzw. kaum gebraucht... Vielleicht täusche ich mich ja komplett, oder missverstehe gar dein ganzes Script aber dann hab' ich wenigstens auch was dabei gelernt

Guten Abend wünscht

Sherlock Holmes

Hallo zusammen,

nach einiger Zeit gibt es von mir heute wieder ein paar Infos, wie sich die Karte im letzten Vierteljahr weiterentwickelt hat, und wie die Zukunftsaussichten sind.

Update zum Baufortschritt:

Der befahrbare Linienweg (nur Straßen, keine Szenerie) umfasst nun den Streckenabschnitt zwischen Stadtmitte und dem Ortseingang von Sickenhausen (ca. 6 km). Leider fehlte mir in den Wochen und Monaten seit meinem letzten Beitrag zunehmend die Motivation und vor allem auch die Zeit. Bedauerlicherweise habe ich auch zukünftig keine Aussichten darauf, wieder mehr Zeit übrig zu haben. Deshalb geht der Weiterbau langsamer voran als zuvor. Sofern jedoch nicht anders kommuniziert, hält der Fortschritt dennoch an, das Projekt ist nicht auf Eis gelegt.

Der Fundus an eigenen Objekten/Gebäuden umfasst mittlerweile 40 Stück (Variationen nicht mit einberechnet). Außerdem gibt es insgesamt 18 modellierte Kreuzungsobjekte.

Zukunftsaussichten:

Aufgrund des Zeitmangels, ist das Ziel, die rund 13km lange Gesamtstrecke der Linie 9 mit allen Linienarmen umzusetzen, in weite Ferne gerückt. Stattdessen fokussiere ich mich jetzt auf die Strecke Stadtmitte <-> Sickenhausen-Auchtert. An der Haltestelle "Auchtert" befindet sich eine Wendemöglichkeit, sodass ein Pendelverkehr zwischen diesen beiden Stationen realistisch umsetzbar wäre. Die Strecke würde dann gut 7 km umfassen, und laut Fahrplan zwischen 14 und 17 Minuten dauern. Sie bietet 14 Haltestellen.

Diese bis auf den verkürzten Streckenumfang realgetreue Karte würde ich dann als Version 0.5 veröffentlichen und mir anschließend je nach Bedarf und verfügbarer Zeit eine (Teil-)Fertigstellung vornehmen.

Bilder:

Aus o.g. Gründen gibt es leider wenig vorzeigbaren Fortschritt. Weitere Bilder folgen sobald als möglich.

Der Blick aus der Fahrgastperspektive zeigt hier den inzwischen (vorläufig) fertiggestellten ZOB (Stadtmitte). Wir warten hier am Bussteig L der Linie 6. Neu hinzugekommen seit dem letzten Bild vom ZOB sind jetzt die Wartehäuschen mit Fahrplankasten und durch die Fahrgäste benutzbaren Bänken. Erstmals ist hier auch ein KI-Bus mit im Bild. Der KI-Verkehr mit allen Stadtbuslinien ist bereits vollständig implementiert.

Neues Bild (05.10.2020):

Blick auf den Friedhof unter den Linden und die Katharinenkirche. Links das gelbe Gebäude der Arbeiterwohlfahrt. Die Linie 9 kommt auf ihrem Weg stadtauswärts hier vom rechten Bildrand und biegt nach links ab. Auch die Linie 2 nach Betzingen verläuft so. Ein Stück jenseits des linken Bildrands liegen die Haltestelle "Friedhof u. d. Linden" und die Emil-Adolff-Straße.

Zwischen Friedhof und AWO-Haus beginnt die Rommelsbacher Straße. Hier verlaufen die Buslinien 3, 4, 31 und X3 in Richtung Nordraum. Rechts verläuft die Straße "Unter den Linden". Hier geht es richtung Bahnhof und Innenstadt.

Feedback:

Ist wie immer erbeten. Egal ob zu einem der neuen oder alten Bilder, zu den heutigen Ankündigungen, oder sonstigem. Teilt mir gerne mit, wo ich noch etwas besser machen kann, wo etwas fehlt o. Ä. (die Lücke im Dach auf dem obigen Bild ist schon bekannt und behoben ) Auch Fragen zur Karte können gerne geäußert werden.

Das war's für heute. Bis zum nächsten Update!

Dass die Busse auch, wenn sie nicht mehr auf der Karte sichtbar sind, "geladen" bleiben, hat m. E. nach wahrscheinlich den Nutzen, dass gespeichert wird, welches der Fahrzeuge aus der AI-List in dieser Spiel-Session diesem Umlauf zugewiesen wurde. Denn so oft man auf denselben KI-Umlauf trifft, soll schließlich der exakt gleiche Bus zu sehen sein.

Gestaltet man sich nun den Fahrplan so um, dass ein Umlauf nur eine Tour enthält, oder wäre es OMSI-seitig so, dass mit dem Despawn der Bus vollständig "weg" wäre, würde das zwar der Performance guttun. Je nachdem, wie die AI-List gestaltet ist (ob sich alle Busse nur durch die Wagennummer unterscheiden, oder ob zig verschiedene Modelle mit unterschiedlichen Repaints zum Einsatz kommen), wie der Spieler Kenntnis von den Umläufen auf der Linie hat, und wie wichtig es ihm ist, immer dem gleichen Bus zu begegnen, wenn das in der Realität auch so sein müsste, brächte das aber wiederum Einbußen im Realismusgefühl, welches auf der Karte aufkommt.

Wenn man bspw. an einer Endhaltestelle immer auf eine KI-Linie trifft, und über Stunden hinweg jedes Mal ein anderer KI-Bus dort steht, wirkt das nicht so realistisch. Je nach Kartengröße fällt das eben mehr oder weniger auf.

Mir zum Beispiel ist es eher wichtiger, den Eindruck zu haben, dass der Gesamtbetriebsablauf auf der Karte realistisch ist, als ein paar FPS mehr zu erreichen. Anderen kommt es viel mehr aufs reine Busfahren an, während der KI-Busverkehr bestenfalls Nebensache ist.

Hallo zusammen,

es gibt einige kleine Neuigkeiten, die ich heute mitteile, darunter ist auch ein Update zum aktuellen Baufortschritt, sowie zwei neue Bilder, und ein reales Objekt.

Statement "reale Objekte am ZOB (Stadtmitte)"

Mir ist zu Ohren gekommen, dass sich von Seiten der Reutlinger OMSI-Fans am ZOB (Stadtmitte) mehr reale Objekte (gemeint ist die Häuserzeile gegenüber der Echaz) gewünscht wurden/werden. Dazu mein Statement: Dort waren bzw. sind eigentlich von mir keine realen Objekte geplant, da ich diese Häuser nicht als dermaßen Ortsbildprägend erachte, dass ich sie unbedingt nachbilden muss. Anders ist das mit der Stadthalle, dem Tübinger Tor, dem GWG-Gebäude, den Wandelhallen, der Post und dem Stuttgarter Tor, welche alle möglichst realgetreu nachgebildet wurden und vom ZOB aus sichtbar sind. Des weiteren sind am ZOB die realen Überdachungen der Bussteige, die DFIs und Mülleimer zu sehen. Der Bau von realen Objekten und Kreuzungen nimmt viel Zeit in Anspruch und bremst den Bau aus. Andere Gebäude haben daher bei mir zunächst höhere Priorität. Ich schließe aber nicht vollständig aus, dass ich am ZOB noch das ein oder andere Standard-Gebäude durch ein reales ersetzen werde.

Update zum Baufortschritt:

Das Straßennetz hat sich nicht großartig erweitert: Der Linienweg ist derzeit bis zum Degerschlachter Friedhof befahrbar. Die Szenerie ist - mit einigen Lücken vor allem in der Innenstadt, wo noch reale Gebäude fehlen - bis zum Friedhof Römerschanze fertiggestellt.

Zum Schluss noch zwei Bilder vom aktuellen Baufortschritt - konstruktives Feedback ist natürlich weiterhin erwünscht.

Hier sehen wir die nahezu fertiggestellte Justinus-Kerner-Straße. Die Szenerie besteht hier überwiegend aus Standard-Objekten. Links im Bild sehen wir aber ein realgetreu nachgebildetes Gebäude. Wir befinden uns hier an der Haltestelle "Kirchsteig" mit Blick stadteinwärts und auf die Schwäbische Alb.

Hier zu sehen ist der Blick von der Haltestelle "Friedhof Römerschanze" stadtauswärts, richtung Degerschlacht.

Das war's auch schon wieder, bis zum nächsten Update!