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

Collision: Bug oder Feature?

Also nochmal konkret gefragt (Ich kann das gerade nicht selbst testen, und schon gar nicht von Region zu Region)

Wird collision_end immer dann ausgelöst, wenn ein Avatar das prim verlässt ? Egal, wieviel aktuell darauf stehen ?

Wenn ja, arbeitet meine Methode. Dein prim wird in Echtzeit reagieren und sich der aktuellen Situation anpassen.


Wird collision_end nicht jedesmal ausgelöst, arbeitet meine Methode nicht.

Du verstehst mich falsch, collision_end wird ausgefuehrt obwohl der Avatar sich noch darauf befindet und es wird kein weiterer collision_start oder collision dieses avatars mehr ausgefuehrt, solange der sich nicht bewegt.

LG
Dae
 
Mir ist aufgefallen, dass MystiTools seit Mitte der Woche bei jedem Simübertritt mit Fahrzeugen folgende Meldung ausgibt:
[09:45] MystiTool HUD 2.0.2: Collision with "[aR] Mudskipper 6x6 AATV v1.5", Owner: Frifra Nayar
Egal welches Fahrzeug und das ist auch erst seit Kurzem so, das war vorher nie.
 
Das bedeutet, das du beim collision_end die UUID eines Avatars geliefert bekommst, der noch auf dem Prim steht ?


Das wäre kein Feature. Das wäre ein Bug.
 
Mit anderen Worten: Es ist ihnen zuviel Aufwand das zu beheben. Wie wechselt Microsoft eine kaputte Glühlampe ? Gar nicht. Sie erklären Dunkelheit zum Standard. Alt, passt aber genau.
 
Entlich ist der Groschen gefallen, aber laut Bittersweets Links und Lindens Dokumentation ist das kein Bug, sondern gewollt. :/

LG
Dae

Das ist möglicherweise nicht mal eine Geschichte der Script Engine, sondern eventuell eine Art "Sicherheitsfeature" bzw. Ressourcenschnung der Havok Engine. Auf diese Weise könnte die Phsysik-Engine bisschen entlastet werden, wenn irgendwo einfach nur was physikalisches rumliegt. Das müsste man allerdings mal in SL genauer anschauen. (Kann hier grade nicht einloggen)

ansonsten: Eventuell wäre auch eine Lösung für den Leuchteboden ein langsamer llSensorRepeat denkbar, in dem man eben über sensor() und no_sensor() Events die Farbe des Prims ändert, so dass man nicht jede Minute 400 mal bis 500mal die Primfarbe ändern lassen muss wie bei der collision Lösung.
 
Ein Bug wäre es, wenn jedes Avatar das nur rumsteht, dauerhaft beliebig viele Kollisionen auslöst. Kollisionen haben einigen Einfluss auf die Performance einer Sim. Ich sehe hier keinen Bug. Auch aus diesem Grund ist es sehr unwarscheinlich, dass sich hier irgendetwas geändert hat.

Eine andere Erklärung, warum das Script zufälliger Weise früher mal funktioniert haben könnte, hab ich angeboten, egal. Ich habs eben nochmal kurz mit llOwnerSay() statt llSetLinkPrimitiveParamsFast() getestet. Dabei wurden im ersten Lauf beliebig viele collisionen mitgeteilt. Erst nach einigen Läufen, kam es auch zum von Dae beschriebenen Phänomen, dass die Kollisionen im collisions-Event abbrechen. Das bringt mich auf den Gedanken einer neuen Sicherheitsfunktion, um Endlosschleifen, die einige Scripter einrichten, zu unterbinden, lach. Aber das ist warscheinlich zu weit hergeholt. Bemerkenswert beim Testen war noch, dass es einige Male dazu kam, dass das letzte llOwnerSay() im collsions-Event nach dem llOwnerSay im collision_end-Event eine Meldung machte. Ok, warscheinlich Chatlag. Aber Lag gibt es nicht nur für Textfunktionen. Das spricht doch sehr für den von mir erwähnten Zufall.

Und bei collision_end bekommt man übrigens auch nicht die UUID des Avatars, dass noch auf dem Prim steht, sondern des Avatars, das den Event ausgelöst hat, auch hier also kein Bug.
 
