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

Prims trotz Änderungen an der Verlinkung sicher erkennen?

Jenna Felton

Superstar
Guten Morgen

Ich hätte da noch eine Frage. Und zwar möchte ich bestimmten Prims im Linkset eine Role zuteilen. Zum Beispiel sollen in einem Fahrzeug bestimmte Prims zusammen blinken. Ein einfacher aber fragiler Ansatz ist über die Linknummer. Ich trage die Linknummer der Blinkprims in eine Liste im Blinkskript ein. Der Einsatz ist fragil, sobald einer was entlinkt oder was dazulinkt, haben die Linknummer der Prims verändert. Also muss man nach jedem Umbau am Linkset die neue Linknummer eintragen.

Etwas flexibler geht es, indem man den Prims einen bestimmten Namen oder Beschreibung zuweist. Wird was am Linkset verändert, sucht der Blinkskript automatisch nach neuen Linknummern. Der Ansatz kann aber ein Problem verursachen, wenn im Gerät, wie das Auto in dem Fall, bereits ein System installiert ist, welches die Namen oder Beschriebung der Prims auch belegt und so nicht mehr funktionieren kann.

Dritter Einsatz ist, in die Blinker je ein Skript legen, welches nichts anderes tut, als auf eine Anfrage des Blinkskripts die Linknummer des Trägerprims zu melden. Die Anfrage schickt der Blinkskript, sobald der Linkset verändert wurde und aktualisiert so die Linknummer der Blinkprims. Das Problem, der Ansatz erhöht die Anzahl der installierten Skripte und macht durch diese auch Last, einmal durch Bereitschaft der Skripte, und einmal weil das Ein- und Aussteigen für den Blinkskript wie eine Linksetänderung aussieht.

Gibt es einen anderen Ansatz, die Prims im Linkset nach Linksetänderung erkennt, der aber zum einen keine Zusatzskripte benötigt und zum Anderen die Primbeschreibung und -Name nicht antastet?

LG
Jenna
 
Zuletzt bearbeitet:
Wie wäre es über die Textur UUID?
OK, würde beim nächsten Owner dann nicht mehr funktionieren, es sei denn er bekommt die Textur gleich full perm mitgeliefert.

Ich halte es relativ einfach bei meinen Sachen:
Das Hauptscript hat im Dialogmenü die Option: unbenötigte Scripte löschen
Dann kommt nochmal eine ausführliche Erklärung was man danach nicht mehr machen kann.
Wird es dann mit OK bestätigt, dann löschen sich alle nicht mehr benötigten Scripte und die Last geht runter.
Ich merke es aktuell bei der Arbeit mit Meshes, daß Scripte ganz bös auf den LandImpact gehen können.

Dies wäre die einfachste und sicherste Lösung, ansonsten hast Du ja schon alles aufgezählt.
 
Hallo Archon, danke Dir

Skripte löschen, ist ein guter Ansatz. Danach würde man den Hauptskrit nicht mehr zurücksetzen dürfen. Zumindest kein Hartreset, ein Softreset wo der Skript die Linknummern noch über den Reset irgendwie extern zwischenmerken kann, wäre möglich. Das geht aber in den Bereich "was man hinterher nicht mehr tun darf."
 
Ich mache das in solchen Fällen so, dass ich den Skripts eindeutige Namen gebe.
Dann kann man die Namen z.B. mit llGetScriptName() abfragen, und das Ergebnis mit der ID einer llMessageLinked vergleichen. Man könnte aber auch die UUIDs der Childprims zur Identifizierung verwenden.
 
Oder den Prims Namen geben und die abfragen
das genau wollte sie nicht tun, aber ich bin jetzt schon die zweite, die das ignoriert.
Warum nicht die bereits genutzten Namen/Beschreibungen weiterverwenden (ggf in Kombination) beim initialen Linksetscan (wäre albern bei jedem Blinkaufruf das Linkset neu zu scannen) in state_entry()?
Schliessen sich da einige gegenseitig von der Logik her aus?
Das wäre blöd.

