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

argus Portal

Freund/in des Forums
Hallo

Ich dachte bislang, das llResetScript ein Script komplett in den Ursprungszustand versetzt.

Mein Problem:

Mehrere Scripte sind vorhanden und kommunizieren mittels llLinkedMessage. Ein Script hing sich auf. Lasse ich es lange genug in dem Zustand, gibt es einen StackHeap-Fehler. Das ist aber nicht das Problem. In dem Script rufe ich llResetScript() im on_rez-Event auf.

Nehme ich dieses Objekt, in dem sich das fragliche Script nun verabschiedet hat, ins Inventar auf und rezze es erneut, erwarte ich, das auch das Problemscript in einen sauberen Anfangszustand versetzt wird.

Daher ist sein state_entry auch leer. Initialisiert wird es erst auf Anforderung über andere Scripte.

Aber es reagiert nicht mehr, wenn es von anderen Scripte angesprochen wird. Ich muss es erst im Viewer-Scripteditor per "Zurücksetzen" behandeln. Dann erst läuft es.

Kann sich jemand einen Reim darauf machen ?
 
Du kannst mal im state_entry() den belegten Speicher mit llGetFreeMemory() oder llGetUsetMemory() ausgeben. Dan vergleichen, ob zwischen Zustand nach Kompilieren und nach dem Reset beim Rezzen einen Unterschied ergibt.

Nach meiner Erfahrung gibt es den aber, Frisch kompillierter Skript belegt um einige (weniger als 50) Bytes mehr als wenn ich den im Editor zurücksetze. Woran das liegt, kann ich aber nicht sagen. Vielleicht gab es einige Nachrichten an den Listener oder Linknachricht, oder etwas ähnliches VM-spezifisch, die zwar in die Schlange angenommen waren aber bis der state_entry() abgearbeitet war, nicht entnommen wurden. Aber der Unterschied war sehr gering.
 
@Jenna: Danke für den Tip. Das würde ggf. bedeuten, das llResetScript nicht hält, was es verspricht. Sobald ich dazu komme, mache ich ein paar experimente.


@Sven: Ein Missverständnis. Das Script ist selbstverständlich aktiv. Aber es ist abgestürzt. Und neu rezzen bringt nichts.. Rest siehe Ausgangsposting
 
Hm, unterschied in einigen Bytes ist nicht so wichtig. Alleine weil die VM auf einem Server läuft, der irgendwelche Daten laufend mit der Umgebung austauscht, kann der Skriptreset nicht immer zum genau gleichen Zustnd der VM führen. Daher hat mich der Unterschied nicht gestört.

Aber wenn ein Skript abgestürzt ist, dann sagt die Wiki auch, man kann es nicht vom anderen Skript aus via llResetOtherScript() zurücksetzen bzw. wieder starten, und von sich aus wird der on_rez Event auch nicht anspringen um den evtl. zurück zu setzen. Nur ein Reset im Editdialog kann das tun dann.

Evtl. wäre da ein Flag sinnvoll, der das Zurücksetzen des abgestürzten Skriptes in bestimmten Situationen (Rezzen, Simwechsel oder Klick) erzwingt. Weil die Sim kann wissen ob der Skript abgestürzt ist und es zurücksetzen dann.
 
Nochmal deutlicher: Ich habe das Objekt, als das Script abgestürzt war, bewusst, um es zu testen, ins Inventar genommen und neu gerezzt. Jetzt sollte on_rez anspringen und damit llResetScript aufrufen, das ich dort plaziert habe. Und das zeigte nicht die erhoffte Wirkung.
 
Nochmal deutlicher: Ich habe das Objekt, als das Script abgestürzt war, bewusst, um es zu testen, ins Inventar genommen und neu gerezzt. Jetzt sollte on_rez anspringen und damit llResetScript aufrufen, das ich dort plaziert habe. Und das zeigte nicht die erhoffte Wirkung.

Erst mal: llResetScript startet ein Script natürlich schon neu, d.h. das Script wird in den Zustand versetzt, den es gleich nach dem kompilieren hatte. Dabei wird dann wohl einfach über den gespeicherten Bytecode eine neue Instanz des Scripts in der VM aktiviert. Und die alte gelöscht.