Zuletzt bearbeitet:
Das bringt mich auf den Gedanken einer neuen Sicherheitsfunktion, um Endlosschleifen, die einige Scripter einrichten, zu unterbinden, lach. Aber das ist warscheinlich zu weit hergeholt.

Das ist möglicherweise nicht mal eine Geschichte der Script Engine, sondern eventuell eine Art "Sicherheitsfeature" bzw. Ressourcenschnung der Havok Engine. Auf diese Weise könnte die Phsysik-Engine bisschen entlastet werden, wenn irgendwo einfach nur was physikalisches rumliegt.

Hm....... Vielleicht doch nicht so weit hergeholt?
 
Die Platte bei mir mit dem script funzt hier OHNE probleme. Aber das collision event spammt den chat, wenn es denn nimmt. collision_start "sagt" nur einmal was. Beide Versionen liegen mal bei mir um, wenn die probieren willst. Eindeutig zu erkennen, welche collsion hat und welche collision_start.
 
Die Platte bei mir mit dem script funzt hier OHNE probleme. Aber das collision event spammt den chat, wenn es denn nimmt. collision_start "sagt" nur einmal was. Beide Versionen liegen mal bei mir um, wenn die probieren willst. Eindeutig zu erkennen, welche collsion hat und welche collision_start.

Lass es mal 5 Minuten laufen und nimm nicht das Avatar des Owners. Bei mir hats zunächst auch funktioniert, später nicht mehr, es kam dann zum Abbruch nach 4-5 Kollisionen, wenn das Avatar nur rumsteht.
 
Zuletzt bearbeitet:
Natuerlich, um serverlast zu vermeiden sehe ich das schon irgend wo ein und mir ist auch klar, dass es nicht ohne ist, im collisions event primitive parameter zu triggern, dennoch halte ich diesen event jetzt fuer ueberfluessig, da er eigentlich keine nutzbare funktion mehr besitzt. bzw. extrem eingeschraenkt funktioniert.

Es ist eigentlich schade, aber ich kann damit leben, wenn das nun nicht mehr geht.
Interessant finde ich, dass es jetzt ueber 2 jahre lang ein Bug war und erst jetzt seit letzter Woche funktioniert, wie es von LL geplant ist.

LG
Dae
 
Die Platte bei mir mit dem script funzt hier OHNE probleme.

Lass mich raten, du benutzt den Firestorm?
Nur mal so nebenbei, hier im Thread wurden schon stimmen laut, weil ich im Collisions Event Primitive Parameter Triggere. Denkst du nicht dass der Firestorm genau diese Serverlast trotzdem verursacht, obwohl die Lindens das nun unterdruecken? Das heisst, der Firestorm verursacht am avatar einen permanenten move, damit collision trotzdem reagiert.
Na wenn das mal nicht gegen die Shared Expirience ist. :p

Aus diesem Grund habe ich die physikalische Kugel und den Linden Viewer als Massstab genannt.

LG
Dae
 
Ich nutzte zu 99% den LL Viewer, da muss ich dich leider entäuschen. Und auch nach über 10 Minuten testen mit mir und meinem alt geht es immer noch, nur dass das einfache collision halt ständig scannt. Ich bin auf meinem Grundstück auf Mainland. Second Life Server 13.09.21.281328
 
Nach kurzem Test: das Script funktioniert hier erst mal problemlos - erst mal. Und mit dem Collision-Event werden auch ca. 7 Collisions pro Sekunde getriggert.
PHP:
integer counter;
integer time;

default{
    collision_start(integer total_number){
        llSay(0,"start");
        counter = 0;
        time = llGetUnixTime();
    }

    collision(integer total_number){
        counter ++;
    }

    collision_end(integer total_number){
        time = llGetUnixTime() - time + 1 ; //(+1 wegen evtl. div. durch 0)
        float med =(float) counter/(float) time;
        llSay(0, "time: "+ (string) time + " ,med: " + (string) med);
    }
}

Nach einiger Zeit fängt aber collision_end gern mal an einfach so zu triggern. Wobei dann aber sofort wieder ein collision_start ausgelöst wird, wenn sich dann wieder irgendwas neues tut.