Bleibt wie vorgeschlagen als alternative der Primcontent.
Aber wozu ein ressourcenverschleuderndes Überwachungsscript?
Warum nicht was Passives?
Oh verdammt, man kann in keine Fremdprims hineinsehn. Warum gibts dafür keine Linksetbefehle?

Ok, was hätten wir noch für resetresistente Primeigenschaften?
TargetOmega, SetKeyframedMotion, SitTarget, PrimMediaParams...?
... vielleicht aber warum so kompliziert?
Jedes Prim in der Linkkette hat doch eine eigene UUID und die sollte, wenn Linden nicht gerade wieder am Rad dreht, bis zum nächsten Rezzen deiner Karre persistent sein
 
Ich nutze nicht den Prim-Namen sondern die Beschreibung. Für mehrere Bezeichnungen und Funktionen eines Prims nutze ich die ~ als Trennungszeichen.
 
manchmal brauchst du Mehrere, die sich gegenseitig ausschliessen.
zb Linksets von Möbeln, die Lockmasterketten erzeugen und gleichzeitig auch noch Farben ändern wollen (Farbgruppen wie zb "Holz", "Metall"...)

fällt dir dann noch was Drittes ein, dann entweder wie genannt irgendwie als Stringliste verkettet (siehe OpenCollar), oder ganz wilde Verrenkungen
 
Das mache ich genau so wie ich es beschrieben habe ;)

holz~metall~stahl

Es geht auch mit Leerzeichen aber ich denke das das auch eine Fehlerquelle sein kann.
 
Wie waers mit einer Kombination aus Namen und nummern?
Speicher die Namen Global und lass im changed bzw. state entry eine Funktion zum auslesen der Primnamen aufrufen, welche dann wieder die Nummern der erkannten Prims im llSetLinkPrimitiveParams.... einsetzt.

So brauch das Linkset nur 1x gescannt werden und du benoetigst keine for schleife beim eigentlichen Befehl.
Bleibt nur noch der Hinweis, das man das Linkset ruhig veraendern darf, die Namen der Prims aber nicht.

LG
Dae
 
Danke für Eure Antworten

Namen und Beschreibung sind eigentlich Tabu. Für meinen speziellen Fall. In den Primbeschreibungen stehen laute 0, ~, und weitere Zeichen, da bin ich ganz sicher, dass die von irgendwelchen Scripten der "Karre" benutzt werden. Die Primnamen sind aber meistens (nicht alle) "Object", da dachte ich, benutze ich die einfach. Aber dann kam die Beschwerde, dass irgendwelche Fahrzeugskripte nach Installation meiner Skripte versagt haben, und meine Skripte können sicher nicht schuld daran sein :) daher gehen die Namen auch nicht.

Allgemein gesehen fallen mir noch zwei weitere statische Eigenschaften neben des Namen und Beschreibung ein, der Hovertext und die Textur irgendeiner unsichtbaren Fläche, die man via llGet/SetPP setzen und abfragen kann. TargetOmega ginge auch, aber dann drehen sich die Prims im Linkset, sowas geht nicht. Nur, wenn man das System nicht kennt, welches im Fahrzeug installiert ist, weiß man ja nicht, ob die nicht gerade diese Eigenschaften ebenfalls nutzen.

Wie waers mit einer Kombination aus Namen und nummern?
Speicher die Namen Global und lass im changed bzw. state entry eine Funktion zum auslesen der Primnamen aufrufen, welche dann wieder die Nummern der erkannten Prims im llSetLinkPrimitiveParams.... einsetzt.

Warum nicht die bereits genutzten Namen/Beschreibungen weiterverwenden (ggf in Kombination) beim initialen Linksetscan (wäre albern bei jedem Blinkaufruf das Linkset neu zu scannen) in state_entry()?

Das ist aber interessanter Ansatz. Ich werde überprüfen, ob die Namen der Prims die Blinken sollen, sich eindeutig von Namen anderer Prims unterscheiden (müssen), und ob ich die daran sicher festmachen kann. Das wäre ideal, da ich dann ohne Zusatzskripte in den Prims diese wiederfinden kann.

