Neo

Hallo, ich habe auf diese Frage gewartet, auch weil die jetzige Implementierung noch nicht final sein muss. Ich denke, es wird hier noch Änderungen geben, sodass mindestens $ beim Laden von Modulskripten zur Verfügung steht. Auf jeden Fall wird das Verhalten am Ende im Wiki dokumentiert. Yes, but only in Lua. Viele Grüße, Neo

Hallo, Seiteneffekte bezeichnen ungewollte Änderungen von globalen Variablen, die so nicht beabsichtigt waren. Zum Beispiel: objekte = {} function InitObjekte() objekte['ABC'] = 'Mein Gleis' end function ClearObjekte() objekte = {} end function VerarbeiteObjekte(modus) objekte['ABC'].verarbeite(modus) ClearObjekte() end VerarbeiteObjekte(1) VerarbeiteObjekte(2) -- Peng! Dieses konstruierte und sinnlose Beispiel soll verdeutlichen, wie schnell eine globale Variable unbeabsichtigt geändert wird. Weil in VerarbeiteObjekte nach der Verarbeitung ein ClearObjekte steht, ist die Tabelle beim zweiten VerarbeiteObjekte-Aufruf leer. Für jemanden, der dein Skript nur schnell überfliegt, könnte es nicht ersichtlich sein, dass ein VerarbeiteObjekte nach dem Verarbeiten die Objekte löscht. Man provoziert so also schnell riskante Situationen, die speziell bei "Modulen", die anderen zur Verfügung gestellt werden sollen, zu Fehlern führen. Daher mein Tipp, auf so viele globale Variablen wie möglich zu verzichten. Viele Grüße, Neo

Hallo, das gilt für jede transparente Grundplatte, die automatische Höhenanpassung funktioniert dort nicht. Das ist jetzt nicht explizit so gewollt, ergibt sich eher aus den technischen Interna. Führt das zu einem bestimmten Problem? @Andy und @Goetz Alle Skripte, egal ob Modulskript oder Ereignisskript, landen am Ende in einer "Datei", die von Lua kompiliert wird. Somit arbeiten alle Bereiche der EV im gleichen Environment. Wird also irgendwo ein Variable ohne local gesetzt, ist sie anschließend Teil des globalen Environments und steht überall zur Verfügung. Ausgeführt wird die zusammengesetzte Lua-Datei beim Kompilieren. Das geschieht sowohl beim Laden der Anlage sowie nach einer Änderung der EV. Mit dem Play-Button hat das nichts zu tun, dieser steuert nur die Animationen. Alles, was nicht in einer Funktion steht, wird beim Kompilieren von Lua ausgeführt. Ereignisskripte stehen immer in einer Funktion, die vom Studio generiert wird, somit werden also nur die Modulskripte direkt beim Kompilieren ausgeführt, die Ereignisskripte immer dann, wenn das Ereignis eintritt. Die Library-Funktionen des Studios stehen zur Kompilierung noch nicht zur Verfügung, weil ich vermeiden möchte, dass während der Kompilierung Anlagenzustände geändert oder sogar Ereignisse aufgerufen werden. Und da die Kompilierung nach jeder EV-Änderung durchgeführt wird (und später vielleicht auch in anderen Situationen), kann sich ein Anlagenplaner nie genau darauf verlassen, wann und wie oft seine Skripte kompiliert/ausgeführt werden. Das ist auch der Grund, warum die $-Funktion noch nicht funktioniert, weil es beim Kompilieren noch keine Verbindung zur Anlage und den Objekten darin gibt. In welcher Situation wird so etwas benötigt? Für explizite Initialisierungen gibt es Möglichkeiten, z.B. ein Ereignis, was nur beim Laden einer Anlage einmalig aufgerufen wird. In so einem Ereignis könnte man dann seine One-Time-Initialisierungen vornehmen. Zuvor würde mich aber interessieren, was das für Initialisierungen typischerweise sind. Einen EV-Export wird es mit V5 noch geben, wobei ich aber auch gern Suchen und Ersetzen im Skript-Editor noch mit einbauen kann. Viele Grüße, Neo

Hallo kutscher, die 32-Bit-Version findest du hier. Viele Grüße, Neo

