Beiträge von D0ct0R_HaCkiE

Zitat von -Dunkelbunt-

Dass man oft mit Verspätungen unterwegs ist habe ich auch bereits am Anfang feststellen müssen. Aber wie ich beobachtet habe liegt es nicht vorrangig am Fahrplan, sondern am Fahrzeug!

Nein, es liegt am Fahrer!
Wenn man weiß, wie man den Bus zu fahren hat und und man sich erlauben darf und was lieber nicht, kann man auch ganz gut den Fahrplan halten.

Wie man sieht, konnte ich dank Sonntagsfahrer auf dem Überlandbereich die V/max nicht herausfahren. Die Geschwindigkeitsbegrenzungen habe ich im Schnitt mit 5 km/h überzogen. Ausgehend vom üblichen Fahrverhalten in der BRD ist das >noch< legitim, solange eben nichts passiert.
Dafür Fahrgäste meckern bei meinem Fahrstil nicht. Gibt auch keinen Grund dafür und ich lag super in der Zeit

Während der gesamten Fahrt habe ich nicht auf den Fahrplan gekuckt, um mich daran zu orientieren. Ich fahre meinen Stil und gut ist.

"Alles eine Frage der Technik"

Mit dem selben Wissen kann ich auch ohne Bleifuß zu fahren, mit einem Ikarus 260, der kaum auf 60 km/h in Spandau zur Rush-Hour den Fahrplan halten.

Zum alltäglichen Busfahren gehört eben mehr, als nur von A nach B zu fahren. Man muß das Fahrzeug kennen, man muß die Strecke kennen und man benötigt genügend Motivation, um gut gelaunt das ganze 8 Stunden täglich auszuhalten und dabei auch noch Kundendienst leisten können. Denn mit schlechter Laune werden die Zeiten auch nur schlechter...

Fazit:
Hört bitte endlich auf, über den Fahrplan zu schimpfen. Das die Zwischenzeiten nur errechnet sind, ist längst bekannt und wird korrigiert. Der Rest passt und wenn es bei euch eben nicht passt, dann liegts wohl nicht vordergründig am AddOn!

Das Problem hatte ich mit dem neuen Update auf 1.04 auch. Beim alten seltsamer Weise nicht.
Es half nur, OMSI + AddOns zu deinstallieren und alles von Grund auf wieder neu zu installieren und mühsehlig die Mods wieder einpflegen. Mal eben knapp 8 GB Daten mit WinMerge abgrasen ist echt ein Erlebnis.... *g*

Sämtliche Versuche, nur Patch oder den Launcher neu zu installieren, führten zu keinem Ergebnis.

Ich habe ein BackUp der installierten Fassung angelegt. Interessant war, daß die neue Installation funktioniert, die alte aber nicht, und das obwohl sämtliche relevante Dateien identisch waren. Was genau die Ursache dafür war, konnte ich nicht ausmachen...

Der folgende Beitrag ist etwas OT-lastig, aber ich hoffe inständig, daß er trotzdem akzeptiert wird. Danke schon mal dafür.

Zitat von Marcel Kuhnt

Und zuletzt noch eine Klarstellung von mir zum Spruch "OMSI - Weil's geht!"

Der Spruch ist natürlich nix für Leute, die glauben, dass allenerstes alles geht! Es gibt nunmal im Leben immer Einschränkungen. Nein, der Spruch bezieht sich vielmehr darauf, dass wir bei der Entwicklung von OMSI stets darauf achten, so wenig Hürden wie irgend möglich für Addonentwickler zu platzieren! Wir kommen beide aus der Addon-Entwicklung und haben uns schon sehr oft darüber geärgert, wenn eine Plattform dieses oder jenes aus Gutdünken nicht erlaubt - ohne erkennbaren Grund!

Aber letztlich ist der Slogan unser ZIEL, weniger die Beschreibung einer Tatsache! Wir werben gewissermaßen damit, dass es uns am Herzen liegt, dass Addon-Entwickler in OMSI besonders viele Möglichkeiten haben, die Umwelt realistisch darzustellen.

Hallo Marcel,

ich hatte den Spruch schon mal zitiert und als Aufhänger für meine Kritik genutzt. Dafür musste ich mir dann auch einiges von euch anhören - nicht unbegründet.

