Tut mir leis.
Aber es scheint, als hätte dieses Problem bis dato noch keiner der Leser gehabt.
Es liegt also nicht am mangelnden Willen, dir zu helfen!
Edit:
Hier schau mal... 20 Seks gesucht und mit dem Begriff "Stromabnehmer" hier in der Suche gefunden:
http://rail-sim.de/forum/board…nt-br-143-pbel/#post52435
Ihr müsst auch bitte mal selbst bisschen suchen.
Spiel das Szenario doch mal im Original mit der 101. Dann weißt du es.
Paypal setzt ein Konto voraus.
Als z.B. Schüler hat man aber (noch) nicht zwingend ein eigenes Girokonto, so dass man auf den guten Willen der Eltern angewiesen ist. Wenn die sich aber querstellen, weil sie entweder zu geizig oder -ich nenne es mal- nur "schwach betucht" sind oder vielleicht sich Paypal im Speziellen oder dem Internet im Allgemeinen verweigern, hat man als Kind ein Problem. Dieses dann zu umschiffen geht dann nur mit einer PSC.
Weitere Gründe könnten sein: Generelle Verweigerung der Nutzung von PayPal, der Wunsch, anonym zu zahlen (Datensparsamkeit) oder eine Weigerung seitens PayPal, weil man dort irgendwie -wie heißt es so schön?- "anbrannte".
Hier ist alles Paletti
Nimm mal den Fuß vom WLan-Kabel runter, dann fließen die Daten besser durch 
Jetzt nicht mehr! Vielen Dank
Wenn ein Thread im falschen Unterforum begonnen wird, darf sehr gerne der melden-Knopf benutzt werden. Dann entgeht uns das nicht und wir können zeitnah agieren.
Vielen Dank
@Wuzzie:
Bitte künftig das passende Unterforum raussuchen 
naja, bisweilen hilft es nicht, das Problem zu ignorieren.
Da muss man eban halt mal den Diagnostiker oder Tester in sich aufwecken, sonst wird man ja bekloppt.
Auf die Art und Weise weiß ich jedenfalls inzwischen ziemlich gut, was ich dem Editor und meiner Kiste zumuten darf, und was nicht und mit der Zeit wurden die Crashs immer weniger, nicht weil ich die Missstände behob (das geht meist garnicht), sondern weil ich durch schmerzliche Erfahrungen lernte, gewisse riskante Tätigkeiten oder riskante Konstellationen zu umschiffen.
Das ist halt ein Entwicklungsprozess.
Ich erinnere mich daran, dass ich mal ein ziemlich langes Stück Loft markierte und mit "v" oder "b" heben/senken wollte. Das markieren der zahlreichen Loft-Segmente klappte super, aber als ich sie dann heben/senken wollte, flog der Editor mir rechts und links um die Ohren. Nach bisschen nachdenken war vollkommen logisch, was passierte: Das markierte Loft verließ die Darstellungszone in ca. 1 km. Und als ich dieses Loft, was ja garnicht mehr physisch im Editor präsent war/angezeigt wurde, es dann bewegen wollte, stieg der Editor aus.
Ich umging das dann, indem ich mich nach dem Markieren in die räumliche Mitte des Lofts begab und das Heben/Senken klappte dann anstandslos. Man hätte das Loft auch teilen können, aber das wollte ich vermeiden.
Was ich damit sagen will... manchmal (oder meist) braucht es nicht viel, um einen Crash zu vermeiden. Dazu gehört teils das Nachdenken, teils aber auch die Erinnerung, was beim letzten mal für eine Konstellation vorherrschte, als es beim letzten mal knallte. Irgendwann ergibt sich ein Zusammenhang, der zwar nicht lösbar, aber durch Vorsicht oder Improvisation vermieden werden kann.
Auf diese Art und Weise nagelte ich die Taschenlampe als Schuldige bei mir fest und seither "dreimal-klopf-auf-holz" kam das nicht mehr vor.
Gute Beobachtungsgabe ist hilfreich. Also nicht nur einfach frustriert neu starten, sondern sich im Moment des Crashs neben Ärgern auch mal besinnen und nachdenken:
Was war da grad anders als sonst? Welche Konstellation herrschte da vor? Was kann gerade passiert sein?
Und irgendwann mal.... ganz unvermittelt, macht es klick im Kopf und man weiß ganz genau: Wenn du jetzt (Beispiel) auf das Ding da klickst, dann machts PENG.
(Oh Gott, was'n Roman)
Im Grunde ist der Vertex-Buffer "nur" lästig, aber er zerschießt einem wenigstens nicht die Tracks.bin und macht daraus ein unbrauchbares 0-Bytes-File.
Da gibts nämlich noch ganz andere Bugs, die genau das tun. Und wenn man dann kein backup hat, ist die Strecke verloren: Weg! Kaputt! Unrettbar im Datennirvana abgesoffen.
Wohl dem, der ein aktuelles Backup hat.
Aha?
Bei den WOP-Hektometersteinen hatte ich das übrigens nie, nur bei Holzlaenders Hektometertafeln.
Ob nun Sh0- oder Sh2-Tafeln davon betroffen waren, kann ich nicht mehr sagen.
Ich denke aber mal, dass wegen der erhöhten Anzahl an Hektometertafeln gegenüber Sh0- und Sh2-Tafeln die Wahrscheinlichkeit höher war bei mir, dass es da eher zu 'nem Crash kam.
Ob das nun wirklich an Holzlaenders Tafeln liegt, kann ich mir eigentlich nicht vorstellen, denn mir scheint, dass "Holzi" schon weiß was er tut.
Ich werde mal 'nen Monitor mitlaufen lassen, vielleicht bringt der Aufschluss z.B. über den VRam-Verbrauch. Wenn der gegen die Decke läuft, weil benutztes und dann nicht mehr benötigtes VRam nicht mehr freigegeben wird ("MemLeak") ist klar, dass es dann irgendwann knallt.
Nachwievor habe ich die Taschenlampe stark im Verdacht, aber vielleicht verstärkt sie das Problem ja auch nur.
Ich halte jedenfalls einen "MemLeak" für den wahrscheinlichsten Grund dieses Fehlers: Alloziert, benutzt, nicht (vollständig) freigegeben ----> VRam voll ----> Fehler: "Kann keinen Vertex-Buffer (mehr) anlegen." ---> PENG
Genau. Und nach meiner Ansicht ist das die Taschenlampe schuld, aber komischerweise nur in Verbindung mit Objekten der Gleisinfrastruktur.
Wenn das noch jemand bestätigen könnte, hätten wir einen Schuldigen dingfest gemacht und könnten alle diese Kombination meiden.
Genau!
Exakt meine Beobachtung, vor allem bei Hektometertafeln.
Bei mir trat das Problem vor allem dann auf, wenn ich dazu noch die Taschenlampe aktiviert hatte. Seither ich die auslasse, hatte ich bislang keinen dieser Vertexbuffer-Fehler mehr. Es mag allerdings Zufall sein, natürlich.
@Freekill:
Bitte künftig Suchfunktion bemühen.
Beiträge 11 bis 13 hierher verschoben, weil ursprünglicher Thread komplett andere Thematik behandelte.
Bei mir rennst du da offene Türen ein. Ich bin auch nicht so DER RWTools-Fan, weil es reichlich buggy ist, mir schon meine Strecke zerschoss, und furchtbar unlogisch verschachtelt und inkonsequent strukturiert ist.
Dennoch gehört einiges dazu, einen zeitlichen Ablauf, der bereits funktioniert, wieder mit anderen Anfangszeiten und -viel schlimmer- Zeitdauern wieder genauso hinzubiegen, wie der Szenariobastler es ursprünglich beabsichtigte.
Bis man das ohne Fehler wieder hinbekommt, können Stunden vergehen ohne Anspruch auf Erfolg.
Daher bleibe ich bei meiner These, dass er nur die Startzeit des Szenarios ändern, und vom Rest die Finger lassen sollte, wenn er nicht masochistisch veranlagt ist.
Übrigens wäre mir neu, dass RWTools da irgendwas (sinnvoll) abändern kann. Die Funktion zum Zeiten abändern ist doch total unbrauchbar, weil RWT alle Startzeiten auf den gleichen Wert legt und weder Differenzen noch Offsets berücksichtigt. Wenn ZugA um 12:00 losfährt und ZugB erst um 12:05 und man ändert in RWT die Zeiten auf z.B. 11:00 Uhr, dann fahren anschließend beide Züge um 11 Uhr statt mit 5 mins Versatz. Zumindest habe ich das noch nicht hinbekommen, daher mach ich das lieber manuell.
Das hilft aber nicht wirklich, weil ja alle KI-Züge auf den Fahrplan des Spielerzuges abgestimmt worden sind. Das ist ja das Problem.
Außerdem hat er nicht während des Fahrens den Zeitmangel, sondern nur beim pünktlichen Losfahren am Beginn, wegen der Rüstzeiten.
(Zumindest verstand ich das so)
Alternativlösung: Beim Aufrüsten die Finger fliegen lassen 
Dann teste doch mal meine Variante in Beitrag #13 mit dem Editieren der SzenarioProperties.xml
Das sollte nun wirklich nicht die fahrpläne der Züge beeinflussen.
Also einfach bei StartTime z.B. 180 Seks abziehen.
Ansonsten bin ich dann auch überfragt und hab einstweilen keine Idee mehr, außer das Szenario im Ganzen abzuändern und jeden Zug anzufassen.
Das ist eigenartig, denn die Startzeit des Spielerzuges ist doch von der Startzeit des Szenarios unabhängig. Die Startzeit des Spielerzuges darf halt nur nicht zeitlich vor der des Szenarios liegen.
Hast du denn die Startzeit mal so geändert, wie Ingvar vorschlug?
Denn diese Änderung sollte wirklich nur die Startzeit des Szenarios ändern, und sonst garnichts, was zur Folge haben müsste, dass man (theoretisch) sich vorher derart viel Zeit einbauen könnte, dass es für 'nen Toilettengang, einen Kaffee und eine entspannte Aufrüstung reicht, bevor es dann losgeht.
Das Auge blendet nur bereits aktivierte Sachen in der Lieste links ein oder aus. Sonst nichts.
Ob der Haken beim Auge an oder aus ist, ist also für die Funktion an sich unerheblich.
Die Objekte, bei denen das Auge deaktiviert wurde, bleiben auf der Strecke / im Szenario in der 3D-Welt sichtbar und aktiv. Sie verschwinden nur in der Liste links, damit diese nicht so "zugemüllt" ist.
Beispiel Streckenbau:
Ich hab 'ne Strecke gebaut, hab alle Signale gesetzt, dann kann ich das Auge bei den Signalen wegmachen, damit die 47.851 Einträge in der Liste nicht mehr auftauchen und ich in Ruhe z.B. die Beschilderung machen kann.
Beispiel Szenarien:
Ich will deutsche Güterwaggons auf der deutschen Strecke verteilen, aber das englische Rollmaterial aus dem Kuju-Ordner nervt mich. Dann setze ich das, was ich aus dem Kuju-Ordner benötige, mache dann das Auge weg bei Kuju und sehe endlich wieder den Wald zwischen den Bäumen.
Wirklich sehr schön.
Alles sehr authentisch vergammelt, verrostet, zugewuchert.
In der Realtät sicherlich nicht so schön, aber hier eine Augenweide.
Sehr schöne Eisenbahnromantik.
Weiter so!
Sieht gut aus.
Da hinten stimmt was an einer Weiche nicht.
Bitte mal nachsehen, was da klemmt.
Das ist leider ein "normales" Verhalten dieser Decals.
Ich drücke bei markiertem Decal "v" oder "j" und dann ist es für die jeweilige Sitzung in ordnungsgemäßer Position. Nach einem Neustart des Editors ist wieder alles beim Alten, aber das stört mich nicht.
Habe derzeit eine Decal-Größe von 400m x 400m, es kann sein, dass größere Decals noch mehr Probleme machen und kleinere umso weniger.
Sieht großartig aus.
Vor allem die Innenansicht ist beeindruckend.
Tolle Geräuschkulisse mit dem ganzen Geknarze und Gerappel.
Bin mit dem Ding in Natura leider nie gefahren, aber Optik und Sound wirken auf mich natürlich und authentisch und vermitteln (mir) einen hohen Grad an Realismus.
Ich freue mich auch drauf.
Der arme Souldream ist jetzt total verunsichert und korrigierte da jetzt irgendwas, wo es garnichts zu korrigieren gab. Der Sinn dieses Satzes bleibt jedenfalls derselbe.
Wie auch immer... einigen wir uns einfach auf ein Konglomerat unglücklicherUmstände mit Hang zur Kettenreaktion.
Unstrittig dürfte sein, dass wir alle dasselbe meinen, und da die Formulierungen nun hinreichend oft durchgekaut, uminterpretiert, korrigiert, die Korrektur richtiggestellt und bestätigt, verloren, aufgefunden, reingewaschen und zum Trocknen auf die Leine gehängt wurden, dürfte hoffentlich jeder Zweifel auch bei einem totalen Eisenbahnneuling beseitigt sein.
