• 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.

Frage zu Scripts

Gestern kam eine Frage zu den Scripts auf die man an sich trägt. Wie man die abfragt ist ja klar. Was nicht klar war ist die Antwort auf die Frage ob man auch irgendwo sehen kann wieviele der Scripts aktiv sind. Wenn ich nun zB 6o Scripts trage unter anderem um eine Textur an einen Ring zu ändern, dann wird dass Scripts doch erst aktiv, wenn ich dann dass Menu öffne um die Textur zu ändern.

Oder versteh ich da was falsch?
 
oh hier wäre ich für eine Aufklärung ebenfalls dankbar!

Zum Einen interessiert es mich aus denselben Gründen wie Angelika. Schließlich nervt es mich schon arg, wenn ich irgendwo lande und man mir eine Scriptanzahl vorschreiben will.

Zum Anderen haben wir diese Diskussion erst auf Frisland gehabt, wo ich den Standpunkt vertrat, dass (als Beispiel) meine gerezzten Apfelbäume, die ich per Script zum Blühen, Früchtetragen, Entlauben etc. bringen kann, diese Scripte nur ausführen, wenn ich es ihnen sage - insofern sind das doch eigentlich ruhende Scripte und sollten die Sim nicht belasten oder bin ich da wasserstoffblond und verstehe das falsch?
 
Jedes Skript ist grundsätzlich inaktiv. Erst, wenn es ein Event durch irgendeine Aktion von aussen (Timer, Chateingabe, Berührung, ...) erhält, wird es aktiv, bis es seine programmierte Aufgabe erfüllt hat und legt sich dann wieder schlafen.

Bei "llListen(0,"","","")" löst jede Eingabe durch jeden in Chatreichweite ein Event aus. Auf einer einsamen Insel, wo sich im Chat nicht viel tut, ist dies kein Problem. In einer vollen Disko sieht das möglicherweise anders aus. Ähnlich ist es auch bei llSensor (Radarsysteme).

Ich kenne keinen Befehl, der die Aktivität eines Skripts feststellt. Dies könnte auch nur ein Momentanwert sein, da das Skript in der nächsten Millisekunde einen anderen Zustand haben kann. Interessanter wäre dann eher ein Wert, der aussagt, wie lange ein Skript in einem vergangenen Zeitraum aktiv war, prozentual oder absolut.
 
Soweit schon mal interessante Aussagen und Danke dafür.

Aber wäre auch dankbar, wenn ich hier noch etwas näheres erfahren würde: Was verstckt sich hinter einem geöffnetem Listener?
 
Unter geöffnetem Listener verstehe ich eine aktive Listener-Funktion.

Mit llListen() wird die Listener-Funktion aktiviert und mit llListenRemove() wieder deaktiviert. Solange die Funktion aktiv ist, wartet sie auf Chateingaben und wertet die aus. Durch Filter beim Aufruf können die Chateingaben, die an das Script weitergegeben werden, eingeschränkt werden. Das Skript hat durch diese Einschränkungen weniger zu tun. Auf dem Server müssen jedoch, wenn die Funktion aktiv ist, alle Chateingaben geprüft werden.

PS: Für den Chat gilt dies alles nur, wenn der Eingabekanal, der erste Parameter von llListen(), 0 ist. Ansonsten muss der jeweilige Kanal so geprüft werden, auf dem sich sicher weniger tun wird.
 
Zuletzt bearbeitet:
Ein Listener erzeugt keinen Lag solange er nicht ausgeführt wird. Es handelt sich um ein paar Bytes an Code, die in die Schleife mit den Listener-Triggern in der Skriptengine/VM des Servers "eingeklinkt" werden und immer überprüft werden (wie in einer if-Abfrage), wenn ein Text irgendwo in der Region auf einem der Chat-Channels gesendet wird.
Wenn man allerdings auf häufig genutzten Channels (z.B. 0) einen Listener hat, dann kann das sehr wohl viel Skriptzeit beanspruchen, vor allem wenn deine Skripts viel Code im Listener ausführen, um den Chattext zu analysieren.

Du kannst allerdings die Script-Events pro Sekunde herausfinden die du mit deinem Avatar verbrauchst, wenn du in eine leere Sim gehst, und dort im Statistikfenster (Strg+Shift+1) den entsprechenden Wert beobachest (bzw. die Veränderung wenn du die Region wieder verlässt).
fs_stats_bar.png

