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

Lindenlab ändert massiv die TPV Policy

OK Jenna, da habe ich mich wohl etwas falsch ausgedrueckt.
Gehen wir mal gar nicht so weit weg und sagen, jemand moechte hier im Forum ein Bild anhaengen oder im Pfofil einbauen.
Nun sind hier gewisse Standards und Formate vorgegeben und ich glaube nicht, das Swapps damit einverstanden waere, wenn jemand mit einem Browser XY diese Format-Vorschrift umgeht, um trotzdem etwas, das nicht dem Foren-Standard entspricht hoch zu laden.

LG
Dae
 
Hmm. bin mir nicht sicher, Dae. Wenn ein Bild aus dem Format fällt, zb. Profilbild ist maximal 200x400 und einer lädt 1024x768 hoch, dann wird dieses gelöscht, Swapps kriegt ein Wochenende ruiniert, um den Bug rauszufinden, der Benutzer ggf. einen Permanentbahn, aber das Bild wäre trotzdem für alle im Großformat zu sehen. Aber es liegt dann ein Bug in der Forumsoftware vor, der es möglich macht, so ein Bild hoch zu laden.

Wenn das Bild aber nur in einem speziellen Browser XY im Großformat zu sehen ist, dann müssen die Besucher von diesem Viewer abweichen. Evtl. wird trotzdem gesucht wie das möglich ist, und evtl. wird der Benutzer verwarnt, wenn es Absicht war. Aber die Besucher könnten den Browser wechseln um das Forum normal zu sehen. Dann liegt aber größtentails ein Browserbug vor, der dafür sorgt, dass manchmal Bilder falsch dargestellt sind.

Genau das ist ja wo 2k eingreift, jeder Browser soll sich ans Standard halten. Der IE stellte zb. die Boxen, aus denen der ganze Inhalt einer Webseite besteht, falsch dar. Beim Text ist das kaum zu sehen, aber Menüs, die im Netscape richtig und bündig dargestellt sind, verrutchten im IE, das Design ist ruiniert. Optimiert man für IE, indem man Größenangaben so anpasst, dass alle Abstände richtig eingehalten werden, ist die Darstellung im IE richtig aber man verletzt den WWW Standard und im Netscape ist die Darstellung häßlich. Das ist sowas Ännliches wie Deine Skulptybilder.
 
Zuletzt bearbeitet:
@Dae, etwas durcheinander geraten. Dieser Beitrag war nicht Antwort auf Deinen zuvor, sondern auf Miro's und ich wollte nur seinen Vergleich Viewer/Browser bestätigen:

...Das mit den Browsern vergleichen, das ist prinzipiell richtig...

Allerdings dem hier stimme ich Dir zu:

...Webseiten bieten zum Beispiel, fuer alle Browser den gleichen Inhalt. Jeder Browser ist dazu in der Lage den Inhalt anzuzeigen.
Mit einem Viewer hingegen, kannst du aber den Inhalt, der ebenfalls fuer andere Sichtbar ist, beeinflussen. Und das macht den Unterschied aus....

Das ist wirklich ein Unterschied. Nur bei diesem Detail stimmt glaube ich nicht ganz:

...Wenn jetzt jemand einen Second Life tauglichen Viewer erstellt, ist es voellig egal ob der alle Skins mit pinken tupfen darstellt, solange ein Skin der durch diesen Viewer erstellt wird, nicht fuer andere auch mit pinken tupfen erscheint, wenn es eigentlich in Photoshop anders aussieht...

Also, wenn mein Viewer meine Skin anders backt, etwa mit pinken Tupfer aus dem Tatoolayer, oder sogar oben ohne, und alle mich so sehen würden, dann ist das in ordnung. Ob die Tupfer im Photoschop braun sind oder nicht. Wichtig ist, alle sehen sie pink. Oder, wenn alle ihre Graphikeinstellung gleich stellen, könnten sie ihre Screenshots vergleichen und kommen zum sehr ähnlichen Ergebnis.

