Alle Aktivitäten

Zuwachs im Fuhrpark

Hallo @SualokinK, Erstmal wieder Tolle Arbeit.🤩🫡😮 Ich hoffe Du nimmst mir das nicht krumm. Hab mich ein wenig mit deinem Modell beschäftigt und hab für mich Variationen erstellt. an beachte die Felgen bei dem silbernen und gelben Fahrzeug. Gruß Christian

Das ist wirklich "tricky" mit den DKW Laternen. Brummis neue DKW Laternen zeigen auf der Rückseite das Spiegelbild von der Vorderseite. Als ich sie gerade alleine untersucht habe, schien mir das auch vollkommen richtig. Ist es aber nicht! Denn wenn man eine DKW vom anderen Ende aus betrachtet, sieht man sie nicht (immer) spiegelbildlich! Die beiden geraden Wege sind nicht gespiegelt. von links nach rechts ist auch von der anderen Seite von links nach rechts Die abbiegenden Wege sind aber spiegelverkehrt. Aus von links nach links wird von rechts nach rechts Ich habe für die Vergleichsbilder nur die Kamera gedreht. Die Lok steht immer am selben Platz! Sorry, @Roter Brummer - die Laternen musst du beide umbauen. Das Bild auf der Rückseite darfst du nicht spiegeln. Du musst es auf den Kopf stellen (180° um die Z-Achse drehen). Viele Grüße Götz

Das Ziel ist ja, solche Variablenlisten zu vermeiden. Sinnvoller erscheint mir da eher die Erweiterung der EV, um alle Animations-/Schalternamen zu enumerieren. Auch der Zugriff auf die Content-ID eines Modells erscheint sinnvoll, um "klassenbasiert" arbeiten zu können.

Wow @SualokinK, einfach nur Spitze deine Arbeit

Hallo Zusammen, die Mercedes-Benz W212 Modelle sind jetzt im Katalog. @Neo vielen Dank dafür. Und weil ich einmal dran war, gibt es den W212 als Einsatzfahrzeug, auch als Combi. Die Modelle sind zur Freigabe in den Katalog geladen. Schöne Grüße SualokinK ach ja, vergesse ich immer wieder: vielen Dank für die Klicks .

no, you're correct. The rear face shows the wrong image!

Hello @Roter Brummer Hello, I saw your two DKW versions now released in the catalog (new). And your layout in this topic. From the front view they work flawless. When I turn the layout upside down, al the DKWs stay on their place, so the train machinist comes from the other side and he sees the "straight on" different compared to the DKW position. Or am I wrong? To illustrate what I ment , a comparision with DKWs from Seehund. Hallo, ich habe deine beiden DKW-Versionen gesehen, die jetzt im Katalog erschienen sind (neu). Und dein Layout in diesem Thema. Von vorne betrachtet funktionieren sie tadellos. Wenn ich die Anlage auf den Kopf stelle, bleiben alle DKWs auf ihrem Platz, so dass der Lokführer von der anderen Seite kommt und er die „geradeaus“ anders sieht als die DKW-Position. Oder liege ich da falsch? Zur Veranschaulichung ein Vergleich mit DKWs von Seehund. Übersetzt mit DeepL.com (kostenlose Version) Kind regards, Herman

Dafür nutze ich die grafische EV. Dort gebe ich ein konkretes Modell an, wähle aus der Liste den richtigen Achsennamen und wechsle dann beim Objekt zu etwas generischem wie "Auslöser" oder "Wiederholung". Und wandle zum Schluss diese Zeile (bei Bedarf) in Lua. Sind ein paar Klicks, aber zur Fehlervermeidung gönne ich mir die.

