Lag auf den meisten Sims hausgemacht

Roya Congrejo schrieb:

Das kann man angeblich hier sehen: Find your sim neighbor in Second Life
Aber k.A. ob das wirklich funzt - müsste ja bei jeden Sim-Restart und etwaiger Serververlagerung neu aktualisiert werden...

Zum Vergrößern anklicken....

Ich denke, dabei kann man davon ausgehen, je aktueller das Datum, desto eher stimmt es.

Stiftung Lagtest unterwegs... man sieht ja den Namen des Servers unter "Hilfe" und dann "Über Second Life...", und natürlich gelten die Daten nur für Stand gerade jetzt, da das alles sich ständig ändern kann...

Port Lydius:
sim4242.agni.lindenlab.com (216.82.4.203:12035)

Es spuckt zwei Nachbarn aus, SHIKOKU und Linden Estate Services3, wobei bei Shikoku das Datum aktüller ist.

Shikoku:
sim4897.agni.lindenlab.com (216.82.63.108:13001)

Passt also nicht.

Linden Estate Services 3:
sim4897.agni.lindenlab.com (216.82.63.108:13000)

Also zeigt das bisher nicht den Nachbarn von Port Lydius an. Nett.

Scagnar:
sim2308.agni.lindenlab.com (216.82.57.59:13001)

Das liefert als Möglichkeiten Fairchang Balboa, Lovely Rita, Eternal Creations und Adixxion. Mal der Reihe nach auf der Webseite...

Eternal Creations:
sim5780.agni.lindenlab.com (216.82.51.82:13000) - passt nicht.

Lovely Rita - Region nicht mehr existent.

Adixxion:
sim2308.agni.lindenlab.com (216.82.57.59:13002) - Treffer, passt.

Fairchang Balboa:
sim2308.agni.lindenlab.com (216.82.57.59:13000) - Treffer, interessant, da kann ich zu Fuß hinlatschen, aber... egal.

Netterweise findet er manche Sims, die schon lange dabei sind wie Torcodino gar nicht. Mh.

Sim: Xcess Adventure
sim4661.agni.lindenlab.com (216.82.19.38:13002)

Sex4All:
sim4661.agni.lindenlab.com (216.82.19.38:12035) - passt

Campos da Jordao:
sim4661.agni.lindenlab.com (216.82.19.38:13001) - passt auch, eine recht fette RP-Sim.

Snatch City:
sim4661.agni.lindenlab.com (216.82.19.38:13000) - passt ebenfalls.

Bei den Stichproben ist es so zu 1/3 in etwa brauchbar. Naja, damit das ein wirklich richtig gutes Hilfsmittel wird, müsste es viel häufiger aktualisieren, denke ich, viele Sims scheinen gar nicht in der Datenbank vorhanden zu sein und die Leichen sind noch nicht entfernt, er zeigt nicht immer längst alle Nachbarn an.

Ach jo, hier hat es noch einen Eintrag in der SL-Knowledgebase, wie man als Simowner die Performance erhöhen kann. Vielleicht ist das ja noch für den einen oder anderen interessant, da steht aber im Prinzip nichts anderes drin, als eh dauernd die Runde macht.

SIM Per: Core CPU
OpenSpace 4 8
Homestead 4 8
Estate 1 2
Mainland 1 2

Zum Vergrößern anklicken....

und was heisst das?

Zwei Mainland Sims auf einem Server?

Kila Shan schrieb:

und was heisst das?

Zwei Mainland Sims auf einem Server?

Zum Vergrößern anklicken....

Selbst mit den Class 4 Servern (AMD Opteron) waren schon 4 Sims auf einem Server. (Zwei Sims pro CPU und 500MB RAM pro Sim.)

Mittlerweile haben die Server 2 Intel 5148 (Dualcore) Prozessoren und jeder Server verwaltet 4 Sims. Einen Sim pro CPU Core. Und 1GB RAM pro Sim.
Ist ein bisschen missverständlich ausgedrückt auf der Webseite.