Nicht in Ordnung ist nur, wenn die Residents mit Viewern X und Y mich mit den pinken Tupfern sehen würden, aber der Viewer Z die pinke Tupfer aus der gebackenen Textur nicht darstellen kann. Obwohl, würde ich mit dem Lindenviewer on kommen, die Tipfer bei allen Viewern darstellbar wären.
 
Zuletzt bearbeitet:
nene, da hast du mich jettz falsch verstanden.
Ich meinte, wenn du mit deinem Viewer alle Skins mit pinken tupfen sehen wuerdest, ist es egal, solange es dir gefaellt.
Dein Viewer duerfte aber nicht, sagen wir mal aus einer unbehandelten default Skin Template vom Marketplace, ploetzlich einen Skin mit pinken tupfen hoch laden, obwohl die pinken tupfen nicht auf dem Skin vorhanden sind. Wie du selber den Skin dann siehst, ist im enteffect voellig egal, solange alle anderen mit dem Standard-Viewer das Original richtig dargestellt bekommen.

LG
Dae
 
Irgendwie brech ich mir selber immer noch die Zunge an meinem Letzten Beitrag.^^
Ich versuchs mal so einfach wie es mir moeglich ist.

Der Viewer darf keinen Content oder den Avatar selber auf eine weise beeinflussen, die nur fuer diesen einen Viewer richtig dargestellt wird.

Ich glaube das trifft es jetzt ziemlich genau.

LG
Dae
 
@Jenna und Dae

Seid mir ned böse, aber ich glaub, das die Erklärung für diesen Sachverhalt mit Hilfe der Attachementpoints Geschichte wesentlich einfacher und verständlicher wäre, denn ich weiß zwar, was ihr meint, aber :bahnhof

mfg Jori
 
@Jenna und Dae

Seid mir ned böse, aber ich glaub, das die Erklärung für diesen Sachverhalt mit Hilfe der Attachementpoints Geschichte wesentlich einfacher und verständlicher wäre, denn ich weiß zwar, was ihr meint, aber :bahnhof

mfg Jori

Vor allem weil bei den verdoppelten Attachments noch eine Sache mir rein fließt:
Früher gabs 32 Attachment Punkt am Avatar, und an jeden konnte man ein Objekt aus bis zu 254 Prims hängen.
Nun ist der Emerald Viewer mit 64 Attachments rausgekommen, d.h. da wurde im Viewer intern einfach die Anzahl der möglichen Attachments verdoppelt.
Was zum einen zum oft erwähnten Problem mit der Darstellung in anderen Viewern geführt hat, die dann die Attachments irgendwo in der Luft gesehen haben.

Zum anderen aber eben - und das dürfte ein mindestens genauso wichtiger Grund gewesen sein für die neue Policy - führt eine doppelte Belegung von Attachments z.B. bei Furries u.ähnlichen Wesen, zu einer wesentlich höheren Belastung der Server. In Spitzenzeiten sind in SL bis zu 70 000 User gleichzeitig online. Wenn diese (nur mal angenommen) im Schnitt je 10 Attachments haben mit je 50 Prims, dann muss die SL-Infrastruktur 700 000 Attachments mit 3 500 000 Prims verwalten. Nutzen nun aber einige User (und der Emerald hatte schon damals einen großen "Marktanteil"...) einfach mehr Attachments als eigentlich vorgesehen, dann kann es durchaus passieren, dass die SL-Infrastruktur plötzlich 1 Mio Attachments verwalten muss. Und damit z.B. 4 Mio oder 5 Mio Prims. D.h. die Simulatoren haben erheblich mehr Last, gerade auf gut gefüllten Sims. (Dabei wurde schon lange im Rahmen des Viewer2 an einer LL-Lösung gewerkelt, die nichts mit dem Emerald-Hack zu tun hatte: bis zu 38 Attachments die beliebig irgendwo am Avatar angehängt werden können...)

