• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Sim Zutritt nur unter 100 Scripten ?

Also ich persoenlich lege auch sehr viel wert auf die verwendung eines einzelnen Scriptes fuers ganze Object, vieles laesst sich halt ideal in einem Script unter bringen und kombinieren.
Dennoch sehe ich kein Problem darin das ein oder andere auszulagern.
Nicht alles kann man in einem Script unter bringen, vieles laesst der Speicher ja schon nicht zu.

Wo ich aber absolut gegen bin, sind unsinnige viele kleine Scripte fuer ein object. Ich brauch kein extra Script fuer jeweils einen Hovertext, Giver, Rotation und gegebenenfalls nen paar Particle. Das geht bequem alles in ein einziges Script und fertig is der LM-Pin.
Bei dem Kleinkram kann man noch nicht von MonsterScript sprechen.
Anders sieht es bei aufwendigen Scripten aus, da sollte man sich vieleicht ueberlegen diverse Funktionen die nicht staendig gebraucht werden, in ein zweites Script zu legen und dieses gegebenenfalls abschalten und einschalten nach bedarf, das geht ziemlich einfach mit llSetScriptState(... , damit laesst sich im Script per befehl der Haken unten Links fuer "Laufend oder nicht" setzen und entfehrnen.

LG
Dae
 
Jemand ab 100 Skripten aufwärts nach Hause zu schicken halte ich persönlich für etwas unfreundlich - bei gut besuchten RP-Sims aber doch noch halbwegs nachvollziehbar (wobei man sicher über die 100 als Limit streiten kann). Dass man mit wenig Skripten viel Lag und umgekehrt machen kann - ja - aber das halte ich für Erbsenzählerei - in der Regel (das ist zumindest meine Erfahrung) ists doch so, dass jemand mit viel Skripten mehr Lag macht als jemand mit wenigen. Ausnahmen bestätigen die Regel. ;)

Danke, nichts anderes hatte ich bereits auf der ersten Seite gesagt. Für mich zumindest ist das Thema auch beendet, ich finde das Niveau etwas niedrig, auf dem im Moment von einigen diskutiert wird und ich warte einfach mal ab, ob LL da etwas unternimmt. Irgendwann.
 
*grummel*
Muss mich doch noch mal melden.

Für alle, die noch immer davon ausgehen, dass es einfach grundsätzlich so ist, dass viele Scripte viel Lag machen und wenig Scripte wenig.

Stellt euch mal ein Lagmeter auf und ihr werdet, wenn ihr nicht ständig im Lendenschurtz rumlauft, ganz schnell sehen, dass es eben doch so ist, dass einige wenige Scripte viel mehr Lag machen können als viele Scripte.

Es gibt da keine goldene Regel oder ein annähernd verlässliches Limit an Scripten für.

Mutmasst nicht rum und haltet verbissen an eurer Meinung fest.
Auch gegenseitige Schuldzuweisungen hier werden da nix ändern oder bessern.

Auch ich habe mich (für mich selbst) verrücktmachen lassen von solchen Behauptungen und schnell alles von Scripten befreit (wenn es denn ging).

Mir sind meine Mitmenschen halt nicht egal und wenn ich etwas verbessern kann, versuche ich mich auch zu informieren und es künftig besser zu machen.

Jedenfalls weiss ich aus praktischen Versuchen am eigenen Inventar nun, dass eben nicht die Anzahl sondern der "Inhalt" der Scripte massgeblich ist.

Desweiteren deckt sich meine Erfahrung mit den Aussagen der meisten Scripter hier (ich selbst verstehe Scripte nicht), welche sich hier zum grossen teil schon im Forum sehr verdient gemacht haben (meine Meinung).

Wie kann man nach all den Aussagen, nachvollziehbaren Beispielen und angeführten Tests denn noch weiterhin über Scriptlimits diskutieren ohne selbst gegenteilige Tests gemacht zu haben die das widerlegen?
 