Zudem sind in der Datenbank lediglich 18523 von über 24000 Sims eingetragen, d.h. man kann zwar daraus ableiten, dass man die und die Sim mal als Nachbar hatte und eventuell immer noch hat - aber kein Treffer in der Datenbank bedeutet eben nicht dass man keinen Nachbarn hat...


Und was die Script Zeit angeht:
Das TOP-Fenster zeigt nur eine Momentaufnahme eines Frames an.

D.h. es kann durchaus sein, dass dort mal ein Script mit 20ms Rechenzeit auftaucht, sogar über 3 oder 4 Snapshopts - und das Script macht eigentlich überhaupt keinen Lag, weil es nach wenigen Sekunden wieder keinen Mucks rechnet und auf einen touch Event wartet.

Andererseits kann das Tolle "low lag" Radar, das lediglich alle 7s einmal im Umkreis von 96m nach gescripteten Objekten, Avas usw. sucht und das in mehreren Listen abarbeitet und umrechnet um es auf dem HUD schön präsentieren zu können, dabei "unter den Tisch Fallen", einfach weil es in dem Moment, in dem es wirklich lag macht, nicht beobachtet wird. Aber es sorgt eben alle 7s dafür, dass die Sim nicht mehr mit 45FPS, sondern nur noch 35 FPS oder weniger läuft.

Kampagnen wie "Spieler! Kauft nicht bei UglyHair! UglyHair raus aus Gor Sims!" treffen so nicht nur den Falschen (und machen dessen Geschäft auch ausserhalb von Gor kaputt, denn wer kauft schon gern "lag Haare"...), sie schießen auch leider weit an der Ursache vorbei.

Es wird also höchste Zeit, dass da a) ein Script Limit kommt um zu verhindern, dass ein User mit seinen Scripts am Ava die Sims so ausbremsen kann, dass er 20 Leuten dort den Spass verdirbt und
b) dass LL endlich mal eine brauchbare Anzeige des Ressourcenverbrauchs einbaut...

Shirley Iuga schrieb:

Kampagnen wie "Spieler! Kauft nicht bei UglyHair! UglyHair raus aus Gor Sims!" treffen so nicht nur den Falschen (und machen dessen Geschäft auch ausserhalb von Gor kaputt, denn wer kauft schon gern "lag Haare"...), sie schießen auch leider weit an der Ursache vorbei.

Zum Vergrößern anklicken....

Sie sind aber derzeit immer häufiger eine Ursache von Lag und das nicht zu wenig.
Wer den Spielern nicht die Möglichkeit gibt die Resizerscripte entfernen zu können, der muss auch nicht länger laggy Sachen verkaufen, das ist doch ganz einfach und treffen in diesem Fall auch den Richtigen.

Daimos

...und damit hat Daimos absolut recht, solange man als Eigentümer nicht z.B. bei No-Mod-Sachen die Ausführung der Skripte anhalten kann.

[X] Unterschreib.

Dann wäre der nächste Schritt, mal seine Scanner und Radare rauszuschmeißen. Mystitool und wie sie nicht alle heißen.

Es gibt einen eingebauten Scanner in der Chatbox (strg+h) oben rechts ("<<" drücken)
Darin werden alle Avatare in Chatrange angezeigt, was sehr hilfreich ist, und das einzigste wofür man fairerweise einen Scanner braucht.

Ansonsten wenn man Leute 3 Sims weiter sehen will, sollte man auf Emerald umsteigen. Kommt aber nicht in Versuchung die Attachment POints doppelt zu belegen, nur weil ihr es könnt. Die ganzen in der Gegend herumfliegenden Armschienen und Gürtel wollen wir garnicht sehen, müssen es aber leider

Vielen Dank
Der Bademeister

Daimos Baarer schrieb:

Sie sind aber derzeit immer häufiger eine Ursache von Lag und das nicht zu wenig.
Wer den Spielern nicht die Möglichkeit gibt die Resizerscripte entfernen zu können, der muss auch nicht länger laggy Sachen verkaufen, das ist doch ganz einfach und treffen in diesem Fall auch den Richtigen.

Zum Vergrößern anklicken....