Diese sind entscheidender als der benutzte Skriptspeicher.
 
Zuletzt bearbeitet:
Ein Script, das nichts macht außer vor sich hin zu idlen und auf Events zu warten, das braucht nur minimale CPU-Zeit. Das bewegt sich je nach dem dann in Bereichen von Bruchteilen von Millisekunden. Und selbst mehrere zehntausend Scripts, die nichts machen, stören einen Server nicht wirklich. Scripts werden sowieso erst dann verarbeitet, wenn der Server dafür Zeit über hat. Wenn ein Script dann auf einen Event reagiert, dann kommt es ganz stark darauf an, was im Script bei diesem Event dann passiert. Passiert da nichts groß weiter, dann macht ein Script auch fast keine CPU-Last. Dazu kommt, dass ein Script höchstens auf 64 Events reagiert. Kommen mehr Events rein, dann werden diese einfach verworfen.
Zudem haben viele Funktionen noch eine Verzögerung eingebaut, das irgendwo zwischen 0.1 Sekunden (z.B. beim Rezzen aus dem Prim-Inventory) bis hin zu 20 Sekunden liegen kann. Aber auch manche Events haben einen kleinen Minimal-Delay eingebaut, listen hat ein 0.022 delay, d.h. nach der Auslösung des listen-Events schläft das Script erst mal kurz für mind. 1 Server-Frame. So dass auch in einem vollen Club maximal 22 Listen-Events pro Sekunde ausgelöst werden können, wenn der Server dann noch mit 45FPS läuft. Nach jedem Event ist ein Frame Pause. Ist der Simulator aber schon am Schwitzen und läuft nur noch mit 30 FPS, dann werden nur noch maximal 15 Events ausgelöst.

Das Problem an den Listenern ist so auch nicht der Listener oder der Event selbst - sondern das, was dann in diesem Listen-Event passiert. Wenn da jedesmal ein Wust an Funktionen, Operationen, komplexen Berechnungen und schnellen Loops ausgeführt wird, dann reichen schon wenige Zeilen Code in einem Script und die Script-Zeit geht in den Keller, wenn man damit auf Kanal 0 und jeden lauscht. Man kann zwar nicht mehr so einfach Sims abschießen wie früher - aber wenn man es richtig anstellt kriegt man einen Simulator nur über Scripts immer noch ausgebremst. Bis hin zum Reboot weil er zu lange zu langsam war.

Script-Speicher ist dabei heute eigentlich kaum noch ein Problem, zumindest wenn man Mono Scripts nutzt. Die maximal 300MB für alle Scritps eines Sim waren früher mal, heute läuft das virtualisiert. Und viele Sims teilen sich letztendlich einen Server mit ordentlich viel Speicher.

==> Nicht die Anzahl der Scripts ist entscheidend, auch nicht die Art der Events - es kommt immer nur darauf an was dann genau in diesen Events in den Scripten passiert. Und wie oft das passiert.
 
Mittels llGetObjectDetails laesst sich sehr leicht die Anzahl und Anzahl laufender Scripte eines Avatars feststellen.

Fuer die "id" setze einfach den Key des Avatars ein list llGetObjectDetails( key id, list params );

Params:
Anzahl Scripte = OBJECT_TOTAL_SCRIPT_COUNT
Anzahl laufender Scripte = OBJECT_RUNNING_SCRIPT_COUNT

LG
Dae
 
Danke Dae, damit läßt sich ein prozentualer Wert über einen bestimmten Zeitraum näherungsweise ausrechnen, wobei hierfür nur die Anzahl laufender Skripte interessant ist.
 
Zuletzt bearbeitet:
Mittels llGetObjectDetails laesst sich sehr leicht die Anzahl und Anzahl laufender Scripte eines Avatars feststellen.

Fuer die "id" setze einfach den Key des Avatars ein list llGetObjectDetails( key id, list params );

Params:
Anzahl Scripte = OBJECT_TOTAL_SCRIPT_COUNT
Anzahl laufender Scripte = OBJECT_RUNNING_SCRIPT_COUNT

LG
Dae


Erstaml danke an alle für die Infos, auch wenn ich eigentlich nur die Hälfte verstanden habe...:)

Dae....kannst Du mal jemanden der Null Ahnung vom scripten hat...also für mich.... mal so erklären dass ich es nutzen kann?

LG

Angel
 
