Beiträge von sfhq

Aerosoft CAN do a lot - they can assign a new developer or development team to repair/patch/maintain OMSI and they should have all rights necessary to do that. They are however required to cancel their contract with Marcel first. This of course requires that they find a valid reason, e.g.violation of contract terms (such as not fixing bugs in time for a specific contract period). As far as I have heared, Aerosoft isn't happy with the current situation at all.

It may seem useless,

but why don't you write to Aerosoft support? Officially, it is their product and it is their job to support it. As Marcel does seem inactive regarding OMSI2 development/patches, why don't you ask the official support? Maybe they'll step in at some point, doing what Marcel seems no longer willing or able to do.

This is just my impression of the current situation and a suggestion to a possible solution for getting help. It is not meant to discredit any work that has already been done by Marcel in the past. Without him (and Rüdiger), there would be no OMSI.

Just my 2 cents

Mark

Zitat von Eschy5

In der Realität wird man vermutlich einen anderen Kodierstecker verwenden müssen, um die Fahrzeuge auf einer anderen Linie einzusetzen. In Omsi steckt man einfach den vorhanden Kodierstecker rein, klickt dann auf die Taste, mit der eine manulle Programmierung der Liniennummer möglich ist und gibt anschließend die Nummer ein. (423 für die 23A oder 424 für die 24A)
Dann noch die TEK-Ziele programmieren, und schon hat der Gelenkbus auch Ziele und Ansagen der Linie 24A bzw. der Solobus Ziele und Ansagen von der 23A.

Taste für manuelle Programmierung der Liniennummer? Die zeige mir mal im LU200 und GU240. Da geht's nur mit dem Kodierstecker.

@all:

Ich habe mir zu jedem der Fahrzeuge mittlerweile je eine weitere .bus Datei angelegt, die man in der Menüauswahl "neues Fahrzeug positionieren" durch den Zusatz "(Linie 23A)" bzw. "(Linie 24A)" auch gut auseinanderhalten kann. Entsprechend wird das Fahrzeug mit dem dazugehöigen Kodierstecker geladen, das geschieht über die Verwendung der alternativen constfile (vom jeweils anderen Fahrzeugtyp) und funktioniert wunderbar. So kann man auch den GU240 auf der 24A und den LU200 auf der 23A ohne Einschränkungen nutzen, wenn man das so wünscht - unabhängig davon, ob das seinerzeit gängige Praxis war oder nicht. Ich könnte den Mod hier im Forum bereitstellen, sofern Interesse besteht und ViewApp das nicht selbst nachliefern möchte.

ViewApp:
Wie sieht's aus? Das wäre doch wirklich eine Kleinigkeit gewesen, oder!? Übrigens, wie war das, die 24A ist nicht geeignet für einen Gelenkbus? Komisch, bin die Linie damit schon gefahren. Sogar schon zu Zeiten, als es den GU240 nur als KI-Bus gab (was er aber nicht lange blieb :P), sehe da keine Probleme mit 'nem Schlenki auf der Linie. Das mag damals nicht üblich gewesen sein, aber warum soll das in OMSI nicht gehen...

So long ...

sfhq

Hallo zusammen!

Ich habe seit kurzem Wien 1 und 2 und muß sagen, daß ich ein wenig enttäuscht bin.

Für die unterschiedlichen Kartenversionen hätte ich mir gewünscht, daß die Chronologie verwendet wird, statt je zwei verschiedene Mapversionen zu liefern. Für Besitzer beider AddOns hätte auch eine "große" Karte gereicht, auf der man beide Linien fahren kann. (Groß wäre die Karte damit immer noch nicht, mit der 23A hat man sich bequemerweise eine ziemlich kurze Linie ausgesucht.)

Richtig übel finde ich aber die feste Linienkodierung durch die fest vorgegebenen Kodierstecker. Wenn ich das richtig sehe, sind auf 24A offiziell nur die Solofahrzeuge einsetzbar und auf 23A nur die Gelenkfahrzeuge. Das ist für Besitzer beider AddOns eine sehr schwache Lösung. Offenbar muß hier der AddOn-Besitzer selbst Hand anlegen, um das Problem zu lösen oder zu umgehen, also modden, um z.B. den GU240 sinnvoll auf der 24A einsetzen zu können. Korrigiert mich gerne, falls ich hier irre.