Hallo @Neo, Im Moment nicht, so eine Zuordnung wird erst dann wichtig, wenn wir uns für einen Standard entschieden haben und die Bestandsmodelle anpassen möchten. Es wäre unabhängig von @gmds Programmierung schon immer schön gewesen, wenn man sich für jedes Modell die Animationsnamen (bzw. in V9 auch die Schalternamen) als Text greifen könnte. Bisher muss man den Text nämlich fehlerträchtig abtippen um seine eigene standardisierte Variable zu füllen. Ich wäre froh, hätte ich ein txt in dem ich für jedes Modell dessen Animations- und Schalternamen finden könnte. Noch eleganter wäre, ich könnte aus den Animationsnamen des Modells im Variablenfenster mit der rechten Maustaste einen auswählen und so eine (vorher von mir angelegte) Textvariable füllen. Ich habe mal die ganze Liste fotografiert damit Du siehst, was ich so alles an standardisierten Variablen in meinen Fahrzeugen habe. Vielleicht nimmst Du das als Feature-Wunsch auf. Beste Grüße Phrontistes

Hallo Walter, wenn Du bei einem 3D-Modell nur die Textur austauschen möchtest, ... ... genügt es, in der x-Datei in der Material-Definition einfach die Texturdatei auszutauschen, und dann die x-Datei (oder die zusammengehörigen x-Dateien bei mehreren LoD-Stufen) unter einem neuen Dateinamen abzuspeichern, Dann hast Du die Garantie, dass sich an der Anzahl der Polygone nichts geändert hat. Eine entsprechend modifizierte Sketchup-Quelldatei wird hierfür nicht benötigt. Noch bequemer ist es, bei Unterscheidungen nur in der Textur mit der varlist-Datei zu arbeiten. Dann belässt Du es bei der Originalen x-Datei mit der ursprünglich verwendeten Textur, generierst mehrere Einträge mit unterschiedlichen Titeln (die dann im Modellbahn-Studio in der Variationen-Liste erscheinen), und weist dem ursprünglichen Textur-Dateinamen mittels Gleichheitszeichen jene Texturdatei zu, welche Du bei der einzelnen Variante stattdessen einsetzen möchtest. Bei mir heißt die im Modell verwendete Textur meistens "_Custom.<Endung>", damit man auf der Anlage Tauschtexturen zuweisen kann. Die "Umlenkung" der Texturdatei funktioniert (zumindest nach dem Wiki) auch mit einer "Nicht-Custom-Textur", die in der x-Datei als Referenz hinterlegt ist. Im obigen Bild sind derselben x-Datei (blau umrahmt) verschiedene Texturdateien zugewiesen (rot umrahmt), die dann im Modellbahn-Studio bei der Wiedergabe der zugehörigen Variation angezeigt werden. Wenn Du eine Fläche beidseitig texurierst, verdoppelt sich die Polygonzahl gegenüber der einseitigen Texturierung. Es bleibt jedoch eine Fläche mit Vorder- und Rückseite), die auch bei beidseitiger Texturierung in der Statistik des Exporter-Protokolls nur einfach gezählt wird. Wenn Du in den Einstellungen des Setchup-DirectX-Exporters versehentlich die Einstellung Flächenauswahl von [nur gefärbte] auf [alle] umgestellt hast, werden vom Exporter auch die ungefärbten Flächen erzeugt und als weiße Flächen an das Modellbahn-Studio übergeben. Entsprechend erhöht sich die Polygonzahl, während die Anzahl der bearbeiteten Flächen sich - wenn überhaupt - nur unwesentlich erhöht (wenn Flächen ganz ohne Einfärbung vorgefunden werden). Die obigen Einstellungen werden übrigens bei jedem Ausgabeprotokoll am Anfang aufgelistet. Wenn Du also die Protokolle erzeugt und noch nicht gelöscht hast (es sind dies die mit den x-Dateien zusammen erzeugten txt-Dateien mit gleichem Namensstamm), kannst Du dort nochmals die Einstellungen zum Zeitpunkt des Exports überprüfen. Falls Du immer nur die gefärbten Flächen erzeugt haben solltest, fällt mit nur noch folgende Idee ein: Du hast doch in deinen Sketchup-Modellen viele _AP-Objekte zusätzlich eingefügt, um zu verhindern, dass sich Bauteile beim Umschalten auf eine höhere LoD-Stufe verschieben. Wenn Du das _AP-Objekt in eine Fläche malst und dann gruppierst, wird es möglicherweise aus der umgebenden Fläche "ausgestanzt". Dieses Loch solltest Du dann unbedingt wieder schließen und dessen Begrenzungslinien entfernen. Denn durch das ausgestanzte Loch wird es notwendig, die Fläche in zusätzliche Dreiecke (Polygone) aufzusplitten. Im obigen Beispiel ist die Fläche ein Quadrat, welches aus 2 Polygonen zusammengesetzt ist (links). Zeichnet man nun in die Fläche eine Raute (Mitte) oder ein Quadrat (rechts) und gruppiert dieses als _AP-Objekt, kann die umgebende Fläche - falls dadurch gelocht - nicht mehr mittels 2 Polygonen erzeugt werden (im obigen Bild sind es nun jeweils 8 Polygone). Wenn an nun das Loch wieder auffüllt und die Begrenzungslinien entfernt, ist die Fläche wieder "komplett" und kann daher wieder mit der ursprünglichen Polygonzahl dargestellt werden. Damit hättest Du aber das Sketchup-Modell verändert, was nach Deiner obigen Aussage nicht geschehen ist. Ich tippe daher tatsächlich auf die geänderte Einstellung für die Flächenauswahl. Andere Ursachen für das von Dir festgestellte Verhalten kann ich mir nicht vorstellen. Viele Grüße BahnLand

