Animationen in OpenSim, Teil 1: Animation Override (AO)

Animation Overrides sind die Antwort der Second-Life-Nutzerschaft auf die hölzernen, staksigen Bewegungen, die die Avatare normalerweise vollführen.

Was sie tun, ist eigentlich ganz einfach erklärt: Es gibt ja verschiedene Dinge, die ein Avatar tun kann, mit jeweils eigenen Animationen. Stehen, laufen, sitzen, auf dem Boden sitzen, springen, fliegen, schwimmen und so weiter. Die Standardanimationen dafür sind bombenfest im System eingebaut.

Nur sind sie eben nicht gut. Schon 2003, als Second Life startete, waren sie im Prinzip auch nur besser als nichts.

Ein Animation Override ist eine Kombination aus zwei Skripten, einer Notecard und einem Haufen Animationen. „Override“ sagt es ja schon: Er überschreibt diese Standardanimationen jeweils mit einer der Animationen, die mit ihm mitgeliefert werden. Oder gleich mit mehreren, die nacheinander durchgeschaltet werden, für mehr Variationen.

Dann hat man nicht mehr diese komische Standard-Stehanimation, die so aussieht, als wenn der Avatar gleich nach hinten umkippen würde, sondern ein halbes Dutzend sehr viel schickere, sehr viel natürlichere Animationen. Auch mehr oder weniger alles andere wird durch die mit dem AO mitgelieferten, schöneren Animationen ersetzt. Einige AOs machen sogar von Bento Gebrauch und steuern auch die einzelnen Finger an den Händen an. Ganz wenige gehen bei Bento sogar so weit, auch die Gesichtsmimik mit einzubeziehen.

ZHAO vs. khAOs vs. Viewer-AO

Es gibt drei Arten von AO, die in Funktionsweise und Handhabung unterschiedlich sind:

ZHAO: Kennt fast jeder, nutzt fast jeder, überlastet die Gridserver

Eine schlechte Nachricht vorweg: Die allermeisten AOs, die man im Hypergrid vorfindet, sind komplett aus Second Life geklaut und wurden da von Vista Animations erschaffen. Die wohl einzigen legalen Fertig-AOs sind Rugged für Männer und Sweetness für Frauen, die Shandon Loring aus zusammengeklaubten legalen Animationen, unter anderem von Linda Kellie, gebaut hat. Woher der das Kernskript hat, weiß ich nicht, aber im allgemeinen kann man aus Second Life keine Closed-Source-Skripte klauen. Die Animationen wirken allerdings ziemlich robotermäßig im Vergleich zu den Motion-Capturing-Animationen aus Second Life.

Das System, das diese AOs verwenden, nennt sich ZHAO. Wer überhaupt AOs kennt, kennt fast ausnahmslos nur das. Das heißt, die Leute wissen meist nicht, was für eine Technologie hinterm AO steckt, es ist ihnen auch egal. Aber in den allerallermeisten Freebie-Stores gibt es nur immer dieselben ZHAO-AOs.

In der Handhabung sind sie denkbar einfach: Der AO ist ein winzigkleines Objekt, das man sich an den Avatar hängt. Und schon läuft er. Schon bewegt sich der Avatar viel schöner. Man braucht sonst nichts zu machen. Das heißt, ein paar AOs haben dazugehörige HUDs, die man sich extra anhängt, mit denen man den AO steuern kann.

ZHAO hat aber einen riesengroßen Nachteil, der auf Beschränkungen in der Second-Life-Skriptsprache LSL zurückzuführen ist: Es verursacht eine immense Serverlast.

Irgendwoher muß der AO ja wissen, wann welche Animation abzuspielen ist. Also quengelt er herum und fragt beim Gridserver an: „Sitz’ ich? Sitz’ ich? Sitz’ ich? Sitz’ ich? Sitz’ ich?“ Und zwar etwa zehnmal pro Sekunde. Pro Animation. Insgesamt also ca. 250× pro Avatar und pro Sekunde. Das ist wie ein Kind, das auf einer Reise ständig fragt: „Sind wir schon da? Sind wir schon da? Sind wir schon da? Sind wir schon da?“ Nur daß Kinder das nicht zehnmal in der Sekunde fragen.

Jedes Mal muß der Server antworten: „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ Auch das ca. 250× pro Avatar und pro Sekunde.