Kennt noch zufaellig jemand den alten Freebie (LibaryScript) RegionMap Projector, oder wie der hiess?
Jedenfalls zeigte es als Particle Hologram die Sim map an.
Frueher hab ich mich immer gewundert, warum ich LAG (Ruckelbilder)ohne ende hatte, wenn ich dem Ding zu nahe kam. Mitlerweile weiss ich das es reiner Viewerlag war, denn der Particle war ziemlich hoch eingestellt und zeigte staendig eine 512px Textur.
Um genau zu sein, Das ParticleScript darin war voellig Falsch eingestellt, saemtliche Werte viel Zu hoch und meine Grafikkarte war ganz schoen am schwitzen.

Der Witz an der Geschichte is, es hatte nur 1 Script.

LG
Dae
 
Yistin das bei dem Mystitool damals ging es um einen permasensor in einem vollbesetzten Club nicht um den Speicherverbrauch! Hab ich nicht geschrieben also zur Klarstellung. Das war nur ein Beispiel für eine andere Diskussion wo es aber auch um die Nutzung von Skripten ging und wo sich die Unfähigkeit zur Selbstreflektion herrausstellte.

Außerdem beziffere ich den Resourcenverbrauch nicht. Warum hast du ja geschrieben: Wir wissen es nicht und können nur vermuten.

Ich sage nur das ein Script Resourcen benutzt und Resurcen nicht unbegrenzt zur Verfügung stehen und das man sich das mal bewusst machen sollte. Einmal für sich Selbst und andererseits als gegenseitige Rücksichtnahme.
Das solltest du eigentlich wissen immerhin lernt man eigentlich im ersten Semester bereits etwas über die Rechenarchitektur des von Neumann Rechners und das ein Skript ob es ruht oder nicht Resourcen verbraucht kannst du nicht bestreiten oder? Es benutzt wenn es ruht die Resource Speicher und wenn es läuft zusätzlich noch die Resource CPU. Beides ist in einem von Neumann Rechner nicht unbegrenzt vorhanden.
Wie viel Resourcen habe ich nicht geschrieben, das wolltest du nur lesen.
Im Gegenteil ich habe geschrieben das die Anzahl der Skripte ein Anhaltspunkt ist mit zu vielen Variablen um eine genaue Aussage treffen zu können.
Die Variablen sind da: einmal Mono oder nicht und bei Monoskripten der tatsächliche Speicherverbrauch, welchen wir nicht ermitteln können und die Tatsache das solch eine Beurteilung nichts über die CPU-Last aussagt.
Also eigentlich deine Meinung oder?

Zu deinem Skriptbeispiel:
Aso ich sollte also ein Skript mit fünf Funktionen, gesteuert über ein Dialogmenü, welches per click aufgerufen wird auf 6 Skripte verteilen weil das besser ist?
Dabei übersiehst du aber das die 6 skripte dabei miteinander kommunizieren müssen was wiederum ein zusätzlichen event erforderlich macht, auf den man in einer einskript Lösung verzichten kann.
Ich weiß was du meinst aber du hast es, mal wieder, einfach so pauschal in die Runde geworfen und behauptet alle die das anders sehen seien dumm.

Du hast vermutlich recht wenn man wie oben ein Kommuniktationsscript hat und eine Funktion einen permaSensor(event) oder einen Timer(event) erfordert, welche die Kommunikation per Listener(event) und oder sich selber gegenseitig ausbremsen könnten. Dann könnte es Sinn machen diesen Sensor oder den Timer auszulagern, meiner Meinung aber nur dann wenn diese nicht permanent an das Hauptscript rückmelden müssen. Dann hättest du zu dem permasensor, und dem timer im übelsten Fall noch zwei permalinkmessages. Die Speicherbelastung dürfte hierbei bei Monoskripten dank dynamischer Speicherverwaltung die Selbe sein wäre aber bei LSL skripten höher.
Das ist eben, wie Shirley schon so richtig schrieb vor allem Funktionsabhängig und weil das so ist habe ich eine ganz bewusst eine allgemeine wahre Aussage gewählt und wegen dieser Tatsache zur gegenseitigen Rücksichtnahme aufgerufen. Wenn das in deinen Augen dumm ist, dann bin ich gerne dumm ich befürchte aber du verstehst mich einfach nur falsch.