Jap, Resizer Scripte machen beim Resizen auf RP sims oft ein bisschen Sim lag.

Das vieldiskutierte Problem mit den Resizer Scripten an sich sind aber weniger die Scriptzeiten, sondern das ist der Speicherverbrauch bei 200 LSO-Scripten. (200 x 16KB = 3,1 MB, nur für die Resizer Slaves in den Haaren eines einzelnen Avas... bei 300MB für die ganze Sim)

Deswegen waren die z.B. auch Grund für die Script Limit Diskussion. Wobei der Speicherverbrauch, wenn man es richtig macht, dank Byte Code Sharing, auch minimal ist. Man muss eben nur wissen, dass man das Resizer Slave Script einmal als Mono kompilieren und dann einfach in die anderen Prims kopieren muss und danach das "Recompile all Scripts in selection" nicht mehr verwenden darf. (64kb shared code + z.B. 200 x 120 bytes für die Variablen und Konstanten in den einzelnen Scripten = 87kB, sollte also kein großes Problem mit dem Speicher mehr sein.)

Was wirklich lag beimResizen macht, das ist aber weniger das Script an sich als vielmehr das gleichzeitige Verändern von z.B. 200 mal z.B. 10 Primwerten = 2000 Werten (Größe, Position, etc.) im Attachment an einem Avatar über llMessageLinked. Das kann durchaus zu spikes von +40ms bis +50ms über ein paar Sekunden führen.

Die Sache ist nur, dass man normalerweise nicht ständig was resizen muss.
Das macht man einmal beim anpassen nach dem Kauf. Oder wenn man seinen shape geändert hat. Und danach machen diese Skripte normalerweise nix, bis eine weitere Linkmessage ankommt. Wobei das warten auf ein linkmessage-event nicht wirklich groß lag macht. Vor allem, wenn das main Script in den Haaren z.B. 2 min nach einem touch wieder in Standby geht und nix macht als auf einen touch zu warten.

Das, was auf den ganzen RP Sims aber meist lag macht, das sind eher die Gormeter, DCS-Combatmeter, die Waffen und zig Collars , Radarhuds, AOs mit listenern usw.

Nur machen die eben nicht die kurzen heftigen Spikes, die dann in den Top Script Listen auftauchen, die machen das immense "Hintergrundrauschen", das dafür sorgt, dass ein Resizer Script, das auf einer "normalen Wohnsim" keine großen Probleme macht, in einer RP Sim oder BDSM Sim lag auslöst.

Einfach weil die Sim normalerweise auf 45FPS = 22,3 ms gedrosselt ist und die 40ms zusätzliche Rechenzeit dann z.B. effektiv zu einer Framezeit von z.B. 45ms = 22FPs führt. Bisschen laggy, man kann sich aber noch bewegen und nach ein paar wenigen Sekunden ist es wieder vorbei. und die Sim ist wieder auf 45 FPS.

Auf der BDSM/RP Sim mit den ganzen Tools und HUDs und Spielzeugen läuft die Sim aber oft schon mit z.B. 25ms = 40FPS, minimaler Lag eben. Wenn da noch ein Spike von z.B. 40ms dazu kommt, dann liegt man schon bei z.B. 65ms = 15FPS, und wenn dann noch nicht nur 500, sondern z.B. 8000+ Scripte gleichzeitig was machen wollen, dann kann sein die Sim ist relativ lange auf unter 10 FPS. Was zusammen mit vielen Avas auf der Sim dann zu sekundenlangen Aussetzern im Downstream führen kann ("sim halt syndrome" - man kann sich nicht mehr bewegen und alles steht immer wieder kurz still).


Das Problem seh ich deswegen weniger in Resizerscripten (oder anderen Scripten, die kurze aber heftige Spikes machen) sondern eher in den Scripten, die ständig ein bisschen bis mittelmäßig viel lag machen. Die ganzen tollen Multitoys eben, mit Radar, Shield, Channelspy, etc. und eben nicht benötigte CombatHUDs, die trotzdem ständig funken. Collars, die auf channel 0 auf alles und jeden lauschen etc.

