Abstürze und Ursachen Diskussion


Abonniere unseren Kanal auf WhatsApp (klicke hier zum abonnieren).
  • abgetrennt aus dem Elbe-Weser-Dreieck Thema, Zaunpfahl



    ######################################
    Vorab:
    Vielen Dank an Zaunpfahl für das Abtrennen vom Ursprungsthread und das Aufsplitten in ein separates Thema.


    Kurze Einführung:
    Die Abstürze der größeren Freewarestrecken wie z.B. Hamburg-Bremen und Elbe-Weser-Dreieck_v2 führten im Elbe-Weser-Dreieck-Thread zu einer Diskussion, wo die Ursachen dieser Abstürze zu suchen sind und wie versucht werden kann, dies zu reparieren und wie dies bei künftigen Strecken generell vermieden werden könnte.
    ######################################



    Und wenn es in der Vorversion klappt und jetzt nur noch Probleme verursacht, dann ist es die SOFTWARE.

    Das ist halt die große Frage. Es kann ja sein, dass ein verbautes Objekt oder eingesetztes Rollmaterial seit TS2013 nicht mehr kompatibel ist und daher die SBHs verursacht.
    Ich erinnere z.B. an den SAD-River oder die Mauer_halbhoch.
    Irgendetwas muss also fehlerhaft an diesen Objekten sein und die Software (der TS) fängt das nicht korrekt ab und steigt aus.


    Natürlich könnte man jetzt sagen, dass der TS eine Prüfungspflicht hätte, um inkompatible Objekte als inkompatibel zu erkennen, damit er nicht abstürzt, aber selbst hochprofessionelle Software wie der Adobe Reader, Java, Flash, oder oder oder haben diese Schwächen, die sie angreifbar machen, wenn man ihnen (absichtlich) inkompatible Sachen zuwirft, die einen Überlauf verursachen, den man dann ausnutzt, um eigenen Code unterzujubeln. Daher sollte man in bezug zum TS da etwas toleranter sein, zumal diese Inkompatibilitäten nicht von den RSC-Objekten stammen, sondern (soweit bisher bekannt) aus dem Freeware-Sektor.


    Wie auch immer.... irgendwann kommen wir bestimmt dahinter, welches "Ding" hier für Unruhe und Frust sorgt.


    Ergänzend möchte ich hier mal anfragen, inwieweit sich jemand mit den Dump-Files schon mal auseinandergesetzt hat. Normalerweise sollte man mit einem geeigneten Debugger dahinterkommen können, weshalb der TS das Zeitliche segnete. Hat da jemand Erfahrungen? Hat das schonmal jemand praktiziert?


    Edit:
    Nach Abtrennung vom EWD-Thread Pramble hinzugefügt. Danke Zauni :thumbup:

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

    2 Mal editiert, zuletzt von Prelli ()

  • Hallo Prelli!


    Es kann ja sein, dass ein verbautes Objekt oder eingesetztes Rollmaterial seit TS2013 nicht mehr kompatibel ist und daher die SBHs verursacht


    Das ist doch genau das, was ich immer sage, das die Software sich geändert hat. Ich, oder Mike oder andere haben doch nichts geändert. Es läuft einfach nicht mehr.
    Und wenn diese Komiker von RSC wenigstens dokumentierten, was sich geändert haben, könnte man ja gegensteuern.
    Aber vielleicht können sie nicht schreiben. :S
    Wenn man so mit Kunden umgeht, sind die irgendwann halt weg.


    Bei den vielen Gebäuden, Lofts und anderen Sachen, die es mittlerweile gibt, ist es doch unmöglich, den oder die Störenfried(e) auszumachen.


    Keine Planunssicherheit, kein Bock mehr. Frust ist Lustverlust *achtung*


    lg
    schotti

    Grüße
    Schotti *hi*

    Win 10 Pro, Intel I7-8700, 32 GB RAM DDR4-2400, 1 TB SSD Boot, Seagate ST 2000 Daten.
    nVidia GTX 1080 8 GB, AOC 28`` 4K Monitor
    TS auf separater SSD 512 GB nur mit deutschen Strecken

  • Das ist doch genau das, was ich immer sage, das die Software sich geändert hat. Ich, oder Mike oder andere haben doch nichts geändert. Es läuft einfach nicht mehr.

    Die Software hat sich nicht wirklich maßgeblich geändert in den letzten Versionen. Das ist falsch. Es kamen ein paar wenige Dinge hinzu, aber die sind meist separiert. Also es hat sich nichts geändert was eine Strecke vernichten würde. Es muss ein Fehler in einem Objekt vorliegen der vll vorher toleriert wurde, nun aber nicht mehr. Das Problem liegt also auf der Seite des Erbauers dieses fehlerhaften Objektes. Meist sind es noch Reste aus dem alten Railsimulator die Probleme machen, oder grundsätzlich falsch erstellte oder falsch konfigurierte Assets. Ein einziger fascher Wert im BP eines Asstes kann sofort zum Absturz führen. Wenn die Strecke lädt, aber auf bestimmten Kacheln dann abschmiert, ist die Logik geboten genau dort zu suchen. Möglichst ohne aktive Szenarien. Szenarien sind von sich aus schon Fehlerquellen wenn sie falsch erstellt werden.


    Und wenn diese Komiker von RSC wenigstens dokumentierten, was sich geändert haben, könnte man ja gegensteuern.
    Aber vielleicht können sie nicht schreiben.

    Die haben halt nichts geändert. Die Neuerungen die von denen kommen sind nur kosmetischer Natur. Der eigentliche Programmkern hat sich nicht verändert.


    Bei den vielen Gebäuden, Lofts und anderen Sachen, die es mittlerweile gibt, ist es doch unmöglich, den oder die Störenfried(e) auszumachen.

    Tja, das muss man dann aber trotzdem machen, sonst bleibt der Erfolg aus. So ist das halt.


    Keine Planunssicherheit, kein Bock mehr. Frust ist Lustverlust

    Und das hält dich auf? Dann bist du nicht geeignet zum Streckenbau (das ist nicht böse gemeint, sondern einfach realistisch gesehen), denn da muss man solche Rückschläge einfach wegstecken. Ich habe selbst diverse Rückschläge erlitten und die kratzen mich 5min. lang und dann gehts weiter. Hier gilt das gute alte Sprichwort "selbst ist der Mann/die Frau". Einfach kann jeder, TS2013 nur wenige.

  • Danke Maik, für die Infos zum Dump.
    Hast du schonmal versucht, einen Debugger mitlaufen zu lassen?
    Meine letzten Erfahrungen mit einem Debugger hatte ich vor ca. 15 Jahren, daher weiß ich nicht, was sich da alles tat.
    Doch muss man doch irgendwie dahinterkommen können, wenn mein einen reproduzierbaren SBH hat.



    Ich wollte auch schon oft alles an die Wand klatschen, das nebenbei.
    Einmal hats mir die Tracks.bin zerlegt, so dass sie nur noch 0 Bytes Größe hatte.
    Ohne Backup wär die Strecke unrettbar weg gewesen.


    Der TS hat Mängel und Schwächen, keine Frage.
    Doch bin ich der Meinung, dass man dahinterkommen kann, was einen SBH verursacht, wenn man genug Energie aufbringt zu suchen und (ganz wichtig) wenn man sich selbst eine vernünftige Strategie erarbeitet, wie man vorzugehen hat. leider ist das meist mit sehr viel Arbeit verbunden, so dass ich -was die EWD von mike betrifft- derzeit etwas auf der Stelle trete und nicht nur ich würde mich freuen, wenn auch andere Leute die Augen offen halten könnten, damit wir herausfinden, was das problem ist.
    Die Lösung käme nämlich nicht nur der EWD zu Gute, sondern auch andere Strecken, die dieses Objekt benutzen. Auf diese Weise kommt man vielleicht auch dahinter, WARUM dieses Objekt Probleme macht, damit künftig sowas generell vermieden werden kann.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Hallo Maik,


    Also es hat sich nichts geändert was eine Strecke vernichten würde


    Na, Du scheinst den Code ja zu kennen, dann müßtest Du doch Abhilfe schaffen!!


    Wenn er RW sich jetzt an Objekten stößt, dann MUß doch was geändert worden sein. Mir kann doch keiner erzählen, das es das gleiche Programm ist, nur empfindlicher.
    Was ist denn da empfindlicher? Wie kann dem Abhilfe schaffen?


    Ausserdem hat das Programm mehr Fehler, wie ein Straßenköter Flöhe.
    Kein Neustart nach Cache leeren - kein Fehler?
    Keine zwei Szenarien nacheinander starten-kein Fehler


    Ich hab Programmieren aber anders gelernt.


    lg
    schotti

    Grüße
    Schotti *hi*

    Win 10 Pro, Intel I7-8700, 32 GB RAM DDR4-2400, 1 TB SSD Boot, Seagate ST 2000 Daten.
    nVidia GTX 1080 8 GB, AOC 28`` 4K Monitor
    TS auf separater SSD 512 GB nur mit deutschen Strecken

  • Erst mal muss definiert werden was für ein Absturz es ist. Ein SBH ist eine allgemeine Meldung die nichts über den wahren Fehler aussagt. Ich habe deine Strecke nicht und ich denke ich werde die auch nicht installieren denn der Asset-Wildwuchs kommt mir nicht auf die Platte. Und da sind wir auch beim wesentlichen Problem. Ich deke du wirst nicht anders heran gegangen sein als Mike mit seinem EWD. Ich habe gerade mal nur die RouteProperties vom EWD aufgemacht und mir war sofort klar warum das nicht gut geht. 122 Provider/Produkt Einträge. Sorry, aber da muss jedem sofort klar sein dass das ein riesen Problem wird. Wenn da 10 drin stehen ist das tolerierbar, aber keine 122. Der TS lädt die alle beim Start der Strecke und prüft die. Die BP Shemes bleiben im RAM hängen und müllen alles voll. Das ist purer Text in XML Format der da hunderte von MB in dem Speicher drückt. Der TS macht bei 1.15GB langsam Schluss im Editor. Bei 1.27Gb sollte man dringend speichern und Backup machen bevor man den Editor schliesst. Im Spiel selbst ist der Verbrauch dann auch ein Problem. Der TS nimmt sich zwar auch gern 3gb Speicher aber läuft dann nicht mehr stabil. Ihzr müsst darauf achten dass der Speicherverbrauch niedrig bleibt, auch wenn man zheoretisch 3.xGB zur verfügung hätte. Dieser Verbrauch ist absolut unnötig. Und nur wenn die laufende Strecke unter dem Wert von 1.2 bleibt ist ein vernünftiger Betrieb zu erwarten. Das geht aber halt nicht mit 100 freigeschalteten Providern. Irgendwann hatte ich das schon mal erwähnt dass das ein Hauptproblem ist und auch die Installation ist alles andere als toll bei solchen Dingen. Lasst euch da mal was neues einfallen. Die verwendeten Asstets sind eh immer die gleichen freeware Objekte also kann man sich da auch zusammentun und ne Lösung finden. RSC packt nicht umsonst alle Assets, auch redundant, immer komplett in den Streckenordner. Das ist dann ein einziger BP Sheme Satz im Speicher der keine 50MB braucht. Die Assets werden nur geladen wenn sie auch gesezt wurden, aber die Shemes werden immer geladen.


    EDIT: was auch ein Problem sein wird, ist dass viele Freewareobjekte nicht unbedingt mit dem BP-Editor erstellt wurden sondern die XML Einträge per Hand gemacht wurden und dann nur über Serz gezogen. Dabei vergessen gern viele die IDs in den Knoten. Ich bin mir da nicht sicher, aber ich denke daher rühren viele Assetkonflikte im Speicher. Die Vererbungstrategie von Kujus Urentwicklung wird diese IDs zu Hilfe nehmen. Wenn man nun sich in den XML Dateien selber die IDs ausdenkt, was man muss wenn man da per Hand drin fummelt, und vll sogar doppelte drin hat, dann sind Fehler eben schon hausgemacht von Ersteller des Assets. Das Asset allein muss dabei nicht mal einen Fehler hervorrufen. Aber im zusammenhang mit vielen anderen wird es eben zum Problem wenn da was kollidiert. Man muss sich schon auch an die Developervorgaben halten soweit das geht. Der BP Editor ist jedem zugänglich und sollte benutzt werden für alles wo es nur geht. Denn der prüft Abhängigkeiten. Wie genau weis man nicht, aber er tut es.

  • Zum Teil kann ich Dir zusteimmen, ich habe eben mal aus Hamburg-Bremen den Szenerieordner rausgenommen, dann geht alles perfekt.
    Aber SBH ist ne Fehlermeldung, das ist ärgerlich genug und wenn diese Schnarcher keine vernünftige Fehlerroutine einbauen können, ist das traurig genug. Da brauch ich keine Definition , nur einen Grund
    warum er Tschüß sagt.
    Wenn Du auch schon so lange mit RS und RW rumgetan hättest, wäre es vielleicht bei Dir nichts anderes:
    Damals gabs nix anderes, als das von RSDL und Freeware. Da hat man alles genommen.


    Da von uns keiner Hellsehen kann und konnte, war zu keinem Zeitpunkt abzusehen, das RSC einmal herginge und Änderungen vornähme, die es unmöglich machten, private Objekte zu verbauen.
    Vor allem Änderungen, die nie näher erläutert wurde. Es geht wohl nur noch um Kaufen und Maul halten. Hauptsache Kohle rüber.
    Schlechtes Marketing, weil ich und auch andere für RW NICHTS mehr kaufen


    Sei es nun EWD, Hamburg-Bremen oder Stuttgart-München, ich für meinen Teil habe es eigentlich für mich gebaut und wollte es nur weiteren Interessenten anbieten, wenn sie möchten.
    Wer möche kann es, wer nicht (wie Du) solls bleiben lassen. Das ist sein gutes REcht und mir völlig Schnurz. Ich brauche keine Profilierung, ich kenne mich seit 67 Jahren und weiß, was ich wert bin. :P
    Wenn bei den 13000 DL von Hamburg-Bremen 20 fahren, ist das doch OK. ICH freu mich an meiner Heimat und an meinem Wohnort (Ulm) - und manch anderer vielleicht auch - TOLL


    Danke für DEine Ausführungen


    schotti

    Grüße
    Schotti *hi*

    Win 10 Pro, Intel I7-8700, 32 GB RAM DDR4-2400, 1 TB SSD Boot, Seagate ST 2000 Daten.
    nVidia GTX 1080 8 GB, AOC 28`` 4K Monitor
    TS auf separater SSD 512 GB nur mit deutschen Strecken

  • Bitte noch mein Edit lesen.


    Aber ja, ich kann dich schon verstehen. Aber die Prinzipien des Programms haben sich seit 2006 nicht wirklich verändert. RSC hat schnell gemerkt dass der Sammelordner KUJU ein Problem ist und ab da dann eben jede Strecke in einen eigenen Ordner gepackt. Seit dem laufen deren Strecken auch deutlich besser und werden extrem schnell geladen. Das ist keine Magie das ist pure Logik. Bei Freeware sicher schwer zu machen, aber man sollte versuchen so viele Assets wie möglich zusammenzuführen um die Blueprint Preloads zu reduzieren. Und eben auf die Korrektheit der Syntax in den XML/Bin Files achten. Das hat sich alles seit Anfang an nicht verändert. Ich habe den RS schon seit er damals auf dem Markt kam und habe den auch damals schon untersucht. Öffentlich habe ich mich erst 2011 damit beschäftigt. Aber ich bin da schon länger dran und weis was ich erzähle. Dein Problem kann sicher gelöst werden, aber nicht mit dem Wildwuchs. Wenn du das nur für dich machst, kannst du ja alles umschichten und deine Strecke auch genießen. Nur verteilen kannst du die dann öffentlich nicht mehr. Je nach dem wie diese gebaut ist wäre das durchaus schade. Ich glaube nämlich nicht dass die Umsetzung von Vizzard so grandios wird, aber da warten wir mal ab.


    Mein Vorschlag wäre dass sich all die Freewarestreckenbauer mal zusamment tun, eine schöne Strecke aussuchen, und dann mal richtig bauen. Ich wette da habt ihr deutlich mehr Erfolg mit und vor allem weniger Ärger. Nur so ne Idee.

  • Hallo Maik,


    die Idee das sich alle mal zusammen tun sollten und ein Projekt dafür Richtig erstellen klingt gut und würde durch aus Sinn machen das man nur einen Developer Ordner hat und am Anfang einen Strecken Ordner.
    Nur wird sich kaum einer darauf einlassen weil dann wieder das schon mal geschriebene Phänomen auftritt Freeware und Cobyright


    Der eine baut Schienen, der andere Objekte usw. und das alles in einem Developer Verzeichnis würde hier so einige Probleme verhindern. Und sämtliche Projekte schneller voran treiben.

  • Wenn ein Freewareprojekt Erfolg haben soll wird man daran nicht vorbei kommen. SADs Freeware damals war deswegen so gut weil er es genau so gemacht hat. Natürlich hat er alles selber gebaut und auch Fehler gemacht, aber dennoch war das der richtige Ansatz. Ich bin mir sicher dass hier genug fähige Leute sind die alle zusammen und ohne irgendwelche (c) Probleme zu haben eine Strecke auf wirklich hohem Nieveau bauen können, aber das fordert enorm viel Disziplin und Ausdauer bei allen Beteiligten. Und das ist ja leider schon rein theoretisch nicht machbar. Jeder hat halt seinen eigenen Kopp. Es würde aber reichen sich einfach im Freewarebereich zu einigen. Es ist nun mal ein technisches Problem wenn 500 Bastler dann auch 500 Assetprovider haben. Manche haben selbst noch 5 eigene weil sie hier und da was falsch machen. Mich schockiert es regelmäßig Assets von Freewarebauern im Developer Verzeichnis zu finden. Sowas darf nicht passieren. Ordnung ist nicht umsonst das halbe Leben.

  • Alles zu einer Strecke in einen Ordner, das macht Sinn!
    Der Streckenbauer darf die Freeware Assets nicht in einen Ordner packen und weitergeben. Der Endbenutzer darf das aber. Könnte man das nicht automatisieren? RW-Tools findet ja schon raus, was bei einer Strecke fehlt, kann also auch herausfinden, was dazu gehört. Wenn das Programm dann das ganze in einen Ordner kopieren würde und die ganzen Pfadangaben in den XML Dateien automatisch anpasst?
    Ich habe bis jetzt keine sehr tiefen Kenntnisse der Dateistruktur vom TS, die Gedanken kreisten halt so im Kopf und ich dacht ich schreibe sie hier mal hin. Maik wird bestimmt gleich erklären, warum ich hier Quatsch geschrieben habe. :ugly:

  • Quatsch nicht aber such mal eine Nadel in 100 Heuhaufen. Da wirst nicht fündig. Freeware Assets die für den Streckenbau gedacht sind und von ihren Erbauern nicht zur Konfektionierung freigegeben werden wollen, sollte man einfach links liegen lassen. Es macht einfach keinen Sinn sich für eine Strecke 200 Ordner auf die Platte zu zimmern und zu denken das wäre alles normal und toll. Ist es nicht. Sieht man ja deutlich. Viel zu viele Abhängigkeiten und irgendeine davon muss nur austicken und schon kracht die ganze Bude zusammen wie ein Kartenhaus. Was du vorschlägst ist schlicht unlösbar. RWT braucht ja schon ewig um ein Szenario oder eine Strecke zu prüfen. Wenn es dann noch die neuen Positionen finden soll und die Asstest in den Streckenordner verschieben muss, dann wird der Salat perfekt und man wartet warscheinlich eine Woche bis das fertig ist. Und eine Garantie, dass das dann alles funktioniert hat, die gibt es auch nicht. Entweder man macht es gleich richtig oder man muss eben mit den Problemen zurechtkommen. Aber dass die Probleme zu groß sind sieht man ja daran schon, dass beide erst mal hinschmeißen wollen/wollten. So löst man die Probleme nicht wirklich.

  • Maik..
    die Bemerkung mit der XML war schonmal gut.
    Ich probier mal was aus.
    Der/die Assetordner die das verursachen, müssen ja zu lokalisieren sein. Hilft evtl dann EWD auch
    Ich will schließlich auch nicht auf meine Arbeit verzichten!


    Schotti

    Grüße
    Schotti *hi*

    Win 10 Pro, Intel I7-8700, 32 GB RAM DDR4-2400, 1 TB SSD Boot, Seagate ST 2000 Daten.
    nVidia GTX 1080 8 GB, AOC 28`` 4K Monitor
    TS auf separater SSD 512 GB nur mit deutschen Strecken

  • Der Nachteil wäre dann, dass viele Objekte doppelt, dreifach, ja vielleicht 20-fach auf der Platte liegen.
    Und wenn dann ein Update eines Objekts käme (aktuellstes Beispiel: die BayWa von ice oder Sachen von pawerybs), dann müssten diese für jede Strecke aktualisiert werden.
    Das sollte und kann nur Aufgabe des Streckenbauers sein. Aber existiert der noch oder spielt der inzwischen Tetris*?
    Das macht es zwar hoffentlich stabiler, aber nicht einfacher.



    Vielleicht sollte man damit anfangen, Freewarebauer zu separieren:
    Wer erlaubt die Unterbringung seiner Sachen in anderen Ordnern und wer nicht?



    * Ihr kennt diese Metapher sicher schon: Tetris steht hier stellvertretend für alles Mögliche, sogar für ein Schaumbad, einen Waldspaziergang oder einen Aufenthalt in der geschlossenen Anstalt. Und ja, sogar für Tetris!

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Tja, wie du siehst ist der Streckenbau eben nicht ganz ohne Folgen. Ist alles zu einer Strecke in einem Ordner ist aber wenigstens eine gewissen Konsistenz vorhanden. Was passiert wenn ein Update in die Hose geht weil es kaputtgedatet wird. Dann weis man oft wieder nicht wo man anfangen soll zu suchen. Wenn der Streckenbauer für ein Update verantwortlich ist, kann er vor Auslieferung dies überprüfen, und wenn dann was nicht stimmt hat nicht der User den Nachteil. Nicht nur der Wildwuchs der Assets ist auch Problem, auch das wilde updaten von hier und da. Verteilte Asseststukturen sind toll, solang sich alle Beteiligten an Regeln halten. Wenn aber Strecke A die Assets der Strecke B überschreibt, eventuell sogar downgraded, dann ist schon das Ende der Konsistenz erreicht. Das kann nicht gut gehen auf Dauer. Die Probleme werden mit der Zeit immer größer werden. Es gibt eben keine Zentrale Verwaltung der Assets wie in Trainz. Es kann im Prinzip gemacht werden was will und das bekommt eben keiner Strecke gut. Eigentlich sollte es so lauten: Strecke = fertig = nicht anfassen. Aber hier fässt jeder User schon bei der Installation an weil jeder anders installiert. Dann vergessen ein Paar noch was und schon haste den Salat. Wohl bekomms dem der den Support leisten muss.

  • Der Nachteil wäre dann, dass viele Objekte doppelt, dreifach, ja vielleicht 20-fach auf der Platte liegen.
    Und wenn dann ein Update eines Objekts käme (aktuellstes Beispiel: die BayWa von ice oder Sachen von pawerybs), dann müssten diese für jede Strecke aktualisiert werden.

    Ein Update hättest Du einfach in dem Du das von mir beschriebene Programm nochmal durchlaufen lässt. Ein Update das nicht vom Streckenbauer freigegeben ist kann aber auch in die Hose gehen (beschreibt ja auch Maik in seinem letzten Post). Den Nachteil, dass Assets mehrfach auf der Platte liegen würde ich für Stabilität biligend in Kauf nehmen. Wenn jede Payware Strecke Ihren eigenen Ordner hat sind da auch Sachen mehrfach vorhanden oder habe ich das falsch verstanden?
    Die Diskussion über das von mir ersonnene Programm nützt aber nichts. Wenn Maik behauptet das geht nicht, dann glaube ich Ihm das schon. Wem sonst? :)

  • Wenn Maik behauptet das geht nicht, dann glaube ich Ihm das schon. Wem sonst?

    Bitte nicht meine Aussagen hier als Weisheiten hinstellen. Da springen dann gleich wieder bestimmte Leute drauf an. Ich habe nicht vor meine Empfehlungen als Gebote zu verstehen zu geben. Jeder darf machen was er selbst fürt richtig erachtet. Ich gebe lediglich Tipps und da ich von mir selber weis, dass ich nur über etwas rede wenn ich davon auch was verstehe, gehe ich davon aus dass ich hier nichts falsches erzähle. Dinge von denen ich nichts versteh über die rede ich nicht. Zum Beispiel das bauen von Modellen. Davon versteh ich nichts und deswegen häng ich mich da nicht rein. Also Vorsicht mit den Worten sonst kippt die Goldwaage um.

  • Was passiert wenn ein Update in die Hose geht weil es kaputtgedatet wird. Dann weis man oft wieder nicht wo man anfangen soll zu suchen. Wenn der Streckenbauer für ein Update verantwortlich ist, kann er vor Auslieferung dies überprüfen, und wenn dann was nicht stimmt hat nicht der User den Nachteil.

    Das ist ein guter Punkt. So wären theoretisch sogar mehrere Versionen eines Assets möglich, wenn z.B. Strecke A -warum auch immer- mit dem Update von Asset X Probleme hätte und daher zwingend das alte Asset X benötigt, Strecke B aber das aktuelle Asset X benutzen kann und soll.


    Den Nachteil, dass Assets mehrfach auf der Platte liegen würde ich für Stabilität biligend in Kauf nehmen.

    Auf jeden Fall. Heutige Festplattenpreise lassen sowas vernachlässigbar erscheinen. Ein Problem hätten allerdings DIE Leute, die eine SSD haben. Da wäre schnell Ende im Gelände.
    Meine Asset-Ordner hat augenblicklich eine Größe von 70,7 GB.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Bitte nicht meine Aussagen hier als Weisheiten hinstellen.

    dann glaube ich Ihm das schon

    Da steht doch "ich" drin. Wenn ich will, darf ich das glauben. Andere müssen das nicht.
    Ich wollte damit nur zum Ausdruck bringen, dass ich weiß, dass du von der besprochenen Materie wesentlich mehr Ahnung hast als ich, weshalb es für mich keinen Grund gibt an Deiner Aussage zu zweifeln. :)