btw.
Wenn meine Aussage so dumm ist, warum kann ich dann auf einem Computer nicht fünft SL-Clients, Photoshop, Blender und den Firefox gleichzeitig ausführen ohne Probleme zu bekommen. Ist der kaputt? Du kannst das Yistin?
 
@ Deamonika
Stimmt hast recht, bin auch nur Mensch.
Aber ein Anflug von temporärer Dummheit klingt netter als einen Riss im Hirn zu unterstellen (sowas kann irreperabel sein mein Gott) ;)

@ Simon
Ich bin für eine Limitierung des Scriptspeichers wie es LL vorhat.
Der Grund ist ganz einfach es steht für die Ausführung der Scripte nicht unbegrenzt Speicher zur Verfügung.
Das ich dafür plädiert habe die Anzahl der Scripte zu limitieren, wüsste ich nicht. Eigentlich habe ich das Gegenteil geschrieben, aber egal.

Was ich auch gemacht habe ist das ganze nicht einseitig zu sehen nur weil es mir grad in den Kram passt. Also nicht nur zu sagen ein Script kann mehr Last verursachen als 10, sondern auch das 10 Scripte sehr wohl auch mehr Last verursachen können als 1 Script. Und da alles nur Vermutung ist, darf das so rum doch auch mal erlaubt sein oder?

Was ich auch gemacht habe, dafür zu pledieren das man Entscheidungen von Simownern respektiert und nicht gleich Bösartigkeit zu unterstellen. Zu Respekt gehört für mich grundsätzlich auch die Leute ihre Fehler selber machen zu lassen, denn nur dann lernt man daraus.
Ich bekomme ehrlicherweise das Kotzen wie in SL Konsumenten über Anbieter und da besonders über die, welche anderen etwas zur freihen Verfügung stellen, pauschal urteilen ohne nur ein ganz kleines bisschen sich mal mit den Gründen für die eine oder andere Entscheidung auseinander zu setzen.
Würde man das tun, würde man bei diesem Fall in erster Linie sagen: Ok ich schau mal auf was ich verzichten kann und nicht dann komme ich eben nicht mehr her du Nazi! (überspitzt ausgedrückt natürlich).

Aber ich habe ja gelernt das verantwortungsvolles Umgehen mit begrenzt vorhandenen Resourcen und gegenseitige Rücksichtnahme dumm ist. ;)
 
btw.
Wenn meine Aussage so dumm ist, warum kann ich dann auf einem Computer nicht fünft SL-Clients, Photoshop, Blender und den Firefox gleichzeitig ausführen ohne Probleme zu bekommen. Ist der kaputt? Du kannst das Yistin?


Das Problem ist, dass dir die Scriptzählerei *nicht* sagt, dass da 5x SL, Blender, Poser, Photoshop, Final Cut usw. gleichzeitig laufen sondern nur, dass da 10 Programme gleichzeitig laufen. Und 10x Wordpad sind weniger kritisch als 1x SL. Ergo: völlig sinnlose Methode.
 
@ Daniel
Meine Aussage war die hier:

Ein Script verbraucht Resourcen und Resourcen sind begrenzt.
Das ändert sich auch mit einem egozentrischen Weltbild nicht.
Was das jetzt mit Scriptzählen zu tun hat weiß ich nicht.

Was etwas mit scriptzählen zu tun hat sind diese Aussagen von mir:
Die Anzahl der Skripte mag zwar ein Anhaltspunkt sein, aber einer mit zu vielen Variablen als das man da eine genaue Aussage treffen könnte.
und weil das bereits anders rum interpretiert wurde:
Im Gegenteil ich habe geschrieben das die Anzahl der Skripte ein Anhaltspunkt ist mit zu vielen Variablen um eine genaue Aussage treffen zu können.
Die Variablen sind da: einmal Mono oder nicht und bei Monoskripten der tatsächliche Speicherverbrauch, welchen wir nicht ermitteln können und die Tatsache das solch eine Beurteilung nichts über die CPU-Last aussagt.
 
Hängt ihr euch jetzt an "Ein Script" auf? Sollte ich Scripte schreiben zum besseren Verständnis?
 