Was bisher noch funktioniert hat:
PHP:
default{
    state_entry(){
        llVolumeDetect(TRUE);
    }

    collision_start(integer num_detected){
        llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_COLOR,0,<1,0,0>,1.0, PRIM_GLOW,0,0.50]); // rot
    }

    collision_end(integer num_detected){
        llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_COLOR,0,<1,1,1>,1.0, PRIM_GLOW,0,0.00]); // weiss
    }
}


damit blieb auch nach einiger Zeit das prim rot - außer das physikalische Prim hat sich aus dem Volumen heraus bewegt. Dafür hat llVolumeDetect leider wiederum einige nicht so tolle Einschränkungen, es funktioniert eben leider z.B. nur im Rootprim.
 
Noch eine kleine Ergänzung:

Ein Minimal-Script, das absolut nichts macht
Code:
default{
    state_entry(){
    }
}
braucht 0.003ms bis 0.004ms normalerweise.

Das Script mit llVolumeDetect braucht rund 0.0005ms, vermutlich weil da einfach nichts passiert sonst. Und das Script, bei dem die Script-Farbe 7 mal pro Sekunde im Collision-Event gesetzt wird braucht nach einigen Minuten (wenn es immer wieder ausgeht nach der Collision) auch nur lediglich 0.0007ms, egal ob das Prim dann kurz leuchtet oder nicht.
Davor (bzw. wenn man als Owner drauf steht und ständig Collisions auslöst )braucht das Script mit den ständigen Prim-Änderungen 7 mal die Sekunde (die aber nicht an den Viewer weiter gegeben werden) allerdings 0.0125ms bis 0.0128ms Rechenzeit.

Das ist vermutlich wirklich eine Drossel wegen der Rechenzeit.
 
Aber das ist warscheinlich zu weit hergeholt. Bemerkenswert beim Testen war noch, dass es einige Male dazu kam, dass das letzte llOwnerSay() im collsions-Event nach dem llOwnerSay im collision_end-Event eine Meldung machte. Ok, warscheinlich Chatlag. Aber Lag gibt es nicht nur für Textfunktionen. Das spricht doch sehr für den von mir erwähnten Zufall.

Es kann immer passieren, dass eine Meldung schneller beim Viewer ankommt als die später abgeschickte, weil es Internet ist, das die Meldung überträgt. Deshalb habe ich in meinen Skripten diese Funktion zum Debuggen via llOwnerSay:

Code:
// =============================================================================
// =============================================================================
integer dbseq = 0;
debug(string message) {
    dbseq++;
    llOwnerSay(":["+(string)dbseq+"]: "+message);
}
// =============================================================================
// =============================================================================

Wo auch immer ich eine Debugmeldung will, schreibe ich das etwa so

Code:
readCommand(string data) {
    debug("readCommand("+data+");");
    ...
}

Diese Meldung erscheint dann mit der laufenden Nummer, etwa so

Object:[33]: readCommand(reset);

Dann muss ich im Log dann die Meldungen auf richtige Position tauschen und weiß in welcher Reihenfolge diese abgeschickt wurden. Vorteil ist auch, dass ich später die Debugfunktion auskommentieren oder löschen brauche und die Debugmeldungen gar nicht vergessen kann, die dann Speicher kosten würden.

Edit

Ich verstehe es so, dass die Kollision dann erkannt wird, wenn der Avatar oder physikalisches Objekt mit einer Geschwindigkeit größer 0 bzgl. des Prims bewegt wird. Steht der Avaar auf dem Prim ist seine Geschwindigkeit 0 und er kollidiert nicht mehr. Evtl. war das auch früher so, der Ava wurde nur leicht vom Prim gedruckt und fiel wieder darauf beim draufstehen wegen der Schwerkraft, deshalb wurden es auch Kollisionen erkannt, jetzt funktioniert die Physikengine möglicherweise richtig :)

Das mit Volumendetect wollte ich auch vorschlagen, so hatte ich es immer gelöst, sogar bei Teppichen zum Drüberlaufen, weil laut meiner Tests wurde die collision_end() dann wirklich nur dann ausgelöst, wenn der Ava den Primbereich verlassen hatte.