Im Zuge meines Projekts zum RBL-Script habe ich gelernt, daß mit OMSI mehr geht, als ich gedacht habe. In dem Script (3x so groß wie die Standard-Version) sind Funktionen drin, von denen ich nicht mal geträumt hätte! Und da passt euer Slogan wieder.
95% der OMSI-Gemeinde wird dies nie bewusst werden. Und hier liegt ebenso zu min. 95% die Ursache aller Probleme und Meinungsverschiedenheiten... (Ich schweife ab)

Dieses AddOn zeigt aber selbiges auf anderem Wege:
In so vielen Details wurde auf das "in OMSI Übliche" verzichtet. Kein IBIS und trotzdem abweichende Routen, das erwähnte Sound-Phänomen, die animierten Straßenbahnen usw. Und alles funktioniert auf eine ganz besondere Art. Für mich ganz klar ein Musterbeispiel für die Community, denn gerade solche etwas unüblichen Herangehensweisen öffnen die Augen für neue Ideen. Ich habe schon einige...

Das AddOn ist de facto herausragend, so viel ist klar. Mit ein paar kleinen Korrekturen könnte es noch besser werden; auch klar. Aber machen wir uns nichts vor: Auch in Spandau gibts an ein paar Ecken Ungereimtheiten. Man lernt sie und arrangiert sich mit ihnen. Einem echten Busfahrer bleibt auch nichts anderes übrig.

PS @ ViewApp:
Bitte, gern geschehen. Ich halte lange meine Klappe, aber das konnte ich mir nicht verkneifen.
Und für die paar kleinen Pluspunkte würde ich mich freuen, wenn ihr euch nochmal an den Spritverbrauch wagen könnt. Ich hatte es irgendwo mal erwähnt, daß der nicht ganz exakt läuft.

Wenn es dir wirklich klar wäre, ist dein Beitrag unnötig.

Also, du wechslst in die Außenansicht, verlässt also das Fahrzeug. Ansagen sind weg.
Ob die jetzt theoretisch noch hörbar wären, weil du direkt im Türbereich stehst, laß ich mal außer Acht, es wäre Haarspalterei.
Das eigentliche Problem ist aber jenes, daß die Ansagen an jener Stelle fortgesetzt werden müssten, an der sie wären, wenn du wieder ins Fahrzeug einsteigst. Mit einfach auf "stumm schalten" ist das nicht getan. Und die Script-Technik gibt dafür nicht viele Möglichkeiten her, genau 2: Sound von Anfang an abspielen oder eben nicht. Und Vorschläge ála Sound ab xy abspielbar machen, wäre m.M.n. völlig deplatziert.

Und ich finde den Lösungsansatz, den Sound abzubrechen (ich bin mir sicher, daß er script-technisch nicht abgebrochen wird - aber tut nix zur Sache), sehr interessant und gibt mir für mein Problem einen guten und originellen Lösungsansatz! Danke dafür

Ich versuche ein RBL3-Script auf die Beine zu stellen und weiß, wie fatal Detailverliebtheit sein kann. Denn wenn man es wirklich nach realem Vorbild machen will - was bei diesem AddOn hier zweifelsfrei das Ziel war -, dann muß man eben auch mit Einschränkungen leben, die sich bei oberflächlicher Gestaltung gar nicht erst aufgetan hätten. Und ihr schimpft trotzdem drüber...

.oO("OMSI - Weils geht". Die jenigen unter euch, die wirklich was eigenes erstellen, haben mit Gewissheit schon zu oft festgestellt, daß vieles eben nicht geht und man tricksen muß, damit es geht - wenn überhaupt. Der (überwiegend fordernde) Rest geht leider davon aus, daß alles geht und ohne Aufwand machbar ist. *auf die Zunge beiß und mir den restlichen Kommentar dazu verkneif*)

Also freut euch doch lieber daran, daß ihr was habt, was eben (wie wird es so schön gesagt) nicht "nur hingeklatscht" wurde, sondern daß an vielen Details eben nachgedacht wurde.

Hallo,

mit Installation des Updates v1.04 wurde mein OMSI absturzwütig. Nach dutzend Experimenten konnte ich die Ursache einkreisen. Die standardmäßig eingstellten Werte von texFilter in der options.cfg waren wohl zu hoch gegriffen.

