Daemonika Nightfire: Viewer Lag, Skripte als Ursache

Daemonika Nightfire hat mir wieder einen Beitrag geschickt, den ich sehr interessant finde und daher veröffentliche. Danke Dae, dass du immer mal wieder etwas für mich schreibst. Die gesamten Beträge von Daemonika findet ihr gesammelt hier.

Daemonika

VIEWER-LAG, SKRIPTE ALS URSACHE

Einige von euch wissen, dass ich mich seit rund 18 Jahren intensiv mit dem Thema LAG in Second Life befasse und Techniken umsetze, um LAG zu vermeiden. Besonders in meinen eigenen Kreationen achte ich sehr genau darauf und berate regelmäßig Interessierte, deren Anliegen meist nicht unbegründet sind.

Auch heute sage ich immer noch: LAG ist die Summe des Ganzen. Es gibt unzählige Faktoren, die die Performance des Viewers negativ beeinflussen können. In diesem Beitrag konzentriere ich mich bewusst auf das Thema Skripte.

Jahrelang habe ich propagiert, dass Skripte sich nicht direkt auf den Viewer auswirken und dass die reine Anzahl von Skripten keinen Rückschluss darauf zulässt, ob ein Objekt LAG verursacht. Diese Aussage muss ich heute, im Jahr 2026, teilweise revidieren.

Die Anzahl allein erlaubt nach wie vor keine direkten Rückschlüsse. Entscheidend ist mittlerweile, was die Skripte tatsächlich tun. Je nach Art der Skript-Aktionen können sie sich indirekt auf die Viewer-Performance (FPS) auswirken.

Ein Skript selbst läuft immer serverseitig im Simulator und belastet zunächst nicht den Viewer. Die Auswirkungen bestimmter Skript-Aktionen jedoch, insbesondere häufige Objekt-Aktualisierungen, können die Performance des Viewers messbar negativ beeinflussen.

OBJEKT-UPDATES UND IHRE AUSWIRKUNGEN AUF DEN VIEWER

Ständige Veränderungen von Objekten wie Textur- oder Farbwechsel, Hovertext-Aktualisierungen sowie Größen-, Positions- oder Formänderungen müssen vom Viewer neu verarbeitet und dargestellt werden. Das ist kein Nebeneffekt, sondern erzeugt realen Rechenaufwand.

Während vor 10 bis 15 Jahren viele Viewer überflüssige oder häufige Updates stillschweigend verworfen oder zusammengefasst haben, reagieren heutige Viewer im Zusammenspiel mit EEP, PBR und modernen Renderpipelines deutlich sensibler auf jede Änderung.

Aus diesem Grund verwende ich bei Boards, HUDs und ähnlichen Systemen bewusst einen 1-Sekunden-Timer. Ein Event einmal pro Sekunde ist in der Regel unkritisch. Das relativiert sich allerdings sofort, wenn viele Objekte oder mehrere solche Systeme gleichzeitig aktiv sind.

(Erklärung: Ein Event ist ein Ereignis, das dem Skript signalisiert: "Jetzt musst du aktiv werden!" Der Server ist derjenige, der dieses Ereignis überwacht und dem Skript dann die Rechenzeit zuteilt, um darauf zu reagieren.) 

Ein Skript, das in vorgetäuschter Echtzeit permanent Objektparameter verändert, bremst den Viewer zwangsläufig aus.

SKRIPT-KOMMUNIKATION UND UNSICHTBARE LAST: TECHNISCHE EINORDNUNG

Ein häufiger Irrtum ist die Annahme, dass Skript-Kommunikation über private Kanäle (Channels) direkt vom Viewer verarbeitet wird. Das ist technisch falsch.

Alle llListen-Events sowie die komplette Chat-Verteilung auf privaten Kanälen finden ausschließlich serverseitig im Simulator statt. Der Viewer empfängt weder private Chatnachrichten noch Listen-Events und verteilt auch keine Skript-Events an andere Skripte. Skripte laufen vollständig unabhängig vom Viewer.

Private Kanäle belasten daher nicht direkt den Viewer, sondern ausschließlich den Simulator.

WOHER KOMMT DANN DER WAHRGENOMMENE VIEWER-LAG?

Der entscheidende Punkt ist die Folgewirkung intensiver Skript-Kommunikation. Wenn viele Skripte untereinander über Kanäle kommunizieren, entstehen unter anderem:

• Eine hohe Skript-Event-Dichte im Simulator.
• Verzögerungen in der Skript-Ausführung und Event-Verarbeitung (Script Lag).
• Häufigere oder gebündelte Objekt-Updates als direkte Folge der Skript-Logik.