Und genau um derartige Features, welche mehr oder weniger unkontrolliert Serverlast und damit Lag in SL verstärken können, in Zukunft zu verhindern, da ist es einfach unerlässlich, dass irgendwelche neue Features in SL nicht nur ausführlich offiziell getestet werden (beim Emerald wurde das eigentlich einfach veröffentlicht weil es technisch problemlos machbar war...), sondern dass derartige Features auch hinsichtlich des Gesamtsystems bewertet und gegebenenfalls verboten werden. Und das alles kann letztendlich nur LL machen, da sie die einzigen sind, die z.B. einen Überblick über die Belastung der Netzwerke und der Infrastruktur haben. Genau dafür gibt es auch den Snowstorm Code.
 
Danke Shirley. Genau solche Informationen meinte ich mit:

Man muss schon sehr naiv sein um zu glauben, dass Linden Lab es bisher nicht geschafft hat das technisch im offiziellen Viewer umzusetzen.

Ergo hat es schon einen guten Grund, dass diese und viele anderen Funktionen nicht im offiziellen Viewer inkludiert wurden. Und nicht jeder gute Grund sollte/muss mit der Community gemeinsam diskutiert werden. Das schreibe ich ohne jeden Sarkasmus.
 
Burps...

Also Linden Lab bringt mal wieder Änderungen heraus. Diese sind von technisch sinnvoll wie bei den Attachments hin zu merkwürdig bei der Privatsphäre (es gibt keine Privatsphäre in SL, Luke - gewöhn dich dran!) bis hin zu fragwürdig bei den Viewertags, wo es den Beigeschmack hat, als wolle Linden Lab das Versagen des eigenen Viewers vertuschen.

So oder so - die Welt geht davon nicht unter, SL wird weiterhin bestehen bleiben und ich sage voraus, dass auch morgen wieder die Sonne aufgehen wird. Halleluja!
 
Der gute Grund ist ja nun unter der Überschrift "Das geht Dich nichts an" bekannt.

Die Viewer TAGs sind abgeschaltet weil es Dich nichts angeht welche Software jemand benutzt. Ob jemand online ist geht Dich auch nichts an, so Linden.
(Anmerkung: Ich brauche kein Script wenn ich wissen will ob jemand online ist)
Darüber wird es keine Diskussion geben denn SL ist keine Demokratie (FAQ Linden)

Alles andere ist Spekulation und konstruiert.

Also was solls. Griff ins Klo in die Fäkalien um ein Änderung der ToS zu rechtfertigen oder Sandkistengezicke. Mir persönlich ist es egal. Nur für den Support ist es wieder schwieriger, da viele User nicht wissen welchen Viewer sie verwenden oder was ein Viewer ist. Aber auch das ist noch herauszufinden. Es ist nur umständlicher.

Was das gemeinsame Erleben angeht bedarf es keine police damit Entwickler Standards einhalten oder etwas basteln was andere benachteiligt. Das gab es zuletzt mit dem Emerald und ist Geschichte. Die Lehren wurden bereits daraus gezogen.

Linden ist ein profitorientiertes Unternehmen. So verlautet in dessen FAQs. So ist es und nichts anderes ist der Beweggrund für derartigen Blödsinn aus Sicht des SL Users.
 
In meinem von mir getragenen Titler findet sich ab sofort die Angabe meines Viewers...

:)

Das geht auch und mit RLV könnte man einen Titler bauen, der beim Viewer den Typ und Version abfragt. Allerdings finde ich die Behauptung komisch, dass man nicht wissen kann, welchen Viewer man nutzt. Man weiß ja wo und was man herunterlädt und wenn nicht, reicht zwei klicks im Menü. Nur Version kenne ich selber nicht auswendig.

So, ich hatte gestern wo ich on war versucht die Weitergabe des Viewertags zu deaktivieren, also bevor ich mich eingeloggt bin. Ich habe die ganzen Einstellungen des Phoenix durchsucht, fand die Stelle dafür nicht, nur wie man den färbt. Policy sagt, man muss der Weitergabe einer Information zustimmen. Falls der Viewer tatsächlich unabschaltbar den Tag meldet, würd das schon die Policy verletzen.