Hallo, mit Verwindungen hat das Rotationsupdate nichts zu tun, hier geht es darum, Gleise schon im 3D-Modell anstellen zu können, z.B. für echte Rampen, wie man sie z.B. bei Holzeisenbahnen kennt. Das Thema Verwindungen bei Gleisen wird mal ein eigenes Thema werden, hab ich aber auf dem Schirm. Viele Grüße, Neo

Hallo, mich wundern diese Aussagen etwas, auch weil an anderen Stellen mitunter erwähnt wird, dass man bei der neuen EV "von vorne anfangen muss". Klar sieht sie anders aus und die Bedienung ist zunächst ungewohnt im Vergleich zu V4, aber das grundlegende Konzept dahinter ist doch identisch, die meisten Ereignisse, Aktionen und Bedingungen besitzen die gleichen Eigenschaften und verhalten sich wie gewohnt. Woher kommt dieser "Neuanfang"? Oder bezieht sich dieser auf die Tatsache, dass mit der neuen EV vorhandene Steuerungen deutlich effizienter umgesetzt werden können, und dafür aber die neu hinzugefügten Funktionen und Konzepte erst verstanden werden müssen? Viele Grüße, Neo

Hallo, ich habe eine neue Version 5.0.3.0 online gestellt, die einige Fehler beseitigt und weitere Verbesserungen enthält. Eine Übersicht erhaltet ihr im ersten Beitrag. Viele Grüße, Neo

Hallo, bitte Hat es einen bestimmten Grund, warum du ein benutzerdefiniertes Ereignis "Kraninit" verwendest, um die Kräne zu initialisieren? Da du komplett auf Lua setzt, hätte ich erwartet, dass du einfach eine Funktion in deinem Modulskript aufrufst. Das Konzept hinter den globalen Tabellen "objekte" und "ziele" finde ich persönlich nicht so schön. Die einzelnen Funktionen in "AblaufTable" besitzen eine hohe Redundanz und unterscheiden sich oft nur in wenigen Details. Hinzu kommt, dass du erst die Funktion aufrufst, um globale Tabellen zu befüllen, um anschließend direkt wieder auf den Tabellen zu arbeiten. Das ist sehr anfällig für Seiteneffekte. Besser wäre es, wenn du eine Funktion schreibst, die die Daten über return zurück gibt, und du so nicht mit globalen Daten arbeiten musst. Prototypisches Beispiel: -- Modulskript Kran10 = function() local objekte = {} local ziele = {} for i = 1, 4 do objekte[i] = "Fass1"..i ziele[i] = "k1"..i end return objekte, ziele end function Kraninit(kran, objekte, ziele) if not kran.variables["buzzy"] then ... end end -- Ereignis if controller.state == 1 then local objekte, ziele = Kran10() Kraninit($("Kran1"), AblaufTable["objekte"], AblaufTable["ziele"]) else ... end Der nächste Schritt wäre dann die KranXX-Funktionen zu vereinheitlichen. Aber das kannst du dir vermutlich sparen. Es wird (wenn auch nicht sofort) Arrays als Objektvariablen geben, wodurch du die Objekte und Ziele eines Krans direkt beim Kran definieren kannst und nicht über eine Funktion initialisieren musst. StartK1 bis StartK3 kannst du dann auch zu einem Ereignis zusammenfassen, da du im Schalter eine Referenz zum entsprechenden Kran hinterlegen kannst. Gibt bestimmt noch weitere Tipps, ich freue mich auf die nächste Iteration Viele Grüße, Neo

Hallo, von welchem Radlader sprichst du? Der von @fmkberlin neu in V5 hochgeladene Radlader ist der erste Radlader mit mehreren Animationen, in V4 hatte er schon immer nur eine Animation. Beziehst du dich eventuell auf ein Test-Modell, welches mittlerweile ausgelaufen ist (was auch das Fragezeichen erklären könnte)? Für deine Demo empfehle ich dir noch, dir die neue Aktion "Ausführung verzögern" anzuschauen. Damit kannst du einige Timer durch einen linearen Ablauf ersetzen und reduziert somit die Ereignisse und Komplexität. Viele Grüße, Neo