Meines Erachtens stimmt das Preis-/Leistungsverhältnis - gerade durch obige Umstände - nicht wirklich. Insbesondere das kostenpflichtige Update Wien (alt) auf Wien 1 ist dreist. (Achtung: Das ist eine MEINUNG.)

Was ich auch nicht in Ordnung finde ich die Art von ViewApp, mit der man hier auf Kritik am Support reagiert. Da lese ich einerseits, wie man sich seitens ViewApp über die Art der Kritikäußerung hier im OMSI-Forum ärgert, andererseits vergreift sich ViewApp m.E. gegenüber den Forennutzern (= den Kunden) ein wenig im Ton. "Der Kunde ist König" hat man offenbar noch nicht gehört. Professioneller Weise wahrt man gegenüber dem Kunden erstmal einen guten Ton, AUCH WENN der Kunde (die entsprechenden Beitragschreiber hier im Forum) vielleicht keinen solchen anschlagen.

Dem Kunden den Supportweg in barschen Worten vorzugeben statt einfach zu helfen ist keine gute Idee, zumal Aerosoft wahrscheinlich am schlechtesten helfen kann, ob sie dafür bezahlt werden oder nicht. Natürlich könnte auch Aerosoft sich hier beim Support-Thread beteiligen, aber damit ist leider nicht zu rechnen. Aerosoft ist ein Publisher, sie entwickeln selbst gar nichts, sie verdienen primär daran, die Produkte anderer zu vermarkten. Würde ich jemanden suchen, der Ahnung hat, würde auch ich eher Hoffnung in den Entwickler setzen. Nicht ohne Grund veröffentlichen heute immer mehr Entwickler ihre Software im Alleingang, die Zeit der klassischen Publisher geht langsam zu Ende.

Btw., wer sucht Rat bezüglich OMSI2-Problemen bei Aerosoft und wer lieber hier im Forum des Entwicklers? Die Antwort kann ich mir denken. An Aerosoft wendet sich wahrscheinlich nur, wer sein Geld zurück haben will. So schlimm ist es ja zum Glück mittlerweile nicht mehr ...

Just my 2 cents

sfhq

Hallo hajo,

leichtes Rauschen, einmal ein leichtes Störgeräusch drin, aber tausendmal besser als die originalen Ansagen der Map!

MfG

sfhq

Hallo,

hatte mit der Installation und Vollständigkeit in der aktuellen Version 1.041 keine Probleme:

Nachdem ich mir noch "Creative Streets" wie auf Seite 1 beschrieben heruntergeladen hatte war laut Maptools alles vorhanden, den ganzen anderen Kram hatte ich schon.

Freue mich schon auf's Testen...

sfhq

Hi,

you haven't provided much information (current map, current bus, logfile), however you might want to check this out:

Have you checked your payware addons (DLCs)? Are they still activated (according to the OMSI2 options menu)?

I have heared several times from different people, that doing an in-place Windows upgrade can cause the activation information to become invalid, so if OMSI2 says "not activated", you might need to re-activate them using Aerosoft's launcher.If you have no payware addons, this approach does not apply to your case.

It's just a guess...

sfhq

Hallo,

hinsichtlich "exklusiver Splines" darf ich auf folgendes hinweisen:

Bei einer Spline handelt es sich um eine Textdatei, die OMSI Instruktionen liefert, wie aus Texturen mit Hilfe von Koordinatenangaben ein Objekt, z.B. eine Straße zu formen ist. Abgesehen von der Ursprungstextur(en) dafür leistet also OMSI die Arbeit der Berechnung. Sofern nicht auch noch besondere Texturen mit diesem "exklusiven Content" unerlaubterweise mitgeliefert wurden, dürfte ein Spline als Textdatei allein nicht die notwendige "Schöpfungshöhe" erreichen, um überhaupt unter das Urheberrecht zu fallen.