Im Prinzip ist das wie mit dem Strom im Haushalt:

Dein Küchenherd hat je nach Anschluss z.B. 3-4kW beim Kochen.
Aber er wird immer nur kurz verwendet, z.B. 30 min und den bisschen weniger oft zu verwenden oder einen Deckel auf den Topf zu legen beim Wasser kochen macht sich in der Stromrechnung weniger deutlich bemerkbar als z.B. seinen alten Fernseher, seinen alten Videorekorder, seinen alten Kaffeeautomaten etc. gegen neue Geräte auszutauschen, die dann statt jeweils 30W bis 70W nur noch 0.2W im Standby verbrauchen. Oder die sich gar mit einem echten Netzschalter ganz abschalten lassen.

Na ja, sorry, das ist in Teilbereichen aber ein wenig blauäugig. Sicher, Spitzen sind nicht soooo tragisch, meine GRP-Technik setzt ja selbst darauf, aber unterschätzen sollte man sie auch nicht.

Wichtiger indess: Wir alle wissen, das jedwede Art der Kommunikation auf Script-Ebene in SL extrem gefährlich sein kann. Und Fakt ist, dass es nun mal jede Menge freier Scripte gibt, die sich einen Dreck um Listener etc. scheren.

Zum anderen Punkt, dem der ständig Lag machenden Scripte:
Die berühmt, berüchtigten BDSM-Kreuze z.B. - wie bereits an anderer Stelle gesagt, sind das Lag-Bomben. Warum? Weil sie zu so vielen Dingen kompatibel sein sollen, dass pro Kreuz mal locker 20, 30, 40 und mehr Listener zusammen kommen.
Andere Dinge sind manche HUDs - modular augebaut, so modular, dass jedes Modul eigene Listener bemüht - natürlich jedes auf exakt demselben Channel.
Oder RLV, das Relay ist Script-technisch eine einzige Katastrophe - es versucht so viele Dinge abzufangen... wovon die meisten absolut überflüssig sind. Einen Knebel abzufragen, obwohl gar kein Knebel getragen wird, ist völlig hirnrissig.
Mal eine rein RLV-Sim besucht? Deren FPS-Werte sind fast immer im Keller.
Ähnliches gilt für die Cambat Meter - die sind inzwischen so sehr bemüht, Cheating abzufangen, dass sie kaum noch in der Lage sind das zu tun, was sie eigentlich tun sollen.
Katastrophal sind auch diese unzähligen Rotation-Scripts, die man auch nach Jahren wider besseren Wissens zu Hauf finded. Und wer zum Teufel braucht einen Bling auf den Schuhen?

Sylvie Munro schrieb:

(...)

Zum anderen Punkt, dem der ständig Lag machenden Scripte:
Die berühmt, berüchtigten BDSM-Kreuze z.B. - wie bereits an anderer Stelle gesagt, sind das Lag-Bomben. Warum? Weil sie zu so vielen Dingen kompatibel sein sollen, dass pro Kreuz mal locker 20, 30, 40 und mehr Listener zusammen kommen.
Andere Dinge sind manche HUDs - modular augebaut, so modular, dass jedes Modul eigene Listener bemüht - natürlich jedes auf exakt demselben Channel.
Oder RLV, das Relay ist Script-technisch eine einzige Katastrophe - es versucht so viele Dinge abzufangen... wovon die meisten absolut überflüssig sind. Einen Knebel abzufragen, obwohl gar kein Knebel getragen wird, ist völlig hirnrissig.
Mal eine rein RLV-Sim besucht? Deren FPS-Werte sind fast immer im Keller.
Ähnliches gilt für die Cambat Meter - die sind inzwischen so sehr bemüht, Cheating abzufangen, dass sie kaum noch in der Lage sind das zu tun, was sie eigentlich tun sollen.
Katastrophal sind auch diese unzähligen Rotation-Scripts, die man auch nach Jahren wider besseren Wissens zu Hauf finded. Und wer zum Teufel braucht einen Bling auf den Schuhen?