Falls RLV überlebt, muss in der Einstellungen zumindest eine Checkbox eingebaut werden, die die Weitergabe der Viewerversion erlaubt. Dadurch könnten in Zukunft Geräte nicht mehr funktionieren, die auf Vorhandensein von RLV durch die Versionabfrage (ist standart) prüfen, falls man vergisst, die Checkbox zu aktivieren.

Aber wo kann ich herausfinden wie der Phönix die Tagfarbe übermittelt hat, oder wurde das ebenfalls mittels ungebackenen Texturen erledigt?
 
:)
Falls RLV überlebt, muss in der Einstellungen zumindest eine Checkbox eingebaut werden, die die Weitergabe der Viewerversion erlaubt. Dadurch könnten in Zukunft Geräte nicht mehr funktionieren, die auf Vorhandensein von RLV durch die Versionabfrage (ist standart) prüfen, falls man vergisst, die Checkbox zu aktivieren.

Aber wo kann ich herausfinden wie der Phönix die Tagfarbe übermittelt hat, oder wurde das ebenfalls mittels ungebackenen Texturen erledigt?

Das läuft da ebenfalls über die Texturen, wie beim Firestorm, ist im Prinzip das selbe System. Die infos dazu findest du in llvoavatar.cpp in indra/newview.
D.h. er zeigt dir genau so die Infos über die Viewer anderer User über Ausnutzung dieses Hacks an, und das ist nun nicht mehr erlaubt, egal wie er an die Informationen kommt.
(2.i: You must not display any information regarding the computer system, software, or network connection of any other Second Life user.)

RLV überlebt wohl auf jeden Fall, da diese API nicht unter 2.k fällt. Wobei RLV aber vom user erst aktiviert werden muss, und damit ist das Kommando "@version" nach wie vor erlaubt. Wer nicht will, dass damit die RLV-Version übermittelt wird, der soll das eben nicht aktivieren. Ein Viewer darf keine System- und Viewer-Informationen an andere Viewer weitergeben, es sei denn, der User hat dem zugestimmt. Was er mit der Aktivierung der RLV-API im Viewer aber getan hat. Irgendwelche automatischen Sytemzusammenfassungen, die man dann per Kommando z.B. an einen Support senden kann, die sind ebenso nach wie vor erlaubt.
Ein Viewer darf das aber nicht mehr von alleine machen, ohne dass dem der User zugestimmt hätte. Was z.B. wohl eine Änderung des http-Clients im Viewer zur Folge haben müsste.

(2.j: You must not include any information regarding the computer system, software, or network connection of the user in any messages sent to other viewers, except when explicitly elected by the user of your viewer.)

Und natürlich darf man sich auch immer noch lustige Tags basteln, in denen steht welchen Viewer man selbst gerade verwendet. Dem hat man ja auch zugestimmt.
Nur das ausspionieren ist eben nun verboten.
 
Das läuft da ebenfalls über die Texturen, wie beim Firestorm, ist im Prinzip das selbe System. Die infos dazu findest du in llvoavatar.cpp in indra/newview.
D.h. er zeigt dir genau so die Infos über die Viewer anderer User über Ausnutzung dieses Hacks an, und das ist nun nicht mehr erlaubt, egal wie er an die Informationen kommt...

Danke, ich gucke mir das dann an.

Habe den Titelskript auch heute geschrieben, der unter anderem via RLV an die Viewerangabe kommt und diese anzeigt. Ist in der Library zu finden. Also wer das braucht um festzustellen welchen Viewer jemand hat dem man helfen will, einfach den Titel geben, Nachteil ist vermuttlich, dass Neulinge auch nicht wissen würden wie sie RLV einschalten und ohne RLV kann der Titler nicht ans info kommen.

RLV Viewer Titler
 
Nabend zusammen :)

Soweit ich gelesen habe, geht es nicht nur um Viewereigenschaften, die einem ggf. den Online / Offline Status von jemandem anzeigen, sondern auch um alle Scripte welche die Funktion llRequestAgenData(uuid,DATA_ONLINE) benutzen, um den Offline / Online Status eines Avatars zu checken.

