Ne, include() giibts nich bei Lua, aber kommt aufs selbe raus. Dieses dofile() geht warscheinlich auch nich und das wäre auch ein eher unglücklicher Weg weil der Code darin ja sofort ausgeführt wird. Weis nich ob man da funktionen drin definieren kann die dann aufrufbar wären.
Theoretisch müsste es doch möglich sein, die LuaC.exe selbst zu kompilieren und zu tauschen. Das merkt doch RW nicht mal. Aber es stünde dann mehr Funktionalität zur Verfügung.
Naja, aber luac.exe wird doch vom Blueprint Editor nur zum Syntaxcheck verwendet und nachher ladet erst recht die Source im Assets-Unterordner. Ich hab aber auch schon gehört, daß man kompilierten Lua-Code genauso in den Assets-Ordner stellen könnte.
Die Frage ist, ob es sich auszahlt, sich mit luac.exe zu spielen. Wegen den paar Include-Files bei Fahrzeugen würd ich mich nicht streßen.
Und bei den Signalen hab ich es vor langer Zeit schon so gelöst, daß alle dasselbe Skript verwenden und zur Laufzeit draufkommen, was sie eigentlich sind - durch Checks, welche Teile grad da sind. (getNearLocation gibt nil zurück, wenn das angesprochene Child nicht da ist.)
Der Blueprint Editor macht mit den Lua Scripts doch gar nix? (EDIT: ich korrigiere mich, der kompiliert es tatsächlich um nach Fehlern in der Syntax zu suchen) Der kopiert die einfach nur mit rüber in den Asset Ordner. Erst beim Laden des Asset wird das Script kopiliert. Ich bearbeite auch immer die Lua Source im Asset Ordner bzw kopiere es manuell dahin. Dass fertig kompilierte Dateien da funktionieren bezweifle ich. Der schickt dann die fertigen durch den Compiler und dann passiert gar nix.
Was ich eher meinte ist, dass man dem Interpreter mal alle Lua-Funktionen gibt. Denn jetzt hat er nicht alle die Lua 5 hergeben würde. Nur is die Frage wie man den "sicher" verteilt und was RW draus macht. An sich sollte es dem RW nicht auffallen ob da nun ein paar Funktionen mehr drin sind, die es erlauben mit require und dofile etc. umzugehen. Das passiert ja eben beim kompilieren, wärend des Ladens des Asset und nicht im Game nachher. Mit requiere() könnte man ja auch dann Module nachladen die so rumschwirren und nützliche Funktionalitäten bereitstellen. Wie zB Zeitberechnungen. Aber ich glaub ich verlange schon wieder zu viel. So lang man bei dem 1-Datei Prozedualscript noch durchschaut ist ja alles ok. Nur ich komm schon an den Punkt wo mir die Fehler um die Ohren flattern. Ich bin eben OOP gewohnt und lagere gern alles in Klassen aus.
Die Idee ist doch, dass man bestimmte Funktionen, die nicht in jedem Rollmaterial benötigt werden, einfach nur vorrätig als "Klasse" hat und dann bei Bedarf einbindet. Aber das geht warscheinlich sowieso nicht, da nur einmal kompiliert wird, und was dann nicht geladen ist das wird auch nicht mehr geladen. Also ne Funktion wie "prüfe den Consist auf irgendwas" die nur einmal bei bestimmten Aktionen oder Bedingungen ausgeführt werden muss, aber vll auch nie auftritt. Warum soll ich sowas in das Hauptscipt komplett reintackern wenns vll eh nich benötigt wird.
noch'n Edith: RW frisst vorkompilierte Lua wenn man diese von .luac nach .lua umbenennt. Ob es aber auch klappt wenn man in RW nicht funktionierende Methoden anwendet müsste man rausfinden. Ich werde dazu mal etwas Code auslagern und per requiere wieder zuladen. Wenn es funktioniert, dann prüft RW nicht nochmal das vorkompilierte Script. (wichtig ist, dass es aus dem Asset Ordner herraus kompiliert wird, damit der Pfad stimmt)
Doch noch mal was zu den Schlusstafeln (die Funktionalität jetzt gibt es ja schon länger in trainz und funktioniert genau gleich): Da diese auch in der Realität "händisch" angebracht werden sollte es doch villeicht sogar möglich sein diese auch in RW händisch anzubringen, Problem ist nur dass ich einen Wagen nicht wie eine LOk "ansprechen" kann (ich meine im Spiel, ausser bei der Kameraansicht wo ich von Wagen zu Wagen gehen kann... es wäre auch zentral um etwa den gleichen Typ von Wagen im Zugverband verschieden zu beladen und zwar im Spiel nicht durch die vorherige Programmierung beim "Einstellen" ins Szenario; sorry ja ich bin weg von trainz, aber dort kann man sich "Ladungstypen" anzeigen lassen und innerhalb des Spiels entscheiden ob nun mit Sand oder Kohle beladen werden soll -bringt jedenfalls enorm viel Spaß) Na jedenfalls könnte das noch nicht der Weisheit letzten Schluss sein, den schliesslich wird auch beim Rangieren/Abstellen die Scheibe niemals genutzt, wirklich nur zu Fahren, im übrigen auch bei einem Lokzug an der letzten Lok). Also Tüfteln ist angesagt.
So, dofile("Assets/{...}/filename.lua") funktioniert schon mal auch ohne vorkompilieren. Das ermöglich zumindest ein paar Codefragmente auszulagern um die Übersicht zu wahren. Ob das mit require auch geht bleibt anzuwarten. Da muss man die Module Loader Technicken da anwenden. Da wird es warscheinlich Pfadprobleme geben.
Mit den Tafeln werde ich es so ähnlich umsetzen wie AndiS es ausführte, wenn die Dinger wirklich nur bei Fahrt als Zug raushängen.
Lok checkt ob was an ihr dran hängt, dann einen Controller wie "Zugschlusstafel" auf 1 stellen. Sofern dieser wirklich durch den Consist reicht (ApplyToConsist), wertet der Wagen diesen aus (was vll sogar mit OnControlValueChange() funktioniert) und checkt ob er der Letzte is. Wenn letzter und Controller 1 dann Tafel raus. Ich denke dass man, wenn OnControlValueChange nicht geht, die Updatezeiten auf Minutenbasis gut ausbalanciert hat.
Muss hier nochal was zu sagen
3.) Damit beim Rangieren der Zugschluß unterbleibt, setzt man im Szenario den Consist Type auf Light Engine (Lokzug oder wie immer die das übersetzt haben), und unterbindet im Skript dann das Message senden für diesen ConsistType.
Das ist meines "beschränkten" Wissens nicht möglich. Welcher Call im Lua soll das herrausfinden?
5.) Wenn dieser Befehl über einen Controller (apply to consist) kommt, dann können nicht ausgerüstete Waggons in der Mitte nicht dazwischen funken. Aber man braucht trotzdem ein Skript, das eine Message schickt, die in diesem Fall vom Empfänger ignoriert wird, weil man nur so feststellen kann, ob ein weiterer Waggon dranhängt oder nicht. D.h. Effizienzsteigerung bekommt man so keine. Aber wenn man es nur selten macht, dann stört es nicht die Flüssigkeit beim Fahren.
ApplyToConsist weigert sich leider beständig zu funktionieren. Alles ausprobiert, da rührt sich nix. Ob mit oder ohne Messages.
Das ganze funktioniert also nur mit Wagen die ausgerüstet sind und eine ausgerüstete Lok vorn dran haben. Ich finde, dass schränkt ziemlich ein oder ?
Ich hab es jetzt grad eben genau so umgesetzt. Wenn eine lok dran hängt, die dem Cosist vermdeldet dass sie angekuppelt ist, dann checken die Wagons nach woe sie stehen und hängen bei bedarf die Tafel raus. Hängt man die Lok ab, gehen die Tafeln weg. Hängt man einen Fremdwagon dazwischen ist keine Tafel mehr da. Ich weis nich wie ich das sonst lösen soll mit den Einschränkungen im RW. Und ehrlich gesagt wollt ich mich nich 2 Monate mit den Tafeln aufhalten. Da sind wichtigere dinge wie die ZWS und ZZA.
Was ich noch veruschen kann ist, das die Wagen erst mal grudsätzlich als letzte im Verband eine Tafel raushalten solange keine ausgerüstete Lok dran ist. Sobal die Lok ihr Dasein bekundet, schalten die Wagen um auf Message und reagieren entsprechend. Sendet die Lok eine Zeit lang nicht mehr, schalten sie zurück und hängen wieder am leeren Ende die Tafel raus. Mehr geht nicht.
Muss hier nochal was zu sagen
Das ist meines "beschränkten" Wissens nicht möglich. Welcher Call im Lua soll das herrausfinden?
GetConsistType wäre das.
Kann jetzt natürlich sein, daß das in Engine Scripts nicht mag, aber GetConsistSpeed geht auch (und ist eine nette Alternative zum Geschwindigkeits-Controller, weil beim Rückwärtsfahren ein negativer Wert angegeben wird).
ZitatApplyToConsist weigert sich leider beständig zu funktionieren. Alles ausprobiert, da rührt sich nix. Ob mit oder ohne Messages.
Das ganze funktioniert also nur mit Wagen die ausgerüstet sind und eine ausgerüstete Lok vorn dran haben. Ich finde, dass schränkt ziemlich ein oder ?
"Interessant."
Ich hab das aber auch nicht als "muß morgen gehen, oder ich reg mich auf" gemeint, sondern eher als Vision für die Community Edition der Waggons.
Wenn das jetzt so ist, daß alle Waggons im Zug damit ausgerüstet sein müssen, dann muß man, wenn es so weit ist, auch mit unseren Nachbarn, z.B. in Italien, in Kontakt treten.
ZitatIch hab es jetzt grad eben genau so umgesetzt. Wenn eine lok dran hängt, die dem Cosist vermdeldet dass sie angekuppelt ist, dann checken die Wagons nach woe sie stehen und hängen bei bedarf die Tafel raus. Hängt man die Lok ab, gehen die Tafeln weg. Hängt man einen Fremdwagon dazwischen ist keine Tafel mehr da. Ich weis nich wie ich das sonst lösen soll mit den Einschränkungen im RW. Und ehrlich gesagt wollt ich mich nich 2 Monate mit den Tafeln aufhalten. Da sind wichtigere dinge wie die ZWS und ZZA.
Genau, es ist einfach ein Feature und vielen, und offensichtlich nicht ganz einfach, den Durchbruch zu schaffen.
Es gibt aber immer noch die Möglichkeit, eine Variante der Waggons mit Zugschluß zu schaffen, haben die Italiener schon lange so (heißt Coda für die italienische Variante bzw. Coda DB-CH-OBB für unsere). Das ist einfach ein Child Blueprint im Wagon Blueprint, das kann daher auch jemand dazufügen, der nicht den Source hat.
Natürlich ist die automatische Lösung viel eleganter, aber die Welt geht nicht unter ohne sie (oder mit einer halben Lösung).
ZitatWas ich noch veruschen kann ist, das die Wagen erst mal grudsätzlich als letzte im Verband eine Tafel raushalten solange keine ausgerüstete Lok dran ist. Sobal die Lok ihr Dasein bekundet, schalten die Wagen um auf Message und reagieren entsprechend. Sendet die Lok eine Zeit lang nicht mehr, schalten sie zurück und hängen wieder am leeren Ende die Tafel raus. Mehr geht nicht.
Sowas würd ich nicht anstreben. Mir persönlich ist lieber, man muß hier und da einmal einen Zugschluß explizit definieren, als es haben alle abgestellten Garnituren auf beiden Enden einen Zugschluß. Das sind einfach wesentlich mehr Fehler. Annahme: 1 Spielerzug, 10 AI-Züge, 50 oder 100 abgestellte Wagengruppen (oder Einzelwaggons). Natürlich nimmt man den Spielerzug mehr wahr, aber deshalb an 50 abgestellten Gruppen einen falschen Zugschluß anschauen?
Was schon eher funktionieren könnte: Wenn die Tafel rausgehängt wird, sobald der Waggon fährt (und der letzte ist). Das deckt dann nämlich alle AI-Züge ab, während abgestellte Waggons korrekt ohne Zugschluß bleiben. Natürlich wird die Tafel in diesen Fällen nie mehr eingeholt, sonst verschwindet sie ja beim Stehen, und AI rangiert eh (noch) nicht, d.h. der Zugschluß soll ewig drauf bleiben.
Damit es dann beim Spielerzug anders ist, kann man ja (dann/später einmal) für den Spielerzug die aufwendigere Lösung versuchen. Dann ist vielleicht die Waggonauswahl eingeschränkt, und die Loks auch, aber dafür hat man da dann die maximale Funktionalität. Und für den bunten Eindruck reicht es, wenn die "sonstigen" Waggons in AI mitfahren, bei der es wiederum reicht, wenn der letzte Waggon "intelligent" ist.
Problem gelöst. Ein paar Tests steheh noch aus, aber ich denke es ist gelöst. Geht mit jeder Lok und mit jedem Wagen dazwischen. Toll wenn man doofe Eigenarten von RW als Feature verwenden kann 
Na hoffentlich schaffen sie die doofe Eigenschaft nicht ab. Ist mir schon passiert, in der Vergangenheit. Nicht jeder Bug bleibt ewig bestehen.
Ich nutze die Eigenheit, dass Züge die in Bewegung waren oder eine aktive Lok besitzen, das Speed Value am zappeln ist. Erst mal nur einfach. Aber ich denke man muss noch etwas genauer die Abweichungen kalkulieren da einmal bewegte Wagons nach dem Abstellen durchaus dort feststehende Werte ausser 0 haben können. Aber Verbändie die nur rumstehen haben so definitiv keine Tafel draussen. Nur aktive und einmal bewegte Züge. Ich denke das is ne gute Lösung oder? Vorerst. Wenn die was ändern daran, dann ist das mit einem kleinen Eingriff wieder abgestellt und die Tafeln höngen wieder draussen wenn nix am Ende hängt. Kompromisse halt.
Na das Zappeln wird uns noch eine Weile erhalten bleiben. Das kann man an Signalen auch "schön" beobachten. Wegen Grenzwert würde ich einmal 0,01 (m/s) annehmen, oder 0,02.
Ja, dann kommen die Tafeln aber erst raus wenn der losfährt. Es ist schwierig da ein Mittelwert zu finden denn das eiert zu stark und zu schnell. Aber hey, wer in RW die Züge langgeht und nach Tafeln sucht der hat einfach zu viel Zeit 
Wenns fährt hat die Tafel hinten rauszuschauen und sonst nicht. Das wird jetzt einfach so festgelegt. So funktionieren die Wagen auch in allen Zügen mit allen Loks. Und wenn der "Krach" zu den Wagen dann mit ausgeliefert wird, will eh keiner mehr so nah ran 
Schön, dass sich eine Lösung abzeichnet! 
Ich hätte noch eine andere Idee gehabt, ohne jetzt aber getestet zu haben, ob es überhaupt möglich ist... Ich bin mir auch nicht so sicher, ob meine Idee der jetzigen geschwindigkeitsbasierten Lösung wirklich überlegen wäre: Ich dachte an eine Zugschlusstafel als Beladung, die im Editor einfach aktiviert wird. Dazu müsste man abklären, ob es überhaupt möglich ist, verschiedene Beladungen für einen Wagen zu ermöglichen. So wären Zugschlusstafel vorne/hinten denkbar... Naja, ich denke halt (leider) immer Script-frei, weil ich mich mit Scripten gar nicht auskenne! 
Man kann zwar mehrere Beladungstypen in einen Wagon bauen, aber separat schalten geht nicht. Entweder alle an oder alle aus.
Die Speed abhängige Variante wurde verworfen, da diese leider nicht berechenbar ist. Es bleibt erst mal wie gehabt. Der Letzte Wagon in einem Consist (beide Enden) hängt ein ZSS raus. Steht er allein kommt kein ZSS. Mal schauen was RW3 bringt und ob man da eine andere Lösung findet.
Man kann zwar mehrere Beladungstypen in einen Wagon bauen, aber separat schalten geht nicht. Entweder alle an oder alle aus.
Die Speed abhängige Variante wurde verworfen, da diese leider nicht berechenbar ist. Es bleibt erst mal wie gehabt. Der Letzte Wagon in einem Consist (beide Enden) hängt ein ZSS raus. Steht er allein kommt kein ZSS. Mal schauen was RW3 bringt und ob man da eine andere Lösung findet.
Danke für den Hinweis!
Hallo Zusammen,
der erste Güterwagen mit dem Script und vor allem dem NEUEN Sound kommt ab morgen in den Shop!!
Gruss Ulf
GetConsistType wäre das.
Kann jetzt natürlich sein, daß das in Engine Scripts nicht mag, aber GetConsistSpeed geht auch (und ist eine nette Alternative zum Geschwindigkeits-Controller, weil beim Rückwärtsfahren ein negativer Wert angegeben wird).
GetConsistSpeed gibt leider nichts zurück.
Hm, wieder eine Hoffnung weniger.
Rein theoretisch könnte natürlich das nächste Signal dem Zug diese Information schicken, aber das wird dann immer irrer.
Mäßig irr wäre es, wenn das Signal nur dann an den Zug meldet, wenn der Spieler TAB drückt. Das soll ja in Zukunft ermöglichen, zwischen Rangieren und Zugfahrt umzuschalten, was den Signalbegriff betrifft. Parallel dazu würde sich auch das Zugschluß-Handling ändern. Aber das ist alles ein bißerl weit gegriffen.
Na wenn man selber fährt ist das weniger schlimm. Denn der Accelerometer geht ins Minus wenn man sich rückwärts bewegt, allerdings auch nur wenn man im selben Cab bleibt. Das musste ich nämlich dann negieren für die Anzeige. Bei der KI kann man aber nicht rausfinden in welche Richtung sich der Zug bewegt von seiner Normalposition aus gesehen, was für die Pantosteuerung bei KI Wendezug natürlich scheisse ist. Aber das kann man mit Consistmessages ausgleichen, was wiederum nur geht wenn der Consist eben dies kann.
grauenvoll....
GetConsistSpeed gibt leider nichts zurück.
das ordninäre "GetSpeed" gibt den Wert auch negativ zurück. Möglicherweise aber nur als KI Zug.