Mir ist aufgefallen, dass MystiTools seit Mitte der Woche bei jedem Simübertritt mit Fahrzeugen folgende Meldung ausgibt:
[09:45] MystiTool HUD 2.0.2: Collision with "[aR] Mudskipper 6x6 AATV v1.5", Owner: Frifra Nayar
Egal welches Fahrzeug und das ist auch erst seit Kurzem so, das war vorher nie.

Das ist (mir) neu, und hängt evtl damit zusammen, wie die Avatare über die Simgrenzen übertragen werden. Der Simübergang müsste jetzt in mehreren Threads stattfinden. Vermuttlich weiß die Zielsim nicht, dass der Avatar noch auf dem Fahrzeig sitzt und beim Avatarübertragen gegen den Fahrzeig beim Rezzen knallt.
 
Zuletzt bearbeitet:
Habe diesen Skript benutzt:

Code:
integer dbseq = 0;
debug(string message) {
    dbseq++;
    llSay(0, ":["+(string)dbseq+"]: "+message);
}

default {
    state_entry() {
        debug("*** init ***");
    }

    on_rez(integer start_param) {
        llResetScript();
    }

    collision(integer num) {
        // triggert so lange wie eine Collision besteht (etwa 8x pro secunde)
        
        debug("collision (detected: "+(string)num+", top with "+llDetectedName(0)+")");
    }

    collision_start(integer num) {
        // Erkennt den Kolisionstart
        
        debug("collision_start (detected: "+(string)num+", top with "+llDetectedName(0)+")");
    }
    
    collision_end(integer num) {
        // Erkennt das Ende einer Kollision
        
        debug("collision_end (detected: "+(string)num+", top with "+llDetectedName(0)+")");
    }
}

Ich bekomme mit Firestorm wie mit dem Lindenviewer dieselbe Nachrichten:

[11:34] Carpet: :[1]: *** init ***
[11:34] Carpet: :[2]: collision_start (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[3]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[4]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[5]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[6]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[7]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[8]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[9]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[10]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[11]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[12]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[13]: collision_end (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[14]: collision_start (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[15]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[16]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[17]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[18]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[19]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[20]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[21]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[22]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[23]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[24]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[25]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[26]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[27]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[28]: collision (detected: 1, top with Jenna Felton)
[11:34] Carpet: :[29]: collision_end (detected: 1, top with Jenna Felton)

Und sobald ich aufhöre mich zu bewegen wird tatsächlich der collision_end geworfen. Ich denke eine Funktion, die das feststellt wäre sinnvoll, also wenn die Collision wie bei llVolumeDetect funktionieren würde aber eben auf der Oberfläche. Bin mir aber nicht sicher wie man das implementieren und anwenden könnte.

Habe mir aber erlaubt, diese Anfrage in Agenda des heutigen Meetings rein zu schreiben :)
 
Also ich bin jetzt um eine Erfahrung reicher, naemlich die dass ich nicht schlauer bin als vorher. :/

Gestern Abend hatten wir im Club eine spontane Party und ich habe die ganze Situation beobachtet.
Wie gesagt, liegen im Club flaechendeckend solche Platten die auf Collision reagieren und das eigenartige ist nun, das es ploetzlich bei mir wieder wie gewohnt funktioniert, obwohl ich nichts veraendert habe.
Interessanterweise funktionierte es nicht bei jedem und ich habe einfach mal rum gefragt wer welchen Viewer benutzt. Scheinbar liegt es nicht am Viewer selber, denn 2 Leute die jeweils den Firestorm verwendeten zeigten unterschiedliche reaktionen, beim einen gings, beim andern eben nicht. Selbst als sich da 10 Leute gleichzeitig aufhielten, waren nur es nur 3 Avatare, bei denen es nicht funktionirte.

Bei einigen Tests haben Jenna und ich es ebenfalls mit unterschiedlichen Avataren probiert, 100% Mesh, Standard , mit & ohne rigged Mesh, mit & ohne AO, grosse & kleine Avatare, Cool VL - Firestorm - Linden Viewer, und wir konnten bei keiner Variante irgend welche Gemeinsamkeiten feststellen.

Kurz gesagt, ich habe absolut keine Ahnung, warum es bei jeder Variante mal so und mal so funktioniert/nicht funktioniert.

LG
Dae
 

Users who are viewing this thread

Zurück
Oben Unten