Das alles, nur weil sich hier einige auf Privatsphäre beziehen..das Ergebnis dieser Funktion gibt nur aus ob jemand on oder off ist, weder in welchem Sim er ist, noch die IP, noch sonst irgendwas diesbezueglich..

Leider wird es mal wieder von LL durchgeboxt..wie sovieles..

Es gibt genug Beispiele wo man auf diese Funktion angewiesen ist..sei es auch nur wenn es um zeitbasierte Abrechnungssysteme geht, für Angestellte in Clubs oder das re(senden) von gekauften Objekten seitens eines Vendors, wenn der Avatar wieder online geht.

Gruss, Alex
 
Diese LSL-Funktion wird ja nicht ganz abgeschafft. Der Creator und der Eigentümer des Scripts kann seinen Online-Zustand so nach wie vor anzeigen lassen.
Und was das "einfach so durchgeboxt" angeht... das Metaversum SL ist letztendlich Privateigentum von LL, und da können sie schalten und walten, wie sie Lust haben. Es gibt kein "Recht auf Userbeteiligung", auch wenn sie da andere User rein lassen, nachdem diese genau das akzeptiert haben in der TOS.

Hier bei der Funktion ist nun das Problem, dass darüber eine offiziell vorhandene Privatsphären-Einstellung (Anzeige des Onlinezustandes kann vom User deaktiviert bzw. auf "offline" gestellt werden), umgangen werden kann. Und dies wurde nun abgeschafft.
Aber das Problem ist wohl u.a. auch (das kam z.B. im Phoenix-Meeting zur Sprache...), dass der Server, der die Online-Präsenz verwaltet, von diesen Anfragen wohl schon ordentlich belastet wird. Das sind dabei weniger die Viewer mit dem Script in der Bridge, die beim Öffnen eines Profiles eine entsprechende Anfrage an den Server schicken. Es sind vielmehr gerade Tools wie zeitbasierte Abrechnungssysteme oder Vendoren oder gar ganze Online-Status-Wände, die alle 2 bis 5 Sekunden meist nicht nur eine, sondern gleich 5 bis 20 dieser Anfragen an den Server loslassen. Und da es in SL nicht nur einen Club und nicht nur einen Vendor und nicht nur eine "Who is online now" Wand gibt, kommen da ständig zig tausende dieser Requests beim zentralen Server an. (Und wäre das ein normaler Webserver/Rootserver, wäre das vermutlich eine erstklassige Flooding-Attacke....).

Dabei geht es auch ganz ohne diese LSL-Abfrage, mit einer dezentralen Last-Verteilung:
Die Abrechnungsbasierten Systeme könnten auch über ein simples client-server System funktionieren. D.h. die Angestellten des Clubs tragen einfach ein Prim mit einem Client Script, wenn sie für den Club arbeiten oder online erreichbar sein wollen. Und der Server im Club merkt damit, wer gerade online ist und wer nicht. Zudem kann man den Online-Zustand eines Avatars auf dem selben Simulator auch ohne diese Funktion abfragen, das geht auch z.B. über llGetAgentSize(), was für den Club reichen sollte. Objekte kann man an Avatare auch dann senden, wenn diese nicht online sind. (Wobei dieses offline sein bei einem inworld SL-Vendor wohl eh nur bei einem crash oder ähnlichen vorkommen sollte) Ansonsten kann man auch einfach einen "Resend"-Button am Vendor einbauen.
Alles in allem gibt es also nicht wirklich was, das unbedingt auf diese LSL-Funktion angewiesen ist. Natürlich wird auch erst mal einiges an Content "broken" sein, d.h. die Hersteller müssen wohl updates machen oder neue Produkte erstellen.