Darüber hinaus muß erkennbar sein, daß es sich um urheberrechtlich geschützten Zusatzcontent handelt. D.h. er sollte zumindest in einen separaten Ordner installiert werden, bei dem schon der Name auf den Urheber hinweist und ggf. eine README.TXT unter Splines\[besonderer Ordner] darauf hinweist, daß es sich um urheberrechtlich geschützten Content handelt, wer der Urheber ist, wie man ihn kontaktieren kann und unter welcher Lizenz der Inhalt steht, alles soweit zutreffend versteht sich. Ein Text in der Spline-Datei selbst hilft wenig - in jede einzelne aufgrund solche Eventualitäten vor Verwendung hineinzusehen ist kaum zumutbar.

Wer exklusiven Content so ausliefert, daß sich dieser mit Standardsplines oder völlig frei verfügbaren AddOn-Splines vermischt, der kann schlecht jemand anderes vorwerfen, diese auf Maps ohne besondere Vorsicht zu verbauen, sie fallen ja überhaupt nicht als exklusiver Zusatzcontent auf!

Just my 2 cents

sfhq

Hallo,

ich teste gerade die Map Ebstein, fahre der Reihe nach alle Linien. Das meiste zur Map, was es zu sagen gibt, wurde hier bereits gesagt, daher beschränke ich mich hier auf einen reinen Bugreport.

Aufgefallen sind mir Kollisionen auf Linie 106 (und möglicherweise anderen), die es nicht geben sollte.

(so wie auf dem Foto gezeigt steht der Bus bereits unmittelbar an der Boundingbox (Kolli!))

(als feine Linien sind die Boundingboxes sichtbar)

Betroffen sind die Objekte:

Sceneryobjects\Dohos_Objects\Misc\Baumecke.sco
Sceneryobjects\Dohos_Objects\Misc\Baumecke_doppel.sco

Diese bilden nicht nur dekorativ Schutzabgrenzungen für Bäume, sondern stellen an einen Stellen gleichzeitig auch Anfang und/oder Ende der Haltestellenbuchten dar. Da diese Objekte eine fürchterliche, rechteckige, über das Objekt hinaus (auch etwas in die Straße hinein) ragende Boundingbox haben, kommt es hier regelmäßig zu Kollisionen und entsprechenden Schäden an Fahrzeug und Lebendfracht, die sich heftig beschwert!

Man könnte die Objekte bis zu einem Fix mit einem [nocollision]-Eintrag patchen, aber das wäre nur ein (unschönes) Provisorium. Daher melde ich den Fehler hier mit Bitte um ein offizielles Update mit Fehlerbehebung. Da ja auch bereits fehlende Hilfspfeile aufgefallen sind, könnte man das ggf. in einem Schritt miterledigen.

Ansonsten erstmal Danke für diese kostenfreie Map!
(An all die Nörgler: Es gibt wirklich wesentlich schlechtere!)

MfG
sfhq

Hallo Alter_Sachse, Tatra und allen anderen, hallo auch an MR/Nachfahren und Aerosoft!

VORWORT
Ich möchte im Folgenden auf die noch bestehenden, extremen Probleme mit der KI eingehen, aber gleichzeitig auch einen Appell an die Entwickler und den Vertrieb von OMSI2 richten. Meine Kritik ist äußerst sachlich verfasst, so daß ich davon ausgehe, daß hier nicht gleich wieder irgendjemand den Text löscht!

PAYLOAD / NUTZINHALT

Es ist mein Eindruck, daß das oben beschriebene Auffahren der KI auf den Userbus spätestens mit v2.2.021 sogar erst so richtig schlimm geworden ist, auf manchen Fahrten passiert das gleich mehrfach. Dabei muß man nicht einmal stehen bleiben, deutliches Verzögern vor Einfahrt in einen Kreisel zum Beispiel reicht völlig aus. Auch seitliche Kollisionen treten immer noch auf.

KI-Fahrzeuge lassen dem Bus auch generell kaum "Bewegungsspielraum" - sie fahren - wenn sie denn rechtzeitig halten - immer so dicht heran wie es nur geht. Im Gegensatz dazu traut sich die KI an Bussen in Haltestellenbuchten zuweilen nicht einmal dann vorbei, wenn noch ~ 30cm Platz bleiben würden.