Die Primsuche bzw. Abfrage der Meldeskripte mache ich aber nicht bei jedem Bliknstart, sondern vor dem ersten Blinkvorgang nach Skriptinitialisierung, da ich da noch keine Linknummern kenne. Und einmal im changed(), wenn sich was am Linkset ändert. Leider mischt sich dabei auch Avatarsetzen mit, so dass ich das echte Umlinken nicht erkennen kann.

Bleibt wie vorgeschlagen als alternative der Primcontent...Oh verdammt, man kann in keine Fremdprims hineinsehn. Warum gibts dafür keine Linksetbefehle?

Das wäre aber ein gutes Featurerequest. Im Content eines anderen Prim zu lesen würde auch sonst Skripten ersparen, und hier würde es garantiert helfen. Da hätte ich in ein Prim einfach eine Notekarte z.B. mit dem Namen "jf.blinker" legen können und schon hätte der Blinkskript das Prim gefunden, egal wie es verlinkt ist.

Ok, was hätten wir noch für resetresistente Primeigenschaften?
TargetOmega, SetKeyframedMotion, SitTarget, PrimMediaParams...?

TargetOmega und PrimMediaParams sind leider visuelle Eigenschaften, die das Prim auch visuell ändern, das geht leider nicht. Eigentlich auch die Hovertext in meinem Vorschlag oben, einige Viewer sollen angeblich das Alpha ignorieren und den "unsichtbaren" Text darstellen.

SitTarget kann man zwar auch vom anderen Prim via llLinkSitTarget setzen, aber wie kriege ich den auch gelesen? Dasselbe bei llSetKeyframedMotion, ich finde irgendwie keine Funktion, die diese Werte auch wieder ausliest.

Jedes Prim in der Linkkette hat doch eine eigene UUID und die sollte, wenn Linden nicht gerade wieder am Rad dreht, bis zum nächsten Rezzen deiner Karre persistent sein

...Man könnte aber auch die UUIDs der Childprims zur Identifizierung verwenden.

Das ist ein Überlegungswerter Ansatz. Beim Rezzen des Fahrzeugs geht der Skript die gespeicherten Linknummern durch und speichert die UUID der Prims. Bei erkanten Umlinkung geht der Skript alle Prims durch und notiert die neuen Linknummern. Der Benutzer, der am Wagen baut, muss sich nur hütten, den zerlegten Wagen ins Inventar zu nehmen, um daran später zu basteln.

Oder der Skript installiert beim bemerkten Zerlegen des Fahrzeugs laufende Sicherungsskripte via llRemoteLoadScriptPin in die jetzt entfernte Prims, die dann nach späteren Einlinken die neue Linknummern vermelden. Das Installieren muss aber möglich sein, also die Pin vorbereitend gesetzt und darf vom System der Fahrzeugskripte ebenfalls nicht benutz/verändert werden, sonst klappt das wieder nicht. Wird aber schon wieder umständlich.
 
Zuletzt bearbeitet:
In den Primbeschreibungen stehen laute 0, ~, und weitere Zeichen, da bin ich ganz sicher, dass die von irgendwelchen Scripten der "Karre" benutzt werden.
probiere deinen Wert mit dem selben Trennzeichen ("~") hinten anzuhängen und dann über den Index -1 auszulesen (falls die unterschiedlich viele Elemente enthalten).
Das könnte nur dann schiefgehn, wenn ACS selbst "-1" (letztes Element) benutzt, was ich für unwahrscheinlich halte, da er die Parameter vermutlich in einer Art API festgelegt hat
 
Die Primsuche bzw. Abfrage der Meldeskripte mache ich aber nicht bei jedem Bliknstart, sondern vor dem ersten Blinkvorgang nach Skriptinitialisierung, da ich da noch keine Linknummern kenne. Und einmal im changed(), wenn sich was am Linkset ändert.
Genau das meinten Dae und ich: Ein einmaliger Linkscan in state_entry(), der eine Liste oder was auch imemr mit deinen "dekodierten" Prims enthält und von CHANGED_LINK neu initiiert wird.