Hallo, das ist normal, weiter entfernte Schatten verwenden aus Performance-Gründen eine niedrigere Auflösung, was bei solchen synthetischen Anlagen (Zug auf Holzplatte) deutlicher sichtbar wird als bei richtigen Landschaften. Kannst du mir bitte einen Gefallen tun und ein Testmodell zukommen lassen, bei dem du ein Wagon aufs Minimum reduziert hast, also alles entfernen, außer der Hülle? Ich kann dein Problem zwar reproduzieren, möchte aber genauer testen, ob das an dem Schattenalgorithmus oder an der besonderen Modellkonstruktion (mit der Innenbeleuchtung) liegt. Was meinst du damit? Werden Objekte gruppiert, wird daraus eine Gruppe. Es gibt hier keinen Bezug zu einer eventuell früher vorhandenen Gruppe, diese wurde ja gelöscht. Nein, hier gibt es keine Reihenfolge, diese kann als zufällig betrachtet werden. Worauf genau beziehst du dich? Es gibt in V5 ja keine globalen Variablen mehr, jede Variable ist Teil eines Ereignismoduls. Wenn du $ eingibst, erhältst du anschließend die Wahl zwischen einem Objekt und einem Ereignismodul. Wählst du dort das Modul, kannst du anschließend auf die Variablen oder andere Eigenschaften/Funktionen zugreifen. Eine direkte Auswahl der Variablen aus einer Liste gibt es in Lua noch nicht, das habe ich mir noch als Verbesserungsmöglichkeit notiert. Viele Grüße, Neo

Hallo Axel, die maximale Texturgröße leitet sich von den maximal Abmessungen deines Modells ab. Vermutlich haben sich diese durch das Kopftuch verändert, konkrete Aussagen kann ich aber nur mit Beispieldaten treffen. Viele Grüße, Neo

Hallo kutscher, herunterladen und installieren. Viele Grüße, Neo

Hallo, im Großen und Ganzen ist das korrekt. Ob eine Tabelle im Hauptmodul oder einem Untermodul erzeugt wird, spielt keine Rolle, weil alle Skripte aller Module beim Speichern der EV zusammengesetzt werden. Hat sich die EV geändert, werden alle Skripte einmalig kompiliert. Dabei werden auch die Tabellen erzeugt. Anders ausgedrückt, globale Tabellen werde nur einmal erzeugt, da spielt die Performance keine nennenswerte Rolle. Etwas anders sieht es aus, wenn Tabellen in Funktionen erzeugt werden, und diese Funktionen sehr häufig aufgerufen werden. Dann werden die Tabellen nämlich bei jedem Aufruf neu erzeugt. Viele Grüße, Neo

Hallo, ich habe das soeben erledigt, danke für den Hinweis. Viele Grüße, Neo

Hallo, dem ist leider nicht so. Die Auswahlliste sagt nur aus, in welchem Maßstab ein Gleis angelegt wird, wenn es erstmalig auf die Platte gezogen wird. Der eigentliche Fehler besteht daher darin, dass im Editor eine Auswahl getroffen werden kann, die gar keinen Einfluss mehr hat. Ich kann jedoch gern die vordefinierten Skalierungsfaktoren auf der Transformationsseite aus V3 wieder reaktivieren, die ein schnelles Umskalieren beliebiger Objekte in andere Maßstäbe erlauben. Viele Grüße, Neo

Hallo Hermann, bitte schick mir die Dateien per E-Mail, da sonst das Forum mit Daten belastet wird, die nie mehr benötigt werden (die Modelle erscheinen ja im Online-Katalog). Viele Grüße, Neo

Hallo Andy, während das für die grafische EV noch machbar ist, wird das in Lua nichts mehr. Dort können Variablennamen beliebig zusammengebaut werden, das kann das Studio nicht selber entscheiden. Dir bleibt in diesem Fall nur die Suche nach Zeichenketten (die noch implementiert wird) und ein manuelles Ersetzen. Viele Grüße, Neo

Hallo Hermann, ich habe deine Variationen zum Online-Katalog hinzugefügt, außer: MaK 1206 BE - Hier fehlt mir die Datei BR 211 MaK 1000233 - DB 212 097-0 EP VI - Handelt es sich hierbei um ein neues Modell oder eine Erweiterung eines vorhandenen? MaK 1000387 - DB 213 340-3 EP VI - Handelt es sich hierbei um ein neues Modell oder eine Erweiterung eines vorhandenen? Viele Grüße, Neo

Hallo Henry, die fehlerhaften Koordinatenursprünge der Gleise der "Maßstab II"-Kategorie habe ich korrigiert. Viele Grüße, Neo

Hallo, einfach noch die ENDE-Taste drücken, wie beim Standard Windows-Texteditor. Viele Grüße, Neo