@angelika: Zunächst mal wäre zu klären, was Du unter 'aktiv' im Bezug auf ein Script verstehst. LSL kennt die Zustände 'running' und 'stopped'. Ein gestopptes Script liegt nur als Objekt im Inv und tut garantiert nichts, insbes. reagiert es nicht auf ein Event, bis es gestartet wird. Ein Script, welches auf ein Event reagieren kann, z.b. einen Listener hat, ist als im Zustand 'running', auch wenn es schläft und nichts tut. Alle Scripte, die 'running' als Zustand haben, liefert die von Dea beschriebene Funktion. Ich gehe mal davon aus, dass du mit 'aktiv' aber die Scripte meinst, die tatsächlich was tun, also nicht auf ein Event warten. Diese kannst du nicht ermittelt (zumindest wüsste ich nicht wie).

Interessanter ist aber die Frage, wofür Du diese Information verwenden willst, denn, wie Shirley schon anmerkte, ist diese Info relativ nichtsagend. Bist du an Informationen über die Last interessiert, die ein Script verursacht, wäre die Laufzeit besser zu betrachten. Diese kannst Du, falls Du auf ner Sim Estate-Rechte hast (oder jemanden kennst, der diese hat) über das Debug-Tool ermitteln oder alternative auch mit der von Dea beschriebenen LSL-Funktion mit dem Parameter 'OBJECT_SCRIPT_TIME' ermitteln.

Gruß

Vesta
 
Hallo Vesta,

eigentlich ist es nichts wichtiges. Wir haben halt gestern mal über die Scripts geredet die man irgendwie angezogen hat. Sei es von Haarem Texturaenderungen von Schmuck usw. Wir kamen dann zu dem Thema wo man weggeportet wird weil man ja Böse ist und zuviel Scripts mit sich führt.

In dem Zusammenhang kam eigentlich dann die Frage auf ob es eine Möglichkeit halt gibt zu erfahren welche Auswirkungen diese Scripts haben und welche eigentlich zum Zeitpunkt X aktiv sind. Wenn ich zb auf meinen Ring klicke, bekomme ich ein Menu. die Frage dann wäre dass schon ein Listener, ein script welches aktiv ist und nur darauf wartet dass man den Ring anklickt? Oder weird dass script erst aktiv wenn ich dann dass Menu dafür habe.

Also schlussendlich mal in erfahrung zu bringen welche denn dann wirklich aktiv sind von denen die man trägt.
 
huhu angelika,

Es kommt darauf an, wie der Listener programmiert wurde.
Du kannst ein Menue mit einem permanenten Listener bedienen, der die ganze Zeit mit laeuft und auf Menue Befehle reagiert, oder besser einen Timer starten, sobald du das Menue oeffnest, der nach ablauf einer gewissen zeit den Listener abschaltet.

Das Problem an Sich sind nicht die Listener selber, sondern die Channel auf die die Listener reagieren.
Ein Listener der auf Channel NULL (0) (local chat) hoert ist sehr mit vorsicht zu geniessen, eben weil das script fuer alles was im Chat passiert jede einzelne "if" im Event abfragt bis eine zutrifft oder eben nicht.
Nun kann man das zwar vorher eingrenzen, das der Listener nur auf bestimmte Objecte, oder Avatare reagiert, dennoch arbeitet das Script und fragt mindestens eine "if" ab.
Kurz gesagt, Channel 0 grundsaetzlich vermeiden, wenn es geht, solange es nicht gerade ein Translator ist.
Fuer jeden anderen Channel ist es tendenziell egal, weil die Wahrscheinlichkeit das zu viele auf dem Channel kommunizieren doch sehr gering ist. Da koennen dann noch so viele Listener auf beispielsweise Channel 1 hoeren, die reagieren alle nicht, solange niemand auf diesem Channel sendet. Dumm wird es dann nur, wenn mehrere unterschiedliche Objecte die gleichen Abfragen verwenden und ploetzlich alles resettet, wenn man nur eins resetten will. ;)

Mit der von mir oben geposteten Abfrage kannst du auch nicht genau sehen, welche Scripte in einem Object mehr Last verursachen als andere, ebenso wenig wie die Abfrage von Vesta, sobald sich mehr als 1 Script im Object befinden. Generell kannst du nur Objecte oder Avatare als Ganzes bewerten, aber selbst dann kommt es immer darauf an, in welcher Verfassung sich der Sim-Server befindet. Eine Region auf der sich 100 Avatare befinden duerfte aehnlich belastet sein, wie eine Region mit 2500 Scripten ganz ohne Avatare. Die Script Time ist nur eine Moment-Aufnahme unter aktueller belastung. Das bedeutet, ein und das selbe Script hat in einem vollen Club deutlich hoehere Script Time, als auf einer leeren Sim, eben weil der Server mit dem vollen Club ohne hin schon genug zu tun hat und eben dann laenger fuer das spezielle Script benoetigt. Deshalb ist das Script jedoch noch lange nicht schlechter als andere.