Na ich verstehe nicht warum mir ausgelegt wird das ich eine Limitierung der Anzahl von Scripten befürworte nur weil ich schreibe das ein Script Resourcen verbraucht. Von Scripten zu reden wäre noch ein Stück allgemeiner gehalten. So wäre die Gefahr gebannt so verstanden zu werden das ein Script immer eine konstante Anzahl von Resourcen verbraucht. Das hat Yistin vermutlich interpretiert.

Ich rätsel eigentlich nur warum man mich nicht versteht und suche die Gründe dafür nun mal bei mir ;)
 
Ich rätsel eigentlich nur warum man mich nicht versteht und suche die Gründe dafür nun mal bei mir ;)

Ach sooo...
...moooooment

Also, Der Script Memory fuer eine Sim betraegt 300MB.
Jedes vorhandene Script, ganz gleich ob activ oder inactiv, verbraucht die Resource Memory in unterschiedlicher hoehe.

Jedes active Script verbraucht zusaetzlich die Resource Script-Time (Rechenzeit), Das ist in etwa die Zeit, die der Server braucht um ein Script zu verarbeiten, dabei spielen andere Factoren noch eine Rolle.

Wenn der Server bereits ausgelastet ist, durch sagen wa mal zuviel Physische Objecte und viele Avatare auf ser Sim, kann das sogar ein popeliges HovertextScript mit nur dem einen Befehl drin, verlangsamen, in der Top-Script Liste macht sich das dann durch hoehere ms werte bemerkbar, weil der Server eben nicht mehr genug Reserven fuer diese Resource frei hat.

Jetzt Kommt noch dazu das ein Server nicht nur eine FullSim verwaltet, sondern gleich 4 oder mehr. Nun kann es sein das deine Sim voellig Scriptarm gestaltet ist, aber trotzdem Laggt wie eine Homestead mit 20 Avataren druff. Das kann daran liegen, das die anderen 3 Sims auf dem Server eben nicht sparsam mit den Resourcen umgingen.

Natuerlich ist es lobenswert erst vor der eigenen Tuer zu kehren und seine Sim im Auge zu behalten, trotzdem muss man nicht an allem Schuld sein. noch weniger die Besucher einer Sim. Der lag kann ganz einfach auch von wo anders her kommen.

ich hoffe das versteht man^^

LG
Dae
 
Natuerlich ist es lobenswert erst vor der eigenen Tuer zu kehren und seine Sim im Auge zu behalten

Da! Genau das meine ich und erweitere das mal zusätzlich um die eigenen Attachments.
Das muss natürlich jeder für sich selbst wissen und außer reden kann man da auch nichts machen.
 
Ja mei, manchem mag der Begriff des Blockwarts nicht gefallen, ich habe auch nirgends hier behauptet, Teilnehmer X oder Y aus dem Thread sei einer, weder direkt noch indirekt.

Nichts desto weniger gibt es diese Purschis. Schon vor zwei Jahren schrieb Gwyneth Llewelyn in ihrem Blogpost "Anatomy of Lag" über ARC-Nazis. Ich denke mal, viele von uns haben schon Bekanntschaft mit diesem Typus Avatar gemacht. Das sind diejenigen, freundlichen Purschis, die sich keine gescheiten Grafikkarten zulegen wollen, und dann früher einen in IMs rund machten, wenn man als Avatar eine ARC > 3000 meinetwegen am Leib trug von wegen wie böse und gemein ist das denn und wie kann man nur, blablabla! Vermutlich würden diese Leute auch Traktor auf der Autobahn fahren, wenn es nur erlaubt wäre, ist nämlich dasselbe in Grün, und sich dann über die bösen 30-Tonner-LKWs auf der rechten Spur wundern, die ständig Lichthupe drücken und ihren Anhänger mit der Stoßstange küssen. Böse, böse aber auch!

Aus bestenfalls fundiertem Halbwissen und einem vermeintlich einfachen Indikator - der ARC - zogen diese mit Leidenschaft die denkbar falschen Schlüsse und machten ihr Umfeld regelmässig rund, manche terrorisierten es geradezu regelrecht.

ARC juckt nur niemandem mehr noch taugt es wirklich als Aufreger, also musste ein neues Empörungs-Buzzword von Seiten Linden Labs her, damit man den Leuten einen neuen, vermeintlich einfachen Aufreger an die Hand geben konnte, um so von den Unzulänglichkeiten der eigenen Technik abzulenken.

