[Video-Tutorial] Scripting mit LUA für den LS11 (Update #3 getScale, Erweiterung unserer Spezi)

  • Moin..



    Ja, hmm.. Der Titel sagt eigentlich schon alles :D



    Der eine oder andere kennt vielleicht schon meinen Channel auf Youtube.. Jedenfalls hab ich seit kurzem das erste und auch gleich das zweite Video zum Thema LUA, Scripting für den LS 11 hochgeladen.
    Wollt die euch hier grade mal vorstellen, vielleicht hilft es ja dem einen oder anderen. Kritik, Anregungen, Fragen etc. zu den Videos könnt ihr auch gerne hier rein posten.. (So lange die Admins da nix dagegen haben? )



    Ach ja, falls einer von euch wirklich richtigen Profis einen Fehler findet in dem was ich sage, ebenfalls bescheid sagen, dass ich es verbessern kann ;)



    Scripting mit LUA #1, die erste Specialization





    Scripting mit LUA #2, Nachtrag: Erklärungen zu unserer ersten Spezi




    Wie gesagt, vielleicht hilft es dem einen oder anderen...



    LG

  • Zum ersten Video: Das Semikolon sagt eigentlich, dass die Zeile dort zuende ist. Da Lua aber ein Zeilenende auch erkennt, wenn man bloß Enter benutzt, ist es eigentlich überflüssig. Man macht es aber trotzdem, um diese Fehlerquelle zu eleminieren. Sven777b hat es mir mit einem Sicherheitsgurt verglichen. Seitdem setze ich es auch immer, damit man sichs angewöhnt.

  • Hab mir jetzt erstmal das erste Video angesehen, folgende Sachen sind mir aufgefallen:


    dt steht für delta time, nur mal so als kleiner Erklärung. Wer in der Schule in Physik und Mathe aufgepasst hat wird das delta kennen^^


    Utils ist eine Klasse. In dieser Klasse sind sehr viele Funktionen definiert, ist also eine Funktionssammlung.


    In dem Beispiel mit "self.wheelScaleState = (not self.wheelScaleState); können die Klammern weg, funktioniert auch ohne Klammern.


    "if wheelScaleState == true then" ist ein weißer Schimmel. Das kann man auch so schreiben: "if wheelScaleState then", wenn man einen Boolean auf false überprüfen wird halt noch ein "not" davor. Weil ein Boolean ja nur 2 Werte annehmen kann braucht man auch kein elseif, sondern braucht nur ein else.



    Das ist mir so aufgefallen, werde mir jetzt auch mal das zweite Video angucken.


    Achja, ich finde es super, dass du darauf hingewiesen hast, das die Funktion "keyEvent" nicht mehr benutzt wird, bzw nicht mehr benutzt werden sollte. Ich krieg nämlich jedes Mal ne Krise, wenn ich den Ostschrott sehe, wo die Funktion noch fleißig benutzt wird. Ich hoffe echt, das Giants die Funktion in LS13 rausschmeißt. Würde sehr dazu beitragen, dass der ganze Ostschrott nicht für LS13 konvertiert wird.

  • Erstmal sehr schön, dass Du da versuchst auf dem Gebiet etwas zu machen. Im ersten Video klickerst Du irgendwie verdammt viel mit der Maus rum. Das Hervorheben von Notepad++ ist zwar praktisch, aber wenn Du erzählst lenkt es mich ab.


    Das zweite Video ist schon fast überflüssig, denn wer sich nichtmal die ersten paar Kapitel auf http://lua.gts-stolberg.de/Programmieren.php anschaut, wird sowieso irgendwann scheitern... z.B. da Du bei ungefähr Minute 16 die Gradzahlen (setRotation) ansprichst - LUA rechnet im Bogenmaß und Gradzahlen müssen entsprechend umgerechnet werden http://lua.gts-stolberg.de/math.php#math.rad
    Programmierung erfordert auch immer die Lösung von diversen Problemen und wer da nicht selber bereit ist Zeit und Arbeit zu investieren, sondern wartet bis jemand einem die Lösung auf dem Silbertablett serviert, wird denke ich schnell die Lust verlieren. Ansonsten weitermachen :thumbup:

  • Guten Abend..


    Danke für euer Feedback :)



    bassaddict,
    Danke für den Hinweiß mit den Klammern, war mir nicht sicher bei der Aufnahme.. :)


    Wegen if x == true then bzw. if x then,
    Ich denke es ist einfach für Anfänger besser zu verstehen und zu lesen, wenn man das ganze ausschreibt. Man sieht einfach auf den ersten Blick was passier ;) Selbiges gilt auch für elseif
    Hab ja gerade das mit else / elseif noch einmal erklärt im zweiten Teil.


    bazillus,
    Ja, mit der Maus... Sorry, versuche ich beim nächsten mal sein zu lassen ;)


    Im Grunde könnte ich das zweite Video streichen, aber es ist eben viel zu lesen da.. Und man hat vielleicht mehr Mut mal ein paar Kapitel zu lesen, wenn man schon das erste Erfolgserlebnis im Scripten hinter sich hat, oder? :)
    Zum grad/radius.. Japp, wo du recht hast...



    LG

  • Soo... Ein weiterer Teil ist Online.


    Hab versucht nicht mehr ganz so viel zu klicken, ist mir aber nur teilweise gelungen.. :(



    Hier, das Video:



    Vielleicht ja das eine oder andere neue für den einen oder anderen von euch.. ;)




    LG
    ps. Kritik und so immer her damit :)

  • Division gehört zur Punktrechnung ;) Ich hätte vermutlich gleich mit dem entsprechenden Faktor multipliziert. Für 70% halt 0.7 - spart Schreibarbeit und Speicher. Bei den kleinen Skripten eher sekundär, aber Kleinvieh macht auch Mist :D
    Die Länge vom Video war angenehm kurz!
    Grüße

  • Jo, da kann ich bazillus nur Recht geben.


    Und die Klickerei kann man noch deutlich verringern. Du brauchst in NP++ nicht immer alles markieren^^


    Aber ansonsten gut, dass du da so ein Videotut machst. Ich selbst hätte da bestimmt keinen Nerv zu sowas zu machen^^

  • hab zufällig gerade das Video entdeckt. Nur mal ein paar Anmerkungen zur Ergänzung - kann sein das einiges inzwischen schon geklärt ist oder später auftaucht. Ich schaue gerade die Videos an und notiere mal chronologisch was mir auffällt...


    - update(dt) wird auf einem Durchschnittlichen PC 20-30x pro Sekunde ausgeführt. Abhängig von der Rechenleistung und der Anzahl der Mods.
    - updateTick(dt) wird nur ca. 2-3x pro Sekunde ausgeführt abhängig von der Multiplayer-Verbindungsgeschwindigkeit. Im SinglePlayer läuft updateTick fast genauso schnell wie update.
    - draw(dt) wird 50 bis 60x pro Sekunde ausgeführt - abhängig von den aktuellen FPS (draw wird 1x pro Frame ausgelöst) Die Laufzeit der Draw Routinen beeinflusst damit auch maßgeblich die maximalen FPS - da sollte wirklich nur rein was nötig ist (Bildschirmausgaben)


    - die Sache mit dem elseif wurde von bassaddict bereits angesprochen. Ich würde hier ebenfalls auf else setzten - zum Einen um Fehler zu minimieren - denn eine elseif-Variante hat einen unbekannten Ausgang (wenn weder die erste noch die zweite Bedingung zB aufgrund eines Schreibfehlers erfüllt würde) und kostet unnötige Performance da ein zweiter Vergleich notwendig wird.


    - die Lösung im update() Bereich ist ineffizient und sollte von Anfang an vermieden werden - in diesem Beispiel ist der Performanceverlust minimal , bei größeren Spezis oder gar MP-Anbindungen kann soetwas böse Folgen haben.


    Erklärung: du prüfst erst auf Tastendruck und setzt entsprechend die Variable self.wheelScaleState. Anschliessend skalierst du basierend auf eben der genannten Variable deine Räder. Bei einem oneRun Script kein Problem. Aber hier wird die update() Routine mehrfach pro Sekunde durchlaufen und du skalierst damit unnötigerweise mehrfach pro Sekunde die Räder - auch wenn es der selbe Wert ist, wird das Rad doch skaliert. Sinnvoller wäre es hier den Skalierungsvorgang direkt in die if-Abfrage des Tastendrucks zu integrieren um sicher zu stellen, dass das Rad nur skaliert wird wenn es notwendig ist.


    Code
    if InputBinding.hasEvent(InputBinding.TASTE_TUTORIALWHEELSCALE) then
    self.wheelScaleState = not self.wheelScaleState;
    if self.wheelScaleState == true then
    setScale(self.wheelToScaleLeft, 0.7,1,1);
    setScale(self.wheelToScaleRight, 0.7,1,1);
    else
    setScale(self.wheelToScaleLeft, 1,1,1);
    setScale(self.wheelToScaleRight, 1,1,1);
    end;
    end;


    - Wichtig wäre darauf hinzuweisen dass das was du im Video als Beispiel getan hast prinzipiell falsch ist. Denn die repr-Node eines Rades darf nicht skaliert werden - weder im GE noch im späteren Spielverlauf. Wenn du die Räder im Spielverlauf skalieren möchtest, solltest du die driveNode dafür verwenden. Also eine tiefer liegende Node - ansonsten gibt es probleme mit der Physik.


    - Ergänzend würde ich - um Redundanzen zu vermeiden - einfach auf die direkten Variablen der Wheels - also self.wheels[2].driveNode und self.wheels[3].driveNode zurück greifen anstatt eine eigene Variable dafür zu verschwenden. Allerdings ist mir durchaus bewusst dass dies nur zu Beispiel-Zwecken diente.

  • zum zweiten Video kann man wenig sagen , da es im Grunde die Informationen des ersten Videos wiederholt.
    Der Verweis auf gdn ist sehr wichtig - es wäre evtl. sinnvoll auf die Strukturen einer solchen (typischen) Befehlsreferenz hinzuweisen.


    Sehr amüsant der Ausflug in die Grundlagen der Mathematik ;) Brüche haben automatisch immer vorrang - abgesehen davon hat bazillus natürlich recht - x*0.7 wäre die einfachste und gemeinhin üblichste Lösung. Entspricht der Formel W = G * P / 100.


    - zum Thema "Float" ... "Fliesskomma-Wert" war das Wort das du gesucht hast - und Prozent heisst in englisch percent.
    - die Wahl zwischen Float und Int trifft man primär aus Gründen der Präzision. Bei Integer Werten wäre (10/2) == 5 immer true. Bei Float ist (10.0/2.0) == 5.0 nicht unweigerlich gegeben. Die Fliesskomma-Präzision ist begrenzt und hinter dem Komma gibts noch viele Stellen... Wers nicht glaubt kann im LUAEdit oder auch in einem LS Script mal die Funktion eingeben:


    Code
    local x = 0.0;
    for y=1,1000 do
    x = x + 0.3;
    end;
    print(x);


    Spoiler: das Resultat ist nicht 300 ;)


    - ich finde es gut das du von vornherein mit englischen Variablen begonnen hast - das sollte man generell beibehalten. Dies macht man nicht nur wegen der Internationalisierung - also das auch andere Scripter damit klarkommen , sondern es hat auch den Vorteil das die englische Sprache keine Sonderzeichen wie äöü oder á und dergleichen besitzt - diese Zeichen sind in Variablennamen verboten. Wenn man gleich englische Bezeichner verwendet, umgeht man diese Problematik vollständig.


    - mich wundert das dir nicht aufgefallen ist das dein Traktor einen Fehler in die log hätte werfen müssen - wegen der skalierten Räder.


    - ich würde in einem zukünftigen Tut auf die Verwendung von Utils.getNoNil hinweisen. Insbesondere wenn die aus der XML ausgelesenen Werte für mathematische Operationen verwendet werden.
    Utils.getNoNil(value, default);
    Wenn der Wert value == nil ist - was zB passiert wenn man ihn in der XML nicht angegeben hat, dann wird er durch den Wert default ersetzt. So vermeidet man einen Crash des Scriptes.

  • Moin..



    Sven777b, erst einmal Danke für deine Ausführliche Analyse der Videos ;)


    Die Sache mit update(), updateTick() und draw(), und wie oft das ganze aufgerufen wird habe ich im Video mal ergänzt.


    Zu den Dingen zwecks Performance, da habt ihr sicherlich alle Recht. Allerdings ist es kein so großer Unterschied am Ende, wenn man nicht gerade 400 schlecht gescriptete Mods Ingame hat.. Da gibt es sicher viele Dinge die sich deutlich mehr auf die Performance auswirken, und mir geht es nicht darum einen am Scripten interessierten gleich von vorn herein mit Problemen die es zu beachten gilt voll zu schütten. Viel eher möchte ich demonstrieren dass die Sache an sich gar nicht so schwierig ist, und vor allem im Grunde für jeden der sich etwas dafür interessiert zu verstehen ist.
    Jeder der da wirklich dran bleibt und sich auch nach dem Video noch einmal mit LUA beschäftigt, wird von allein darauf kommen wie man das ganze Performanceoptimiert aufbauen kann. Und wenn nicht, interessiert es ihn auch nicht, und ich könnte mir den Mund fusselig reden...
    Man kann ja auch noch tausendmal irgendwo erwähnen dass nicht die Polys sondern die Monstergroßen Texturen für Bad Allocation und FPS-Einbrüche verantwortlich sind, aber glauben tun es trotzdem die wenigsten.
    (Wobei ich in einem zukünftigen Video ja vielleicht noch auf die Performanceoptimierung der Scripte eingehe, allerdings bringt es nichts jemandem zu erklären wie er unnötige If-Abfragen einsparen kann, wenn er noch nicht einmal so genau versteht was If-Abfragen überhaupt sind.)


    Zitat

    - Wichtig wäre darauf hinzuweisen dass das was du im Video als Beispiel getan hast prinzipiell falsch ist. Denn die repr-Node eines Rades darf nicht skaliert werden - weder im GE noch im späteren Spielverlauf. Wenn du die Räder im Spielverlauf skalieren möchtest, solltest du die driveNode dafür verwenden. Also eine tiefer liegende Node - ansonsten gibt es probleme mit der Physik.


    Da die Physik nur ein mal in Verbindung mit der repr-Node kommt, nämlich beim laden des Traktors, und da das Scalen auch die Position des repr-Node an sich nicht verändert, und da die Skalierung des repr-Node für die Physik des LS keine Bedeutung hat sollte es hier zu keinen Problemen kommen. Ebenso ist repr-Node und driveNode bei sämtlichen Hinterrädern ein und der selbe Index.


    Zitat

    - mich wundert das dir nicht aufgefallen ist das dein Traktor einen Fehler in die log hätte werfen müssen - wegen der skalierten Räder.


    Hätte es einen Error gegeben hätte ich das Video nicht hoch geladen ;) Habe es aber trotzdem eben noch einmal probiert, zur Sicherheit. Kein Error nach Skalieren der Räder :)


    Zitat

    - Ergänzend würde ich - um Redundanzen zu vermeiden - einfach auf die direkten Variablen der Wheels - also self.wheels[2].driveNode und self.wheels[3].driveNode zurück greifen anstatt eine eigene Variable dafür zu verschwenden. Allerdings ist mir durchaus bewusst dass dies nur zu Beispiel-Zwecken diente.


    Das stimmt natürlich, aber ich wollte so viel Info wie möglich in das Video packen.. Darum die Index-Abfrage über XML.



    Zitat

    Sehr amüsant der Ausflug in die Grundlagen der Mathematik


    Sorry... Mit Mathematik kann ich leider wirklich nicht dienen, da fehlt mir das meiste Wissen. Vielleicht bin ich nicht der best geeignete für ein Video-Tutorial zum Thema LUA, aber ich bin wohl der einzige der es macht.



    Zitat

    - ich würde in einem zukünftigen Tut auf die Verwendung von Utils.getNoNil hinweisen. Insbesondere wenn die aus der XML ausgelesenen Werte für mathematische Operationen verwendet werden.


    Werde ich im nächsten Tutorial einbringen ;)




    LG

  • modelleicher: ich hoffe du verstehst das ganze nicht als wilde Kritik an deinen Videos. Ich respektiere natürlich die Arbeit die du dir gemacht hast und finde das auch ganz toll. Meine Kommentare sind eher als Tipps oder Anregungen zu verstehen was man evtl. anders machen/sagen könnte.


    Bzgl. der Räder.. spätestens beim 3. video wo die Räder von vornherein skaliert waren, hätte ein Fehler beim Laden des Traktors kommen müssen. Ausserdem werden die Räder nicht nur beim Laden berücksichtigt sondern sie werden permanent aktualisiert. Skalierte Räder haben ein unvorhersehbares physikalisches Verhalten - das kann zu seltsamen Effekten führen die man später möglicherweise nicht mehr ihrer eigentlichen Ursache zuordnen kann.


    Genau wie die performance Geschichte ist es sinnvoll manche Dinge von Anfang an zu berücksichtigen auch wenn man es erstmal einfach halten möchte - so vermeidet man möglicherweise zukünftige Fehler. In der Fahrschule bekommst du beigebracht was du an deinem Fahrzeug alles zu warten und zu prüfen hast - noch bevor du überhaupt ein eigenes Auto hast , geschweige denn fahren kannst. Aber manche Dinge sollte man den Leuten nunmal von Anfang an beibringen - denn auch Kleinigkeiten wie ein läppischer Liter Bremsflüssigkeit können bei 200kmh den Unterschied zwischen Leben und Tot ausmachen. Unterschätze niemals den Konsequenzen einer einzelnen Handlung.


    Bezüglich der Performance hatte ich deswegen auch extra erwähnt dass dies vor allem bei MP Anbindung wichtig wird. Glaube mir - ich habe für LS11 schon mehr als genug (weit über 20 Spezis ) gesehen , die via Update() Routine Syncronisierungen 30x pro Sekunde auslösen. Da reicht ein solcher Mod um den MP lahm zu legen und dann wundern sich die Leute warum sie die Hälfte der Maschinen nach dem Sync nicht sehen können oder warum ihre Log voll ist mit "Packet not received"


    Wie gesagt - nur Ansatzpunkte und Hinweise. Ich möchte wirklich nicht kritisieren - ich weiss wie aufwändig es ist so ein Tutorial zu entwerfen - erst recht als Videotut.

  • Kritik ist durchaus Ok, ganz im Gegenteil. Habe ja explizit danach gefragt, mit dem vorstellen der Videos hier im Thread.. :) Darum immer her mit den Anregungen..
    Nur bei ein paar Dingen kann ich dir beim besten Willen nicht zustimmen ;)


    Zitat

    Bzgl. der Räder.. spätestens beim 3. video wo die Räder von vornherein skaliert waren, hätte ein Fehler beim Laden des Traktors kommen müssen.


    Hab es noch einmal überprüft, exakt die LUA aus dem dritten Video. Kein Fehler, kein Error, keine Probleme Ingame.


    In Zeile 152 der vehicle.lua wird wheel.driveNode = wheel.repr gesetzt, falls driveNode nicht in der XML angegeben ist. (Was in 99% der Fälle bei Hinterreifen so ist. DriveNode braucht man nur wenn man Kotflügel hat die mitlenken..)
    In Zeile 157 wird die Translation von wheel.repr abgenommen, und fortan in den Variablen positionX, positionY und positionZ gespeichert.
    In Zeile 176 wird dann mit diesen Werten, der Node dem die Reifen untergeordnet sind, spring, damper usw. ein wheelShape erstellt.


    Fortan wird die Physikalische Berechnung des Reifens komplett über das wheelShape abgewickelt, das zwar an der Position des eigentlichen Rades erstellt wurde, aber im Grunde nichts mehr damit zu tun hat. Der eigentliche repr wird, sofern driveNode nicht vorhanden ist, ab da nur noch in rotation und translation verändert, Um der Federwirkung der wheelShapes zu folgen, und um das drehen der Reifen zu simulieren..
    Wie das ganze sklaliert ist ist dabei aber völlig wurscht.. Ebenso ob man nun driveNode oder repr verändert ;)


    Sollte ich da komplett falsch liegen dann sage mir das bitte.. Aber so ist wie ich das ganze verstehe. ?



    Zitat

    Genau wie die performance Geschichte ist es sinnvoll manche Dinge von Anfang an zu berücksichtigen auch wenn man es erstmal einfach halten möchte - so vermeidet man möglicherweise zukünftige Fehler. In der Fahrschule bekommst du beigebracht was du an deinem Fahrzeug alles zu warten und zu prüfen hast - noch bevor du überhaupt ein eigenes Auto hast , geschweige denn fahren kannst.


    Aber ich denke in der Fahrschule bekommt man nicht gleich am ersten Tag gezeigt wie man das Auto warten und prüfen muss, oder?
    Du hast sicherlich Recht, dass es nicht falsch ist von Anfang an auf gewisse Dinge zu achten. Allerdings möchte ich die Leute auch nicht gleich total verwirren.. Zumindest mir hat es am Anfang zum Verständnis meiner eigenen LUA's geholfen, dass ich so Dinge wie if x == true then eben ausgeschrieben habe, und nicht if x then,
    und dass ich eben auch auf elseif gesetzt habe.. Das ganze basiert eben auch auf eigenen Erfahrungen, sicher kann man nicht immer von sich selbst auf andere schließen, aber ich denke der Weg ist trotzdem nicht schlecht.



    Zitat

    die via Update() Routine Syncronisierungen 30x pro Sekunde auslösen.


    Naja.. Dass man das vermeiden sollte dürfte denke ich so ziemlich jedem klar sein. Möchte ja in einem Video auch noch speziell auf die MP-Geschichten eingehen, da kann ich dann solche Dinge mit Sicherheit einbringen ;) Jedoch für das Grundverständnis erst einmal wie so eine Spezi aufgebaut ist, ist das erst einmal zweitrangig.



    So, nun hab ich dann aber trotzdem noch einmal eine Frage, die Performance betreffend.. Du sagst es wär nicht gut wenn der Reifen bei jedem Durchlauf skaliert würde.. Dann frage ich mich aber, warum alle Rotationen auf genau diese Art und Weise funktionieren. Zumindest die der Standart-LS-Scripte, und die in 99% aller Mods.
    Bestes Beispiel hierfür ist der Pflug und dessen Rotation... "http://ls-mods.de/scriptDocume…es/specializations/Plough"
    Im Grunde dürfte diese Methode doch total schlecht sein, weil der Pflug ständig rotiert wird, sobald man ihn am Traktor hat und drinne sitzt..


    Hier mal wie ich die Rotationsanimation einer Knickdeichsel, die dann ja eigentlich "besser" sein sollte?
    [expander][lua]
    function Knickdeichsel:update(dt)
    -- Sorgt dafü, dass die Deichsel beim Spielstart richtig gestellt wird.
    if self.kdDoRotCheckAfterLoad then
    self:doRot(nil, 0, self.kdCurRot, 0, true, self.kdJointNumber)
    self.kdDoRotCheckAfterLoad = false;
    end;
    -- Tastenevent für die Deichsel
    if self:getIsActiveForInput() then
    if InputBinding.hasEvent(InputBinding.KNICKDEICHSEL) then
    self:setState(not self.kdCurrentState, true)
    end;
    end;

    -- Position der Deichsel wird festgelegt
    if self:getIsActive() then
    if self.kdDoRot == true then
    if self.kdMinRot < self.kdMaxRot then -- Positiv
    if self.kdCurrentState == false then -- zu MinRot
    if self.kdCurRot > self.kdMinRot then
    self.kdCurRot = math.max(self.kdCurRot - dt*0.005, self.kdMinRot);
    else
    self.kdDoRot = false;
    end;
    elseif self.kdCurrentState == true then -- zu Maxrot
    if self.kdCurRot < self.kdMaxRot then
    self.kdCurRot = math.min(self.kdCurRot + dt*0.005, self.kdMaxRot);
    else
    self.kdDoRot = false;
    end;
    end;
    elseif self.kdMinRot > self.kdMaxRot then -- Negativ
    if self.kdCurrentState == false then -- zu MinRot
    if self.kdCurRot < self.kdMinRot then
    self.kdCurRot = math.min(self.kdCurRot + dt*0.005, self.kdMinRot);
    else
    self.kdDoRot = false;
    end;
    elseif self.kdCurrentState == true then -- zu Maxrot
    if self.kdCurRot > self.kdMaxRot then
    self.kdCurRot = math.max(self.kdCurRot - dt*0.005, self.kdMaxRot);
    else
    self.kdDoRot = false;
    end;
    end;
    end;
    end;
    if self.kdDoRot == true then
    self:doRot(nil, 0, self.kdCurRot, 0, true, self.kdJointNumber)
    end;
    end;
    end;


    function Knickdeichsel:doRot(index, rotX, rotY, rotZ, doRotJoint, jointNumber)
    if doRotJoint == true then
    local jointNode = self.componentJoints[jointNumber].jointNode;
    local jointIndex = self.componentJoints[jointNumber].jointIndex;
    setRotation(jointNode, Utils.degToRad(rotX), Utils.degToRad(rotY), Utils.degToRad(rotZ));
    setJointFrame(jointIndex, 1, jointNode);
    end;
    end;[/lua][/expander]


    Oder auch Mist, weil man mit dieser Methode wesentlich mehr If-Abfragen braucht? (Dass auch ein compJoint mit rotiert wird ist erst einmal zweitrangig.. )




    LG

  • :thumbsup: Dankle für deine Mühe das du so ein tolles Video TUT gemacht hast, finde ich echt spitzen mäßig!


    Was mir nur etwas Probleme macht ist die Lautstärke, ich habe selber keine zusätzlichen lautsprecher am PC angeschlossen, wenn ich nun den monitor auf volle lautstärke stelle und bei youTube auch voll aufziehe habe ich noch immer echt problem dich zu verstehen.


    Wenn du das bei (hoffentlich) weiteren teilen ändern könntest, also das die lautstärke beim aufnehmen größer ist,wäre das echt toll. Leiser stellen ist ja hinterher kein problem.


    Danke nochmal!!!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!