Ok Super ihr beiden dann bin ich ja beruhigt das das alles dann so geschmeidig ineinander rein flutscht

Das ist mir nicht genug, sorry. Ich verwende liebe komplette daten auch wenn sie nicht standardisiert sind, und werde daraus einen standard fuer mich ableiten. Ich bin ja auch nicht auf einfach oder mehrfachschalter angewiesen und es ist fuer mich auch nicht wichtig ob ein modell alle funktionen hat, ich muss einfach nur wissen ob eine funktion vorhanden ist und wie sie heist. Wenn daraus etwas allgemein verwendbares entsteht, oder zumindest anregungen gibt, dann ok, aber ich warte nicht bis eine solche diskussion abgeschlossen ist. Es kostet mich nicht mehr als ein paar stunden die liste zu erstellen die ich brauche als sample. Muessen ja nicht alle sein, und wenn das zu einem brauchbaren ergenis fuehrt koenen wir weiter diskutieren. Wenn ich die fahrzeug zuordnung habe kann ich die animationen typisieren und wenn ich sie typisiert habe kann ich einen moeglichen standard ableiten. Das ist meine normal vorgehensweise. gruss Gmd

Eine explizite Meldung bekommst du nicht, das Studio lädt immer automatisch die aktuellste Version aus dem Online-Katalog. Du kannst den Online-Katalog aber nach dem Änderungsdatum absteigend sortieren, dann bekommst du eine Liste der Modelle, die zuletzt angepasst worden.

Das hast du misverstanden, ich meine nur ob eine animation richtungsabhaengig ist, pantograf, tueren, stirnlicht usw. aber nicht rauch, abgase, kabinenlicht etc .. bei der typisierung geht is um eigenschaftstypen. Gruss Gmd

Ich habe die Liste ersetzt, nun enthält sie auch die Zustandsnamen der erweiterten Schalter. Im Moment nicht, so eine Zuordnung wird erst dann wichtig, wenn wir uns für einen Standard entschieden haben und die Bestandsmodelle anpassen möchten. Lass uns zunächst bei einem Thema bleiben und einen Standard evaluieren. Ein erweiterter/mehrwertiger Schalter sollte nur für exklusive Zustände genutzt werden, nicht für alle möglichen Kombinationen, die auch einzeln ansteuerbar sind. Türen würde ich daher auch in Zukunft über einen linken und rechten Schalter getrennt ansteuern. Ein mehrwertiger Schalter bietet sich bei der Beleuchtung an, wo z.B. ein Abblendlicht und ein Fernlicht sich gegenseitig ausschließen. Das Einführen von Standardschaltern wird nur ein erster Schritt sein und nicht alle Probleme lösen. Es wird langfristig auch eine Erweiterung des Automatikmodus geben, um z.B. Blinker oder Türen automatisch zu steuern (damit der Nutzer für Standardaktionen nicht immer wieder die gleiche EV schreiben muss). Meine Empfehlung ist daher, mit den Vorlagen von Standardschaltern zu beginnen und die Bestandsmodelle auf das einheitliche System umzustellen. Damit werden schon viele Bereiche vereinfacht werden (mit dem Zusatz, dass die Standardschalter später maschinell bearbeitet werden können, falls sich Standards ändern). Viele Grüße, Neo