Aber letztendlich wird wohl einiges an Serverlast durch llRequestAgentData() reduziert werden und die Privacy-Einstellungen sind dann wohl auch wirksam, d.h. Stalker u.ä. sind dann erst mal ausgebremst.
Und andere Lösungen wie eine Permission-Abfrage mit Beibehaltung der alten Funktion kommen laut Oz aus Performance-Gründen nicht in Frage.
 
Diese LSL-Funktion wird ja nicht ganz abgeschafft. Der Creator und der Eigentümer des Scripts kann seinen Online-Zustand so nach wie vor anzeigen lassen.
Und was das "einfach so durchgeboxt" angeht... das Metaversum SL ist letztendlich Privateigentum von LL, und da können sie schalten und walten, wie sie Lust haben. Es gibt kein "Recht auf Userbeteiligung", auch wenn sie da andere User rein lassen, nachdem diese genau das akzeptiert haben in der TOS.

Sicherlich richtig, aber durch solche und zukuenftige Aktionen (ich schliesse mal nicht aus, das es dabei bleibt, noch das es das 1. mal ist in Richtung "durchboxen" war) .bleiben immer mehr User SL fern oder weichen auf andere Grids aus..sicherlich aber dafür umso leichter auf einem Grid dann was durchzusetzen wo kaum einer mehr ist....Ebay macht da ja auch letztens seine Erfahrungen..aber das ist ein anderes Thema..

Hier bei der Funktion ist nun das Problem, dass darüber eine offiziell vorhandene Privatsphären-Einstellung (Anzeige des Onlinezustandes kann vom User deaktiviert bzw. auf "offline" gestellt werden), umgangen werden kann.

"Privatsphären-Einstellung"..mm..welche bitte? Das ich sehe ob jemand off / on ist den ich nicht in der Kontaktliste habe? Schreckt Stalker wohl kaum ab..die immen einen blind an wenn man off ist..kommt nix zurueck mit ".... offline" labern sie munter drauf los..Mute Button soll da helfen..und da es sonst keine Info preisgibt..so what..

Aber das Problem ist wohl u.a. auch (das kam z.B. im Phoenix-Meeting zur Sprache...), dass der Server, der die Online-Präsenz verwaltet, von diesen Anfragen wohl schon ordentlich belastet wird. Das sind dabei weniger die Viewer mit dem Script in der Bridge, die beim Öffnen eines Profiles eine entsprechende Anfrage an den Server schicken. Es sind vielmehr gerade Tools wie zeitbasierte Abrechnungssysteme oder Vendoren oder gar ganze Online-Status-Wände, die alle 2 bis 5 Sekunden meist nicht nur eine, sondern gleich 5 bis 20 dieser Anfragen an den Server loslassen. Und da es in SL nicht nur einen Club und nicht nur einen Vendor und nicht nur eine "Who is online now" Wand gibt, kommen da ständig zig tausende dieser Requests beim zentralen Server an. (Und wäre das ein normaler Webserver/Rootserver, wäre das vermutlich eine erstklassige Flooding-Attacke....).

Diesen Grund finde ich plausibel und ist durchaus zu verstehen. Auf dem Phoenix Meeting war ich nicht, hab dem Viewer abgeschworen, benutze im moment Singularity, aber der Grund ist nachvollziehbar.

Frage: Koennen nicht die Intervalle zwischen den Anfragen scriptmässig erhoeht werden, so dass die Last geringer wird?

Dabei geht es auch ganz ohne diese LSL-Abfrage, mit einer dezentralen Last-Verteilung:
Die Abrechnungsbasierten Systeme könnten auch über ein simples client-server System funktionieren. D.h. die Angestellten des Clubs tragen einfach ein Prim mit einem Client Script, wenn sie für den Club arbeiten oder online erreichbar sein wollen.

Und der Server im Club merkt damit, wer gerade online ist und wer nicht. Zudem kann man den Online-Zustand eines Avatars auf dem selben Simulator auch ohne diese Funktion abfragen, das geht auch z.B. über llGetAgentSize(), was für den Club reichen sollte.

Test ich dann mal :)


Gruss, Alex
 

Users who are viewing this thread

Zurück
Oben Unten