Scripts in SL sind keine reine Ablaufprogrammierungen, das sind State Machines, die auf Events mit bestimmten Abläufen reagieren. Packt man ein laufendes Script ein (oder macht einen TP), dann wird auf dem Sim das Script im Momentanzustand eingefroren und so als "Scriptzustand" gespeichert. Und dann z.B. ins Inventory oder auf einen anderen Server kopiert. Beim erneuten Rezzen wird dann das Script wieder entpackt und der Momentanzustand wird eben wieder in die VM kopiert. Je nach dem wird dann noch z.B. ein "on_rez" Event ausgelöst und in den Event-Qeue gesetzt. Und der wird vom Script nach und nach abgearbeitet.

Ist das Script aber einmal mit einem Stack/Heap Crash, einem Mathefehler oder ähnlichem abgestürtzt, dann läuft die State Machine des Scripts nicht mehr weiter, auch wenn das Script "aktiv" ist - und damit werden auch keine weiteren Events mehr abgearbeitet. Auch nach einem neu rezzen nicht. Folglich wird im Script selbst auch kein Event und damit auch kein llResetScript mehr ausgeführt. In diesem Fall muss dann eben das Script von außen, über den Sim neu gestartet werden. Womit dann aber wieder eine komplett neue Instanz des Scripts in die VM geschrieben und gestartet wird.

Man kann das in etwa mit einem Auto vergleichen, das gegen einen Baum gefahren wurde, wenn der Motor nicht mehr läuft, weil der Kühler sich um einen Baum gewickelt hat, dann bringt es auch nichts mehr wenn man die Zündung ausschaltet und den Motor mit dem Zündschlüssel neu starten will. Dann braucht man einfach eine ganz neue Autokopie. Ohne Motorschaden.
 
Zuletzt bearbeitet:
Danke für die Antwort ! Das leuchtet ein. Einen Bugreport spare ich mir. Aber hier hat LL wirklich geschlampt. Evtl. ist ihnen der Aufwand zu hoch um llResetScript den absoluten Vorrang zu geben, und das Problem des eingefrorenen Scriptzustands zu lösen. Wenigstens, indem unabhängig davon im on_rez nachgesehen wird.
 
ich würde genau dort ansetzen.

den abgesoffenen motor mit der handkurbel neu zu starten ist nicht die günstigste herangehensweise

Nein. Sowas kann immer passieren. Und nach Möglichkeit will ich meine Scripte wasserdicht machen.

Aber hier geht es, wie ich eingangs schon sagte, überhaupt gar nicht um den Fehler. Es ging hier ausschliesslich um eine LSL-Funktion, die nicht das tut, was man erwartet. Da frage ich nach, wenn mir so etwas auffällt.
 
Nirgendwo steht geschrieben, dass llResetScript ein gecrashtes script resetten können muss. Bzw. der event on_rez dann noch gehen sollte. Ist doch auch logisch, was hat denn einer davon, wenn die scripte nicht durchlaufen und der Kunde es immer wieder einpacken müsste und neu rezzen? Fang lieber das Problem sauber ab, dann ist dein Script auch Wasserdicht, wie du so schön sagst. Um es mit dem Auto zu sagen, bau eine routine ein, die sagt: Fahr nicht gegen den Baum.
 
Danke für die Antwort ! Das leuchtet ein. Einen Bugreport spare ich mir. Aber hier hat LL wirklich geschlampt. Evtl. ist ihnen der Aufwand zu hoch um llResetScript den absoluten Vorrang zu geben, und das Problem des eingefrorenen Scriptzustands zu lösen. Wenigstens, indem unabhängig davon im on_rez nachgesehen wird.

Ich fürchte du hast das nicht ganz verstanden. Das Script ist nach dem Crash nicht nur eingefroren. Nach einem Crash gibt es kein Script mehr, das laufen könnte oder resettet werden könnte, dann gibt es im Grunde nur noch Datenmüll.

Mal im Detail:

Ein Script besteht zunächst aus Text, der von einem Compiler in Bytecode umgewandelt wird, also Maschinensprache. Bei LSO wird dann für diesen Bytecode zusammen mit dem Stack und dem Heap (Stapelspeicher bzw. Haldenspeicher) ein Speicherbereich von 16kB vorgesehen. Ohne zu sehr auf die Details einzugehen greift das Script auf Speicherbereiche über Zeiger zu, die dem Script sagen aus welchem Speicherbereich z.B. Daten geholt werden müssen. Das Problem tritt nun auf wenn der Speicher komplett voll ist - dann zeigt ein Zeiger nach einer Operation eben auf einen "falschen" Speicherbereich. Und das Script kann an dieser Stelle keine weiteren sinnvollen Operationen mehr ausführen. Deswegen wird das ganze mit einem "Stack/Heap Error" abgebrochen. Das Script läuft dann einfach nicht weiter, der Speicherbereich des Scripts ist "tot".
Bei Mono ist das ein klein bisschen anders, da kann ein Script kurzfristig durchaus mehr als 64kB haben und es gibt keine festen Speicherbereiche (Ein Script kann auch nur 6kB Speicher belegen etwa), so dass es möglicherweise nicht gleich zu diesem Fehler kommt. Allerdings prüft die VM ständig wie viel Speicher das Script belegt, und wenn das zu viel ist (mehr als die zulässigen 64kB), dann wird die weitere Ausführung des Scripts ebenfalls radikal abgebrochen, der Speicherbereich des Scripts ist ebenfalls "tot".


Ein weiteres Problem, das auftreten kann, ist ein Hängen in einem Event durch einen Programmierfehler.
Ereignisse werden von einem Script in einem Qeue gespeichert. Und dort werden die Events einer nach dem anderen abgearbeitet, d.h. sequentiell. Und ein neuer Event wird erst dann abgearbeitet, wenn der Ablauf des alten beendet ist. Ein Script mit einem while(TRUE){Liste += Liste;} loop im touch_start Event wird aber niemals mit diesem Event fertig sein. Das Script wird nach dem Berühren einfach weiter einen Eintrag nach dem anderen in Liste kopieren, bis eben der Speicher voll ist und das ganze ein Crash wird.
Da bringt es dann auch nichts, wenn man über einen anderen Event ein llResetScript() auslösen will. Oder wenn man durch neu rezzen einen on_rez Script auslösen will.
Denn die neuen Events würden zwar abgearbeitet werden, wenn der Queue sonst leer ist - aber da kommt vorher der Crash.
 
Leute, seid ihr in übertriebener Wochenendstimmung ?

Sorry, aber ihr (besonders Sven, aber auch du, shirley) redet gerade Unsinn und am Thema vorbei.

1. Fehler macht jeder. Wer das verneint, versteht von Programmierung nicht wirklich viel oder ist über "Hello world" nicht weit hinausgekommen.

2. Zum einen ist die Frage mittlerweile beantwortet.

Aber, diese techn. Hintergründe in allen Ehren, wenn ich ein Objekt rezze, erwarte ich selbstverständlich, das es sich um eine neue Instanz handelt. on_rez sollte aufgerufen werden und gut ist. Hier haben wir es mit einer Designschwäche zu tun. Das war meine Kritik. Wie das severseitig gehandhabt wird ist also nicht ganz optimal.

Schlussendlich: Wichtig für mich ist einfach, das meine Frage, die ich aus rein techn. Interesse stellte, nun beantwortet ist.

Weitermachen. Oder auch nicht


:rofl
 
Danke für die Antwort ! Das leuchtet ein. Einen Bugreport spare ich mir. Aber hier hat LL wirklich geschlampt. Evtl. ist ihnen der Aufwand zu hoch um llResetScript den absoluten Vorrang zu geben, und das Problem des eingefrorenen Scriptzustands zu lösen. Wenigstens, indem unabhängig davon im on_rez nachgesehen wird.

Sorry, aber da hat nicht LL geschlampt, sondern du.
Wenn dein Script einen Stack Heap Error vorweist, hast du es einfach ueberladen. Fuer den Ersteller des Scriptes normalerweise ein kleines Uebel, aber wenn so ein Script verkauft wird und das entsprechende Object dann auch noch no modify ist, kann der Besitzer das ganze Object in die Tonne kloppen oder allenfalls noch als Deco verwenden.
Ein Stack Heap Error angehaltenes Script laesst sich nur noch ueber die Werkzeugleiste des Viewers wieder neustarten bzw. resetten sofern das Object fuer den jeweiligen Besitzer modify ist.
Ich wuerde mir auch nicht die Muehe machen, das mit einem zweiten Script im Object mittels llSetScriptState neu zu starten, das ist naemlich keine Loesung, sondern gepfuscht. An deiner Stelle wuerde ich den ganzen Code des betroffenen Scriptes mal komplett ueberdenken und gegebenenfalls etwas auslagern oder ganz ordinaer, nicht so viele Funktionen und Variablen Global ueber dem script eintragen, sondern gleich im eigentlichen Code, wo sie viel weniger Memory verbrauchen.
Globale Variablen und Funktionen wuerde ich nur dann anlegen, wenn sie etwas speichern sollen, oder im Script mehr als 1x und/oder in verschiedenen Events erneut benoetigt werden.