Deshalb legt Neo ja Wert darauf, dass die Erbauer "alte" Modelle direkt bearbeiten (nicht überschreiben) und damit die Animationsnamen beibehalten. Ja, Du bekommst beim nächsten Laden der Anlage automatisch das aktualisierte Modell und alles läuft wie bisher - nur hast Du ggf. noch neue, weitere Möglichkeiten.

Eigentlich nicht. Solange die Modellbauer die Begriffe "rechts" bzw. "links" als in Fahrtrichtung rechts/links definiert haben (was soweit ersichtlich durchweg der Fall ist) ist es einfach per EV die "richtigen" Türen anzusprechen weil man die Fahrtrichtung des Verbandes kennt und weil man die Orientierung jedes einzelnen Fahrzeuges feststellen kann (und weil man weiß, ob der Bahnsteig links oder rechts ist). Für die mehrwertigen Schalter musst Du beachten, dass zwei Informationen gebraucht werden: Schaltername (text) und Schalterstellung (number). Für Türen in einem mehrwertigen Schalter eines (noch nicht veröffentlichten) V9-Fahrzeuges (Name: "Türen"; 0 = Alle Türen zu, 1 = Türen rechts, 2 = Türen links, 3 = Alle Türen auf) mache ich das so nachdem ich in die Fahrzeugvariable (Liste mit zwei Einträgen) "9 Doors R open" "Türen" und "2" hineingeschrieben habe. if Vehicle.variables["9 Doors R open"] ~= nil then Vehicle.actions[Vehicle.variables["9 Doors R open"]["1"]].state = Vehicle.variables["9 Doors R open"]["2"] Vehicle.actions[Vehicle.variables["9 Doors R open"]["1"]].autoMode = "" Die mehrwertigen Schalter müssen anders behandelt werden als bisher. Der Code geht für die bisherigen Animationen wie folgt weiter: else if Vehicle.variables["Doors at right side"] ~= nil then if Vehicle.variables["Door speed"] ~= nil then Vehicle.animations[Vehicle.variables["Doors at right side"]]:play(-1, 1, -1, -1, Vehicle.variables["Door speed"]) else Vehicle.animations[Vehicle.variables["Doors at right side"]]:play(-1, 1) end end Die Animationsgeschwindigkeit kann man übrigens mit den neuen V9-Schaltern (noch) nicht verändern, das will @Neo aber noch implementieren. Das musst Du manchem Modellbauer aber noch deutlicher rüberbringen, sonst setzen diese die alte Logik fort und bauen Schalterbänke wie hier. Beste Grüße Phrontistes

Ja das geht natürlich gar ned wenn man alles neu machen muss ( allein die vielen Menschen die ich bei Menschen in Zügen in die Züge alle gesetzt hab , die ganzen EVs auf den Anlagen ). Sag mal Neo bekommt man vom Programm eigentlich ein Hinweis das ein upgrade von einem Modell auf den Anlagen vorliegt oder wird das einfach dann automatisch überschrieben ?

Neo, zunaechst einmal danke, ABER .. lol die liste ist ja keine zuordnung von schalter zu modellen und das ist ja das entscheidende. Ich bin dabei eine datenstruktur aufzubauen und animationen zu typisieren und mit eigenchaften zu versehen, die dann als steuerungsparameter verwendet werden koennen. Bin gerne bereit hier input zu erhalten. Animationen koennen eigenschaften haben, was noch fehlt sind richtungsbedingungen, ich betrachte zunaechst einmal nur fahrzeuge. Typen dienen zur schnelleren definition von eigenschaften und steuerfunktionen. Mal sehen was daraus wird, werde regelmaessig berichten und du kannst ja deinen input dazu geben, happy to oblige. Nun was machen wir mit dem problem der fahrzeugzuordnung, wieder zurueck zum AI ? klingt schlimmer als es ist und die fehlerquote ist gering. Gruss Gmd