Und das Empörungs-Buzzword der Stunde ist nunmal der Avatar Script Count. Auch hier - und das ist die Parallele zum ARC - ist es wieder sehr einfach aus einem vermeintlich einfachen Indikator die denkbarst falschen Schlüsse zu ziehen, und Schuld sind mal wieder die anderen, und so geschieht es auch deftigst.

Wie schon Shirley auseinander dividierte, ist die Script Count ein Faktor, der "Lag" auf einer Sim beitragen kann, aber längst nicht der Einzige. Denn der Speicherbedarf sagt nichts darüber aus, wie rechenintensiv die Skripte sind oder auch nicht. Wer will, der kann auch mit einer Hand voll Skripte oder weniger eine Sim ganz schön massiv lahmlegen, und der Script Counter zeigt dennoch bei dem Avatar alles auf Grün! Praktisch!

Dabei war die Avatar Script Count früher (angeblich) Teil eines wirklich sinnvolleren, größeren Projektes gewesen, nämlich jedem Avatar die Hilfsmittel an die Hand zu geben, den eigenen Impakt auf eine Sim mal objektiv messen zu können und als Fernziel irgendwann vielleicht mal gar von der primbasierten Wirtschaftsweise, die sich inzwischen teilweise selbst ad acta legt, wegzukommen. Aber leider hat das Linden Lab nicht mehr weiter ausgebaut, sondern diese Anstrengungen auf Eis gelegt und auch ihre Mono-Gurus wie Babbage Linden ja letztes Jahr in der großen Entlassungswelle allesamt gefeuert.
 
...Was wird passieren?

Statt 20 kleiner Scripte in einem MultiHUD ala MystiTool (Nach deiner Argumentation ein riesiger Verbrauch, was falsch ist) von denen die meisten schlafen und nur ein Minimum an Systemzeit belegen wird der Scripter dann alles in ein Monster packen, das ständig läuft (Nach deiner Argumentation ja deutlich weniger Verbrauch).

Fakt dagegen: Den echten Speicherbedarf der Scripte weis niemand - die hier bisher angegebenen 64 MB oder ähnlich sind schlicht Maximalwerte, die die gut wartbaren kleinen Sscripte nicht mal annähernd erreichen.

Statt dessen hast du dann ein Monsterscript, das als Ganzes permanent aktiv ist (kein Idle Task mehr) und dann definitiv einen Riesenspeicherplatz und obendrein große CPU-Times belegt - und es kann nicht mal teilweise ausgelagert werden, was bei kleineren Scripten durchaus möglich wäre.

Wenn das die sinnfüllende und lagverhindernde Lösung sein soll, gebe ich meinen Informatiker zurück. Der Schuss geht völlig nach hinten los.

Sorry, das ist nicht sinnvoll, sowas fällt in die Kategorie "Ideologisch verbrämte Dummheit"

"Scripte verbrauchen Ressourcen" klingt so toll... es ist unüberlegt. Denn viele kleine Scripte, von denen nur eines aktiv ist, verbrauchen weit weniger Ressourcen als das zwangsläufige Resultat einer Scriptbegrenzung - Monsterscripte, die im "Klotz" laufen und zwangsläufig permanent große Ressourcen belegen.

Ich bleibe dabei: Wer mit Gewalt Scripte nach Anzahl limitiert und "1 Script zuviel = Rausschmiss" propagiert, stellt sich auf die Stufe der Redzone-User: Nichts begriffen, unbelehrbar, ideologisch vorgebleicht. Kommt der mir damit, sieht er mich nimmer wieder, mein Geld nehmen auch andere, die weniger dümmlich handeln.

Das Problem Deines Beitrags ist, dass Du absolute Aussagen aus eher theoretischer Perspektive einzelner möglicher Zusammenhänge als allgemeingültige Wahrheiten nimmst, und die daraus resultierenden ... "Schlussfolgerungen" dann noch mit einer Reihe wenig netter Beschimpfungen garnierst. Absolute Wahrheiten gibt es in der Praxis aber eher selten, sondern die Leute tragen einen wilden Mix der unterschiedlichsten Skripte mit sich herum ... der dennoch gewisse Erfahrungen und Schlussfolgerungen aus der Praxis erlaubt (was im Einzelfall natürlich nicht stimmen muss, aber darauf kommt es eigentlich gar nicht an).