PS: Bei mir im Shop steht seit Jahren ein fertiger Script Counter mit diesen Funktionen zwischen den FREEBIES herum. ;)

LG
Dae
 
Zuletzt bearbeitet:
...wo ich den Standpunkt vertrat, dass (als Beispiel) meine gerezzten Apfelbäume, die ich per Script zum Blühen, Früchtetragen, Entlauben etc. bringen kann, diese Scripte nur ausführen, wenn ich es ihnen sage - insofern sind das doch eigentlich ruhende Scripte...
sind sie nicht, sie sind nur in einem "idle" Modus, heißt, ihre Simbelastung ist nahe Null.
Richtig abgeschalten ist ein Skript nur, wenn man es entweder per Baumenü auf halt stellt oder mit llSetScriptState in eben diesen Zustand versetzt. Dann allerdings bemerkt es weder touch, noch Listener noch sonstwas.
Reaktivieren lässt es sich von einem anderen Skript im selben Prim aus llSetScriptState("anderes-angehaltenes-skript",TRUE);,
macht also nur Sinn in Multiskriptgeräten wie Sitzmaschinen etc. wo man bis auf ein Hauptskript zur Interaktion alles Andere schlafen legen kann.
 
Ein Script mit einem Sensor, das lediglich eine Tuer oeffnet, sobald sich ein Avatar in der naehe befindet, ist vergleichsweise harmlos im Gegensatz zu einem Script mit einem Sensor, das Avatare in der Naehe scannt und saemtliche Informationen ueber den Avatar wie Script-Cound, Script-Running-Count, Script-Time, Groesse des Avatars, Kontonummer und Telefonnummer auswertet.

Ein Script mit einem Listener auf Channel 0, das nur auf den Owner reagiert ist vergleichsweise harmlos im Gegensatz zu einem Script mit einem Listener auf Channel 0 bei jedem Avatar reagiert. Beide Scripte sind jedoch unzumutbar fuer die Region und man sollte doch lieber jeden anderen Channel fuer Script-Kommunikation verwenden.

Grundsaetzlich tun Scripte erst einmal ueberhaupt gar nichts, wenn sie nicht gerade ueber einen Timer oder Sensor-Repeat verfuegen. Die stehen so zu sagen nur auf Stand-By wie ein abgeschalteter Fernseher, bei dem noch das rote Laempchen leuchtet.

LG
Dae
 
Für den nicht scripter ist ein script ja nur die Aussenwirkung sichtbar, sei es eine Tür, die aufgeht oder ein Fahrzeug. Aber grundsätzlich läuft ein script. Es macht also last in jedenfall. Ausser man schaltet sie ab, wie Dianna sagt.

Ich würd mir das wie mit einen Auto vorstellen. Dein Auto ist aus: Es reagiert auf nix, du kannst das Pedal treten bis zum Anschlag... es passiert nix. Das wäre wie der Zustand, denn Dianna schon beschrieb, wenn man per Baumenü das script manuell abschaltet.
Machst du das Auto an, dann würde es reagieren auf alles, was du machst. Auch ein Script, dass läuft, würde auf alles reagieren, auf das es soll: ein touch oder ein sich setzen. etc. Das Warten darauf verbraucht vergleichsweise wenig "Sprit", genau wie ein Auto im Leerlauf. Die Aussenwirkung bei beiden ist immer noch gleich 0, das Script scheint nix zu tun, wie auch das Auto. Wenn du aber Gas gibst, reagiert das Auto und verbraucht mehr Sprit und tut was. Genau das selbe ist beim Script der Fall, du touchst es oder setzt dich hin, dass was dann folgt, hat eine Aussenwirkung für dich, das nimmt man wahr. Je mehr du Gas gibst, und dann noch ggf um die Kurve fährst, desto mehr Sprit verbraucht es, genauso ist es bei einem Script, es muss mehr machen, damit verbraucht es mehr CPU Zeit.
 