Erst wenn auf die Frage „Sitz’ ich?“ ein „Ja“ kommt, geht der Avatar von einer der Stehanimationen zu einer der Sitzanimationen über. Damit hört aber nicht das Gequengel auf, denn weiterhin will der AO für jeden einzelnen Zustand wissen, ob er gerade aktuell ist. Auch wenn der Avatar sitzt, will der AO weiterhin wissen, ob der Avatar (immer noch) sitzt. Und ob er steht und ob er auf dem Boden sitzt und ob er läuft und ob er schwimmt und so weiter.

Die Belastung des Servers durch einen einzelnen Avatar kann man getrost vernachlässigen. Aber jetzt stelle man sich mal ein richtig großes Event vor. Nicht gerade den OSCC, da werden Avatarskripte und damit auch alle angehängten AOs unterbunden. Man stelle sich eher vor, ein großes, populäres Grid eröffnet eine neue Sim mit einer fetten Party. Oder noch schlimmer, eine Hochzeit. Und Avatarskripte werden nicht blockiert.

Da kommen dann 50 Avatare mit ZHAO-AOs. Zusätzlich zur himmelhohen Avatar-Komplexität – fast niemand kennt die Komplexität des eigenen Avatars – kommen also diese Skripte, die den Server mit Anfragen bombardieren. Über 12.000× pro Sekunde! Und der Server muß jedes Mal antworten – auch wieder über 12.000× pro Sekunde.

Und dann wundern sich die Leute, warum die Sim laggt von extrem langsam ladenden Objekten über schweren Chatlag bis hin zu massiven Bewegungsschwierigkeiten. Oder warum die Sim gleich mitten in der Party ganz abstürzt. Schuld hat dann der Simbetreiber. Oder der Gridbetreiber. Oder wenn beide jegliche Schuld von sich weisen und mit dem Finger auf die Nutzer zeigen, waren es mal wieder die anderen. Was auch immer die gemacht haben. Aber irgendwas müssen die ja gemacht haben. Man selbst hat auf jeden Fall gar nichts gemacht. Glaubt man.

Und selbst wenn: Man kann ja sonst nichts machen, außer ganz auf einen AO zu verzichten. Glaubt man.

Viewer-AO: Eigeninitiative zur Serverentlastung

Dabei ginge es auch anders. Man muß sich einen AO nicht zwingend als geskriptetes Objekt an den Avatar hängen und damit auf den Server einprügeln.

Man kann das auch im Viewer stattfinden lassen. Gute Viewer bieten nämlich die Möglichkeit, AOs aus dem Viewer heraus auszuführen. Man kann sich im Viewer seinen eigenen AO zusammenbauen, man kann aber auch fertige AOs importieren. Dabei sieht man den AO nicht nur selbst, sondern alle anderen sehen den auch.

Der große Vorteil ist, daß der AO nicht mehr beim Server herumquengelt. Er wird nun dadurch gesteuert, daß der Viewer sagt: „Du sitzt jetzt.“ Oder: „Du schwimmst jetzt.“ Je nachdem eben. Die Serverbelastung durch den AO schrumpft auf ziemlich genau null. Wenn das alle machen würden, hätte man auf Partys sehr viel weniger Lag.

Ein schöner Nebeneffekt ist, daß die AOs im Viewer viel einfacher zu handhaben sind als per Avatar-Anhängsel. Sagen wir, du mußt für irgendwas deinen AO abschalten. Normalerweise mußt du ihn ganz vom Avatar abnehmen. Wenn du ihn wieder benutzen willst und ihn nicht unter deinen Favoriten abgelegt hast, darfst du ihn erst aus dem Wuhling heraussuchen, zu dem dein Inventar mit der Zeit geworden ist. Wenn du ihn irgendwann gefunden hast, mußt du ihn an den Avatar wieder dranhängen. Dann darfst du warten, bis das Ding gerezzt und sein Inhalt geladen ist.

Den Viewer-AO kannst du mit einer Schaltfläche im Viewer ausschalten. Und wieder einschalten. Wenn der Viewer gut eingerichtet ist, ohne jegliche Menütaucherei. Standardmäßig ist nämlich die AO-Schaltfläche weder im Firestorm noch im Singularity sichtbar – wahrscheinlich, weil die meisten sie nicht brauchen, weil eh „alle“ mit ZHAO-AOs oder ganz ohne AO herumlaufen. Dadurch wissen viele aber nicht, daß man AOs auch im Viewer laufen lassen kann.

Auch das Wechseln des AO ist im Viewer einfacher: Man muß nicht erst das Inventar durchwühlen. Für die AO-Steuerung im Viewer gibt’s ein eigenes Menü, über das man einen der im Viewer eingebauten AOs auswählen kann.