Hallo, was meinst du damit? Ich kann problemlos auch die letzte Zeile markieren. Viele Grüße, Neo

Hallo, auf Grund von eurem Feedback habe ich die Farben des Gleiskontakts gedreht. Bisher bedeutete "Grün", dass der Gleiskontakt auslöst, wenn ein Fahrzeug aus der Richtung, in die der Pfeil zeigt, den Kontakt überfährt. Intuitiv haben die meisten Leute den Pfeil aber so interpretiert, dass der Gleiskontakt auslöst, wenn ein Fahrzeug in die angegebene Richtung fährt. Zugleich habe ich weitere Farbvariationen und die Option der Tauschtextur hinzugefügt. Auf die Logik selbst hat die Farbänderung keine Auswirkung. Eine Art History für Anlagen gibt es schon länger auf meiner ToDo-Liste, irgendwann wird sie kommen Das geht leider nicht per Skript, weil das Studio bei nil nicht unterscheiden kann, ob eine leere Referenz gemeint ist, oder das Löschen der Variable. Das Ergebnis ist zwar in beiden Fällen das gleiche, allerdings werden in der neuen EV häufig Variablen für das Speichern von dynamischen Objektverbindungen genutzt, und wenn diese gelöscht werden, könnte das die Übersicht verschlechtern, weil der Nutzer dann nicht mehr weiß, ob er die Variable vergessen hat anzulegen, oder ob sie einfach nur leer ist. Das wird aber nicht ewig so sein, sobald die wichtigsten Punkte noch abgearbeitet sind, plane ich auch die Unterstützung von Listen und Tabellen in Variablen. Variablen kannst du bequem per Copy&Paste kopieren/verschieben. Bei den Timern würde ich eher empfehlen, diese durch verzögerte Aktionen abzubilden, wenn man schon dabei ist, eine V4-EV aufzuräumen. In den meisten Fällen wurden Timer früher nur dazu genutzt, Aktionen einmalig/sporadisch zu verzögern. Viele Grüße, Neo

Hallo, das stimmt, so eine Liste gibt es in Lua noch nicht. Ich werde mir hier etwas einfallen lassen. Das war mir bisher auch neu, dass es atan2 früher gab und jetzt in atan integriert wurde. @EASY was die grundlegenden mathematischen Funktionen angeht, hast du im Studio vollen Zugriff auf alles was Lua anbietet. Hast du die Texturen selber erstellt? Wenn ja, dann kann ich diese gern mit in den Katalog aufnehmen, schick sie mir einfach an die E-Mail, die hier unten auf der Kontakt-Seite angezeigt wird. Gern erweitere ich die Suche nach Variablennamen. Ich wusste das bisher auch nicht. Meine Code-Completion-Liste bildet nur die offizielle Lua-Docu nach, dort taucht atan2 nicht auf. Schaut man allerdings in den Code, sieht man, dass Lua diese Funktionen doch noch anbietet. Es handelt sich also vorwiegend um eine Kompatibilität alter Skripte. Neue Skripte sollten nur die offiziellen Befehle verwenden, da es durchaus sein könnte, dass die alten Funktionen in neuen Lua-Versionen rausfliegen. Weil Code in den Modulskripten bei jeder Kompilierung der Skripte ausgeführt wird, und das mitunter beim Laden der Anlagen geschieht, wobei die Anlage noch gar nicht vollständig vorliegt. Auch werden die Skripte bei jeder Änderung der EV neu kompiliert. Wenn du etwas einmalig und kontrolliert initialisieren willst, solltest du den Weg über ein konkretes Ereignis gehen. Viele Grüße, Neo

Hallo Frank, hast du dich bewusst für "Eine beliebige Objekt-Variable wird gesetzt" entschieden, um die Rekursion zu starten? Das wirkt auf mich etwas umständlich, auch weil es Zwischenvariablen erfordert. Das gleiche Verhalten erreichst du ja auch mit den benutzerdefinierten Ereignissen, nur dass die Parameter dort nicht irgendwo zwischengespeichert werden müssen, sondern als "Stack" automatisch vom Studio verwaltet werden. Viele Grüße, Neo

Wenn ich da an die trockenen Übungen aus dem Informatikunterricht in der Schule zurückdenke, niemand konnte sich mit den Türmen von Hanoi wirklich anfreunden. Hätte es doch nur damals schon ein MBS gegeben