"Was wird passieren..." - ahem, das halte ich mit Verlaub gesagt für Kappes ... damit Deine Aussage wirksame SL-Realität werden könnte, müssten tausende Skripter einen Grossteil ihres Krams auf den Haufen werfen und alles unter der einzigen Maxime "packe alles in EIN skript - packe ALLES in EIN skript" neu machen, und versuchen einen Grossumtausch neu gegen alt zu machen. Das wird so aber sicher nicht passieren.

Was wir haben, ist doch immer nur eine Momentaufnahme, eine kleine Zeitscheibe im sich weiterentwickelnden SL-Universum. D.h., im Moment haben wir gewisse Indikatoren zur Verfügung, die eine erhöhte Lagbelastung signalisieren könnten (und es nach aller Erfahrung in der Summe der heute durch die Welt rennenden Avatare imho auch tun). Dass es nicht immer einen zwingenden Schluss zwischen Indikator und Ursache geben muss, ist doch allen Beteiligten klar - aber das stellt noch lange nicht in Frage dass es in vielen Fällen derzeit doch solche Zusammenhänge gibt. Derzeit. Heute und vielleicht Morgen.

Übermorgen haben wir vielleicht neue und bessere Funktionen zur Ressourcenmessung an der Hand, vielleicht bessere Server mit mehr Ressourcen und peu a peu werden auch die Skripter ihre gewonnenen Erfahrungen umsetzen, und alte Lagschleudern nach und nach verschwinden - weil - auch deshalb, weil durch die heute zur Verfügung stehenden Mittel zur Ressourcenmessung, auch wenn sie nicht perfekt sind, bei der Masse der Leute erstmal das Bewusstsein geweckt wird, vielleicht auch auf die eigene Ressourcennutzung zu achten, statt immer nur allgemein über den bösen Lag zu schimpfen.

Und: Auch andere verstehen vielleicht was von Informatik, und ich finde es macht sich nicht sonderlich gut, anderen "Dummheit" zu unterstellen nur weil sie anderer Meinung sind. Dass man die Instrumente der Skriptmessungen sinnvoll nutzen sollte und möglichst wenig Barrieren für die SL-User errichten sollte, steht doch eigentlich auch ausser Frage - da rennst Du glaube ich bei dem meisten hier nur offene Türen ein... ;)
 
Ich hab doch diesen kleinen Versuch mit 11700 zusätzlichen default Scripten gemacht.

Hätte ich zu diesem Zeitpunkt eines dieser tollen LSL-Laggometer stehen gehabt, dann hätte das Angezeigt: "Grenzwert der akzeptablen Scriptzahlgrenze von 100 Scripten um 10 000% überschriten - Speicherbelegung durch dich: 731.2 MB"

Absolut üble Sache, oder?

Aber in der Praxis haben diese Scripte mit einer zusätzlichen Laufzeit von 0.00025 ms pro Skript keinen wirklichen CPU-Load für die Verwaltung der Script gemacht. D.h. da wurde wohl eine Art NOP ausgeführt. D.h. die LSL Mono Enginge macht da mit der CPU wohl einfach etwas, das stark gegen nichts strebt. 3ms mehr Rechenzeit (Script Time ging von 18ms bei 4100 Scripten auf 21ms bei 15800 Scripten hoch) für 11700 Scripten eben.

Und wegen Mono mit Bytecodesharing usw. haben die 11700 Scripte zusammen vermutlich lediglich um 1KB oder so im Script Speicher verbraucht. Auf jeden Fall unter 100kB. Das waren ja alles Klone von kompilierten Scripten.