Vor- und Nachteil gleichzeitig sind die Einstellmöglichkeiten, die noch dazu je nach Viewer verschieden sind: Einerseits kann man z. B. einstellen, ob automatisch zwischen verschiedenen Animationen desselben Typs gewechselt werden soll, ob in fester oder zufälliger Reihenfolge, und wie lange jede Animation laufen soll. Andererseits kann der Viewer nicht selbständig erkennen, wie lange die Animationen laufen. Das muß man selbst ermitteln (geht im Firestorm erst seit Version 6.4 und in anderen Viewern überhaupt nicht) und dann eine entsprechende Zeit händisch einstellen.

Was man auch noch einstellen kann, ist, wie sich die Sitzanimationen im Sitzen verhalten. Man hat drei Möglichkeiten: Entweder werden die Sitzanimationen des AO im Sitzen nie ausgeführt. Oder sie werden immer ausgeführt, auch wenn vom Objekt, auf dem man sitzt, schon eine Animation zur Verfügung gestellt wird (außer die so zur Verfügung gestellte Animation hat eine höhere Priorität). Oder sie werden immer ausgeführt, außer wenn vom Objekt, auf dem man sitzt, eine Animation zur Verfügung gestellt wird.

Nachteilig ist gegenüber dem angehängten AO aber die kompliziertere, unbequemere Handhabung vor der Inbetriebnahme. Da hat man ganz offensichtlich schon vor einer geschriebenen Anleitung kapituliert und statt dessen ein Video auf YouTube zur Verfügung gestellt.

Wie man AOs in den Viewer einbaut

Der erste Schritt ist, den AO selbst zu rezzen, also irgendwo in die Landschaft zu packen, wo man das darf. Da stellt er sich dar als, wie gesagt, winzigkleines Objekt. Es hilft ungemein zu wissen, wie er aussieht, sonst findet man ihn womöglich gar nicht. Dann öffnet man ihn und packt den Inhalt ins eigene Inventar aus. Die Vorgehensweise ist also dieselbe, wie wenn man eine Verkaufsbox rezzt und auspackt, nur mit einem sehr viel kleineren Objekt.

Der zweite Schritt ist, den AO in den Viewer zu holen. Dafür öffnet man zunächst das AO-Fenster. Dann sucht man sich im Inventar den ausgepackten AO. In dem gibt es eine Notecard, die die Funktionen des AO beschreibt. Die zieht man ins AO-Fenster. Welche Notecard das ist, erkennt man daran, ob der AO in den Viewer importiert wird oder nicht. Manche AOs sind eigentlich mehrere AOs in einem und enthalten mehrere solche Notecards. Die kann man dann alle nacheinander in den Viewer importieren, die liegen dann jeweils als eigenständige AOs vor.

Als drittes wird der AO dann – optional, sollte man aber in Erwägung ziehen – eingestellt. Verhalten beim Sitzen, automatisches Durchschalten der Animationen, oder wenn nicht, welche der verschiedenen Animationen man verwenden will, und so weiter.

Der Firestorm hat übrigens den Vorteil, daß man das nur einmal für alle zusammen machen muß, weil die Einstellungen nebst Animationen im Inventar gespeichert werden. Egal, wieviele Firestorm-Installationen man hat, die AO-Einstellungen sind immer gleich. Andere Viewer wie Singularity bieten diesen Komfort nicht, da muß man den zweiten und dritten Schritt einmal pro Viewer machen wenn man mehrere hat.

khAOs: OpenSim-Spezialität, so bequem wie ZHAO bei viel geringerer Serverlast, kennt aber keiner

Daß man überhaupt AOs direkt im Viewer nutzen kann, weiß aber kaum jemand. Wie das geht, erst recht nicht. Und von denen, die davon schon mal gehört, sind sich viele zu bequem und/oder zu unsicher in der Handhabung des Ganzen. Die bleiben lieber bei AOs, die man sich ganz einfach aus dem Inventar an den Avatar hängt. Die haben ja auch den Vorteil, daß man sie mit Outfits abspeichern kann. In Alltagskleidung bewegt sich der Avatar dann anders als im Abendkleid.

Als „Retter“ kam dann der Mann daher, der in OpenSim auch schon der Titanic das Sinken beigebracht hat: Kayaker Magic. Der schrieb ein neues Kernskript für die Anhäng-AOs. Und er schrieb es in OSSL. Das Ergebnis nannte er „khAOs“ und brachte es im August 2020 offiziell heraus.