Meines Erachtens ist es auch der vollkommen falsche Weg, Kollisionsprävention nur anhand von "Spline des Users erraten" zu betreiben - und genau so kommt es einem auch vor. Grundsätzlich sollte es in keiner Situation dazu kommen, daß die KI den Userbus (und sich untereinander) rammt! Einmal weiß OMSI ganz genau, welche exakten Dimensionen ein jedes Fahrzeug in OMSI hat (genauer als es jeder Spieler einschätzen kann), zweitens läßt sich nicht nur anhand von Splines, sondern auch von aktueller Fahrtrichtung und Geschwindigkeit einschätzen, wolang das Fahrzeug fahren und welchen Platz es dafür beanspruchen wird.

Grundsätzlich vermisse ich in OMSI die Beachtung des §1 der StVO, hier heißt es:

Zitat

Straßenverkehrs-Ordnung

§ 1 - Grundregeln

(1) Die Teilnahme am Straßenverkehr erfordert ständige Vorsicht und gegenseitige Rücksicht.

(2) Wer am Verkehr teilnimmt hat sich so zu verhalten, dass kein Anderer geschädigt, gefährdet oder mehr, als nach den Umständen unvermeidbar, behindert oder belästigt wird.

Alles anzeigen

Das heißt, wenn OMSI korrekt arbeiten würde - als Simulator (nicht Arcade-Spiel) kann man das wohl erwarten - gäbe es kaum Unfälle mit der KI, denn die müßte ALLES MÖGLICHE UND ZUMUTBARE tun, um Unfälle zu vermeiden. D.h. selbst bei einem Fehler des Busfahrers müßte sie, wenn erforderlich, im Rahemen der Möglichkeiten zumindest abbremsen (auch scharf), wenn sich dadurch eine Kollision vermeiden läßt. Gleiches gilt natürlich auch für den (menschlichen) Busfahrer vor dem PC. Daß das KI-seitig recht gut funktionieren kann beweist SCS Software mit Euro Truck Simulator 2. Der sagt mir zwar aus anderen Gründen nicht so zu, aber die KI verhält sich meist ganz anständig.

Das Erzwingen einer Vorfahrt (sofern die KI dabei mal im Recht ist) ist ein Verstoß gegen die StVO und führt damit zu einer Mitschuld, u.U. sogar zur Hauptschuld (grobe Fahrlässigkeit, Vorsatz) an einem Unfall.

Unnötiges, womöglich scharfes Abbremsen, das zu einem Auffahrunfall führt, ist ebenso zu unterlassen und kann zu einer (Mit-) Schuld am Unfall führen, dazu kommen die vollkommen unrealistischen und oft auch sinnlosen Spurwechsel in OMSI. Dringend fehlt auch eine Möglichkeit, einen Straßenabschnitt als "außerorts" (Landstraße, Schnellstraße, Autobahn) zu deklarieren, damit OMSI hier das Rechtsfahrgebot einhält. Wie MR-Software / Nachfolger bestens bekannt sein dürfte, gibt es reichlich Kartenmaterial mit solchen Straßenabschnitten, die dringend eine solche Definitionsmöglichkeit erfordern, denn ohne ist das KI-Verhalten auf solchen Straßen unerträglich.

Da OMSI und seine Verkaufszahlen extrem von der Moddingfähigkeit und User-generated-Content profitieren, kann man hier m.E. auch nicht den Kopf in den Sand stecken nach dem Motto "haben wir für Berlin nicht gebraucht". Über den Status einer nur für Berlin angedachten Simulation sind wir seit OMSI2-Release wohl definitiv hinaus, denn schon zu OMSI1-Zeiten war recht bald klar, daß die Berlin-Karte bei vielen OMSI-Installationen unabhängig von den ursprünglichen Intentionen von Marcel und Rüdiger schon bald nur noch eine untergeordnete Rolle einzunehmen vermochte. Nichts gegen die Berlin-Karte, aber die allein ist vielen zu anspruchslos und auf die Dauer langweilig.