und @ Gina:
den Tatsächlichen Speicherverbrauch bei LSL Scripten kann man nicht exakt ermitteln - aber man kann ihn als Autor sehr wohl abschätzen. LSO-Scripte belegen z.B. immer 16kB pro Script. Monoscripte belegen in etwa nur den Platz, den sie brauchen wenn man folgende Tabelle zu Grunde legt: LSL Script Memory - Second Life Wiki + kleinen Overhead für Mono; bis eben zu einem Limit von 64kB. Enthalten die Scripte keine weiteren (eigenen) Daten und sind sie nur geklont auf dem Simulator, dann belegen sie überhaupt keinen zusätzlichen Speicher. (Mehr Details zu Mono Scripts sind noch hier: Mono - Second Life Wiki)

Von daher sind die LSL Ressourcen zwar schon begrenzt - aber bei weitem nicht so knapp wie manchmal dargestellt wird.

Und wenn die Hersteller auf unsinnigen Schnickschnack in den Scripten und Tools verzichten und die User auf unsinnige Tools wie Anti-Push Schilde, Orbiter, etc., dann reichen die Ressourcen in SL locker damit jeder so viele Scripte mit sich rumschleppen kann, wie er für seinen Ava nun mal braucht.

Auch in einer RP Sim.

Und wer SL als Egoshooter nutzen will und daher eine System Performance wie bei Counterstrike erwartet, der ist sowieso falsch hier, dafür ist die Enginge und die ganze Architektur von SL nicht ausgelegt und dafür ist sie nicht wirklich geeignet. Weil z.B. Scripte nur dann ausgeführt werden, wenn freie Zeit auf dem Server ist...um nur mal einen Grund von mehreren zu nennen. Aber da gibts noch weitaus mehrere, wie z.B. die Art und Weise wie in SL Bewegungs- und Positionsdaten generiert und kommuniziert werden etc.
 
Sorry Bart, aber den Script Count als nonsens ohne aussagekraft zu bezeichnen ist absolut FALSCH.
Der Scriptcount mag zwar nicht 100% genau sein, liefert aber allemal genug informationen auf den Verbrauch, welchen man sogar locker im Kopf rechnen kann.

Man nehme einen Avatar mit 500 activen Scripten, da kannst du locker davon ausgenen das der Avatar in der Top-scriptliste mit minimum 1.000ms angezeigt wird, da jedes laufende Script, ganz gleich ob es grad was tut oder nicht, mindestens 0.002ms Script-Time verbraucht.
Da die Scripte aber nicht immer nur nix tun, kannst du ehr mit einem Wert von 3.000ms rechnen.
Stellst du jetzt nur 10 Avatare mir gleicher Anzahl active Scripte auf die Sim, hast du ganz schnell 30.000ms, nun wird eine Sim allgemein ab 15.000ms in der Statistigbar schon als leicht Laggy empfunden, der richtwert in der Statistikbar liegt bei 20.000ms wo eine Sim laggy IST. soweit mir bekannt ist, sollte man eine Sim Neustarten wenn sie einen Wert von 25.000 dauerhaft anzeigt.

Von daher finde ich den Scriptcount auf jeden Fall interessant.

LG
Dae
 
und @ Gina:
den Tatsächlichen Speicherverbrauch bei LSL Scripten kann man nicht exakt ermitteln - aber man kann ihn als Autor sehr wohl abschätzen.

Das ist nicht ganz richtig, denn die Funktionen dafuer sind nur noch nicht auf allen 4 Server Klassen implementiert.

guckst du hier?
LlGetSPMaxMemory - Second Life Wiki
LlGetUsedMemory - Second Life Wiki
LlScriptProfiler - Second Life Wiki

Server:
Category:Server Release Notes - Second Life Wiki

NACHTRAG:
@ Shirley
Ich hab deinen Beitrag gelesen ueber den verbrauch.
Nur frage ich dich, war es eine leere Sim?
Waren noch andere Avatare auf der Sim?
Hast du den Test auch als Attachment gemacht?

LG
Dae
 
Sorry Bart, aber den Script Count als nonsens ohne aussagekraft zu bezeichnen ist absolut FALSCH.

Und wo bitte sehr habe ich das geschrieben?

Ich schrieb nur, dass der Script Count ein Faktor von vielen ist, der zum Lag beiträgt, aber längst nicht der Einzigste und sein Beitrag dazu oft überbewertet wird.
 

Users who are viewing this thread

Zurück
Oben Unten