Ich habe nun die Werte 2 und 4 gewählt - also kein AF - und nun läuft OMSI stabil. Allerdings kommt mir die Grafik nun etwas schlechter als vorher vor.

Aus diesem Grund würde ich gern erfahren, welche Werte man setzen müsste, um den selben Zustand von vor dem Update zu erhalten. Auch würde ich mich freuen, wenn man einiges mehr zu den möglichen Filtern und den dazugehörigen Stufen (Min/Max/Optimum) verraten könnte.

Könnte man theoretisch auch ein niedrigen Filter (wie mein gegenwärtig aktiver) verwenden und das AA/AF über die Grafiktreiber erzwingen?

Bevor jemand fragt, ich habe Windows 7, mehr RAM als OMSI adressieren kann und als Grafikkarte eine GeForce GTX460 KO mit aktuellen Treibern.

Hallo,

nachdem ich nun OMSI stabil zum Laufen bekommen habe, konnte ich nun endlich das AddOn testen. Ein paar Kleinigkeiten gibts in der Tat zu bemängeln, aber die doch recht hohe Detailverliebtheit gilt es genau zu erwähnen. Ich denke, meine Vorredner haben dies ausreichend getan.

Was höchstwahrscheinlich noch nicht aufgefallen ist, ist folgendes Phänomen:

Im Handbuch wird das Fahrzeug genau beschrieben und man findet unter Verbrauch die Angabe ca. 110 Liter. So weit so gut...

Im Hintergrund läuft bei mir ein Fahrtenschreiber. In der Zusammenfassung zeigt mir dieser folgende Werte an:

Nun soll keiner sagen, daß die Aufzeichnung fehlerhaft sei. Wie man an den übrigen Einträgen erkennt, ist die Aufzeichnung nicht fehlerhaft.

Ich würde mich sehr freuen, wenn man dieses Detail korrigieren könnte.

Hallo,

nach der Freude über den Patch kommt die Ernüchterung.

OMSI ist nun mächtig absturzfreundig geworden.
Aller paar Minuten erscheint Zugriffsverletzung in Speicheradresse 00000000 oder FFFFFFFF - selbst auf Grundorf.
Recht häufig friert nach paar Minuten Simulationszeit das gesamte System ein. Da hilft nur noch Reset. Sowas kannte ich gar nicht.

Beides in dieser Kombination sorgt dafür, daß Konfigrationsdateien (und vermutlich auch weitere Dateien - Prüfung beginne ich gleich) beschädigt worden sind, was zu noch mehr Fehler führt. Jedenfalls begrüßt mich OMSI nun auf ungarisch und mein gespeichertes Konfigurationsprofil erkennt es nicht mehr.

Mein System lief seit Wochen Störungsfrei und habe nun nach 2 Stunden unzähliger Versuche 4 je unterschiedliche Bluescreens hinter mir. Ehrlich, das lief vorher besser. Und da fluchen so manche Nutzer hier über evtl. Alpha- und Beta-Releaser mancher Mod-Autoren...

In der LogFile sind außer nicht gefundene Texturen keine Auffälligkeiten zu finden. Und so habe ich den Verdacht, daß Aerosoft bei der ganzen Geschichte nicht unbeteiligt ist. Ein Patch, nur damit die AddOns mit Kopierschutz ausgestattet werden können. Erinnert irgendwie an GTA, wo selbst Rockstars irgendwann offiziell eingeräumt hat, man sollte einen Crack verwenden, damit das Spiel überhaupt läuft. Trauchiger Trend.

Nachtrag:
Meine Ursache konnte ich ausfindig machen. Es ist die erzwungene AF.

Mit den Einstellungen

konnte ich wie gewohnt mehrere Umläufe fehlerfrei fahren, und habe dabei was ganz was anderes feststellen müssen...

Da hat man nun eine Grafikkarte, die mehr Strom verbraucht, als der restliche PC samt Monitor zusammen und dann das. Nun denn...

Anfrage an M+R:
Welche Einstellung wäre das Equivalent zu OMSI < 1.04?
Dies wäre als Ausgangswert sehr interessant zu wissen, denn so könnte man etwas konkreter nach höheren Parametern suchen, die OMSI auch noch hinnimmt.