Zum Vergrößern anklicken....

Was das Relay angeht: Ob die lag machen oder nicht, das hängt stark vom verwendeten Code ab. Es gibt welche, die eben vermutlich eben mal 10+ Listener gleichzeitig aufmachen und ständig irgendwas verarbeiten, während andere mit 2 oder 3 aktiven auskommen. Manche lassen alle 2s einen Garbage Collector laufen während andere drauf verzichten und der User bei einem Kommunikationsfehler eben von Hand aufräumen muss oder gar ohne RLV resetten. Allein bei den Beispielen in der Spec gibts schon riesen Unterschiede zwischen dem einzelnen Script von Julia Banshee und zwischen dem tkPBA Scriptset.

Das Relay fragt aber eigentlich auch keine Knebel ab, das übersetzt nur Anweisungen von einem Objekt auf dem RLV Kanal in llOwnerSay() Messages und kommuniziert über diesen Kanal mit dem Objekt. Die Frage ob da nun ein Knebel getragen wird oder nicht hat wenn überhaupt, dann was mit dem Tool in SL und dem einzelnen Viewer zu tun. Von daher versteh ich nicht so ganz was du mit diesem Hinweis jetzt meinst.

Particles (also Bling) machen nebenbei keinen Sim Lag, genauso wie rotierende Objkekte mit llTargetOmega bei normalen (nonphysical) Prims keine großen Auswirkungen auf den Server hat (der nur einmal den Status "rotation = true" verarbeiten muss). Du verwechselst da Sim lag mit Client-Side lag.

Hier: Gwyn’s Home Blog Archive Lag Myths Dispelled ist ne nette Seite dazu.

Aber selbst wenn wir beim Server Lag bleiben:
Ein offnener Listener alleine macht noch keinen Lag, genauso wie ein Sensor an sich, der lag entsteht erst, wenn ein Script viel Verarbeiten muss. Z.B. weil jemand so schlau war sein Collar auf Channel 0 lauschen un zu lassen und dabei dann konsequent auf ein else verzichtet hat um das Ergebnis diverser hochkomplexer Listenberechnungen über 10 lists anschließend in unzähligen Scripts und mit ständigen linkmessage bursts zu versenden.

Aber du kannst mit 60 listenern in deinem Script arbeiten ohne lag zu machen, wenn keine Kommunikation in deinen Filtern hängen bleibt...

Shirley Iuga schrieb:

...
Was wirklich lag beimResizen macht, das ist aber weniger das Script an sich als vielmehr das gleichzeitige Verändern von z.B. 200 mal z.B. 10 Primwerten = 2000 Werten (Größe, Position, etc.) im Attachment an einem Avatar über llMessageLinked. Das kann durchaus zu spikes von +40ms bis +50ms über ein paar Sekunden führen.

Die Sache ist nur, dass man normalerweise nicht ständig was resizen muss...

Zum Vergrößern anklicken....

Also ich hatte hier mehrere Tage einen Besucher rumrennen der/die mit ca. 3.000 ms permanent die Top Skriptmonster-Liste anführte. Nach Entfernen von Mysti-Tool. warens dann "nur" noch 2.300 ... der ganze "Rest" ging grossteils zu Lasten von Resizerskripten von den Schuhen bis zu den Haarspitzen.

Nicht zu vergessen der Moment wo solche Avas eine Sim betreten und der ganze Mist erstmal geladen werden muß!

Es sind nicht nur die Hersteller die sowas - im schlimmsten Fall sogar unlöschbar - verkaufen, es fehlt schlicht und einfach das Bewusstsein für das was man mit dem Tragen solcher Teile anrichtet, weil man solche Werte als normaler User ja bislang selber garnicht sehen kann, und viele deshalb garnicht auf die Idee kommen ihre Resizerskipte zu entfernen.

Höchste Zeit, dass das endlich geändert wird.

Roya Congrejo schrieb:

Es sind nicht nur die Hersteller die sowas - im schlimmsten Fall sogar unlöschbar - verkaufen, es fehlt schlicht und einfach das Bewusstsein für das was man mit dem Tragen solcher Teile anrichtet, weil man solche Werte als normaler User ja bislang selber garnicht sehen kann, und viele deshalb garnicht auf die Idee kommen ihre Resizerskipte zu entfernen.
Höchste Zeit, dass das endlich geändert wird.

Zum Vergrößern anklicken....

Das ist ein Manko, finde ich.

Das mit dem ARC hab ich ja irgendwann gefunden und begriffen .. die Werte da haben mich doch sehr beeindruckt.
Ich gehöre auch zu denen, die die Resize-Scripte nicht entfernen.
Bling mach ich allerdings auf off, wenn es denn geht bzw. sich die Scrpte entfernen lassen, schmeiß ich sie raus.

Wie wirken sich denn eigentlich die allseits beliebten persönlichen Flutlichter (Facelights) aus?

Shirley Iuga schrieb:

Hier: Gwyn’s Home Blog Archive Lag Myths Dispelled ist ne nette Seite dazu.

Zum Vergrößern anklicken....

Och ich zu Hartz IV nun lieber, weil es schöner klingt, ALG-II sage: es ist und bleibt dieselbe Sache.

Gwyneth argumentiert recht technisch, dass es keinen serverseitigen Lag mehr durch geskriptete Attachments seit 2006.

LL soll damals einen neuen Scheduler eingeführt haben, der die Skripte einfach in der Ausführung nur noch dann drannimmt, wenn er dafür Zeit hat. Sprich, Skripte können nicht mehr den Server bei der Arbeit behindern, weil der Server ein hartes Zeitmanagement fährt. Die Skripte laufen andauernd, nur mitunter... langsamer.

Das ist für sie kein Lag. Für die Mehrheit von uns, wenn man ihr das erzählt, ist diese Argumentationsweise selbst in die Tasche gelogen und sehr wohl Lag, wenn Skripte deswegen nicht mehr so flott ausgeführt werden, wie man es erwartet, z.B. bei HUDs.

Unberührt dessen bleibt übrigens der Speicherbedarf der Skripte. Scheduler hin oder her, wenn der Server zu stark das Swappen anfängt, ist es mit der Herrlichkeit vorbei.

Byte Code Sharing ist eine nette Sache, aber die Frage ist, wieviele der Haardesigner setzen das auch wirklich korrekt um und bei wievielen Haaren ist das nicht der Fall? Nur weil die Technik vorhanden ist, wird sie noch leider nicht auch überall angewandt.

Linden Lab selber übrigens gibt in ihrer Knowledge Base zu viele laufende Skripte als einen möglichen Grund von Server Side Lag an.

Losgelöst davon wird das Bewußtsein dafür erst dann richtig wachsen, wenn LL den Benutzern auch Mittel an die Hand gibt, den eigenen "Verbrauch" zu sehen und vor allem richtig zu bewerten.

Aber du kannst mit 60 listenern in deinem Script arbeiten ohne lag zu machen, wenn keine Kommunikation in deinen Filtern hängen bleibt.

Zum Vergrößern anklicken....

Nun, sowas tut das GRP-Collar. Es kommt mit 2 Listenern aus. Wie schaffe ich es, einen Parser über den Chat-Text laufen zu lassen, der auf Channel 0 (und einem weiteren) stattfinded, ohne dass die Verarbeitungszeit in den Himmel schnellt? Eigentlich einfach: Das erste, was ich tue ist, eine bestimmte Grundbedingung abzufragen, ist die nicht gegeben, passiert gar nichts weiter mehr, es wird sofort abgebrochen.
Dann frage ich ab, ob eine Animation gemeint sein könnte, die sich im Inv des Collars befindet. Wenn ja, was in 95% aller bis dahin ausgewerteten Chats der Fall ist, wird die ausgeführt - und erst, wenn auch das kein Ergebnis brachte, erfolgt der komplexe Teil. Der wird also nur dann ausgeführt, wenn alle anderen Lösungsversuche kein Ergebnis brachten. Aber wie gesagt, ohne die Grundbedingung (welche das ist, müsst Ihr selbst erraten ) passiert absolut nichts mehr. Kein Parsing, keine Anim-Suche, nichts.