Danke erst einmal für die Ausführungen, die selbst mir als absoluten Laien irgendwie ein wenig einleuchten :)

Aber trotzdem nochmal eine weitere Frage: Wenn ich jetzt alles richtig verstanden habe, sind im Grunde fast alle Scripte inworld in Objekten zu Gange, auch wenn sie vielleicht (für mein Verständnis) ruhen, aber eben in Bereitschaft sind.

Macht es da Sinn, dass man konsequent löscht? Also als Beispiel Haare oder eben Ringe, die ein Colorchanger oder Resizer Script in sich tragen. Soll ich da lieber eine Kopie machen und das Script jedes Mal löschen und somit mein Inventar künstlich aufblähen oder das Ganze getrost ignorieren? Was belastet da letztendlich mehr?

Ebenso meine Apfelbäume. Wir haben auf Frisland etliche Gewächse (Gras, Sträucher, Bäume), die Scripte enthalten. Nun empfinde ich es persönlich als sehr mühselig, diese zu jeder Jahreszeit zu löschen, um dann drei Monate später die Sachen zu ersetzen, dort das Script zu bedienen, um den gewünschten Änderungseffekt zu erzielen, und dann wieder die Scripte aus den einzelnen Objekten zu löschen. Ist es für die Simperformance tatsächlich empfehlenswert oder fällt der Unterschied so marginal aus, dass ich mir diese Mühe sparen könnte?
 
Zuletzt bearbeitet:
Bei Attachments welche Scripte enthalten um eine einmalige aenderung hervor zu heben, lohnt es sich immer die Scripte danach zu entfernen und eine leere Kopie zu tragen. Das verbessert auch dein Teleport Empfinden, denn jedes Script was du zusaetzlich traegst, muss erst zwischen den Servern hin und her geschoben werden.
Kurz gesagt, jeder Content den du weniger traegst, reduziert den gefuehlten Teleport-LAG.

Bei deinen gerezzten Objecten ist es gehopst wie gesprungen, solange die Scritpe nicht permanent irgend welche Abfragen verarbeiten. Das heisst, deine Baeume sind nicht der Rede Wert, da sie so zu sagen nur auf interaktion warten, die uebrige Zeit verwenden die Scripte gegebenenfalls lediglich 0.000 - 0.002ms Script Time und es stoert auch nicht weiter, wenn der Server die mal nicht beachtet, sollte die Sim mal hoeher belastet werden.

Genau so verhaelt es sich mit Pose-Scripten, die tun erst einmal gar nichts und selbst dann wenn jemand drauf sitzt tun die auch nichts mehr, sobald die Animation vergeben wurde.

Hier mal ein paar Beispiele, welche Scripte eine Region ehr belasten koennen.
Greeter (Sensor und/oder Timer)
Radar (Sensor und/oder Timer)
Script-Zaehl-Boards (Sensor und/oder Timer)
Uhr (Timer mit 1 Tick pro sec.)
Follower-Pets (Sensor und/oder Timer)
Translator (Listener auf dem Lokalen Chat)
Zuchtviecher (Sensor und/oder Timer + http-Requests)
Es gibt noch einige Beispiele mehr, aber ich hatte kein Bock mehr.

LG
Dae
 
Also erstmal möchte ich mich auch bei allen bedanken und kann mich da Charlie nur anschliessen. Mir ist zwar immer noch nicht alles klar, aber vieles halt klarer.

Und wenn ich es nun richtig verstanden habe ist zB der Listener bei meinem Schmuck total unproblematisch weil er nicht permanent läuft, denn wenn ich auf den Ring gehe um dass Menu zu bedienen meldet er mir nach einer gewissen Zeit so gesehen ein Timeout wenn ich dass Menu einfach nur so stehen lasse. Ist dann so wie bei dem Beispiel mit dem Fernseher. Wenn der eine gewisse zeit läuft ohne dass eine Funktion betätigt wurde meldet er sich nach einer gewissen Zeit das er sich abschalten wird. Und man kann wohl sagen das jemand der Unmengen an Scripts mit sich rumträgt zwar nicht unbedingt eine Last mit bringt, aber auch Zig Tropfen können auch ein Glas voll machen...:)

Aber wenn ich es nun auch richtig verstanden habe kann ich mich nicht einfach an eine ruhige Stelle bewegen und sehen dass ich zwar 60 Scripts an mir habe , aber davon nur 1 Script läuft.
 

Users who are viewing this thread

Zurück
Oben Unten