Hallo,

ich möchte meinen Dank für das Update auf v1.4 aussprechen.

Damals noch meinen Wunsch bzgl. mehrere Türöffner/Haltewunschzustände per Email an die Entwickler mitgeteilt, fand dieser Berücksichtigung. Nach der Installation gleich versucht, die Funktionsweise zu verstehen. Die Dokumentation ist etwas rudimentär, aber es mit bisschen Try&Test hat es geklappt, was ich schon sehr lange wollte... Danke Jungs

... Und schon kommen die nächsten Ideen, was man mit den neuen Funktionen noch so alles anstellen könnte *g*

Das sich die Spiegel erst aktualisieren, wenn der Mittelpunkt sichtbar ist, ist mit unter etwas unpraktisch. Vlt könnte man später noch einbauen, welcher Punkt sichtbar sein muß, damit sich der Spiegel aktualisiert. Aber die Frameraten sind deutlich gestiegen und das ist nicht unwesentlich.

Ein paar Frage noch bzgl. der Internet-Texturen:
Wie werden die Texturen heruntergeladen? Port 80 oder spezielles Protokoll?
Wie verhält es sich, wenn man nicht mit dem Internet verbunden ist? Bleiben die Texturen dann weiß?
Kann man die Texturen auch manuell runterladen und in OMSI einfügen? Das diese dann evtl. nicht zwingend auf dem neusten Stand sind, spielt keine Rolle.

Hi,

@ Charmed-Life :

wenn du meinen Beitrag nicht nur sehr auffällig zitiert, sondern ihn auch gelesen hättest, wüsstest du, daß ich die Bremskraft gar nicht ändern will.
Außerdem schreibst du selbst, daß du dir nicht vorstellen kannst, daß die Bremse so wirksam ist. Ich habe meine Feststellungen zur Bremskraft auf meine selbst gesammelten Erfahrungen bezogen, die ich mit echten Bussen gesammelt habe! Und darunter zählten eben auch Bremsversuche aus 60 und 10 km/h. Und die sind mit dem Modell hier sehr gut vergleichbar.
Meine Aussage derart zu untergraben, finde ich schon sehr anmaßend und unnötig!

@ Julian oder jene, die sich (wirklich) damit auskennen :

Ich würde mich freuen, wenn meine Anfrage zum IBIS beantwortet werden könnte.

Dazu ergänzend ist mir noch folgendes eingefallen: Das Steuergerät, was bei mir in der Schrankwand steht (ein MAS3), beherrscht auch noch andere Fehlermeldungen (Ansagen, Anzeigen, Funk reagieren nicht etc.). Kann das bei dir verwendete Steuergerät im Original solche Meldungen nicht, oder hast du sie nur aus Gründen der Komplexität nicht mit eingebaut?

@ Mich selbst :

Man muß sich hier wirklich genau überlegen, ob und was man schreibt...

Hallo,

das Fahrzeug ist einfach nur fantastisch. Probleme mit der Installation gab es nicht.

Ich durfte sowohl schon einen O405GN1 als auch GN2 fahren und auch wenn NSL und NSG nur bedingt vergleichbar sind, kommt das Fahrgefühl bei dem Modell sehr gut rüber. Die Bremsen sind zwar - im Vergleich zu den übrigen Bussen im OMSI - in der Tat etwas stark, aber das ist in Echt eben auch so. Nach paar Kilometer gewöhnt man sich dran.

Nach den ersten Runden ist mir aber auch einiges aufgefallen:

[']Der Geldwechsler hat 5 Röhren aber 6 Münzeinwürfe. Wo verschwinden die 5 DM-Münzen?
[']Taster für Tür 1 ist nicht animiert.
[']Matrix-Hintergrund und Schrift passen nicht ganz zusammen. Stört etwas, wenn man sich das ganz im Detail ansieht)

Auch finde ich es etwas merkwürdig, daß man die Kursnummern missbraucht, um Sonderlinienzeichen darzustellen. Da aber jeder Betrieb seine Daten pflegt, wie er sie eben braucht, nehme ich das einfach mal hin. In Stettin ist es aber sehr schwer, eine Kursnummer zu finden, bei der auch wirklich die Linie 522 dargestellt wird. Das Fahren mit Kurs 0 ist in meiner Region nicht vorgesehen. Aber auch das lässt sich ja korrigieren.

Zum IBIS hätte ich aber noch eine Detailfrage:
Ich kenne zwar das abgebildete Modell nicht, aber müsste mit der Meldung "IBIS GESTÖRT" nicht das gesamte Gerät funktionslos werden?
Auf dem Gerät kann ich ja nix mehr eingeben, also ist meine Annahme wohl zutreffend. Da die Anzeigen aber noch unter Strom stehen, müssten sämtliche Anzeigen nach ca. 10-30 Sekunden ihre alten Darstellungen löschen, da sie vom Steuergerät keine neuen Datentelegramme kriegen. Das wäre bei Flipdot- als auch bei LED-Anzeigen der Fall.
Dieses Phänomen hätte natürlich den m.M.n. gravierenden Vorteil, daß man regelrecht gezwungen wird, das Fahrzeug ab- und wieder aufzurüsten, denn sonst steigt bekanntlich keiner mehr ein.

Das sind doch schon mal gute Nachrichten

Sofern möglich und falls Interesse besteht, könntest du auch noch ein paar weitere Tasten mit Funktionen belegen. So könnte man u. a. das "IFIS-Stop" integrieren und die nach ganz korrekte Funktionsweise der Korrektur-Taste und der Haltestellenfortschaltung korrigieren.
Für Infos und Unterstützung stehe ich bereit

Hi,

ich hätte zum besseren Verständnis zwei Fragen:
Ist die als "neu" angepriesene Erweiterung für den U15 die selbe, die es vor geraumer Zeit schon einmal gab?
Falls nicht, was unterscheidet beide Versionen?

Für den U15 habe ich die Kasse schon längst drin und für den U10 fehlte sie eben bis dato noch. Nun endlich ist sie da und darüber freue ich mich sehr!

Die Freude wird aber ein wenig dadurch getrübt, daß das Wechselgeld in der Fahrertür verschwindet. Wäre super, wenn das noch korrigiert werden könnte. Kasse und Geldwechsler müssten ja nur etwas höher platziert werden, oder führt das zu neuen Problemen?
Das die Fahrertür noch weniger in den Bus rein passt, als das schon beim U15 der Fall war, ist ein Schönheitsfehler, der mich nicht weiter stört. Ich kucke ja schließlich auf die Straße und nicht auf die Füße. Nur wenn ich den Arbeitsplatz verlassen will, hilft nur über die Tür drüber steigen.

@ Zane:

Tolle Theorie, leider nicht haltbar.

Ich fahre überwiegend auf der Spandauer Map mit unter ganze Schichten (also 2x ca. 4 Std.) und da taucht das Problem nicht auf. Die gesamte Hinfahrt auf der 92 verlief störungsfrei und nach wenigen Haltestellen auf der Rückfahrt ist die Simulation nicht mehr fortsetzbar. Interessant ist eben auch der Umstand, daß die Framerate nur bei der Cockpitansicht rapide abfällt. Der Umstand, daß mein Rechner da nicht hinter her kommt, erschließt sich mir dabei nicht. Zumal ich das Problem bei anderen Fahrzeugen eben nicht kenne.

Edit:
Erschreckend, wer um diese Uhrzeit noch so alles wach ist ;-P

Zitat von Kamaz

Ums gleich vorweg zu nehmen, die Probleme mit dem Überhitzen und der Path's-Problematik sind bekannt und werden behoben.

Hallo,

eines vorweg, in Echt mag ich diese Busse überhaupt nicht. Liegt aber wohl auch daran, daß sie unter gewissen Umständen bei meinem hiesigen Busunternehmen fast gewandelt worden wären. Aber das tut nichts zu Sache. Das Modell finde ich hingegen sehr interessant und es macht mir auch Spaß damit zu fahren. Das will was heißen!

Da ich mich etwas genauer mit dem Spritverbrauch befasse, ist mir aufgefallen, daß der Verbrauch selbst bei gemäßigter Fahrweise bei etwa 80 Liter liegt. Auf Grundorf ist kaum etwas unter 100 Liter zu machen. Die "Kisten" sind zwar nicht gerade spritsparend, aber das ist dann doch etwas zu viel. Hängt evtl. mit dem Überhitzen auch mit zusammen.

Nach ca. 1 Std. Fahrzeit (OL 92) begann das Fahrzeug durch die Gegend zu springen. Mit der Außenansicht ist das zwar in den Griff zu bekommen, jedoch springt der Wagen wieder weiter, sobald man in die Cockpit-Ansicht wechselt. Da wird wohl in den Scripts etwas schief laufen!?
Installiert habe ich aktuell den unveränderten Bus + LCD-Mod. Ob das Phänomen auch ohne dem LCD-Mod auftritt, müsste ich seperat prüfen, sofern dies gewünscht wird.

Ansonsten ist mir nur aufgefallen, daß die Boundingbox nicht ganz korrekt festgelegt ist. Hat den Vorteil, daß man den Berliner Kreisverkehr so recht einfach (ein bisschen zu einfach) abfahren kann. Trübt aber eben auch etwas den Realitätsfaktor.

Hallo,

das sollte gehen. Die Passagiere/Passanten haben Script-Variablen, die deren aktuelle Position enthält. Damit müsste man also ermitteln können, ob und an welchem Ausgang sie gerade stehen. Aber das müsste dann manuell für jedes Fahrzeug angepasst werden. Nachteil: wie Lichtschranken in Supermärkten könnten dann auch Passanten von außen die Steuerung durcheinander bringen.

Wenn ich mal wieder etwas freie Zeit haben werde, würde ich mir diese Idee an meinem Ikarus 260 ausprobieren. Da der von außen keine Haltewunsch-Taster/Türöffner hat, kann ich diesen Umstand ignorieren. Wäre echt genial, wenn das funktioniert...

Hallo,

bei meinen Arbeiten mit dem Ikarus 260 bin ich auf ein ähnliches Problem gestoßen: der Bus hat für jede Tür einen seperaten Haltewunsch. Hat den enormen Vorteil, daß man nur jene Türen öffnen braucht, die auch für den Fahrgastwechsel benötigt werden.
Ich habe mehrere Versuche unternommen, alle samt gescheitert. Ich habe das Projekt eingestellt. Denn leider spielt OMSI hier nicht mit. Der Haltewunsch der Fahrgäste erfolgt eben nicht sciptgesteuert sondern liegt wohl tief vergraben in der EXE selbst. Damit ist es uns nicht mehr möglich, mehrere Haltewunschzustände zu simulieren. Eine Anfrage, ob sich dies im Zuge eines Updates ändern lässt, ist im Sande verlaufen.

Da - wie erwähnt - aber auch Gelenkbusse i.d.R. mehr als einen auswertbaren Haltewunsch-Zustand haben, müsste sich in der EXE auf jeden Fall etwas tun. Und ich bin mir sicher daß M+R dies im Zuge der Modellierung des Gelenkbusses dies auch schon bemerkt haben. Und wenn nicht, hätten sie hier einen wertvollen Hinweis

Hallo M+R,

ich arbeite an einem PlugIn, welches in C# geschrieben wird. Mit ein paar Umwegen ist es möglich, die DLL in OMSI geladen zu bekommen. Allerdings gibt es ein Problem mit der Schnittstelle selbst.

Die erwartete Funktion "Finalize" hat in der .Net-Welt eine spezielle Funktion, was zu einem Konflikt führt:

Zitat von Compiler

Warnung CS0465: Eine neue Finalize-Methode kann den Aufruf eines Destruktors stören. Wollten Sie einen Destruktor deklarieren?

Und genau diese Störung tritt auch ein. Ist die Funktion deklariert, beantwortet OMSI dies unmittelbar nach Programmstart mit "External Exception E0434F4D" (Die Speicheradresse ist bei mir jedes mal die selbe. Sicherlich kein Zufall).
Lasse ich die Funktion weg, startet OMSI und mein PlugIn fehlerfrei. Allerdings kann ich OMSI nun nicht mehr fehlerfrei beenden, da die erwartete Funktion "Finalize" nicht gefunden wird. Ergo führt dies zu einer 0-Pointer-Exception. Beende ich OMSI über den Task Manager gibt es zwar keine Exception, jedoch werden auch die Fahrerstatistiken nicht mehr aktualisiert, was bei mir ein mächtiger Motivationskiller darstellt.

Um den Leitmotto von OMSI gerecht zu werden und falls die die Funktionsnamen nicht von Delphi fest vorgegeben werden, wäre es sinnvoll die Funktionsnamen so zu bestimmen, daß sie nicht mit anderen Sprachelementen kollidieren. Es wäre sehr mühsehlig, wenn jedes PlugIn zwingend in Delphi geschrieben werden müsste. "Weil's geht" ist dann nicht mehr wirklich zutreffend

Das Einfachste wäre sicherlich, die opl-Datei zu erweitern, in der man die Namen der Funktionen angeben könnte. Ob man anhand des Strings die dazu gehörige Funktion in Delphi aufrufen kann, entzieht sich allerdings meiner Kenntnis. Ansonsten könnte man vlt. prüfen, ob FunktionA vorhanden ist, wenn nicht FunktionB ausführen. Die Existenz auf vorhandene Funktionen lassen sich in der .Net-Welt abfragen, also sollte das in Delphi auch irgendwie möglich sein...

Es wäre super, wenn sich eine Korrektur dieses Konflikts zeitnah (bspw. im Zuge des OL 5-Updates) einfinden könnte. Denn leider ist eine Veröffentlichung meines PlugIns unter dieses Gesichtspunkten nicht zumutbar.

Vielen Dank im Voraus.

PS:
Apropos Fahrerstatistiken... wäre es nicht sinnvoll, die Stats in der Simulation aller xy Minuten oder nach Abschluß einer Fahrplanfahrt zu speichern? Wenn ich bspw. eine ganze Schicht fahren will und OMSI/Windows stürzt ab, ist alles verloren. Sehr ärgerlich - kam leider auch schon mehrfach vor.

M+R haben im Wiki Recht: es sicherlich mit nahezu jeder Programmiersprache möglich, solange diese auch Zeiger beherrscht. Denn die Vermutung, daß das Gegenstück zu "var" Zeiger sind, ist zutreffend. Visual Basic fällt damit aus; um zumindest ein Negativbeispiel zu bringen.
Ganz so einfach ist's aber nicht, denn in der .Net-Welt wird alles im Grunde nur vorkompiliert, aber mit genügend Know-How oder entsprechenden Recherchen findet sich auf alles eine Lösung...

... nur bei dem Problem mit den String-Variablen habe ich absolut noch keinen brauchbaren Ansatz finden können

Hallo,

ich versuche mich ebenfalls an einem Plugin und möchte ebenfalls String-Variablen auslesen. Bisher erfolglos. Gemäß Wiki sollte es ja möglich sein.

Wie im obigen Beispiel müsste ja eine 2. (überladene) Funktion AccessVariable her, die statt einer Zahl auch Strings übergeben bekommen kann. Mein PlugIn soll in C# entstehen, welches Zeiger auf Strings nicht verwalten kann.
Selbst wenn ich aber den Zeiger-Aspekt außen vor lasse, müsste ich zumindest die Speicheradressen erhalten. Gegenwärtig erhalte ich aber nichts - seltsamer Weise auch keine Fehler.

Die nachvollziehbare Bitte von Tatra könnte man vlt. auch dahingehend abändern, daß die Admins uns gleich verraten, wie es gehen müsste. Das führt zumindest nicht zu einer Gratwanderung bzgl. Datenschutz und wir werden trotzdem schlauer

Hi,

Also die Passengercabin.cfg regelt das nicht. Wie der Name schon sagt, ist das nur die Definition des Fahrgastraums.

Ich habe mal ein bisschen in den Dateien rumgesucht, und habe den (niederschmetternden) Verdacht, daß der von den Fahrägsten ausgelöste Haltewunsch fest in der Omsi.exe enthalten ist. Sollte es keine Möglichkeiten geben, diese Methode zu überschreiben (vlt. mit einem PlugIn - nur wie?), wäre mein Vorhaben damit wohl gescheitert.

Über ein Statement der beiden Autoren würde ich mich sehr freuen. Sollte sich mein Verdacht bestätigen, würde ich mich sehr freuen, wenn über eine entsprechende Anpassung des Hauptprogramms nachgedacht wird. Ansonsten hätte ich das erste Argument dafür, daß der OMSI-Slogan doch nicht zu 100% zutreffend ist