Ich hoffe wirklich sehr, daß sich mit den kommenden Patches nicht nur an Programmablauffehlern, sondern auch an konzeptionellen Fehlern wie dem KI-Verkehr und der Performance noch einiges tun wird. Vielleicht versucht man ja auch nochmal ein Parallelrelease einer 64bittigen OMSI-Version, das würde dem Speichermanagement sicherlich ordentlich helfen.

UND HIER KOMMEN WIR ZUM APPELL AN ENTWICKLER UND PUBLISHER
<im öffentlichen Beitrag entfernt> (Janine)

In der Hoffnung auf eine positive Weiterentwicklung!

sfhq

Bestimmte, neuere Nvidia-basierte Grafikkarten und deren Treiber unterstützen das Zusammenfassen mehrerer Monitore zu einem, d.h. das Betriebssystem Windows, das Spiele im Multimonitorbetrieb nicht besonders gut unterstützt, sieht nur noch einen (riesigen) Monitor mit gigantischer Auflösung. In diesem Fall sollte der Windowed Mode nicht einmal notwendig sein. Die Nvidia-basierten GeForce GTX960/970/980 unterstützen dies meines Wissens, zu anderen Karten bitte Informationen selbst einholen (http://www.nvidia.com). Ob das auch mit AMD/ATI-Karten (Radeon) geht ist mir nicht bekannt.

Damit's nicht total bescheuert aussieht, sollten es bei mehr als einem Monitor gleich drei (identische!) sein - bei zwei Monitoren würde in der normalen Fahreransicht diese genau in der Mitte durch die beiden Monitore geteilt. Bei drei Monitoren sollte die Fahreransicht normal bleiben, während links und rechts der erweiterte Blickwinkel zur Seite hin dargestellt wird.

Zitat von Daniel25ffm

Irgendwie finde ich den Kurzläufer von der Linie 27 Richtung Gabelung nicht in den Fahrplänen. Sind die vergessen worden???

Nein, ich denke nicht, Kurs 1007 (Mo-Fr) hat als letzte Tour

23:38 Mecklenbeck Wendeplatz ---> Gabelung 00:04

Wie ich aber 3 Artikel davor schon geschrieben hatte, gibt's da einen widersprüchlichen Eintrag in der HOF-Datei, so daß man das Ziel nicht richtig über Linie/Route schildern kann (schildert dann Ziel 100, Sisselsforst), m.E. aber manuell als Ziel 103.

MfG

sfhq

Hallo Städtedreieck-Team,

beim Erstellen von Umlaufkarten für unseren vBetrieb ist mir eine Merkwürdigkeit in der HOF-Datei aufgefallen, die Fahrten der Linie 27 nach Gabelung (Kurzläufer) betreffen. Das sind die Routen 02700/10, 02700/12 und 02700/14.

Bei diesen Routen ist das Ziel 100 in der HOF-Datei hinterlegt, was aber Sisselsforst Busbahnhof entspricht. Gabelung hat laut Terminus-Liste die 103.

Frage:
Hat sich hier jemand vertan und müßte da nun wirklich 103 stehen (wovon ich ausgehe), oder gibt es irgendeinen triftigen Grund für diesen "Falscheintrag", so er denn beabsichtigt ist?

Ich gehe jetzt mal spekulativ davon aus, daß Fahrgäste so in Richtung Sisselsforst in den Kurzläufer einsteigen und sich dann wundern, wenn sie an der Gabelung wieder raus sollen, umgekehrt aber von Sisselsforst kommend in Richtung Mecklenbeck gar nicht einsteigen, also nicht einmal bis Gabelung mitfahren.

Anders kann ich mir das höchstens dann erklären, wenn der Fahrplan der Karte an dieser Stelle ebenfalls irgendwelche Merkwürdigkeiten enthält, doch mit dem Fahrplaneditor kenne ich mich nicht aus, kann es selbst daher nicht überprüfen.

So es ein Fehler in der .HOF-Datei ist, könnte dieser mit einem künftigen Update natürlich behoben werden, derweil kann ich das hier lokal selbst schon mal korrigieren.

Besten Dank im Voraus und für das bisher geleistete!

MfG

sfhq

Zitat von O 405

Das geht schon, es müssen nur weitere Bedingungen vor dem {if} der Form "(L.$.number) xyz" $= ||" eingefügt werden. Naheliegenderweise sollten diese Nummern dann auch in der "Fahrzeugnummern_ORN.org" stehen.
"xyz" kann hier eine beliebige Wagennummer sein.

Code

1. {macro:details_frame}
4. 0 (S.L.Details_12)
7. (L.$.number) "620" $=
8. (L.$.number) "xyz" $= ||
9. (L.$.number) "xyz" $= ||
10. (L.$.number) "xyz" $= ||
11. {if}
12. 1 (S.L.Details_12)
13. {endif}
16. {end}

Alles anzeigen

Hi...

... ich gebe Dir absolut Recht, daß diese Methode auch funktioniert. Ich beschäftige mich aber noch nicht so lange mit OMSI-Scripts, daher war ich mit meiner Lösung schon ganz glücklich, die immerhin funktioniert. Ich hatte gar nicht in Betracht gezogen, daß OMSI ein logisches ODER verarbeiten kann.

Wenn ich was programmiere, dann eher mal in Perl (unter Linux) oder mal ein Linux-Shell-Script.

MfG

sfhq

doge43:

Was haben die Yufa Splines damit zu tun, welche Türen ein Bus hat??? Das mußt Du uns hier mal erklären.

Also ich sehe da einen ziemlichen Unterschied allein in der Ordnerstruktur:

Splines\...
Vehicles\...

Die können sich gar nicht beeinflussen, denn sie "bedienen" sich keinesfalls beim jeweiligen Nachbarn, sondern sind autark.

Die Außenschwenktüren hat standardmäßig nur der GÜ (ORN) mit der Wagennummer 620. Die anderen haben nur bei der mittleren Tür eine Außenschwenktür, sonst Innenschwenk. Ist hier im Thread auch schon reichlich oft erwähnt worden. Entspricht dem Vorbild in Mainz.

Wer eigene Wagennummern nutzen will und/oder die Zuordnung der Türen zu den Wagennummern beeinflussen will, der schaue sich mal im GÜ/ORN-Unterordner "Script" die Datei "sichtbarkeiten.osc" an. Die ist standardmäßig folgende:

So wie das gebaut ist, kann man die Wagennummer, die komplett Außenschwenktüren haben soll, 1:1 gegen eine andere austauschen. Mehrere Wagennummern mit kompl. Außenschwenk wird hier nicht unterstützt. Das ginge hingegen beispielsweise so:

Um mehrere Ausnahmen von der Mischbestückung Innen - Außen - Innenschwenk zu ermöglichen, habe ich die "if then else" Abfrage (wenn, dann, sonst) in eine reine "if then" (wenn, dann) umgebaut und die Standardeinstellung der Mischbestückung "0 (S.L.Details_12)" oben fest eingefügt. Das Script setzt also erstmal auf Mischbestückung bei den Türen. Dann werden die einzelnen if-Abfragen abgeklappert und der bereits gesetzte Wert ggf. mit "1 (S.L.Details_12)" so umgestellt, daß komplett Außenschwenk zum Einsatz kommt. Das Gute an dieser Lösung ist, daß man noch beliebige Abschnitte wie

für weitere Wagennummern einführen kann.

Es geht aber auch komplett anders herum:

Wer in den oben gezeigten Codeschnipseln einfach alle "1 (S.L.Details_12)" durch "0 (S.L.Details_12)" und umgekehrt ersetzt, der hat komplett Außenschwenk als Standard und die Mischbestückung im definierten Einzelfall.

Hoffe, das waren jetzt nicht zu viele böhmische Dörfer....

MfG

sfhq

Hallo,

eine Frage an die Ersteller dieser Map, also EVAG4101 & Co.:

Selbst unter den fiktien Maps gibt es bei vielen eine Story dazu, wo in etwa die Karte geografisch liegen soll. So z.B. bei Bad Kinzau, Römerberg, Ruhrau, ... um nur ein paar zu nennen.

Gibt es auch eine diesbezügliche Story zum Städtedreieck? Bisher habe ich dazu nichts gefunden, außer daß es die Orte Laupendahl (als Ortsteil von Heiligenhaus im Ruhrgebiet) und Kaisertal (in Österreich) tatsächlich gibt, nur ein wenig weit auseinander.

Danke im Voraus!

MfG

sfhq

No, this is NOT neccessarily steam-related (pure speculation), 'cause I got the same problem here:

My OMSI2 just froze while telling me it's loading / generating terrain. However, there is no payware addon involved here, but the error message is quite similar:

Zugriffsverletzung bei Adresse 50CE5CFA in Modul 'nvd3dum.dll'. Lesen von Adresse 00000DAB: POI.GHAA - C (vehicles\MAN_LC_GUE\Lions_City_G_Nach.bus)

The vehicle involved is a MAN Lion´s City GÜ from Projekt Mainz, Freeware.

---

Nein, das ist NICHT zwangsläufig ein Steam-Problem (reine Spekulation), denn ich habe hier das gleiche Problem:

Mein OMSI2 ist gerade eingefroren, während es lt. roter Schrift mit dem Laden/Generieren von Terrain beschäftigt war. Allerdings sind hier keine Payware-Addons im Spiel, dennoch ist die Fehlermeldung recht ähnlich:

Zugriffsverletzung bei Adresse 50CE5CFA in Modul 'nvd3dum.dll'. Lesen von Adresse 00000DAB: POI.GHAA - C (vehicles\MAN_LC_GUE\Lions_City_G_Nach.bus)

Das Fahrzeug ist ein MAN Lion´s City GÜ aus Projekt Mainz.

Any better ideas? Irgendwelche besseren Ideen?

sfhq

Tag zusammen!

Da die Fahrersichtperspektiven ("Fahrerkameras") auch beim heutigen Patch (24.06.) nicht verbessert wurden, erlaube ich mir auf folgenden Beitrag unter Bus-Mods hinzuweisen:

Überarbeitete Fahrersichtperspektiven für die MANs aus Projekt Mainz

Es handelt sich um einen Mod in Form einer Anleitung, wie man die Sicht des Fahrers bei allen drei MANs aus Projekt Mainz drastisch verbessern kann, auch der Hotkey für die Fahrplanansicht ist enthalten. Ist mit etwas Übung in 5-10 Minuten integriert.

MfG

sfhq

Zitat von Michael

C:\Users\Downloads\Mainz_V1_Teil1.rar: Prüfsummenfehler der Datei Sceneryobjects\Wiesbaden\texture\DrRing1.bmp. Die Datei ist beschädigt.
C:\Users\Downloads\Mainz_V1_Teil1.rar: Unerwartetes Archivende.

Die fehler bekomme ich bei Teil 1

C:\Users\\Downloads\Mainz_V1_Teil2.rar: Prüfsummenfehler der Datei vehicles\MAN_LC_G_MVG\Sound\DAF\DAF@575.wav. Die Datei ist beschädigt.
C:\Users\\Downloads\Mainz_V1_Teil2.rar: Unerwartetes Archivende.
Dies für Winrar und 7Zip in Teil 2

Und der Solo-LC ist nicht mehr mit drin. Ich habe alles vorher entfernt und nun ist er weg!!!
Auch Maps-Dateien fehlen alle, er entpackt nur vor dem Archivende Vehicles (4X) und Sceneryobjects.
Ergo kann ich aktuell nicht spielen, da ich ja keinen Maps-Ordner Mainz mehr habe!

Alles anzeigen

Das sieht so aus, als wäre Dein Download vorzeitig abgebrochen. Versuche es nochmal mit einem frischen Download, bei erneuten Problemen mal einen anderen Browser versuchen. Ich habe das Update heute auch heruntergeladen und es ist einwandfrei in Ordnung, natürlich mit dem Lion´s City Solo.

MfG

sfhq

Bilder zum Mod ergänzt, siehe Link am Ende des Originalbeitrags.