Beiträge von Bamp

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    Fakt ist,

    und

    (1) Sammlungen von Werken, Daten oder anderen unabhängigen Elementen, die aufgrund der Auswahl oder Anordnung der Elemente eine persönliche geistige Schöpfung sind (Sammelwerke), werden, unbeschadet eines an den einzelnen Elementen gegebenenfalls bestehenden Urheberrechts oder verwandten Schutzrechts, wie selbständige Werke geschützt.
    (2) Datenbankwerk im Sinne dieses Gesetzes ist ein Sammelwerk, dessen Elemente systematisch oder methodisch angeordnet und einzeln mit Hilfe elektronischer Mittel oder auf andere Weise zugänglich sind. Ein zur Schaffung des Datenbankwerkes oder zur Ermöglichung des Zugangs zu dessen Elementen verwendetes Computerprogramm (§ 69a) ist nicht Bestandteil des Datenbankwerkes.

    finden auf unserer Plattform, da wir im "deutschen Internet" ansässig sind, Anwendung. Man könne die Kacheldateien durchaus als Datenbank interpretieren (s. §4, Abs. 2 UrhG; oben) und fallen daher auch unter urheberrechtlichen Schutz. Weiteres müsste wohl ein Gericht entscheiden - wobei ich kaum glaube, dass sich irgendein Gericht ansatzweise um eine unbedeutende (dennoch rechtswidrige, wenn vorhanden) Urheberrechtsverletzung kümmern würde.


    Wie kann es dann sein, dass auf buchstäblich jeder Karte (außer Thüringer Wald) Spandau-Standardobjekte verbaut sind und sämtliche Spandau-Modern-Superneu-2020-aktuell-nichtmehr80erJahre-Karten die originalen Kacheln beinhalten?

    Entweder wurde sich eine Erlaubnis seitens des Publishers (hier Aerosoft, nicht Marcel oder Rüdiger) eingeholt, oder die Karte wäre in dem Fall rein theoretisch illegal.

    Das reine Verbauen von den Objekten stellt ja keine Urheberrechtsverletzung dar, da sie selbst platziert wurden. Es ist was anderes, wenn man dieses Werk von anderen Autoren ohne Erlaubnis verwendet oder sich diese "Datenbank" (s.o.) selbst erstellt / generiert.

    Was du hier geschildert hast, ist cracken

    Ja, das ist illegal. Aber es ist nur genau das bei verschiedene Dateien eines DLCs wiederholt, was du hier scheinbar meinst, was erlaubt wäre:

    Was bringt einem die Schöpfungshöhe ohne Objekte?


    Das ist cracken. Und das ist illegal. Genau das wollte ich ja mit meinem vorhergehenden Post verbindlichen bzw. erklären. Ich glaube, da sind wir uns einig ^^

    Es geht halt ums Prinzip des Urheberrechts.


    Mal angenommen, auf Plattform a werden nur die Kacheln hochgeladen. Auf Plattform b werden nur die sco-Dateien hochgeladen. Dann werden auf Plattform c nur die o3d-Dateien hochgeladen. (ggf. weitere Schritte, Prinzip wird aber denke ich klar). Dann hast du aus diesen 3 Quellen die gesamte Karte heruntergeladen.

    Klar, wahrscheinlich ist es nicht, aber eben genau sowas soll prinzipiell verhindert werden. Sowieso stünde es gar nicht infrage, da es so oder so gegen das Urheberrecht verstöße.

    Bloß was ist so problematisch an den Kacheln, wenn man mit denen alleine nichts anstellen kann?

    Außerdem beinhalten auch die Kacheldateien eine gewisse Schöpfungshöhe: Nicht nur die Objekte an sich, sondern auch die Platzierung der Objekte (und Splines) besitzen eine ausreichende Schöpfungshöhe.

    Damit ist es nicht so problematisch Sachen von der Karte mitzuliefern.

    Das stimmt so nicht. Es handelt sich um einen gekauften Inhalt, der so nicht weiterverbreitet werden darf. Genau so verhält es sich mit DLCs. Generell gilt bei nur käuflich erwerbbaren Inhalten, dass diese nicht weiterverbreitet werden dürfen.

    Nein, idR hängt das mit der Festlplattenleistung an sich zusammen. Was du versuchen kannst, ist deine Festplatte mal zu defragmentieren / optimieren, das findest du in der Windows-Suche als "Laufwerke defragmentieren und optimieren". Das könnte u.U. die Schreibprozesse beschleunigen.

    In der Logfile steht verschiedenes - Zunächst zähle bitte einmal die Zähler bei den Scripts, Constfiles und (string)varlists durch, denn dort scheint ein Zähler zu hoch zu sein:

    Code
    Error while loading file vehicles\C2_IVU\\

    ... ist schlichtweg das Resultat, wenn OMSI versucht eine leere Zeile auszulesen (was im Falle eines zu hohen Zählers meist passiert).


    Scheinbar fehlt eine gesamte Constfile, wie ich das deuten kann (von der IVU). Problem ist da, dass dir hinter den Dateipfad in der Auflistung der Constfiles in der bus-Datei ein "s" gerutscht ist:


    Ist das gefixt, sollten die ganzen <SC_ErrorInCommand_constantinvalid>-Errors auch weg sein.


    Außerdem hast du beim Einbau der IVU vergessen, aus dem Main-Script (C2_main_CoD.osc) die "Funktionen (Makros) des ehem. IBIS und des Ticketdruckers zu entfernen. Oben in der main-Datei findet sich idR ein Abschnitt "{init}" und ein Abschnitt "{frame}". Befehle in init werden beim Spawnen des Busses ein einziges Mal ausgeführt (hier gehören z.B. auch Daueranimationen rein), frame wird in jedem Frame ausgeführt, also die ganze Zeit über.

    Meist sind die Makronamen (werden mit (M.L.name) aufgerufen und führen eine Funktion aus wie z.B. die Steuerung der Türanimationen in einer anderen Scriptdatei) gut aufgeschlüsselt.

    Dir fehlen lt. Logfile folgende Makros, welche in deinem Fall aber gar nicht mehr aufgerufen werden sollen:

    Code
    (M.L.ticketprinter_frame)
    (M.L.IBIS_frame)
    (M.L.ticketprinter_init)
    (M.L.IBIS_init)

    Nun suchst du entweder im init- oder frame-Abschnitt (siehe Namensendung des jeweiligen Makroaufrufs) nach der jeweiligen Textzeile und entfernst sie.


    Damit sollte Scriptseitig alles behoben sein. Natürlich kann es dennoch vorkommen, dass einige Scriptfehler hier nicht angezeigt wurden und erst danach auftreten, dann muss man eine ähnliche Prozedur nochmal wiederholen.


    Bezüglich der model.cfg, dort scheint folgendes Mesh zu fehlen:

    vehicles\C2_IVU\model\12m\Matrix_K++_new.o3d


    Gleiches Problem hatte ich auch, ich habe dazu einfach den Suffix "_new" in der model.cfg entfernt, da diese Datei vorhanden ist (dennoch nochmal nachprüfen, es könnte auch sein, dass der Pfad anders ist - ggf. anpassen).


    Zu guter Letzt fehlt dir noch ein Animations-Parent für den Zahltisch in Zeile 4453. Dort sollte folgendes stehen:

    ändere dort "zahltisch" mal zu "fahrertuer". Das ist jetzt spezifisch für den MXC2, soweit ich das durchblickt habe. Damit wird dem vorhergehendem Mesh - in dem Falle - die Animation der Fahrertür zugewiesen, damit sich dieses beim Öffnen der Fahrertür auch mitdreht. Je nachdem, wo die IVU (ich nehme mal an, dass es sich um ein Objekt von dieser handelt) befindet, kannst du das Schlüsselwort (inkl. den eckigen Klammern) ganz rausnehmen. Weil wenn sie auf der Fläche vor der Fahrertür befestigt ist, soll sie sich beim Öffnen der Tür ja nicht mitdrehen. lol


    Wenn das ganze behoben ist, starte OMSI mal neu, bzw. du kannst auch das aktuelle Spiel speichern, ein neues Spiel laden und dort einfach die selbe Karte mit dem letzten Stand laden. Das geht meistens etwas schneller. :-)


    Dann schaue mal, ob alles funktioniert und ob in der Logfile noch was steht.


    Hast du zwischenzeitlich eigentlich noch den Ticketdrucker eingebaut? Weil ich merke gerade, dass es ja eigentlich um die Matrix geht, aber scheinbar kommen alle Fehler von der IVU. :"D:D


    ----------

    Ich wollte die letzten Wochen sowieso mal ein allgemeines Tutorial zur den Ein- bzw. Umbau von Ticketdruckern, Matrixen etc. schreiben, bin aber noch nicht zu gekommen. Vielleicht setze ich mich da die Woche mal dran.


    some1 Das mag eine berechtigte Aussage sein, wenn man sich zum 3. oder 4. mal eine Matrix einbaut. Tut man das allerdings zum 1. oder 2. Mal und hat noch nicht so viele Erfahrungen mit dem Aufbau von model.cfg oder Skripten, kann einem das durchaus schwer sein. Und solche Hilfe sind vor allem bei OMSI wichtig, da es bekanntlich ja leider keine Dokumentationen bzw. Tutorials über Skripte etc. gibt. Wie auch bei Programmiersprachen gilt hier "Learning by doing". Außerdem können Laien mit Fehlermeldungen wie Fehler: im Befehl "(C.L.Overhead_Meldung_1)"(vehicles\C2_IVU\\script\IVU_Ticketbox.osc) <SC_ErrorInCommand_constantinvalid> nicht viel anfangen.


    Held_Reisen_Fan Fall noch Fehler aufkommen sollten, melde dich nochmal und hänge gleich die Logfile an. Zumindest sollte der Bus nach den Fehlerbehebungen oben wieder angezeigt werden.

    Problem ist leider immer noch, dass die WebDisk derzeit auf WSC 5.2.x läuft - benötigt wird mind. WSC 5.5.x. Theoretisch ist das Update möglich, allerdings benötigt das auch so einige zeitliche Ressourcen, die momentan nicht vorhanden sind.

    Moin, ich melde mich mal zu Wort.

    Zu aller erst sei gesagt, dass wir diese Umfrage erstellt haben, da wir uns in dieser Kurzfristigkeit selbst unsicher waren, wie wie verfahren sollten. Diese ganze Thematik sorgte sowohl im Team als auch bei den Benutzern und zwischen den beiden Akteuren für ziemliche Spannungen.


    Meine Meinung zu diesem Thema ist etwas zwischen den "Fronten", tendiert allerdings dazu, dass ähnliche Dateien zusammengeführt werden sollten. Als - ich beurteile das jetzt mal so - technisch versierter überwiegen schlicht und einfach die Argumente für die Zusammenführung von Dateien, ganz vorne die Übersichtlichkeit der Filebase und der Fakt, dass sich z.B. Repaints auch im Pack über die Google-Suche finden lassen. Außerdem wäre damit die automatische Zuteilung des OMSI-Modders legitimier. Angenommen, ein im Forum aktiver Benutzer (1000P. erreicht) veröffentlicht Wagen AB-CD 1 bis AB-CD 20 des Unternehmens Mustermann Verkehr GmbH als einzelne Dateien, so erhält er gemäß der Grenzen des OMSI-Modders diesen Rang. Wenn hingegen ein anderer Benutzer, der im Support unheimlich aktiv ist und 3 seiner Karten veröffentlicht, erhält dieser den Modder-Rang nicht, da die 20 Dateien nicht erreicht wurden. Klar, in solchen Fällen nehmen wir idR eine manuelle Zuteilung vor, aber ich bin bei diesem Punkt eher aufs Prinzip aus - aus irgendeinem Grund gibt es diese automatische Zuteilung ja.

    Ein Argument, was meine Meinung diesbzgl. entkräftet, wären diverse Diskussionen bei beanstandeten Dateien...

    Dann frag ich mich, wie eindeutig ein Ergebnis noch ausfallen muss, wenn man schon dankenswerterweise eine Umfrage macht...

    ... denn solch eine Regel bietet viel Interpretationsspielraum. Die letzte Form, die von dieser Regel existierte, machte nicht klar, welche Dateien oder Dateitypen von dieser Regel betroffen sind. Es wäre also eine sehr genaue Regelung erforderlich, um das Vorgehen für die Benutzer transparent zu gestalten und "störende" Diskussionen (nicht negativ gemeint, es raubt schlichtweg nur Zeit) zu vermeiden.

    Daher bin ich mir selbst etwas unsicher, welche Lösung ich nun wirklich lieber gehabt hätte. Müsste ich mich entscheiden, landete ich allerdings wohl doch bei einer Regel für die Zusammenführung der Dateien.


    Um womöglich etwas den Hintergrund zu klären: Ich kann sagen, dass diese Umfrage aus zuletzt starken Diskussionen zwischen einigen Benutzern und dem Team hinausging. Dort war die Stimmung zeitweise zwar sehr mies, dennoch fand ich es gut, dass sich die Benutzer eben für ihre Meinung eingesetzt haben. Genau das wollen wir ja auch mit den Umfragen erreichen, dass die Benutzer auf unserer Plattform mitbestimmen können - genau wie in der Urversion der WebDisk handelt es sich immer noch um eine Plattform "von Spielern für Spieler". Aus diesem Grund kann ich auch das Empören darüber nachvollziehen, dass die Dreiviertelmehrheit dieser Umfrage keine Beachtung erhalten hat. Dennoch viel die mehrheitliche Entscheidung im Team bis jetzt, dass die Regelung entfernt wird. Außerdem sind die Umfragen nie bindend.


    Dennoch vertrete ich diese Entscheidung nun nach außen hinaus, auch wenn ich dazu meine eigene Meinung habe - nicht jeder ist immer der gleichen Meinung und es ist wichtig, ein bisschen Meinungsaustausch zu betreiben.


    Dazu sei noch gesagt, dass wir uns mit dieser Umfrage lediglich eine Meinung der Benutzer eingeholt haben. Nirgends stand, dass wir rein basierend auf den Umfragewerten die Regel (nicht) einführen.

    Das Problem ist leider, dass die neuste Version nicht mehr mit unser Forensoftware-Version (5.2.x, mind. 6.x benötigt) kompatibel ist. An einem Update der Forensoftware arbeiten wir allerdings gerade. Ein genaues Datum gibt's dazu allerdings noch nicht.

    Moin!


    Ich habe mir in den vergangenen Tagen ein ordentliches AO-Bake für den Citaro Ü erstellt, und bin dabei auf folgendes Problem gestoßen:

    Wenn (meshseitig, per setvar) kein Kennzeichenmesh vorhanden ist, wird nur der Halter angezeigt:


    Das ist per Textur durchsichtig (wie bei Kennzeichenhaltern üblich). Wenn ich allerdings ein Bake durchführe, entsteht das:


    Beim Bake wird also nicht die Transparenz des Kennzeichenhalter-Materials berücksichtigt.

    Wie genau kann man hier bewirken, dass die Texturtransparenz auch als "echte" Transparenz von Blender erkannt und für den Bake berücksichtigt wird?


    Das sind die Materialeinstellung, die ich für relevant halte. U.a. Z-Transparenz ist bereits aktiviert.


    Oder lässt sich das ganze über eine bestimmte Map lösen, die sich per Nodes einstellen lässt?


    Ach ja, ich benutze (noch) Blender 2.79. Wenn ich dafür nun unbedingt auf eine höhere Version wechseln muss, mach ich das. ^^


    Danke für alle Vorschläge! :-)


    Viele Grüße

    Dennis123 Beitrag hierher verschoben.

    Bitte erstelle dein Thema / Beitrag das nächste mal in der richtigen Kategorie bzw. in einem Sammelthread wie diesen hier. Beim Erstellen deines ehem. Themas in der Kategorie "Fragen zur WebDisk" hast du sogar die Bestätigung bestätigt, bitte schenke ihr das nächste Mal doch etwas Acht.