Leider mischt sich dabei auch Avatarsetzen mit, so dass ich das echte Umlinken nicht erkennen kann.
Speichere in state_entry auch den primcount.
Avatare, die sich setzen werden hinten an die Linkkette angehängt und wenn du die Primanzahl von vorm Sitzen kennst, kannst du deine Schleife so gestalten, das die Avatare gar nicht mitgezählt werden.

alternativ über AgentSize() fallentscheiden ob Avatar oder Prim
 
Zuletzt bearbeitet:
Ich meine ich kann nicht erkenen, ob changed() durchs Fummeln am Linkset ausgelöst wurde oder einfach nur durchs Setzen und Aufstehen. Also wird die Prüfschleife dadurch ausgelöst, obwohl gar nicht nötig.

Ich kann evtl aber tatsächlich die Zahl echter Prims merken und beim changed() von hinten prüfen, bzw, den Prim nach dem letzten gemerkten Prim prüfen, ob das ein Avatar ist und wenn ja, dann die Primsuche abbrechen. Ich bin mir aber nicht sicher, ob ich dabei nicht ein echtes Umlinken übersehen kann. Muss ich irgendwie testen.

Das mit dem Zugriff auf Inhalt anderer Prims im Linkset habe ich es mir erlaubt, ein Featurerequest zu machen, da ich keinen fand

https://jira.secondlife.com/browse/BUG-5334

Ist aber länger geworden, weil ich dabei noch Updater und weitere Anwendungen mitgenommen habe. Die hier wichtige Kennzeichnung der Prims durch deren spezielle Inhalte wäre ein kleiner Anwendungsfall davon und irgendwie eher ein kuriöses Nebeneffekt.
 
zuwenig kaffee, also nochmal
so vielleicht?