OpenSim hat hier nämlich einen gewaltigen Vorteil gegenüber Second Life: Der Server teilt proaktiv dem Avatar mit, was letzterer gerade tut. Der Avatar muß gar nicht erst nachfragen. Entsprechend gibt es in OSSL die Möglichkeit, diese Mitteilungen in Skripten zu nutzen.

Statt also immer und immer und immer wieder zu fragen: „Sitz‘ ich?“ und auf die Antwort des Servers zu warten, tut das Skript zunächst einmal überhaupt nichts. Wenn sich nun ein Avatar hinsetzt, schickt der Server ihm die Nachricht: „Okay, du sitzt jetzt.“ Nur auf dieser Grundlage schaltet der Avatar dann um auf eine andere Animation (oder mehrere, je nachdem).

Für den Nutzer ändert sich durch khAOs grundsätzlich überhaupt nichts. Der AO handhabt sich genau wie die AOs, die man schon kennt: an den Avatar hängen und läuft. Einen Unterschied gibt es nur, wenn man schon einen Viewer-AO laufen hat und jetzt z. B. einen Rollschuh-AO, Schlittschuh-AO, Ski-AO oder dergleichen nutzen will, der auf khAOs umgebaut ist. Dann muß man nämlich den Viewer-AO so lange abschalten. (Oder man packt sich auch diesen zweckgebundenen AO in den Viewer.)

Gegenüber den ZHAO-AOs, die man fast überall in Freebie-Stores findet, sinkt die Serverbelastung durch khAOs-AOs auf nahe null. Das Gequengel fällt ja weg. Wenn auf einer Party mit 50 oder mehr Avataren viele einen khAOs-AO haben, hat man nicht mehr eine größere vierstellige Anzahl Anfragen pro Sekunde an den Server, der die alle beantworten muß. Wenn alle als Anhäng-AO einen auf khAOs-Basis haben, hat man auch mal minutenlang gar keine mehr, weil niemand den Zustand seines Avatars ändert, weil alle ihre Avatare auf der Line-Dance-Tanzfläche geparkt oder an den Clubmaster gehängt haben.

Jetzt gibt es aber zwei neue Probleme. Beide gehen darauf zurück, daß keine Sau weiß, daß khAOs existiert. Zum einen gibt es ziemlich genau null Nachfrage nach khAOs-AOs. Zum anderen ist bis jetzt wohl nur Cataplexia Numbers auf die Idee gekommen, sich mal die ganzen geklauten AOs vorzunehmen und auf khAOs umzubauen. Ich meine, der Umbau an sich ist simpel, man muß nur das Kernskript durch ein anderes ersetzen. Aber das macht eben keiner. Und auch Cat hat ihre umgebauten AOs alle in eine neutrale Sammelbox geschmissen und die irgendwo in ein oder zwei ihrer Sims versenkt, statt jeden AO einzeln in seiner eigenen bunten Box an die Wand eines populären Freebie-Store zu hängen. Ansonsten bietet nur Kayaker Magic selbst die Rugged- und Sweetness-AOs als khAOs-Umbauten an.

Wie man einen AO von ZHAO auf khAOs umbaut

Vielleicht ist ja jetzt jemand am Umbau in Eigeninitiative interessiert. Vielleicht hat jetzt sogar jemand vor, die vielen geklauten AOs, die man überall im Hypergrid in de Freebie-Stores findet, als khAOs-Versionen in den eigenen Freebie-Store zu hängen.

Wie gesagt: Der Umbau ist, wenn auch nicht ganz trivial, keine Raketenwissenschaft.

Falls man das Ganze jetzt in der modifizierten Originalschachtel weitergeben will, geht es hier weiter. Voraussetzung ist natürlich, daß man den AO schon auf khAOs umgebaut hat, daher zähle ich mit 8 weiter.

Wenn man Glück hat, kommen dann wieder Leute, die ihre eigenen neuen Freebie-Stores bauen wollen, und nehmen dafür genau diese umgebauten AOs mit. Dann kann sich das Ganze endlich weiter ausbreiten.

Second-Life-Nutzer, die das hier gelesen haben, muß ich enttäuschen: khAOs läuft nicht in Second Life. Ich schrieb ja schon, daß es in OSSL geschrieben ist und nicht in LSL. Und OSSL-Skripte funktionieren nicht in Second Life, nur in OpenSim.

#OpenSim #FürAnfänger #FürFortgeschrittene #FürSecondLifeUmsteiger #Animationen