LG
Dae
 
Zuletzt bearbeitet:
Sorry, aber da hat nicht LL geschlampt, sondern du.

Den Rest der ganzen Wichtigtuerei entsorgt.

Bleib freundlich. Kein Wunder, das es hier manchmal seltsam zugeht.
Einige haben hier eine Macke. Dich eingeschlossen.

Liess bevor du schreibst. Ich würde diesen Thread gerne sachlich halten.

Der Fehler war winzig. Der war schon behoben als ich den Thread eröffnete.

Ich habe deutlich gesagt, das es nicht um den Fehler geht. Der brachte mich
nur auf die Frage.

Ist dir beim Arbeiten noch nie etwas aufgefallen, das dir eine Frage wert ist?

Wie kommst du auf die Idee, das ich fehlerhafte Sachen ausliefern würde?
Das klingt zumindest beinahe aus deinem überheblichen Beitrag heraus.


Es ging dir also nur ums Wichtigtun. Deine pseudotechnischen Tips haben mit dem
Thread nichts zu tun. Geh bitte woanders angeben.
 
@ argus

Es steht dir natuerlich frei, meine Ausfuehrungen persoenlich zu nehmen, das geht mir da vorbei wo keine Sonne hin scheint.
Nur versuch mal irgend einen Event auszufuehren, wenn im Script Fenster unten links der Haken bei "laeuft" heraus genommen wurde, denn nichts anderes macht der Server bei einem Stack Heap Error.

LG
Dae
 
@ argus

Es steht dir natuerlich frei, meine Ausfuehrungen persoenlich zu nehmen, das geht mir da vorbei wo keine Sonne hin scheint.

Eben. Und das ist Teil deiner Macke.
Ansonsten geht bei mir an derselben Stelle vorbei, wo bei dir die Sonne scheint.

Nur versuch mal irgend einen Event auszufuehren, wenn im Script Fenster unten links der Haken bei "laeuft" heraus genommen wurde, denn nichts anderes macht der Server bei einem Stack Heap Error.

Ich bin so frei mich zu wiederholen

---Selbstzitat ----
Aber, diese techn. Hintergründe in allen Ehren, wenn ich ein Objekt rezze, erwarte ich selbstverständlich, das es sich um eine neue Instanz handelt. on_rez sollte aufgerufen werden und gut ist. Hier haben wir es mit einer Designschwäche zu tun. Das war meine Kritik. Wie das severseitig gehandhabt wird ist also nicht ganz optimal.

-------------------

Warum liesst du nicht, bevor du schreibst! So umfangreich ist der Thread noch nicht. Das bischen Mühe kann man dir schon zumuten.

In ihrem ersten Beitrag war Shirley noch bei der Sache und hat erklärt was los ist. Und ich habe dann lediglich festgestellt, dass das Ganze inkonsequent oder halbherzig umgesetzt ist. Willst du dem ernsthaft widersprechen?

Wenn ich das Problem einer "Script-Leiche" via Viewer lösen kann, ist der erste techn. Ansatz seitens Linden doch schon realisiert. Hoffen wir, das der Rest noch folgt
 
Du scheinst nicht zu verstehen, das ist kein Design-Fehler von LL.
Ein Stack Heap Error sagt nichts anderes aus als dass das Script zu voll ist. Das ist ein Design-Fehler des jeweiligen Scripters.
Dieses Problem mit einem automatischen Reset umgehen ist keine Loesung, sondern primitiv gepfuscht.
Wir haben nun mal diese Limits und danach muessen wir uns richten.

LG
Dae
 

Users who are viewing this thread

Zurück
Oben Unten