PHP:
changed(integer change)
{
  if(change & CHANGED_LINK)
  {
    integer lastlink = llGetNumberOfPrims();
    while(--lastlink >= alterprimcount)
    {
       if(llGetAgentSize(lastlink)) // also grösser 0, also avatar
       {
          llOwnerSay("War nur ein Avatar, keine Panik");
          return;
       }
    }
    RescanLinkSet();
  }



und zu dem Jiradings, es wäre natürlich unbedingt unabdingbar also zumindest menscheitsüberlebenswichtig, das wir auch den Inhalt anderer prims löschen können und sowas
 
Zuletzt bearbeitet:
zuwenig kaffee, also nochmal
so vielleicht?

PHP:
changed(integer change)
{
  if(change & CHANGED_LINK)
  {
    integer lastlink = llGetNumberOfPrims();
    while(--lastlink >= alterprimcount)
    {
       if(llGetAgentSize(lastlink)) // also grösser 0, also avatar
       {
          llOwnerSay("War nur ein Avatar, keine Panik");
          return;
       }
    }
    RescanLinkSet();
  }

Sind gleich zwei Fehler drin. In der while-Schleife gehören die beiden Minuszeichen hinter das lastlink, nicht davor. Und llGetAgentSize verlangt nen Key, also muss es llGetAgentSize(llGetLinkKey(lastlink)) heissen.
LG Reb
 
Das war nur vorm Morgenkaffee aus dem Kopf zusammengeschrieben, ich denke das genügt Jenna schon als Anregung
Danke für die Korrektur

Die Befehlsverarbeitung ist von links nach rechts, steht der Operator links wird es vorher ausgeführt
 
Zuletzt bearbeitet:
Ja, fast :) Eigentlich gehören die Minuszeichen hinter dem letzten auftreten von lastlink, also so: llGetAgentSize(llGetLinkKey(lastlink--))

Weil in einem Linkset aus mehr als 1 Prim der erste Prim die Linknummer 1 hat. Daher ist die Nummer, welche llGetNumberOfPrims() liefert, eine echte Nummer des letzten Prims, also muss man die auch prüfen und ganz zum Schluss dekrementieren.

Und eine "Schleife von hinten" muss ich auch nicht machen. Sondern danach prüfen, ob alterprimcount immer noch den echten letzten Prim angibt, also einen echten Prim angibt und der Prm dahinter schon ein Avatar ist. Also wäre die Prüfung so:

PHP:
changed(integer change)
{
    if(change & CHANGED_LINK)
    {
        integer lastlink = llGetNumberOfPrims(); 
        if (lastlink > alterprimcount)
        {
            if (!llGetAgentSize(alterprimcount)
                && llGetAgentSize(alterprimcount+1))
            {
                llOwnerSay("Awatar hat sich hingesetzt.");
                return;
            }
        }
        
        else if (lastlink == alterprimcount)
        {
            if (!llGetAgentSize(alterprimcount))
            {
                llOwnerSay("Awatar ist aufgestanden.");
                return;
            }
        }

        RescanLinkSet();
    }
}

Setzt sich ein Avatar hin, oder mehrere, steigt die Primzahl über die echte Linkzahl. Steigen die alle auf, fällt die Primzahl auf die alte Linkzahl zurück. Fällt die Primzahl unter die alte Linkzahl, wurde was entlinkt. Auch wenn ein Avatar sich hinsetzt und ein Prim entlinkt wird. Dann fällt die Primzahl auf die Linkzahl zurück, aber der letzte Prim ist nicht mehr ein echter Prim.

Ich schätze so kann ich alles erfassen. Unter einer Bedingung, dass es nicht auftreten kann, dass etwas entlinkt und dasselbe Zahl von Prims verlinkt werden, ohne dass zwischen den beiden Ereignissen der changed() - Ereignis ausgelöst wird, um die zwischenzeitlich veränderte Primzahl zu merken und auf die jetzt veränderte Linkreihenfolge der Prims zu reagieren.

Ich bin mir da irgendwie nicht sicher, der touch() Ereignis kann in SL auch aussetzen, um irgendwann später gebündelt zu triggern. Wenn sowas auch mit changed() passieren kann, dann reicht es nicht, nur an der Zahl echter Prims die Veränderung am Linkset festzustellen.

und zu dem Jiradings, es wäre natürlich unbedingt unabdingbar also zumindest menscheitsüberlebenswichtig, das wir auch den Inhalt anderer prims löschen können und sowas

Ja, schon. Es reicht nicht, nur einige Befehle zum entfernten Inhaltzugriff zu definieren. Man kann nur dann auf Hilfsskripte in anderen Prims verzichten, wenn man wirklich für sämmtliche Befehle, die etwas mit dem Priminhalt zu tun haben, auch Befehle zum entfernten Zugriff einführt. Und das wollte ich mit dem Jira machen. Für die Kennzeichnung der Prims durch den Inhalt wäre die angegebene Befehlsliste natürlich zu umfangreich.

Aber ich merke gerade, sogar die Befehlsliste ist immer noch nicht vollständig. Da fehlt noch die llRequestInventoryData.
 
Zuletzt bearbeitet:
...

Dritter Einsatz ist, in die Blinker je ein Skript legen, welches nichts anderes tut, als auf eine Anfrage des Blinkskripts die Linknummer des Trägerprims zu melden. Die Anfrage schickt der Blinkskript, sobald der Linkset verändert wurde und aktualisiert so die Linknummer der Blinkprims. Das Problem, der Ansatz erhöht die Anzahl der installierten Skripte und macht durch diese auch Last, einmal durch Bereitschaft der Skripte, und einmal weil das Ein- und Aussteigen für den Blinkskript wie eine Linksetänderung aussieht.

Gibt es einen anderen Ansatz, die Prims im Linkset nach Linksetänderung erkennt, der aber zum einen keine Zusatzskripte benötigt und zum Anderen die Primbeschreibung und -Name nicht antastet?

LG
Jenna

Warum die Meldung der Linknummer bei Änderung automatisch durchführen? Es wäre doch sicher okay, falls das Linkset gändert wurde,
einen manuellen Reset des Linksets zu veranlassen, und ansonsten bei Ereignissen wie Eigentümerwechsel und Rez. Ein-/Aussteigen sollte
damit umgangen werden, und falls das Childprim nichts anderes tut als die Nummer zu veröffentlichen, sollte Lag keine große Rolle spielen.

LG Michael
 

Users who are viewing this thread

Zurück
Oben Unten