Sobald ein Skript als Reaktion auf diese Kommunikation Objektparameter verändert – etwa Positionen, Rotationen, Farben, Materialien (PBR), Hovertext, Alpha-Werte, Texturen oder Sounds –, müssen diese Änderungen an alle relevanten Viewer übertragen werden. Erst an diesem Punkt entsteht Viewer-Last.

Der Viewer verarbeitet also nicht die Chat- oder Listen-Events selbst, sondern ausschließlich die daraus resultierenden Änderungen am Objektzustand.

UNSICHTBARE LAST MIT SICHTBAREN FOLGEN

In der Praxis äußert sich das so: Ein System mit intensiver interner Skript-Kommunikation kann auf den ersten Blick harmlos wirken. Es ist kein Chat sichtbar, und keine offensichtlichen Effekte sind zu sehen. Trotzdem können im Hintergrund permanent Objektzustände aktualisiert werden.

Diese Updates erreichen den Viewer oft gebündelt oder in hoher Frequenz und erzeugen dort messbare Last. Das erklärt Situationen, in denen Nutzer berichten, dass Kamera, Maus oder Chat deutlich verzögert reagieren, obwohl augenscheinlich nichts passiert.

Die Ursache liegt dann nicht in den privaten Kanälen selbst, sondern in der Menge und Frequenz der daraus resultierenden Viewer-relevanten Updates.

MINI-BEISPIEL: INDIREKTE VIEWER-LAST DURCH SKRIPT-LOGIK

Ein Objekt enthält 250 Skripte, die über private Kanäle intensiv miteinander kommunizieren:

• Die Chat-Nachrichten und Listen-Events belasten ausschließlich den Simulator.
• Führt diese Kommunikation dazu, dass regelmäßig Objektparameter verändert werden, muss der Simulator diese Änderungen an alle Viewer senden.
• Der Viewer muss diese Updates verarbeiten, neu rendern oder neu synchronisieren.

Die Viewer-Last entsteht also indirekt – nicht durch die Nachrichten selbst, sondern durch deren Auswirkungen auf die Objekt-Eigenschaften.

Im Vergleich dazu ist eine Frisur aus dem Jahr 2010 mit 256 Flexi-Prims und je einem Skript pro Link oft vergleichsweise harmlos. Ein einzelnes modernes Skript hingegen, das mehrmals pro Sekunde objektwirksame Änderungen auslöst, kann den Viewer deutlich stärker belasten.

SKRIPTE, DIE SOUNDS ABSPIELEN

Nehmen wir ein einzelnes Skript, das regelmäßig Sounds abspielt: Die Belastung für den Viewer entsteht weniger durch das Skript selbst, sondern durch die Verarbeitung des Audiostreams.

Sobald ein Skript llPlaySound ausführt, muss der Viewer den Sound verarbeiten und wiedergeben. Ist der Sound noch nicht im lokalen Cache vorhanden, fordert der Viewer die Datei zusätzlich vom Asset-Server an. Das erzeugt zusätzliche Netzwerk-Last und Ladezeit.

Anschließend wird der Sound im Cache gespeichert, räumlich positioniert (3D-Audio), mit der Audio-Engine synchronisiert und abgespielt. Diese Schritte verursachen die eigentliche Viewer-Last, nicht die bloße Skript-Ausführung im Simulator.

In der Praxis zeigt sich das deutlich: Viele gleichzeitig abgespielte Sounds bremsen den Viewer merklich aus, während die gleiche Anzahl an Skripten ohne Audio-Ausgabe kaum spürbaren LAG verursacht.

FAZIT

Wer Viewer-LAG vermeiden will, muss bei Skripten auf die Aktionen achten, nicht auf die Anzahl.

• Private Kanäle (Channels) und llListen erzeugen keinen direkten Viewer-LAG.
• Viewer-LAG entsteht durch objektwirksame Änderungen, Sounds und andere darstellungsrelevante Effekte.
• Intensive Skript-Kommunikation kann indirekt starken Viewer-LAG verursachen, wenn sie häufige Updates auslöst.

Praktisch bedeutet das:

• Skripte effizient gestalten und unnötige Events vermeiden.
• Zu schnelle Wiederholungsraten (Timer-Intervalle) kritisch hinterfragen.
• Alles, was der Viewer verarbeiten muss, kostet Leistung – egal, ob es offensichtlich sichtbar ist oder nicht.

LG Dae