Die Funktion ist also:
Grundbedingung? Nein? -> Ende
Ja
Animation? Ja? -> Ausführen; Ende
Nein
Befehl? Ja -> Ausführen; Ende
Nein
Ende

OK, eines muss ich dazu sagen - ich nutze durchaus auch "return".

Die Frage ob da nun ein Knebel getragen wird oder nicht hat wenn überhaupt, dann was mit dem Tool in SL und dem einzelnen Viewer zu tun. Von daher versteh ich nicht so ganz was du mit diesem Hinweis jetzt meinst.

Zum Vergrößern anklicken....

Nun, zumindest einige Scripte fragen ständig alles ab, besonders die, die es ermöglichen, dass die getragenen Objekte selbst keine Funktionalität haben müssen - RLV erlaubt das ja. Oder auf Deutsch: Ich kann damit jemanden Knebeln, der gar keinen Knebel trägt - welches Attachment das steuert, ist dann unerheblich. Das kann ein HUD sein, ein Ohring - sogar eine Haarsträhne, wenn's sein muss. OK, hat weniger mit Lag zu tun als mit blödsinniger Funktionalität, gebe ich zu.

Habe vorhin in der Gad Gruppe das gelesne mit dem Resizerscripten löschen.Habe das auch gemacht und mich gewundert.Angeblich sollen ja dadurch diese Rendering Costen gesenkt werdne was wieder weniger Lag verursacht.Nur wurden nach dem löschen diese Punkte nicht weniger.Entweder ist es ein Gedankenfehler von mir oder Geister hatte sich da vertan.

Rendering cost bezieht sich auf die Grafik, also auf die clientseitige Belastung. Sim Lag ist serverabhängig zum grössten Teil. Dazu zählt auch die Scriptzeit in den Resizerhaaren. Berichtigt mich wenn ich falsch liege.

Dann ahbe ich es falsch verstanden.Aber Rendering Cost hat dann danahc nichts mit Serverlag zu tun sondern eigentlich zu grossenteil am Rechner oder denke ich da wieder falsch ?

Die Avatar Rendering Cost (kurz ARC) ist clientseitig. Sie ist einfach ein Maß dafür, wieviel Arbeit eure Grafikkarte hat, einen Avatar in all seiner Pracht zu rendern. Mit Simlag hat das nichts zu tun, denn hier gilt, je schneller der Rechner und je besser die Grafikkarte, desto weniger Einfluss hat diese auf euer Spielerlebnis.

Simlag entsteht durch verschiedene Faktoren, wie viele sich ändernde Texturen, viele laufende Skripte, viele gleichzeitig anwesende Avatare und viele, physikalische Objekte.

Geister lag also daneben, wer durch die ARC leicht genervt ist, wird ohnehin sein Grafikeinstellungen drastisch herunterdrehen.

Wärend die Sim selber und die Scripte die auf ihr aufgerufen werden über den server abgewickelt werden, werden die Avatare clientseitig abgehandelt. Ich glaueb das gilt nur nicht für die Position der Avas. Das heisst dein Viewer holt sich die Info wer wie aussieht über eine Abfrage vom Client des anderen Avatars mal extrem vereinfacht. Dazu zählen Sounds, AO, Attachements und ähnliches. Darum siehst du zum Beispiel jemanden als Wolke wärend ein anderer diesen Ava schon komplett sieht. So hab ichs mal erklärt bekommen.

Also Aos udn so werden Clientseitig abgearbeitet ?Aber Aos arbeiten ja auch mit Scripten.Wird dann das Script getrennt bearbeitet ?

Das Script in der AO belastet die Sim..die Animation selbst wird an deinen Client übermittelt-Darum zum Beispiel setzen Bewegungen bei schwerem Lag erst verspätet ein oder man "sieht" sein schwert erst später gezogen als man es tatsächlich in der Hand hält. Das Script bedient sich der Ressourcen der Sim und musste erst über den Qeue.