Hallo @Neo, Das ist schon eine tolle Hilfe. Wie ich der Liste entnehme, sind die erweiterten Schalter noch nicht enthalten. Wenn Du das noch ergänzend könntest. Ein Vorschlag für Erweiterten Schalter "Beleuchtung hinten" bei E-Lok Modell BR 285: Beleuchtung hinten|0 - aus|1 - Führerkabine|2 - Führerstand|3 - Führerkabine und Führerstand Wobei das Pipe-Zeichen (|) als Trennzeichen dient und nicht in den Schalternamen vorkommen sollte. Für alle Steuerungen wird wohl keine Normierung notwendig sein (z.B. Segel reffen vorn). Aber für bestimmte, oft in der EV benötigte Steuerungen sollten Standard-Steuerungsnamen festgelegt werden. Ein erster Vorschlag wäre: Bahnfahrzeuge: Tueren|0 - links|1 - rechts Fahrlicht|0 - vorn|1 - hinten Fernlicht|0 - vorn|1 - hinten Schlusslicht|0 - vorn|1 - hinten Innenbeleuchtung Pantograf|0 - vorn|1 - hinten Straßenfahrzeuge: Blinker|0 - links|1 - rechts Bremslicht Fahrlicht Tueren|0 - links|1 - rechts Lichtobjekte (Laternen etc.) Licht Wie weit man mit anderen Modellen (z.B. beleuchtete Häuser) verfahren möchte, sollte diskutiert werden, besonders bei Häusern, die mehrere Beleuchtungsmöglichkeiten anbieten. Da sind wohl die Geschmäcker verschieden. Noch eine Anmerkung: Ist bei einer Standardfunktion (z.B. Fahrlicht) bei einem Modell nur eine Steuerung für "0 - vorn" vorhanden, müsste für "1 - hinten" eine Dummy-Funktion eingerichtet werden. Viele Grüße, Wolfgang

Hallo, folgendes Archiv enthält eine sortierte Liste aller Schalternamen aller Modelle im Online-Katalog (inkl. Archiv): Schalter.zip Es wird schnell klar, dass die fehlende Standardisierung zu einem Wildwuchs von Schalternamen geführt hat. Wenn wir aus der vorhandenen Liste "Standardnamen" extrahieren können, kann ich diese als Vorlagen direkt in das Studio einbauen, sodass Modellbauer beim Erstellen neuer Aktionen sofort auf bekannte Namen zurückgreifen können. Diese Vorlagen hätten den Vorteil, dass sie übersetzbar wären (so wie die Weichen- und Signalstellungen). Zusätzlich zu den Standardnamen müsste man sich aber auch entscheiden, ob es sich um einen einfachen oder um einen erweiterten Schalter handelt (um z.B. Abblend- und Fernlichter zusammenzufassen). Mit den Schaltern ab V9 möchte ich ja weg von der Einzelansteuerung der Modellanimationen, hin zu generischen Modellfunktionen. Wenn die Standardisierung funktioniert, würde ich eine Kompatibilitätsfunktion einbauen, um Bestandsmodelle an das neue System anzupassen. Viele Grüße, Neo

Hallo Reinhard, vielen Dank für die Überarbeitung der ICE. Den ICE 1 habe ich schon freigegeben, beim ICE 3 müsstest du noch einmal ran, da du diese Modelle neu erstellt und die alten überschrieben hast. Dadurch gehen aber die alten Animationsnamen verloren und Bestandsanlagen funktionieren nicht mehr. Wenn du alte Modelle anpasst, dann musst du diese direkt bearbeiten (nicht als neu überschreiben) und die alten Animationsnamen beibehalten. Viele Grüße, Neo

Neo, danke, Ich hatte das ja bereits erwaehnt war aber nicht sicher ob du dazu bereit bist. Natuerlich ist das die beste loesung , frage ist nur in welcher form. Warte auf die liste und mal schauen was ich daraus machen kann. Gruss Gmd

Das Extrahieren von Schalternamen per Screenshot und einer KI halte ich für übertrieben, die Daten kann ich euch ohne Fehleranfälligkeit auch im Studio bereitstellen.