Second Life Wiki - User contributions [en]

Servicestörungen

2010-11-12T23:09:04Z

Phillie Rhode: Typo cleaning/ Umstellung auf neue CT-Richtlinie der Anrede/Einarbeitung der letzten Änderung des englischen Artikels

{{Help/de|Parent=Service Disruptions|BugFixes=*}}

Second Life ist ein komplexes System mit vielen Komponenten, die miteinander interagieren, von den Simulatoren und Datenbanken zu dem Viewer, den Sie am Laufen haben und den Internetverbindungen, über welche die Daten fliessen. Obwohl es als so [http://de.wikipedia.org/wiki/Lose_Kopplung lose gekoppelt] wie möglich und robust gegen Probleme ausgedacht ist, können immer noch Ereignisse auftreten, die zu Störungen bei den Diensten führen.

In manchen Fällen befinden sich die Fehler außerhalb der Kontrolle von Linden Lab. Allerdings wird in fast allen Fällen aktiv daran gearbeitet, Störungen abzuschwächen - entweder sie gar nicht auftreten zu lassen oder die Auswirkung beträchtlich zu reduzieren.

Wenn eine Störung auftritt, tritt normalerweise folgender Ablauf in Kraft:
* ein System hört auf, zu reagieren
* automatische Mitteilungen gehen los, die unser Team, das für den Betrieb verantwortlich ist (Operationsteam), alarmieren
* Oft werden Residents sofort informiert und der inworld Support alarmiert, der unserem Operationsteam das Problem bestätigt
* das Operationsteam erkennt das System, das die Ursache des Problems ist
* das Kommunikationsteam wird benachrichtigt und darum gebeten, die Information über die Störung im Blog bereitzustellen
* wenn die Störung länger als ein paar Minuten dauert, wird das Blog regelmässig aktualisiert
* wenn das Problem dann einmal gelöst ist, wird eine "Alles Klar" Meldung im Blog veröffentlicht

Bitte beachten Sie, daß in vielen Fällen eine Störung behoben sein kann, bevor es möglich ist, eine Information im Blog zu veröffentlichen, um die Einzelheiten des Problems zu erklären. Ein Zweck dieses Dokumentes ist es, ein "Dokumentationszentrum" für Arten von Störungen in den Diensten bereitzustellen, damit das Blogposting sich auf diese Seite beziehen kann, wenn sich ein Systemfehler ereignet.

Zum Zeitpunkt der Erstellung dieses Dokumentes und in keiner besonderen Reihenfolge, sind das die Systeme, von denen bekannt wurde, dass sie Störungen in den Diensten auslösen:

== Assetspeichercluster ==

'''Was es ist:''' Ein Cluster von Maschinen, die einen riesigen [http://de.wikipedia.org/wiki/WebDAV WebDAV] (stellen Sie sich eine "webbasierte Festplatte" vor) Speichermechanismus mit Terabytes von Platz zum Speichern von Beständen, einschliesslich hochgeladener Texturen, Snapshots, Skripten, Objekten, die ins Inventar aufgenommen wurden, Skriptzuständen, gespeicherten Zuständen von Regionen (Simstates), usw., die Second Life ausmachen. Die Technologie dafür (Software und Hardware) ist von einem Drittanbieter lizenziert.

'''Wie ein Fehler auftreten kann:''' Das System sollte gegen Ausfälle einzelner Knoten robust sein. In dem Fall dass mehrere Festplatten ausfallen, bei Softwareaktualisierungen, beim Entfernen fehlerhafter Knoten oder dem Hinzufügen neuer Knoten können einige oder alle der Cluster offline gehen. Wenn das passiert, scheitern das Hoch- und Herunterladen von Beständen - das führt dazu, dass Uploads von Texturen und das Abspeichern von Simstates fehlschlagen. Weil die vorübergehenden Daten beim Überqueren von Regionen (Zustände von Attachmants usw.) als Assets weggeschrieben werden, wird oft auch das Überqueren von Regionen scheitern.

'''Wie wir das beheben:''' Wenn dieser Fehler festgestellt wird, schalten wir oft die Logins ab und schicken inworld eine Nachricht (wenn möglich), um dabei zu helfen, Datenverluste zu vermeiden. Knoten, bei denen Fehler auftraten, können aus der Rotation genommen werden. Ein Neustart von anderen Knoten kann notwendig sein. Wenn die Software auf den Knoten aktualisiert wird, ist der Grid normalerweise geschlossen, um Datenverluste während irgendwelchen ungewollten Ausfällen zu verhindern. Ein Fehler im Assetsystem, der einen Neustart erforderlich machte, trat am [http://blog.secondlife.com/2008/03/28/asset-server-issues/ 28. März 2008]{{nnlink/de}} und am [http://status.secondlifegrid.net/2008/05/13/post70/ 14. Mai 2008]{{nnlink/de}} auf.

== Zentraler Datenbankcluster ==

'''Was es ist:''' Ein Cluster von Datenbanken, der die grundlegenden, gleichbleibenden Informationen über Second Life speichert - einschliesslich den Profilen von Residents, Gruppen, Regionen, Grundstücke, L$ Transaktionen und Kleinanzeigen.

'''Wie ein Fehler auftreten kann:''' Die Datenbank kann während dem Normalbetrieb ausgelastet werden, sodass ein Teil von Transaktionen fehlschlägt und entweder von Hand erneut versucht werden muss oder automatisch erneut versucht werden. Hardwareausfälle oder Softwarefehler im Programmcode der Datenbank können auch dazu führen, daß die Datenbank abstürzt oder aufhört, zu reagieren. Logins werden fehlschlagen, Transaktionen inworld und auf der Website werden scheitern und so weiter.

'''Wie wir das beheben:''' Wenn die primäre Datenbank ausfällt, wechseln wir auf eine der sekundären. Wenn die Belastung der Datenbank zu hoch ist, sie aber nicht ausgefallen ist, können wir Dienste abschalten, um zu versuchen, die Belastung zu reduzieren.

''Das Eliminieren dieses Clusters als Flaschenhals bei der Skalierbarkeit und Ausfallpunkt hat eine sehr hohe Priorität für Linden Lab. Während das in Arbeit ist, tritt eine Abmilderung der Belastung auf. Behaltet das [http://blog.secondlife.com/2008/04/07/profile-and-group-services-temporarily-unavailable/ Second Life Blog]{{nnlink/de}} im Auge, um aktuelle Informationen zu bekommen''

== Agenten- ("Inventar-") Datenbankcluster ==

'''Was es ist:''' Speicher für die meisten agentenspezifischen Daten wie den Inventarbaum ist über eine Reihe von Datenbanken verteilt. Jeder Agent ist einem bestimmten Inventarspeicherbereich (einer primären Datenbank und ihren sekundären Sicherungen) zugeordnet. Zum Zeitpunkt, als dieses Dokument geschrieben wird, haben wir ungefähr 15 Speicherbereiche für Agentendatenbanken.

Die ursprüngliche Verwendung dieser nach Agenten unterteilten Datenbanken war für das Inventar, so dass sie von Lindens oft als "Inventardatenbanken" bezeichnet werden, aber das ist nicht mehr länger ein Ausdruck dafür, welche agentenspezifischen Daten in ihnen gespeichert werden.

'''Wie ein Fehler auftreten kann:''' Hardware- oder Softwareausfälle können die primäre Datenbank innerhalb eines Speicherbereiches beeinflussen, sodass sie entweder nicht mehr auf Anfragen reagiert oder überaus langsam wird.

'''Wie wir das beheben:''' Wenn eine Agentendatenbank ausfällt, können wir auf die Sicherung innerhalb dieses Speicherbereiches umschalten, was einige Minuten dauert. Wenn das nicht sofort passiert oder wenn Probleme festgestellt werden, wird dieser bestimmte Agentenspeicherbereich vorübergehend "auf eine schwarze Liste gesetzt"; das führt dazu, daß Logins von Agents, die diesem Speicherbereich zugeordnet sind, blockiert werden und alle eingeloggten Agents "gekickt" werden, während die Behebung des Fehlers in Arbeit ist. Das beeinträchtigt einige Teile des Grids, aber nicht jeden.

''Das ist ein Beispiel für ein System, das in der Vergangenheit dafür bekannt war, eine globale Störung der Dienste auszulösen. Es wurde neu entworfen, um die Auswirkung auf die Residents auch in Anbetracht eines Hardwareausfalles zu begrenzen; nur Residents, die einem bestimmten Speicherbereich zugeordnet sind, werden während eines solchen Ausfalles beeinträchtigt''

== Andere Datenbankcluster ==

'''Was es ist:''' Es gibt eine Handvoll weiterer Datenbankcluster, die in Verwendung sind. Einer davon wird für die Logdateien (Protokolldateien) verwendet.

'''Wie ein Fehler auftreten kann:''' Hardware- oder Softwareausfälle können einen Datenbankcluster dazu bringen, offline zu gehen. Es sollten keine Auswirkungen inworld davon zu spüren sein, wenn einer dieser Datenbankcluster ausfällt, aber gelegentlich führt eine Unaufmerksamkeit im Softwareentwurf zu einer Abhängigkeit, die nicht abgefangen wird. Zum Beispiel haben Logins üblicherweise eine erfolgreiche Verbindung zu der Logindatenbank erfordert, um die Login- und Viewerstatistik aufzuzeichnen, aber diese Abhängigkeit wurde entfernt.

'''Wie wir das beheben:''' Alle Datenbanken in Clustern laufen auf einer Primärmaschine und verschiedenen Sekundärmaschinen. Im Fall eines Fehlers kann eine Sekundärmaschine an die Stelle der Primärmaschine gesetzt werden.

''Unser Datawarehousing Team hat innerhalb des letzten Jahres eine bedeutende Arbeit geleistet, um sicherzustellen, dass die ständig anwachsende Menge an Daten über die Performance von Simulatoren und anderen Systemen, die aufgezeichnet werden, analysiert werden kann und dass die Sammlung dieser Daten "transparent" für die anderen Systeme geschieht - der Ausfall von Protokolldatenbanken sollte nicht mehr länger zu Ausfällen der Dienste führen.''

== Dienste für vorübergehende Daten ==

'''Was es ist:''' Ein Cluster von Maschinen (derzeit: 16), die Daten im Gedächtnis halten, die "flüchtiger" Natur sind. Das beinhaltet Dinge wie die Gegenwart von Agents ("Wer ist eingeloggt?"), Teilnahme an Gruppenchats, die Umsetzung von eingehenden Emails in Skripten und so weiter. Diese Daten werden nicht in einer Datenbank gespeichert und werden entweder ständig aufgefrischt (zum Beispiel aktualisiert der Simulator alle paar Minuten die Gegenwart von Agents) oder aber wiederherstellbar (zum Beispiel durch das erneute Aufrufen eines Gruppenchats).

'''Wie ein Fehler auftreten kann:''' Hardwareausfälle können das Fassungsvermögen dieser Maschinen vermindern oder sie auch komplett offline nehmen. Softwarefehler können auch eine sehr schwache Performance verursachen - zum Beispiel führt ein Speicherleck in einem Dienst dazu, daß die Dienste insgesamt anfangen, langsam zu reagieren. Wenn ein bestimmter Dienst unterbrochen ist, werden die anderen Dienste insgesamt weiterhin funktionsfähig bleiben.

'''Wie wir das beheben:''' Weil der Status vorübergehend und flüchtig ist, kann eine Ersatzmaschine schnell online gebracht werden und die Daten "heilen" sich selbst mit der Zeit. Wenn der Fehler softwareseitig ist, können die Dienste einfach mit wenig Auswirkungen für die Residents neu gestartet werden, sobald eine Fehlerbehebung für das Problem gefunden ist.

== Simulatoren ==

'''Was es ist:''' Eine [[Glossary#Sim|sim]]{{nnlink/de}} ist eine Maschine, auf der [[Glossary#Simulator|Simulatoren]]{{nnlink/de}} laufen, welche wiederum Computerprozesse sind, auf denen [[region|Regionen]]{{nnlink/de}} laufen. (Stellen Sie sich eine ''Region'' wie ein Dokument vor, den ''Simulator'' wie ein Textverarbeitungsprogramm und die ''Sim'' als den Computer selbst, auf dem das Programm läuft.) Weil es sich dabei um eng verwandte Konzepte handelt, tendiert der Jargon/die Terminologie und Ausdrucksweise dazu, etwas unklar zu sein, zum Beispiel sollte der "Simstatus" in Wirklichkeit "Status der Region" sein. Der Simulator teilt seine Zeit auf die Kommunikation mit Viewern, die Kommunikation mit anderen Systemkomponenten, das Simulieren von physikalischen Vorgängen und das Ausführen von Skripten auf.

'''Wie ein Fehler auftreten kann:''' Ein Fehler im Programmcode des Simulators kann einen Absturz verursachen. Die meisten Abstürze führen dazu, daß der Simstatus einer Region abgespeichert wird und ein anderer Simulator diesen Simstatus nach ein paar Minuten laden wird. Oft wird der Fehler auch durch einige bestimmte Arten von Inhalten einer Region ausgelöst - einem Skript oder einem physikalischen Objekt.

Andere Probleme teilen sich in zwei Kategorien auf - Probleme mit einer bestimmten Sim oder gridweite Probleme. Probleme mit einer bestimmten Sim können aus einer Überlastung (zum Beispiel 4 Regionen mit hohem Traffic auf einer Sim) oder Fehlern (Speicherplatz erschöpft, Netzwerkkarte verloren, Hardwarefehler) bestehen. Gridweite Probleme sind gewöhnlich durch andere Faktoren ausgelöst, als sie hier aufgelistet sind, so zum Beispiel Verlust der Netzwerkanbindung oder Datenbankfehler oder Fehler im Assetcluster (welche zum Beispiel dazu führen können, dass Simulatoren daran gehindert werden, Simstati zu laden. Neue Programmcodes für die Simulatoren bringen manchmal Fehler mit gridweiten Auswirkungen ein (zum Beispiel verursacht übermässiges Protokollieren eine Überlastung durch den Netzwerkverkehr.)

'''Wie wir das beheben:''' Simulatorabstürze werden genauso wie Viewerabstürze berichtet. Wir können die Daten dazu nutzen, das grundlegende Untersystem festzulegen, das den Absturz ausgelöst hat (die Initialisierung, Physikengine, Skripte, Nachrichtenübermittlung usw.). Wenn der Absturz durch Inhalte (Skripten oder physikalische Objekte) ausgelöst wurde, können wir die Absturzdaten dazu verwenden, festzustellen, warum er aufgetreten ist. In der Zwischenzeit (da eine Fehlerbehebung auch einige Tage dauern kann oder im Fall von Problemen mit der Physikengine ein Projekt wie der Umzug auf Havok4 notwendig ist), wird die Region wieder mit deaktivierten Skripten/physikalischen Eigenschaften und nach dem Entfernen der auslösenden Objekte online gebracht.

Probleme mit einer bestimmten Sim können durch das Neustarten der Regionen in den Griff bekommen werden, was dazu führt, dass ein Simulatorprozess auf einer anderen Sim sie laufen lässt. Gridweite Probleme werden vorzugsweise an der Quelle behoben (zum Beispiel durch die Reparatur des Netzwerks). Bugs in Veröffentlichungen von neuem Programmcode erfordern entweder eine Änderung der Konfiguration (um ein neues Feature abzuschalten) oder einen rolling Restart mit aktualisiertem Code.

''Die Reduzierung von Simulatorabstürzen war die Hauptmotivation hinter dem Umstieg auf [[Havok4]]{{nnlink/de}} für die Physiksimulation und den bevorstehenden Umstieg auf [[Mono]]{{nnlink/de}} für die Skriktausführung.''

== Datenserver ==

'''Was es ist:''' Die meiste Kommunikation zwischen dem Simulator zur Datenbank wird durch einen Prozess, der "Datenserver" heißt, zwischengespeichert; es gibt einige wenige Datenserverprozesse auf jedem Simhost. Das verhindert eine direkte Abhängigkeit von der Datenbank und erlaubt es dem Datenserver, auch eine längere Abfrage zu blockieren, während der Simulator eine bestimmte Framerate zu erreichen versucht.

'''Wie ein Fehler auftreten kann:''' Der Datenserverprozess kann aufgrund von Bugs abstürzen, die in Bezug zu unvorhergesehenen Umständen stehen. Zum Beispiel, wenn ein kurzer Netzwerkausfall auftritt, kann die Verbindung zu einer Datenbank verlorengehen. Normalerweise erholt sich das System gutmütig und transparent von einem Fehler mit dem Datenserver, aber bei einem bestimmten Simulator können einige Transaktionen vorübergehend scheitern. Die Unterbrechung der Dienste ist auf den bestimmten Simulator beschränkt. Es ist auch möglich, dass ein Softwareupdate Bugs mit einbringen kann, die gridweite Effekte auslösen können (zum Beispiel erhöhte Last auf den zentralen Datenbanken oder einfach häufigere Abstürze). Wenn eine Datenbank nicht auf Verbindungsanfragen reagiert, wird der Überwachungsdienst den Datenservers automatisch anhalten und den Datenserver neu starten, damit neue Anfragen bearbeitet werden können.

'''Wie wir das beheben:''' Wenn ein einzelner Datenserver abstürzt, wird er automatisch wieder hergestellt. Wenn ein Bug einbracht wurde, der gridweite Effekte auslöst, können die Datenserverprozesse normalerweise ohne Downtime ersetzt werden.

''Die Datenserverkomponente ist dabei, ausgeschaltet und durch webbasierte Datenserverdienste ersetzt zu werden; Simulatoren werden HTTP verwenden, um mit einer neuen Art von Hosts zu reden, die als Relaisstation für Anfragen an die Datenbank dienen. Das wird uns dir Möglichkeit geben, das System leichter zu modifizieren, um die Performance zu verbessern und Unterbrechungen auszuschalten.''

== Login Server Cluster ==

'''Was es ist:''' Ein Cluster von Servern, der den ersten Dienst bereitstellt, mit dem der Viewer sich verbindet, wenn versucht wird, sich einzuloggen. Dieser überprüft die Benutzerdaten des Residents, prüft die Viewerversion auf mögliche Updates und stellt sicher, dass die neuesten Benutzerbestimmungen (Terms of Service) aktualisiert wurden. Angenommen, alle Überprüfungen verlaufen positiv, sendet der Cluster eine erste Übersicht über die Inventarordner des Residents und einige wenige weitere Teile von Daten. Schliesslich verhandelt er mit dem Simulator für die gewünschte Startregion und lässt den Viewer wissen, mit welchem Simulator er zu reden hat.

'''Wie ein Fehler auftreten kann:''' Wenn ein Server offline geht, wird ein gewisser Prozentsatz an Logins scheitern. Zusätzlich werden Logins auch scheitern, wenn wenn die zentrale Datenbank oder der Cluster der Inventardatenbank Probleme haben, da der Ablauf des Logins sehr datenbankintensiv ist. Schliesslich kann es auch passieren, dass nach einer grösseren Unterbrechung die dazu führte, dass die Mehrzahl der Residents ausgeloggt wurde oder sich nicht einloggen konnte, mehr Residents versuchen, sich einzuloggen, als unser Second Life verarbeiten kann (ungefähr 1000 Logins/Minute); das kann dann für Residents, die versuchen, sich einzuloggen, so aussehen, als ob der Logindienst fehlerhaft ist, obwohl er voll einsatzbereit ist und nur bei maximaler Kapazität läuft.

'''Wie wir das beheben:''' Wenn ein Loginserver selbst ausfällt, nehmen wir diesen aus der Rotation der Server. Wenn das Problem in einem anderen System oder Dienst begründet liegt, beheben wir es dort.

== Web Site ==

'''Was es ist:''' Ein Cluster von Maschinen, die die Webseiten und Webdienste bedienen, die der Öffentlichkeit zur Verfügung stehen - diese enthalten secondlife.com, lindenlab.com, slurl.com, usw.

'''Wie ein Fehler auftreten kann:''' Hardwareausfälle können eine Maschine im Webcluster verlangsamen oder herunterfahren. In diesem Fall sollten Lastverteiler den Webtraffic von der Maschine, die langsam arbeitet, umleiten, aber der Lastverteiler selbst kann auch Fehler haben (zum Beispiel solche Ausfälle nicht sauber erkennen oder selbst blockiert werden). Fehler in den Websites können durch Codeaktualisierungen an den Websites, die täglich passieren, eingebracht werden. Ausserdem beruht die Website für viele Aktionen der Dienste auf dem zentralen Datenbankcluster, deshalb werden Fehler dort sich auch auf Tätigkeiten und Dienste auf der Website wie LindeX und Transaktionsverlauf, Landstore, Freunde online und so weiter auswirken.

'''Wie wir das beheben:''' Problematische Hardware kann aus der Rotation genommen werden, um die Reaktionsfähigkeit der Website wieder herzustellen. Probleme in anderen Systemen wie dem zentralen Datenbankcluster müssen dort in den Griff bekommen werden.

== Linden Netzwerk ==

'''Was es ist:''' Die Leitungen, durch die das Zeug reist. Vor Allem die Verbindungen zwischen unseren Zweigniederlassungen (co-location facilities = "colos"), zum Beispiel San Francisco und Dallas. aber auch die Leitungen innerhalb der Colos. Das beinhaltet "VPNs", Switches, Router und andere esoterische Dinge. Manches davon ist Ausstattung, die Linden gehört, manches ist gemietete Ausrüstung (zum Beispiel bezahlen wir einen Drittanbieter dafür, dass wir seine "Leitungen" zwischen unseren Colos alleine benutzen können) und es werden auch öffentliche Internetverbindungen genutzt.

'''Wie ein Fehler auftreten kann:''' Eine Komponente kann ausfallen; zum Beispiel kann ein Router damit beginnen, Pakete zu verwerfen (aufhören, Daten zu senden). Das sieht dann oft so aus, als ob ein anderes System (Assetspeicher, Datenbank, Simulatoren, Logins) fehlerhaft wäre, da die Systeme nicht mehr länger miteinander kommunizieren können. Der [http://blog.secondlife.com/2008/04/05/logins-disabled-until-further-notice/ Ausfall am 05. April 2008]{{nnlink/de}} ist ein Beispiel für diese Art von Fehler.

'''Wir wir es beheben:''' Die fehlerhafte Komponente so schnell wie möglich herausfinden und außer Betrieb nehmen oder ersetzen. Wenn es sich um eine gemietete Komponente handelt, müssen wir mit unserem Anbieter reden.

== Internet ==

'''Was es ist:''' Eine [http://en.wikipedia.org/wiki/Series_of_tubes Reihe von Leitungen]{{nnlink/de}}, die Second Life zu Ihrem Computer bringen, von den großen transatlantischen und transkontinentalen Leitungen, die die Welt verbinden, bis hinunter zu der Breitbandverbindung von Ihrem Internetanbieter (Internet Service Provider (ISP)) zu Ihrem Zuhause.

'''Wie ein Fehler auftreten kann:''' Fehler können auf verschiedenen Ebenen auftreten. Wenn es auf einen hohen Level passiert - zum Beispiel wenn eine Hauptverbindung nach Europa offline geht - können Tausende von Residents die Verbindung zu Second Life verlieren.

'''Wie wir es beheben:''' Das ist normalerweise außerhalb unserer Kontrolle. Wenn wir das Problem isolieren können, können wir es an Netzwerkkontakte weitermelden, aber ansonsten müssen wir warten, bis das Problem behoben worden ist, genauso wie die Residents.

Koordinatenbezugssysteme im Viewer

2010-11-11T14:06:15Z

Phillie Rhode:

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|Region]], die das Objekt "besitzt".

=== Agent ===
Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird. Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)

=== Lokal ===
Derzeit ein Sammelbegriff für Bezugssysteme, die nicht eines der oben erklärten sind. Im Allgemeinen die Positionierung relativ zu einem Objekt.

In [[LSL]] wird das lokale Bezugssystem auf zwei Arten genutzt:
:<h4> Childprims </h4>
:Childprims (nicht Rootprims) werden lokal zum Rootprim positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Rootprims beeinflusst.
:<h4> Attachments </h4>
:Objekte, die angezogen werden, werden lokal zum Tragepunkt positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Avatars und den abgespielten Animationen beeinflusst.

= Namenskonventionen =
ALLE Variablen/Klassenmitglieder, die mit Werten aus einem dieser Bezugssysteme zu tun haben, sollten in Namen nachgestellt das Bezugssystem haben, das verwendet wird. BITTE tun Sie das - es hilft großartig dabei, Fehler zu vermindern.

Zum Beispiel:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Konvertierungsfunktionen =
In LLAgent und LLViewerRegion sind Konvertierungsfunktionen zur Umwandlung von einem Bezugssystem in ein anderes implemetiert. Sie haben eine Syntax der Form getPos<Ziel>From<Quelle>() - zum Beispiel konvertiert getPosAgentFromGlobal() vom globalen in das Agent Bezugssystem.

= Typumwandlung =
Um den sehr genauen globalen Koordinaten gerecht zu werden, gibt es die neue Klasse LLVector3d, der Name kommt von LLVector3, doppelte Genauigkeit. das ist zwar in gewisser Hinsicht nicht konsistent zur bisherigen Namensgebung, aber die einzige andere Alternative wäre es gewesen, ALLE mathematischen Klassen umzubenennen, um die aus GL kommende Typkonvention mit dem letzten Buchstaben zu verwenden, wozu ich nicht in der Lage gewesen wäre.

ALLE Berechnungen, die mit globalen Koordinateen durchgeführt werden, sollten unter der Verwendung von LLVector3d gemacht werden. Derzeit geben alle Funktionen, die globale Koordinaten als Rückgabewerte haben, diese im Typ LLVector3d zurück. Die momentan EINZIGE Ausnahme dazu ist Audio, bei dem ich die Werte in normale LLVector3 umwandle, bevor ich sie an die Audioengine übergebe - Ich denke, das wird auch so lange der Fall bleiben, bis wir die Audioengine dahingehend unstellen, daß sie Agentkoordinaten verwendet.

Die Klasse LLVector3d enthält ABSICHTLICH KEINERLEI Form einer automatischen Typumwandlung zwischen ihr und der Klasse LLVector3. Weil die Umwandlung hin und zurück nicht einfach ist (und wahrscheinlich auch zum Verlust von Genauigkeit führt), müssen Sie explizit einen setVec() zu der anderen Klasse setzen, um in die eine oder andere Richtung umzuwandeln.

Koordinate

2010-08-22T11:29:20Z

Phillie Rhode:

{{help/de
|Glossary=*
|Parent=Coordinate}}

Eine Koordinate ist die durch einen Vektor (x,y,z) dargestellte Position im dreidimensionalen Raum. Die aktuellen Koordinaten des Avatars eines Bewohners sind normalerweise am oberen Rand des Bildschirms neben dem Namen der Parzelle, auf der Sie sich befinden, angezeigt. Diese Koordinaten geben die Position auf der Simulator an ("sim-lokal", nicht "global").
== Lesen Sie dazu auch ==
* [[Koordinatenbezugssysteme_im_Viewer|Koordinatenbezugssysteme im Viewer]]

Koordinate

2010-08-22T11:28:20Z

Phillie Rhode: Replaced link to German article

Viewer coordinate frames/de

2010-08-21T15:57:46Z

Phillie Rhode: moved Viewer coordinate frames/de to Koordinatenbezugssysteme im Viewer: Translation

#REDIRECT [[Koordinatenbezugssysteme im Viewer]]

Koordinatenbezugssysteme im Viewer

2010-08-21T15:57:46Z

Phillie Rhode: moved Viewer coordinate frames/de to Koordinatenbezugssysteme im Viewer: Translation

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|Region]], die das Objekt "besitzt".

=== Agent ===
Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird. Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)

=== Lokal ===
Derzeit ein Sammelbegriff für Bezugssysteme, die nicht eines der oben erklärten sind. Im Allgemeinen die Positionierung relativ zu einem Objekt.

In LSL wird das lokale Bezugssystem auf zwei Arten genutzt:
:<h4> Childprims </h4>
:Childprims (nicht Rootprims) werden lokal zum Rootprim positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Rootprims beeinflusst.
:<h4> Attachments </h4>
:Objekte, die angezogen werden, werden lokal zum Tragepunkt positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Avatars und den abgespielten Animationen beeinflusst.

= Namenskonventionen =
ALLE Variablen/Klassenmitglieder, die mit Werten aus einem dieser Bezugssysteme zu tun haben, sollten in Namen nachgestellt das Bezugssystem haben, das verwendet wird. BITTE tun Sie das - es hilft großartig dabei, Fehler zu vermindern.

Zum Beispiel:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Konvertierungsfunktionen =
In LLAgent und LLViewerRegion sind Konvertierungsfunktionen zur Umwandlung von einem Bezugssystem in ein anderes implemetiert. Sie haben eine Syntax der Form getPos<Ziel>From<Quelle>() - zum Beispiel konvertiert getPosAgentFromGlobal() vom globalen in das Agent Bezugssystem.

= Typumwandlung =
Um den sehr genauen globalen Koordinaten gerecht zu werden, gibt es die neue Klasse LLVector3d, der Name kommt von LLVector3, doppelte Genauigkeit. das ist zwar in gewisser Hinsicht nicht konsistent zur bisherigen Namensgebung, aber die einzige andere Alternative wäre es gewesen, ALLE mathematischen Klassen umzubenennen, um die aus GL kommende Typkonvention mit dem letzten Buchstaben zu verwenden, wozu ich nicht in der Lage gewesen wäre.

ALLE Berechnungen, die mit globalen Koordinateen durchgeführt werden, sollten unter der Verwendung von LLVector3d gemacht werden. Derzeit geben alle Funktionen, die globale Koordinaten als Rückgabewerte haben, diese im Typ LLVector3d zurück. Die momentan EINZIGE Ausnahme dazu ist Audio, bei dem ich die Werte in normale LLVector3 umwandle, bevor ich sie an die Audioengine übergebe - Ich denke, das wird auch so lange der Fall bleiben, bis wir die Audioengine dahingehend unstellen, daß sie Agentkoordinaten verwendet.

Die Klasse LLVector3d enthält ABSICHTLICH KEINERLEI Form einer automatischen Typumwandlung zwischen ihr und der Klasse LLVector3. Weil die Umwandlung hin und zurück nicht einfach ist (und wahrscheinlich auch zum Verlust von Genauigkeit führt), müssen Sie explizit einen setVec() zu der anderen Klasse setzen, um in die eine oder andere Richtung umzuwandeln.

Koordinatenbezugssysteme im Viewer

2010-08-21T15:53:32Z

Phillie Rhode: /* Type conversion */ Translated

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|Region]], die das Objekt "besitzt".

=== Agent ===
Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird. Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)

=== Lokal ===
Derzeit ein Sammelbegriff für Bezugssysteme, die nicht eines der oben erklärten sind. Im Allgemeinen die Positionierung relativ zu einem Objekt.

In LSL wird das lokale Bezugssystem auf zwei Arten genutzt:
:<h4> Childprims </h4>
:Childprims (nicht Rootprims) werden lokal zum Rootprim positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Rootprims beeinflusst.
:<h4> Attachments </h4>
:Objekte, die angezogen werden, werden lokal zum Tragepunkt positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Avatars und den abgespielten Animationen beeinflusst.

= Namenskonventionen =
ALLE Variablen/Klassenmitglieder, die mit Werten aus einem dieser Bezugssysteme zu tun haben, sollten in Namen nachgestellt das Bezugssystem haben, das verwendet wird. BITTE tun Sie das - es hilft großartig dabei, Fehler zu vermindern.

Zum Beispiel:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Konvertierungsfunktionen =
In LLAgent und LLViewerRegion sind Konvertierungsfunktionen zur Umwandlung von einem Bezugssystem in ein anderes implemetiert. Sie haben eine Syntax der Form getPos<Ziel>From<Quelle>() - zum Beispiel konvertiert getPosAgentFromGlobal() vom globalen in das Agent Bezugssystem.

= Typumwandlung =
Um den sehr genauen globalen Koordinaten gerecht zu werden, gibt es die neue Klasse LLVector3d, der Name kommt von LLVector3, doppelte Genauigkeit. das ist zwar in gewisser Hinsicht nicht konsistent zur bisherigen Namensgebung, aber die einzige andere Alternative wäre es gewesen, ALLE mathematischen Klassen umzubenennen, um die aus GL kommende Typkonvention mit dem letzten Buchstaben zu verwenden, wozu ich nicht in der Lage gewesen wäre.

ALLE Berechnungen, die mit globalen Koordinateen durchgeführt werden, sollten unter der Verwendung von LLVector3d gemacht werden. Derzeit geben alle Funktionen, die globale Koordinaten als Rückgabewerte haben, diese im Typ LLVector3d zurück. Die momentan EINZIGE Ausnahme dazu ist Audio, bei dem ich die Werte in normale LLVector3 umwandle, bevor ich sie an die Audioengine übergebe - Ich denke, das wird auch so lange der Fall bleiben, bis wir die Audioengine dahingehend unstellen, daß sie Agentkoordinaten verwendet.

Die Klasse LLVector3d enthält ABSICHTLICH KEINERLEI Form einer automatischen Typumwandlung zwischen ihr und der Klasse LLVector3. Weil die Umwandlung hin und zurück nicht einfach ist (und wahrscheinlich auch zum Verlust von Genauigkeit führt), müssen Sie explizit einen setVec() zu der anderen Klasse setzen, um in die eine oder andere Richtung umzuwandeln.

Koordinatenbezugssysteme im Viewer

2010-08-21T13:27:59Z

Phillie Rhode: /* Conversion functions */ translated

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|Region]], die das Objekt "besitzt".

=== Agent ===
Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird. Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)

=== Lokal ===
Derzeit ein Sammelbegriff für Bezugssysteme, die nicht eines der oben erklärten sind. Im Allgemeinen die Positionierung relativ zu einem Objekt.

In LSL wird das lokale Bezugssystem auf zwei Arten genutzt:
:<h4> Childprims </h4>
:Childprims (nicht Rootprims) werden lokal zum Rootprim positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Rootprims beeinflusst.
:<h4> Attachments </h4>
:Objekte, die angezogen werden, werden lokal zum Tragepunkt positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Avatars und den abgespielten Animationen beeinflusst.

= Namenskonventionen =
ALLE Variablen/Klassenmitglieder, die mit Werten aus einem dieser Bezugssysteme zu tun haben, sollten in Namen nachgestellt das Bezugssystem haben, das verwendet wird. BITTE tun Sie das - es hilft großartig dabei, Fehler zu vermindern.

Zum Beispiel:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Konvertierungsfunktionen =
In LLAgent und LLViewerRegion sind Konvertierungsfunktionen zur Umwandlung von einem Bezugssystem in ein anderes implemetiert. Sie haben eine Syntax der Form getPos<Ziel>From<Quelle>() - zum Beispiel konvertiert getPosAgentFromGlobal() vom globalen in das Agent Bezugssystem.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Koordinatenbezugssysteme im Viewer

2010-08-21T13:23:51Z

Phillie Rhode: /* Namenskonventionen */

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|Region]], die das Objekt "besitzt".

=== Agent ===
Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird. Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)

=== Lokal ===
Derzeit ein Sammelbegriff für Bezugssysteme, die nicht eines der oben erklärten sind. Im Allgemeinen die Positionierung relativ zu einem Objekt.

In LSL wird das lokale Bezugssystem auf zwei Arten genutzt:
:<h4> Childprims </h4>
:Childprims (nicht Rootprims) werden lokal zum Rootprim positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Rootprims beeinflusst.
:<h4> Attachments </h4>
:Objekte, die angezogen werden, werden lokal zum Tragepunkt positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Avatars und den abgespielten Animationen beeinflusst.

= Namenskonventionen =
ALLE Variablen/Klassenmitglieder, die mit Werten aus einem dieser Bezugssysteme zu tun haben, sollten in Namen nachgestellt das Bezugssystem haben, das verwendet wird. BITTE tun Sie das - es hilft großartig dabei, Fehler zu vermindern.

Zum Beispiel:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Koordinatenbezugssysteme im Viewer

2010-08-21T13:22:53Z

Phillie Rhode: /* Naming conventions */ translated

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|Region]], die das Objekt "besitzt".

=== Agent ===
Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird. Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)

=== Lokal ===
Derzeit ein Sammelbegriff für Bezugssysteme, die nicht eines der oben erklärten sind. Im Allgemeinen die Positionierung relativ zu einem Objekt.

In LSL wird das lokale Bezugssystem auf zwei Arten genutzt:
:<h4> Childprims </h4>
:Childprims (nicht Rootprims) werden lokal zum Rootprim positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Rootprims beeinflusst.
:<h4> Attachments </h4>
:Objekte, die angezogen werden, werden lokal zum Tragepunkt positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Avatars und den abgespielten Animationen beeinflusst.

= Namenskonventionen =
ALLE Variables/Klassenmitglieder, die mit Werten aus einem dieser Bezugssysteme zu tun haben, sollten in Namen nachgestellt das Bezugssystem haben, das darin verwendet wird. BITTE tun Sie das - es hilft großartig dabei, Fehler zu vermindern.

Zum Beispiel:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Koordinatenbezugssysteme im Viewer

2010-08-07T21:05:32Z

Phillie Rhode: /* Local */ translated

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|Region]], die das Objekt "besitzt".

=== Agent ===
Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird. Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)

=== Lokal ===
Derzeit ein Sammelbegriff für Bezugssysteme, die nicht eines der oben erklärten sind. Im Allgemeinen die Positionierung relativ zu einem Objekt.

In LSL wird das lokale Bezugssystem auf zwei Arten genutzt:
:<h4> Childprims </h4>
:Childprims (nicht Rootprims) werden lokal zum Rootprim positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Rootprims beeinflusst.
:<h4> Attachments </h4>
:Objekte, die angezogen werden, werden lokal zum Tragepunkt positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Avatars und den abgespielten Animationen beeinflusst.

= Naming conventions =
ALL variables/class members dealing with values in one of these coordinate frames should be post-fixed appended with the coordinate frame that it's being used in. PLEASE do this - it greatly reduces errors.

For example:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Koordinatenbezugssysteme im Viewer

2010-08-07T20:37:25Z

Phillie Rhode: /* Agent */ translated

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|Region]], die das Objekt "besitzt".

=== Agent ===
Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird. Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)

=== Local ===
Currently a catch-all for coordinate frames which are not one of the ones above. Generally object-relative positioning.

The local frame is used in two ways in LSL:
:<h4> Child Prims </h4>
:Child prims (not root prims) are positioned local to the root prim; their global position and angle effected by both the root prims rotation and position.
:<h4> Attachments </h4>
:Objects that are attached are positioned local to the attach point; their global position and angle are affected by the position and rotation of the avatar and the playing animations.

= Naming conventions =
ALL variables/class members dealing with values in one of these coordinate frames should be post-fixed appended with the coordinate frame that it's being used in. PLEASE do this - it greatly reduces errors.

For example:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Koordinatenbezugssysteme im Viewer

2010-07-20T13:40:15Z

Phillie Rhode: Translation in progress

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|Region]], die das Objekt "besitzt".

=== Agent ===
Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in ZUkunft so sein wird. This should be used only for code involving rendering (pipeline, visibility/frustum calculations)

=== Local ===
Currently a catch-all for coordinate frames which are not one of the ones above. Generally object-relative positioning.

The local frame is used in two ways in LSL:
:<h4> Child Prims </h4>
:Child prims (not root prims) are positioned local to the root prim; their global position and angle effected by both the root prims rotation and position.
:<h4> Attachments </h4>
:Objects that are attached are positioned local to the attach point; their global position and angle are affected by the position and rotation of the avatar and the playing animations.

= Naming conventions =
ALL variables/class members dealing with values in one of these coordinate frames should be post-fixed appended with the coordinate frame that it's being used in. PLEASE do this - it greatly reduces errors.

For example:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Koordinatenbezugssysteme im Viewer

2010-07-20T13:25:07Z

Phillie Rhode: /* Region */

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Coder im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Der Ausgangspunkt ist der Ursprung der [[Land#Region|region]], die das Objekt "besitzt".

=== Agent ===
Currently, the origin is the origin of the agent's current region. THIS DOES NOT necessarily have to be the case in the future. This should be used only for code involving rendering (pipeline, visibility/frustum calculations)

=== Local ===
Currently a catch-all for coordinate frames which are not one of the ones above. Generally object-relative positioning.

The local frame is used in two ways in LSL:
:<h4> Child Prims </h4>
:Child prims (not root prims) are positioned local to the root prim; their global position and angle effected by both the root prims rotation and position.
:<h4> Attachments </h4>
:Objects that are attached are positioned local to the attach point; their global position and angle are affected by the position and rotation of the avatar and the playing animations.

= Naming conventions =
ALL variables/class members dealing with values in one of these coordinate frames should be post-fixed appended with the coordinate frame that it's being used in. PLEASE do this - it greatly reduces errors.

For example:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Koordinatenbezugssysteme im Viewer

2010-07-20T13:20:21Z

Phillie Rhode: Translation in progress

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Coder im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10<sup>9</sup> Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

=== Region ===
Origin is the origin of the [[Land#Region|region]] which "owns" the object.

=== Agent ===
Currently, the origin is the origin of the agent's current region. THIS DOES NOT necessarily have to be the case in the future. This should be used only for code involving rendering (pipeline, visibility/frustum calculations)

=== Local ===
Currently a catch-all for coordinate frames which are not one of the ones above. Generally object-relative positioning.

The local frame is used in two ways in LSL:
:<h4> Child Prims </h4>
:Child prims (not root prims) are positioned local to the root prim; their global position and angle effected by both the root prims rotation and position.
:<h4> Attachments </h4>
:Objects that are attached are positioned local to the attach point; their global position and angle are affected by the position and rotation of the avatar and the playing animations.

= Naming conventions =
ALL variables/class members dealing with values in one of these coordinate frames should be post-fixed appended with the coordinate frame that it's being used in. PLEASE do this - it greatly reduces errors.

For example:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Koordinatenbezugssysteme im Viewer

2010-07-20T12:52:46Z

Phillie Rhode:

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Coder im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die KOnventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Werte direkt aus diesen heraus verwenden.

=== Global ===
Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet ist. Precise enough for ~10<sup>9</sup> regions on an edge with same precision as region-local coordinates.

=== Region ===
Origin is the origin of the [[Land#Region|region]] which "owns" the object.

=== Agent ===
Currently, the origin is the origin of the agent's current region. THIS DOES NOT necessarily have to be the case in the future. This should be used only for code involving rendering (pipeline, visibility/frustum calculations)

=== Local ===
Currently a catch-all for coordinate frames which are not one of the ones above. Generally object-relative positioning.

The local frame is used in two ways in LSL:
:<h4> Child Prims </h4>
:Child prims (not root prims) are positioned local to the root prim; their global position and angle effected by both the root prims rotation and position.
:<h4> Attachments </h4>
:Objects that are attached are positioned local to the attach point; their global position and angle are affected by the position and rotation of the avatar and the playing animations.

= Naming conventions =
ALL variables/class members dealing with values in one of these coordinate frames should be post-fixed appended with the coordinate frame that it's being used in. PLEASE do this - it greatly reduces errors.

For example:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Koordinatenbezugssysteme im Viewer

2010-07-20T11:54:10Z

Phillie Rhode: Translation started

{{multi-lang|1=Viewer_coordinate_frames|2=/de}}
{{ViewerArchNav}}

= Koordinaten Bezugssysteme =
Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden.
Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Coder im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert.
Auch allgemeine Bibliothken (LLCamera und LLPrimitive im speziellen) verwenden do NOT use this convention. Be particularly careful when pulling values directly out of these.

=== Global ===
Absolute global coordinate frame, expressed using F64's. This is derived from the U32 x and y coords of the handles of regions, plus the region offset. Precise enough for ~10<sup>9</sup> regions on an edge with same precision as region-local coordinates.

=== Region ===
Origin is the origin of the [[Land#Region|region]] which "owns" the object.

=== Agent ===
Currently, the origin is the origin of the agent's current region. THIS DOES NOT necessarily have to be the case in the future. This should be used only for code involving rendering (pipeline, visibility/frustum calculations)

=== Local ===
Currently a catch-all for coordinate frames which are not one of the ones above. Generally object-relative positioning.

The local frame is used in two ways in LSL:
:<h4> Child Prims </h4>
:Child prims (not root prims) are positioned local to the root prim; their global position and angle effected by both the root prims rotation and position.
:<h4> Attachments </h4>
:Objects that are attached are positioned local to the attach point; their global position and angle are affected by the position and rotation of the avatar and the playing animations.

= Naming conventions =
ALL variables/class members dealing with values in one of these coordinate frames should be post-fixed appended with the coordinate frame that it's being used in. PLEASE do this - it greatly reduces errors.

For example:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Coordinate/de

2010-07-20T10:44:03Z

Phillie Rhode: moved Coordinate/de to Koordinate: translation

#REDIRECT [[Koordinate]]

Koordinate

2010-07-20T10:44:03Z

Phillie Rhode: moved Coordinate/de to Koordinate: translation

Koordinate

2010-07-20T10:42:53Z

Phillie Rhode: Translated

Animation Override/de

2010-07-17T21:41:39Z

Phillie Rhode: Translation

{{help/de
|Glossary=*
|Parent=Animation_Override}}

Ein Animation Override ("AO") ist ein geskriptetes [[Attachment]], das Standardanimationen (Laufen, Hüpfen, Stehen, Rennen usw.) durch Animationen ersetzt, die von [[Resident|Bewohnern]] erstellt wurden.

Acronyms

2010-07-17T10:54:23Z

Phillie Rhode:

{{Help|Glossary=*}}
== Second Life Slang ==
This section lists Second Life specific slang ('''SL'''ang). Link to this page with '''http://tr.im/slang'''

<div align="center">
{| style="border:1px solid #A3B1BF; text-align:left; background:#f5faff"
|-
| width="25%" style="background: #cee0f2; padding: 0.3em; text-align:center;"|'''Acronym'''
| style="background: #cee0f2; padding: 0.3em; text-align:center;"|'''Meaning'''
|-
|ALT
|[[Alternate Account]]
|-
|AO
|[[Animation Override]]
|-
|AR
|[[Abuse Report]]
|-
|ARC
|[[Avatar Rendering Cost]]
|-
|AV
|[[Avatar]]
|-
|CG
|[[Community Gateway]]
|-
|CS
|[[LL:Second Life Community Standards|Community Standards]]
|-
|DMCA
|[http://secondlife.com/corporate/dmca.php Digital Millennium Copyright Act]
|-
|HI(P)
|[[Help Island]] ([[Help Island Public|Public]])
|-
|HUD
|[[Head-up display]]
|-
|IM
|[[Instant Message]]
|-
|KB
|[[Knowledge Base]]
|-
|KBAotW
|[[KB Article of the Week|Knowledge Base Article of the Week]]
|-
|LDPW
|[[Linden Department of Public Works]]
|-
|LL
|[[Linden Lab]]
|-
|LSL
|[[Linden Scripting Language]]
|-
|LM
|[[Landmark]]
|-
|MG
|[[Main Grid]]
|-
|MotD
|[[Message of the Day]]
|-
|NC
|[[Notecard]]
|-
|OGP
|[[Open Grid Protocol]]
|-
|OH
|[[Office Hour]]
|-
|OI(P)
|[[Orientation Island]] ([[Orientation Island Public|Public]])
|-
|PyOGP
|[[PyOGP|Python Open Grid Protocol]]
|-
|RC
|[[Release Candidate]]
|-
|SL
|[[Second Life]]
|-
|SLB
|[[Second Life Birthday]]
|-
|SLRR
|[[SLRR|Second Life Railroad]]
|-
|SLT
|[[SLT|Second Life Time]]
|-
|SLurl
|[[SLurl|Second Life URL]]<ref>URL is an acronym for '''U'''niform '''R'''esource '''L'''ocator, see [http://de.wikipedia.org/wiki/Uniform_Resource_Locator Wikipedia: URL]</ref>
|-
|TG
|[[Teen Grid]]
|-
|ToS
|[[LL:Second Life Terms of Service|Second Life Terms of Service]]
|-
|TotW
|[[Video Tutorials/TotW|Tip of the Week]]
|-
|TP
|[[Teleport]]
|-
|TSL
|[[Teen Second Life]]
|-
|WA
|[[Welcome Area]]
|}</div>

<references />

== Internet Slang ==
For general Internet slang, see: http://en.wiktionary.org/wiki/Appendix:Internet_slang

Acronyms

2010-07-17T10:52:43Z

Phillie Rhode:

{{Help|Glossary=*}}
== Second Life Slang ==
This section lists Second Life specific slang ('''SL'''ang). Link to this page with '''http://tr.im/slang'''

<div align="center">
{| style="border:1px solid #A3B1BF; text-align:left; background:#f5faff"
|-
| width="25%" style="background: #cee0f2; padding: 0.3em; text-align:center;"|'''Acronym'''
| style="background: #cee0f2; padding: 0.3em; text-align:center;"|'''Meaning'''
|-
|ALT
|[[Alternate Account]]
|-
|AO
|[[Animation Override]]
|-
|AR
|[[Abuse Report]]
|-
|ARC
|[[Avatar Rendering Cost]]
|-
|AV
|[[Avatar]]
|-
|CG
|[[Community Gateway]]
|-
|CS
|[[LL:Second Life Community Standards|Community Standards]]
|-
|DMCA
|[[http://secondlife.com/corporate/dmca.php| Digital Millennium Copyright Act]]
|-
|HI(P)
|[[Help Island]] ([[Help Island Public|Public]])
|-
|HUD
|[[Head-up display]]
|-
|IM
|[[Instant Message]]
|-
|KB
|[[Knowledge Base]]
|-
|KBAotW
|[[KB Article of the Week|Knowledge Base Article of the Week]]
|-
|LDPW
|[[Linden Department of Public Works]]
|-
|LL
|[[Linden Lab]]
|-
|LSL
|[[Linden Scripting Language]]
|-
|LM
|[[Landmark]]
|-
|MG
|[[Main Grid]]
|-
|MotD
|[[Message of the Day]]
|-
|NC
|[[Notecard]]
|-
|OGP
|[[Open Grid Protocol]]
|-
|OH
|[[Office Hour]]
|-
|OI(P)
|[[Orientation Island]] ([[Orientation Island Public|Public]])
|-
|PyOGP
|[[PyOGP|Python Open Grid Protocol]]
|-
|RC
|[[Release Candidate]]
|-
|SL
|[[Second Life]]
|-
|SLB
|[[Second Life Birthday]]
|-
|SLRR
|[[SLRR|Second Life Railroad]]
|-
|SLT
|[[SLT|Second Life Time]]
|-
|SLurl
|[[SLurl|Second Life URL]]<ref>URL is an acronym for '''U'''niform '''R'''esource '''L'''ocator, see [http://de.wikipedia.org/wiki/Uniform_Resource_Locator Wikipedia: URL]</ref>
|-
|TG
|[[Teen Grid]]
|-
|ToS
|[[LL:Second Life Terms of Service|Second Life Terms of Service]]
|-
|TotW
|[[Video Tutorials/TotW|Tip of the Week]]
|-
|TP
|[[Teleport]]
|-
|TSL
|[[Teen Second Life]]
|-
|WA
|[[Welcome Area]]
|}</div>

<references />

== Internet Slang ==
For general Internet slang, see: http://en.wiktionary.org/wiki/Appendix:Internet_slang

Acronyms

2010-07-17T10:51:25Z

Phillie Rhode: corrected URL to DMCA

{{Help|Glossary=*}}
== Second Life Slang ==
This section lists Second Life specific slang ('''SL'''ang). Link to this page with '''http://tr.im/slang'''

<div align="center">
{| style="border:1px solid #A3B1BF; text-align:left; background:#f5faff"
|-
| width="25%" style="background: #cee0f2; padding: 0.3em; text-align:center;"|'''Acronym'''
| style="background: #cee0f2; padding: 0.3em; text-align:center;"|'''Meaning'''
|-
|ALT
|[[Alternate Account]]
|-
|AO
|[[Animation Override]]
|-
|AR
|[[Abuse Report]]
|-
|ARC
|[[Avatar Rendering Cost]]
|-
|AV
|[[Avatar]]
|-
|CG
|[[Community Gateway]]
|-
|CS
|[[LL:Second Life Community Standards|Community Standards]]
|-
|DMCA
|[[http://secondlife.com/corporate/dmca.php|Digital Millennium Copyright Act]]
|-
|HI(P)
|[[Help Island]] ([[Help Island Public|Public]])
|-
|HUD
|[[Head-up display]]
|-
|IM
|[[Instant Message]]
|-
|KB
|[[Knowledge Base]]
|-
|KBAotW
|[[KB Article of the Week|Knowledge Base Article of the Week]]
|-
|LDPW
|[[Linden Department of Public Works]]
|-
|LL
|[[Linden Lab]]
|-
|LSL
|[[Linden Scripting Language]]
|-
|LM
|[[Landmark]]
|-
|MG
|[[Main Grid]]
|-
|MotD
|[[Message of the Day]]
|-
|NC
|[[Notecard]]
|-
|OGP
|[[Open Grid Protocol]]
|-
|OH
|[[Office Hour]]
|-
|OI(P)
|[[Orientation Island]] ([[Orientation Island Public|Public]])
|-
|PyOGP
|[[PyOGP|Python Open Grid Protocol]]
|-
|RC
|[[Release Candidate]]
|-
|SL
|[[Second Life]]
|-
|SLB
|[[Second Life Birthday]]
|-
|SLRR
|[[SLRR|Second Life Railroad]]
|-
|SLT
|[[SLT|Second Life Time]]
|-
|SLurl
|[[SLurl|Second Life URL]]<ref>URL is an acronym for '''U'''niform '''R'''esource '''L'''ocator, see [http://de.wikipedia.org/wiki/Uniform_Resource_Locator Wikipedia: URL]</ref>
|-
|TG
|[[Teen Grid]]
|-
|ToS
|[[LL:Second Life Terms of Service|Second Life Terms of Service]]
|-
|TotW
|[[Video Tutorials/TotW|Tip of the Week]]
|-
|TP
|[[Teleport]]
|-
|TSL
|[[Teen Second Life]]
|-
|WA
|[[Welcome Area]]
|}</div>

<references />

== Internet Slang ==
For general Internet slang, see: http://en.wiktionary.org/wiki/Appendix:Internet_slang

Project:Editing Guidelines/de

2010-07-16T12:47:11Z

Phillie Rhode:

{{Multi-lang}}

== Inhalt ==

Diese Wiki ist eine Zusammenarbeit zwischen LindenLab und der Second Life Benutzergemeinschaft. Auch wenn Linden Lab nicht jeden Beitrag zum Übermittlungszeitpunkt überprüfen kann, behalten wird uns das Recht vor unzulässige Inhalte jederzeit zu löschen. Wir bieten diese Wiki als eine Dienstleistung für durch die Portale dieser Wiki beschriebenen Benutzergruppen an, welche zum Zeitpunkt der Erstellung dieses Beitrags wie folgt lauten:
* The [[Open Source Portal]]
* The [[Volunteer Portal]]
* The [[LSL Portal]]
* The [[Community Development Resources Portal]]

Neue Portale können auf alleinigen Beschluss durch Linden Lab jederzeit hinzugefügt werden.

== Perspektive ==

Artikel in dem Haupt-Namespace sollten in der dritten Person verfasst werden. Der Änderungsverlauf der Seite (page history) wird den gesamten Verlauf von Änderungen und Beiträgen enthalten, es besteht daher kein Bedarf, Artikel zu unterzeichnen. Generell sollte eine neutrale Wertung gewählt werden, immer unter dem Gesichtspunkt, dass die Zielgruppe Personen sind, die helfen wollen, Second Life zu schaffen und das Wiki sollte auch nicht für allgemeine Beschwerden über Second Life als Dienstleistung oder Linden Lab als Unternehmen verwendet werden. Kritik, welche neue Merkmale vorschlägt oder Lösungsansätze liefert, ist akzeptabel (z.B. "Sehen Sie hier Problem X. Die Einführung von Y wird X beheben."), generell sollen jedoch Beiträge und Beschwerden die davon abraten, Second Life zu verwenden ,an anderer Stelle genannt werden.

== Erstellen einer neuen Seite ==

* Benutzen Sie den treffensten und einfachsten Namen wenn Sie eine neue Seite erstellen. Wir können jederzeit eine weiterführende Seite zur Begriffserklärung erstellen, wenn dies notwendig sein sollte.
* Helfen Sie Wiki-Auswucherungen zu vermeiden... bearbeiten Sie lieber eine existierende Seite anstatt eine neue zu erstellen.

== Der "Project" Namespace ==

Dieses Wiki hat einen "Project:" Namespace. Inhalte in diesem Namespace sollten auf Informationen über das Wiki selbst begrenzt sein. Bei den meisten MediaWiki Installationen ist der "Project:"-Namespace gleich dem Namen des Wiki selbst, das ist jedoch in diesem Wiki deaktiviert, dadurch ist "Project:" die einzige Möglichkeit, diesen Namespace zu erreichen. Die Dinge, die in dem "Project:"-Namespace erstellt werden, sollten auf Inhalte, welche die Richtlinien zum Bearbeiten dieses Wiki betreffen und Inhalte über das Wiki selbst abzielen und nicht Second Life als Thema haben.

== Templates ==

* Benutzen Sie "inclusion templates" um eine durchgehende Navigation zu gewährleisten
* [https://wiki.secondlife.com/w/index.php?title=Special%3AAllpages&from=&namespace=10 Komplette Liste der verfügbaren Templates]

Account

2010-07-16T07:18:26Z

Phillie Rhode: Corrected URL for Alt Account FAQ

{{Help|Glossary=*|Misc=*}}
== Basic Account ==
A basic account is a free account. Basic accounts can access basic support, can rent land on private [[estates]].
== Premium Account ==
Allows a [[Resident]] to buy [[mainland]], to receive a monthly stipend and to access advanced support.
You can also read [http://secondlife.com/whatis/plans.php this page] if you want more information about membership plans.
== Alt Account ==
An alternate account (or "alt" for short) is an account used by a Resident for something other than their usual activity or to do things in privacy (such as building or scripting).
*[http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alt_Account_FAQ Alt Account FAQ] in the [[Knowledge Base]]

== Cancel an Account ==
*[[Knowledge Base]] articles:
**[[Linden_Lab_Official:How to Cancel an Account|How to Cancel an Account]]
**[[Linden_Lab_Official:How long can my Second Life account remain inactive before it's deleted|How long can my Second Life account remain inactive before it's deleted?]]
**[[Linden_Lab_Official:I just canceled my account and I'm still being charged!|I just canceled my account and I'm still being charged!]]
**[[My account was cancelled and I'd like to reactivate it. What should I do|My account was cancelled and I'd like to reactivate it. What should I do?]]

== Related Links ==
*[[Knowledge Base]] articles:
**[[Linden_Lab_Official:What are the different levels of account membership|What are the different levels of account membership?]]
**[[Linden_Lab_Official:Safeguarding your account and protecting your password|Safeguarding your account and protecting your password]]
**[[Linden_Lab_Official:Sharing Second Life Accounts|Sharing Second Life Accounts]]
**[[Linden_Lab_Official:Tickets for Basic and Guest Accounts|Tickets for Basic and Guest Accounts]]

Academia Electronica/de

2010-07-16T00:45:00Z

Phillie Rhode:

{{Multi-lang|1=Academia_Electronica|2=/de}}

[[Image:Mehaniczna_ręka.jpg|frame|Mechanic hand]]

==Ursprung==

Academia Electronica ist als elektronischer Raum für ernsthafte wissenschaftliche Diskussionen entworfen worden.<br>
Academia Electronica wirbt für eine interdisziplinäre Zusammenarbeit über Fakultäten und Wissenschaftsdisziplinen wie Philosophie, Sozialwissenschaften, Psychologie und Kulturwissenschaften hinweg und konzentriert sich dabei auf die Problematik der elektronischen Umgebung, die als Teil der Erlebniswelt der Menschen behandelt wird.<br>

==Funktion==

Academia Electronica besteht als offene Plattform für jeden, der dazu gewillt ist, die folgenden Forschungsbereiche zu erkunden und zu diskutieren:
:*Implementierung/Immersion eines menschlichen Seins in eine elektronische Umgebung, die dann dessen erste Realität wird (eine Realität, die eine vollwertige und funktionsfähige Existenz ermöglicht)
:*Veränderung der Sprache in der hypertextuellen elektronischen Umgebgebung (neu entstandene Kommunikationsstrategien und -muster, neu entstehende Spachvariationen und -bereiche)
:*tiefgehende Untersuchung von wechselseitigen Verbindungen zwischen Mensch und Technologie

Wenn Sie zu diesen Themen eine Rede oder Vorlesung halten möchten oder einfach nur Ihre Erfahrungen als Bewohner der elektronischen Welt von Second Life mit anderen teilen wollen, nehmen Sie bitte Kontakt mit dem Schirmherrn der Academy - Sidey Myoo - auf oder besuchen Sie unsere Schule in-world {{simpleslurl|Uzume|210|78|33|Academia Electronica}}

God Mode/de

2010-07-15T23:54:06Z

Phillie Rhode: moved God Mode/de to Gott-Modus: translation

#REDIRECT [[Gott-Modus]]

Gott-Modus

2010-07-15T23:54:06Z

Phillie Rhode: moved God Mode/de to Gott-Modus: translation

{{Help/de
|Glossary=*
|Parent=God_Mode}}

"Gott-Modus" ist der Begriff, der dazu benutzt wird, um das Aktivieren von administrativen Werkzeugen und Fähigkeiten im Second Life Viewer zu beschreiben.

Obwohl die Fähigkeiten und Menüs mit in Viewer einprogrammiert sind, wird in dem Fall, dass ein nicht autorisierter Benutzer versucht, über die Tastenkombination {{KeyCombo|ctrl=*|alt=*|G}} oder die Menüoption ''Entwickler > Admin-Status anfordern'' den "Gott-Modus" zu Aktivieren, ein Dialogfenster angezeigt, das den Benutzer so informiert: "'''Request for special powers failed. This request has been logged'''" (Das Anfordern von Spezialkräften ist fehlgeschlagen. Diese Anfrage wurde aufgezeichnet). Die Optionen, die einem autorisiertem Benutzer zur Verfügung stehen, können immer noch über den Tastaturbefehl {{KeyCombo|ctrl=*|alt=*|V}} (nur bis zum Viewer 1.23) oder die Menüauswahl ''Entwickler > Admin-Menü anzeigen'' sichtbar gemacht werden - obwohl der "Gott-Modus" scheinbar aktiviert ist, wird der Server auf keinen Versuch reagieren, die Funktionen daraus zu benutzen.

== Was kann man damit machen? ==

In Grids, die Linden gehören (wie zum Beispiel [[Agni]]), erlaubt es der "Gott-Modus" [[:Category:Linden Lab Employees|Angestellten von Linden Lab]], Aufgaben komplett im Viewer zu erledigen; dazu gehören unter anderen die folgenden:
* Informationen über das Land oder Region bearbeiten
* Avatare hinauswerfen oder einzufrieren
* Land oder Objekte auf sie selbst zu übertragen
* Jeden aus Second Life abzumelden

Der "Gott-Modus" ermöglicht es auch, dass Einschränkungen auf Parzellen - wie "Fliegen verboten" - ignoriert werden können.

== Zu was benutzen Sie das? ==

Angestellten von Linden Lab dürfen den "Gott-Modus" aus vielen Gründen benutzen, darunter zur Wahrung der Privatsphäre dadurch, dass sie für Sensoren unsichtbar sind{{footnote|2=Lindens im Gott-Modus sind nur unsichtbar für Sensoren, wenn sich der Sensor in der gleichen Region wie der Linden befindet. Lesen Sie dazu auf der Diskussionsseite des Benutzers talk:Soft Linden#sensor caveat|1=Lindens im Gott-Modus sind nur unsichtbar für Sensoren, wenn sich der Sensor in der gleichen [[region|Region]] wie der Linden befindet. Weitere Informationen finden Sie hier: [https://wiki.secondlife.com/w/index.php?title=User_talk%3ASoft_Linden&diff=89470&oldid=89468 User talk:Soft Linden#sensor caveat].}}, um zurückgegebenes Land wieder in Besitz zu nehmen und um mit Griefern umzugehen.

== Gott-Modus Stufen ==
Der [http://svn.secondlife.com/trac/linden/browser/trunk/indra/llcommon/indra_constants.h#L242 Programmcode des Viewers] zeigt, dass es verschiedene Stufen für den "Gott-Modus" gibt (jede Stufe beinhaltet die Möglichkeiten der vorherigen Stufen):

=== GOD_NOT ===
Wert: 0
* Vermutlich der Standard "Gott-Modus" Status, den jeder eingeloggte Benutzer bekommt

=== GOD_LIKE ===
Wert: 1
* Objekte umbenennen, ohne das Recht "Bearbeiten" zu haben

=== GOD_CUSTOMER_SERVICE ===
Wert: 100
* Die Geometrie des Characters umschalten
* Eine Kopie ins Inventar aufnehmen (unabhängig von den Rechten)
* Den Besitz von Objekten übernehmen
* Zum Inhalt von Linden erklären
* Öffentliches Land in Besitz nehmen

=== GOD_LIAISON ===
Wert: 150
* Land zur Versteigerung freigeben

=== GOD_FULL ===
Wert: 200
* Der Unterschied zu [[#GOD_LIAISON|GOD_LIAISON]] ist nicht erkennbar.

=== GOD_MAINTENANCE ===
Wert: 250
* Der Unterschied zu [[#GOD_FULL|GOD_FULL]] ist nicht erkennbar.

== Fussnote ==
{{footnotes}}

== Verwandte Artikel ==
* [[:Category:LSL God Mode|God Mode LSL Functions]]

Gott-Modus

2010-07-15T23:53:31Z

Phillie Rhode: translation

Gott-Modus

2010-07-15T19:55:17Z

Phillie Rhode: Started translation, still in progress

{{Help/de
|Glossary=*
|Parent=God_Mode}}

"Gott-Modus" ist der Begriff, der dazu benutzt wird, um das Aktivieren von administrativen Werkzeugen und Fähigkeiten im Second Life Viewer zu beschreiben.

Obwohl die Fähigkeiten und Menüs mit in Viewer einprogrammiert sind, wird in dem Fall, dass ein nicht autorisierter Benutzer versucht, über die Tastenkombination {{KeyCombo|ctrl=*|alt=*|G}} oder die Menüoption ''Erweitert > Request Admin Powers'' den "Gott-Modus" zu Aktivieren, ein Dialogfenster angezeigt, das den Benutzer so informiert: "'''Das Anfordern von Spezialkräften ist fehlgeschlagen. Diese Anfrage wurde ausgezeichnet'''". The options available to an authorized user can still be viewed via {{KeyCombo|ctrl=*|alt=*|V}} or the ''Advanced > View Admin Options'' menu option- although "God Mode" appears to be enabled, the server will not act upon any attempts to use them.

== Was kann man damit machen? ==

In Linden-owned grids (such as [[Agni]]), "God Mode" enables [[:Category:Linden Lab Employees|Linden Lab employees]] to perform tasks entirely in the viewer, such as:
* edit land or region info
* kick or freeze avatars,
* claim land or objects to themselves
* Log everyone out of Second Life

"God Mode" also allows parcel restrictions such as "no fly" to be ignored.

== Zu was benutzen Sie das? ==

Linden Lab employees may use "God Mode" for many reasons, including the privacy granted from being invisible to sensors{{footnote|2=Lindens in God Mode are only hidden from sensors, in case the sensor is in the same region as the Linden. See User talk:Soft Linden#sensor caveat|1=Lindens in God Mode are only hidden from sensors, in case the sensor is in the same [[region]] as the Linden. See [https://wiki.secondlife.com/w/index.php?title=User_talk%3ASoft_Linden&diff=89470&oldid=89468 User talk:Soft Linden#sensor caveat].}}, reclaiming abandoned land and dealing with griefers.

== God Mode Levels ==
The [http://svn.secondlife.com/trac/linden/browser/trunk/indra/llcommon/indra_constants.h#L242 Viewer source code] shows that there are several levels of "God Mode" (each level has all the previous levels' powers):

=== GOD_NOT ===
Value: 0
Presumably the default "God Mode" status given to every logged-in user

=== GOD_LIKE ===
Value: 1
* rename objects without modify permission

=== GOD_CUSTOMER_SERVICE ===
Value: 100
* Toggle character geometry
* Take copy
* Owner To Me
* Set To Linden Content
* Claim Public Land

=== GOD_LIAISON ===
Value: 150
* Enable land auction

=== GOD_FULL ===
Value: 200
Difference from [[#GOD_LIAISON|GOD_LIAISON]] not apparent.

=== GOD_MAINTENANCE ===
Value: 250
Difference from [[#GOD_FULL|GOD_FULL]] not apparent.

== Footnotes ==
{{footnotes}}

== Related Articles ==
* [[:Category:LSL God Mode|God Mode LSL Functions]]

Academia Electronica/de

2010-07-15T16:56:31Z

Phillie Rhode: /* Ursprung */

Academia Electronica/de

2010-07-15T16:55:29Z

Phillie Rhode: /* Ursprung */

{{Multi-lang|1=Academia_Electronica|2=/de}}

[[Image:Mehaniczna_ręka.jpg|frame|Mechanic hand]]

==Ursprung==

Academia Electronica ist als elektronischer Raum für ernsthafte wissenschaftliche Diskussionen entworfenworden.<br>
Academia Electronica wirbt für eine interdisziplinäre Zusammenarbeit über Fakultäten und Wissenschaftsdisziplinen wie Philosophie, Sozialwissenschaften, Psychologie und Kulturwissenschaften hinweg und konzentriert sich dabei auf die Problematik der elektronischen Umgebung, die als Teil der Erlebniswelt der Menschen behandelt wird.<br>

==Funktion==

Academia Electronica besteht als offene Plattform für jeden, der dazu gewillt ist, die folgenden Forschungsbereiche zu erkunden und zu diskutieren:
:*Implementierung/Immersion eines menschlichen Seins in eine elektronische Umgebung, die dann dessen erste Realität wird (eine Realität, die eine vollwertige und funktionsfähige Existenz ermöglicht)
:*Veränderung der Sprache in der hypertextuellen elektronischen Umgebgebung (neu entstandene Kommunikationsstrategien und -muster, neu entstehende Spachvariationen und -bereiche)
:*tiefgehende Untersuchung von wechselseitigen Verbindungen zwischen Mensch und Technologie

Wenn Sie zu diesen Themen eine Rede oder Vorlesung halten möchten oder einfach nur Ihre Erfahrungen als Bewohner der elektronischen Welt von Second Life mit anderen teilen wollen, nehmen Sie bitte Kontakt mit dem Schirmherrn der Academy - Sidey Myoo - auf oder besuchen Sie unsere Schule in-world {{simpleslurl|Polish Community|91|180|28|Academia Electronica}}

Academia Electronica/de

2010-07-15T16:54:48Z

Phillie Rhode: /* Ursprung */

{{Multi-lang|1=Academia_Electronica|2=/de}}

[[Image:Mehaniczna_ręka.jpg|frame|Mechanic hand]]

==Ursprung==

Academia Electronica ist als elektronischer Raum für ernsthafte wissenschaftliche Diskussionen entworfenworden.<br>
Academia Electronica wirbt für eine interdisziplinäre Zusammenarbeit über Fakultäten und Wissenschaftsdisziplinen wie Philosophie, Sozialwissenschaften, Psychologie und Kulturwissenschaften hinweg und konzentriert sich dabei auf die Probelmatik der elektronischen Umgebung, die als Teil der Erlebendwelt der Menschen behandelt wird.<br>

==Funktion==

Academia Electronica besteht als offene Plattform für jeden, der dazu gewillt ist, die folgenden Forschungsbereiche zu erkunden und zu diskutieren:
:*Implementierung/Immersion eines menschlichen Seins in eine elektronische Umgebung, die dann dessen erste Realität wird (eine Realität, die eine vollwertige und funktionsfähige Existenz ermöglicht)
:*Veränderung der Sprache in der hypertextuellen elektronischen Umgebgebung (neu entstandene Kommunikationsstrategien und -muster, neu entstehende Spachvariationen und -bereiche)
:*tiefgehende Untersuchung von wechselseitigen Verbindungen zwischen Mensch und Technologie

Wenn Sie zu diesen Themen eine Rede oder Vorlesung halten möchten oder einfach nur Ihre Erfahrungen als Bewohner der elektronischen Welt von Second Life mit anderen teilen wollen, nehmen Sie bitte Kontakt mit dem Schirmherrn der Academy - Sidey Myoo - auf oder besuchen Sie unsere Schule in-world {{simpleslurl|Polish Community|91|180|28|Academia Electronica}}

Academia Electronica/de

2010-07-15T16:51:07Z

Phillie Rhode: translation

{{Multi-lang|1=Academia_Electronica|2=/de}}

[[Image:Mehaniczna_ręka.jpg|frame|Mechanic hand]]

==Ursprung==

Academia Electronica ist als elektronischer Raum für ernsthafte wissenschaftliche Diskussionen entworfenworden.<br>
Academia Electronica wirbt für eine interdisziplinäre Zusammenarbeit über Fakultäten und Wissenschaftsdisziplinen wie Philisophie, Sozialwissenschaften, Psychologie und Kulturwissenschaften hinweg und konzentriert sich dabei auf die Probelmatik der elektronischen Umgebung, die als Teil der Erlebendwelt der Menschen behandelt wird.<br>

==Funktion==

Academia Electronica besteht als offene Plattform für jeden, der dazu gewillt ist, die folgenden Forschungsbereiche zu erkunden und zu diskutieren:
:*Implementierung/Immersion eines menschlichen Seins in eine elektronische Umgebung, die dann dessen erste Realität wird (eine Realität, die eine vollwertige und funktionsfähige Existenz ermöglicht)
:*Veränderung der Sprache in der hypertextuellen elektronischen Umgebgebung (neu entstandene Kommunikationsstrategien und -muster, neu entstehende Spachvariationen und -bereiche)
:*tiefgehende Untersuchung von wechselseitigen Verbindungen zwischen Mensch und Technologie

Wenn Sie zu diesen Themen eine Rede oder Vorlesung halten möchten oder einfach nur Ihre Erfahrungen als Bewohner der elektronischen Welt von Second Life mit anderen teilen wollen, nehmen Sie bitte Kontakt mit dem Schirmherrn der Academy - Sidey Myoo - auf oder besuchen Sie unsere Schule in-world {{simpleslurl|Polish Community|91|180|28|Academia Electronica}}

10 Truths about the Electronic World/de

2010-07-15T16:25:39Z

Phillie Rhode: moved 10 Truths about the Electronic World/de to 10 Tatsachen über die elektronische Welt: translation of "10 Truths about the Electronic World"

#REDIRECT [[10 Tatsachen über die elektronische Welt]]

10 Tatsachen über die elektronische Welt

2010-07-15T16:25:39Z

Phillie Rhode: moved 10 Truths about the Electronic World/de to 10 Tatsachen über die elektronische Welt: translation of "10 Truths about the Electronic World"

{{Help/de|Parent=10_Truths_about_the_Electronic_World}}

'''10 Tatsachen über die elektronische Welt:'''<br><br>

:#Die elektronische Welt ist eine alternative Realität im Verhältnis zu der physikalischen Welt.<br><br>
:#Die elektronische Welt ist eine menschliche Welt, die dazu in der Lage ist, menschliche Maßstäbe zu beherbergen: Emotionen, Gefühle und geistige Werte.<br><br>
:#Die elektronische Welt ist eine Realität, die den Ausdruck von allen Arten menschlicher Lebensaktivität akzeptiert; sie ist eine Quelle der Selbstfindung und unabhänger Schöpfung, persönlicher Betrachtung und Ausdrucksweise.<br><br>
:#Die elektronische Welt ist eine Quelle von neuen Möglichkeiten, die sich von denen, die in der physikalischen Welt existieren, unterscheiden.<br><br>
:#Die elektronische Welt kann den Platz dafür bieten, die Ziele für existentielle Entscheidungen zu bestimmen und menschliche Entscheidungen darüber zu treffen, die die Realität betreffen, in der Personen ihr Leben erfahren wollen.<br><br>
:#Die elektronische Welt ist immateriell und entwickelt einen Raum, der von der physikalischen Welt getrennt ist.<br><br>
:#Die elektronische Welt vergrößert ihre Kapazitäten in linear zu technischen Fortschritten.<br><br>
:#Die elektronische Welt entwickelt sich schneller fort als die physikalische Welt und beeinflusst die Weiterentwicklung der menschlichen Daseins.<br><br>
:#Die elektronische Welt ist keine Simulation und es gibt darin keinen Platz für Simulationen.<br><br>
:#Die elektronische Welt ist Realität, das Ergebnis erscheint in der physikalischen Welt.<br><br>

<center>Sidey Myoo</center>

10 Tatsachen über die elektronische Welt

2010-07-15T16:23:09Z

Phillie Rhode: Translated

User:Phillie Rhode

2010-07-15T15:43:22Z

Phillie Rhode:

'''I am Phillie....'''

I am {{Age|04|03|2007}} days old and a wandering Neko. I try to walk all the roads in SL and enjoy the fun and the silence.

Translating EN <=> DE IS relaxing for me and a useful hobby

Member of the GsL, adoring the Wiki scribes *giggles*

{{ISO 639-3/cat-speaking/Volunteers|eng}}
{{ISO 639-3/cat-speaking/Volunteers|deu}}
{{visl|Mentors=*|Linguist=*}}
[[Category:German speaking Linguists|{{PAGENAME}}]]

Über Traffic

2010-02-22T11:08:56Z

Phillie Rhode: Finished Translation of the new paragraph

{{Help/de
|Parent=About Traffic
|LandSim=*}}
Was ist Traffic? (Verweildauer)

[[Linden Lab]]{{nnlink/de}} führte den "Traffic" oder die "Verweildauer" urspünglich dazu ein, um [[resident|Bewohner]]{{nnlink/de}} zu belohnen, die populäre Orte gebaut haben.

== Seit 2009 ==
Im Blog über Land und Wasserflächen<ref>https://blogs.secondlife.com/community/land/blog/2009/04/23/conclusion-to-the-blog-post-on-bots</ref>{{nnlink/de}}, hat Jack Linden die Benutzung von Bots zur Generierung von Traffic diskutiert. Dort stellt er fest, dass sich fast alle einig sind, dass dies eine unlauteres Vorgehen ist und obwohl die Verwendung von Bots im allgemeinen in Ordnung ist, wird der Einsatz für die Generierung von Traffic nun als Verletzung der TOS angesehen.
In dem Blogeintrag wird das wie folgt zusammengefasst:
* Die Verwendung von Bots zum Beeinflussen des Traffics wird als eine Verletzung der TOS angesehen.
* Bots sind gut und wir unterstützen ihre Verwendung inworld zu guten Zwecken, aber wir werden bei unangemessenem Gebrauch von diesen dagegen vorgehen.
* Traffic hat einen Wert als Kennzahl für Land und wird Bestand haben.
* Verantwortliche Nutzung von Landbots ist derzeit akzeptabel, aber eine übermässige Nutzung wird zu einem weiteren Vorgehen führen.

== Seit 2006 ==
* Im Jahr 2006 wurde der Traffic auf eine Minute umgestellt, die ein Avatar auf einem Grundstück<ref>http://forums.secondlife.com/showpost.php?p=1371911&postcount=19</ref> verbringt, aber nur für Avatare, die sich innerhalb der Zeitspanne von 24 Stunden für die Datensammlung (für mindestends fünf Minuten) nicht auf andere Grundstücke bewegen. Im Übrigen funktioniert es im Großen und Ganzen noch nach dem Modell vor 2006, wie Linden Lab im Mai 2008<ref>http://www.massively.com/2008/05/26/peering-inside-Trafficking-in-meaning/</ref> erklärt hat.
* Es zählt der Traffic von allen [[avatar|Avataren]]{{nnlink/de}}, unabhängig von deren Kontoart oder ob es sich um einen Bewohner oder einen [[bot|Bot]] handelt.
* [[Mainland]] Regionen, die im Allgemeinen auf 40 Avatare beschränkt sind, können keinen Traffic über 57.600 haben, während private Regionen{{nnlink/de}} mit einem [[limit|Limit]]{{nnlink/de}} von 100 Avataren normalerweise nicht über 144.000 kommen. Diese Höchstwerte können aber durch Avatare überschritten werden, die sich erneut auf eine Region einloggen.
* Der Traffic entscheidet auch über die "Beliebten Orte", die jede Nacht ausgewählt werden. Sie können diese sehen, wenn Sie auf den Button "Suchen" klicken und das Register "Beliebte Orte" auswählen. Sie erscheinen auch auf der [[Map|Karte]]{{nnlink/de}} als Icon mit dem Daumen nach oben. (Hinweis: Ab der Viewerversion 1.20 sind "Beliebte Orte" nicht mehr länger im Suchsystem enthalten.)
* Wenn Sie ein weiteres langweiliges Streitgespräch darüber beginnen wollen, ob diese Wiki-Seite, die Knowledgebase oder eine andere Informationsquelle (einschließlich verschiedener Linden Lab Mitarbeiter) richtig ist, lesen Sie bitte [http://forums.secondlife.com/showthread.php?t=310130 diesen Thread] und insbesondere diesen [http://forums.secondlife.com/showpost.php?p=2345872&postcount=67 Beitrag]<ref>http://forums.secondlife.com/showpost.php?p=2345872&postcount=67</ref>, der erneut schlüssig bewiesen hat, daß der Traffic ein Punkt pro Avatar pro Minute ist (mit Ausnahme einiger kleinen Fragen über den Zeitpunkt, wann der Mechanismus, der die Minuten ermittelt, läuft)

== Bis 2006 ==
* Ursprünglich war die Verweildauer eine feste Anzahl von Punkten für jeden Bewohner, der dardurch zugewiesen wurde, dass der Anteil der Zeit aus der Gesamtzeit ermittelt wurde, den ein Bewohner innerhalb eines Tages auf den verschiedenen Plätzen in SL verbrachte. Vorher musste ein Bewohner mindestends ununterbrochen 5 Minuten auf einem Grundstück bleiben, um diesem mindestends einen Trafficpunkt zu geben.
* Linden Lab hat in der Vergangenheit den 2% der Landbesitzer, die die höchste Verweildauer - im Verhältnis zu der Verweildauer, die ihre Grundstücksbesitze erreichten - eine Prämie in US$ angeboten. Im August 2004 wurden 2.308 US$ unter 36 Landbesitzern aufgeteilt. Das war in den Anfangstagen von SL wichtig für die Startfinanzierung, wenn ein Bauwerk, obwohl es beliebt war, aufgrund der sehr geringen Bevölkerungszahl wirtschaftlich nicht überlebenfähig sein konnte.
* Mitte des Jahres 2006 wurden Stipendien, die auf der Verweildauer basierten, entfernt, da das Bevölkerungswachstum ein ausreichend großes Publikum bot, um eine eher herkömmliche Wirtschaft in Second Life zu unterstützen.

== Referenzierte Artikel ==
<references />

[[Category:Text from In-world Notecards|Dwell]]
[[Category:Text from In-world Notecards|Traffic]]

Über Traffic

2010-02-21T17:52:26Z

Phillie Rhode: Added new Paragraph about 2009 changes

{{Help/de
|Parent=About Traffic
|LandSim=*}}
Was ist Traffic? (Verweildauer)

[[Linden Lab]]{{nnlink/de}} führte den "Traffic" oder die "Verweildauer" urspünglich dazu ein, um [[resident|Bewohner]]{{nnlink/de}} zu belohnen, die populäre Orte gebaut haben.

== Seit 2009 ==
Im Blog über Land und Wasserflächen<ref>https://blogs.secondlife.com/community/land/blog/2009/04/23/conclusion-to-the-blog-post-on-bots</ref>{{nnlink/de}}, hat Jack Linden die Benutzung von Bots zur Generierung von Traffic diskutiert. In here he states that almost everyone agrees that this is an unfair practice and although the use of bots in general is acceptable, the use for generating traffic is now considered an violation.
In the blog it is summarized as follow:
* Use of Bots to game Traffic will be considered a violation.
* Bots are fine and we totally support their good use inworld, but we will deal with inappropriate use of them.
* Traffic has value as a land metric, and will remain.
* Responsible use of Land Bots is acceptable for now, but overuse will result in further action.

== Seit 2006 ==
* Im Jahr 2006 wurde der Traffic auf eine Minute umgestellt, die ein Avatar auf einem Grundstück<ref>http://forums.secondlife.com/showpost.php?p=1371911&postcount=19</ref> verbringt, aber nur für Avatare, die sich innerhalb der Zeitspanne von 24 Stunden für die Datensammlung (für mindestends fünf Minuten) nicht auf andere Grundstücke bewegen. Im Übrigen funktioniert es im Großen und Ganzen noch nach dem Modell vor 2006, wie Linden Lab im Mai 2008<ref>http://www.massively.com/2008/05/26/peering-inside-Trafficking-in-meaning/</ref> erklärt hat.
* Es zählt der Traffic von allen [[avatar|Avataren]]{{nnlink/de}}, unabhängig von deren Kontoart oder ob es sich um einen Bewohner oder einen [[bot|Bot]] handelt.
* [[Mainland]] Regionen, die im Allgemeinen auf 40 Avatare beschränkt sind, können keinen Traffic über 57.600 haben, während private Regionen{{nnlink/de}} mit einem [[limit|Limit]]{{nnlink/de}} von 100 Avataren normalerweise nicht über 144.000 kommen. Diese Höchstwerte können aber durch Avatare überschritten werden, die sich erneut auf eine Region einloggen.
* Der Traffic entscheidet auch über die "Beliebten Orte", die jede Nacht ausgewählt werden. Sie können diese sehen, wenn Sie auf den Button "Suchen" klicken und das Register "Beliebte Orte" auswählen. Sie erscheinen auch auf der [[Map|Karte]]{{nnlink/de}} als Icon mit dem Daumen nach oben. (Hinweis: Ab der Viewerversion 1.20 sind "Beliebte Orte" nicht mehr länger im Suchsystem enthalten.)
* Wenn Sie ein weiteres langweiliges Streitgespräch darüber beginnen wollen, ob diese Wiki-Seite, die Knowledgebase oder eine andere Informationsquelle (einschließlich verschiedener Linden Lab Mitarbeiter) richtig ist, lesen Sie bitte [http://forums.secondlife.com/showthread.php?t=310130 diesen Thread] und insbesondere diesen [http://forums.secondlife.com/showpost.php?p=2345872&postcount=67 Beitrag]<ref>http://forums.secondlife.com/showpost.php?p=2345872&postcount=67</ref>, der erneut schlüssig bewiesen hat, daß der Traffic ein Punkt pro Avatar pro Minute ist (mit Ausnahme einiger kleinen Fragen über den Zeitpunkt, wann der Mechanismus, der die Minuten ermittelt, läuft)

== Bis 2006 ==
* Ursprünglich war die Verweildauer eine feste Anzahl von Punkten für jeden Bewohner, der dardurch zugewiesen wurde, dass der Anteil der Zeit aus der Gesamtzeit ermittelt wurde, den ein Bewohner innerhalb eines Tages auf den verschiedenen Plätzen in SL verbrachte. Vorher musste ein Bewohner mindestends ununterbrochen 5 Minuten auf einem Grundstück bleiben, um diesem mindestends einen Trafficpunkt zu geben.
* Linden Lab hat in der Vergangenheit den 2% der Landbesitzer, die die höchste Verweildauer - im Verhältnis zu der Verweildauer, die ihre Grundstücksbesitze erreichten - eine Prämie in US$ angeboten. Im August 2004 wurden 2.308 US$ unter 36 Landbesitzern aufgeteilt. Das war in den Anfangstagen von SL wichtig für die Startfinanzierung, wenn ein Bauwerk, obwohl es beliebt war, aufgrund der sehr geringen Bevölkerungszahl wirtschaftlich nicht überlebenfähig sein konnte.
* Mitte des Jahres 2006 wurden Stipendien, die auf der Verweildauer basierten, entfernt, da das Bevölkerungswachstum ein ausreichend großes Publikum bot, um eine eher herkömmliche Wirtschaft in Second Life zu unterstützen.

== Referenzierte Artikel ==
<references />

[[Category:Text from In-world Notecards|Dwell]]
[[Category:Text from In-world Notecards|Traffic]]

Über Traffic

2009-11-06T15:14:01Z

Phillie Rhode:

{{Help/de
|Parent=About Traffic
|LandSim=*}}
Was ist Traffic? (Verweildauer)

[[Linden Lab]] führte den "Traffic" oder die "Verweildauer" urspünglich dazu ein, um [[resident|Bewohner]] zu belohnen, die populäre Orte gebaut haben.

== Seit 2006 ==
* Im Jahr 2006 wurde der Traffic auf eine Minute umgestellt, die ein Avatar in einem Grundstück<ref>http://forums.secondlife.com/showpost.php?p=1371911&postcount=19</ref> verbringt, aber nur für Avatare, die sich innerhalb der Zeitspanne von 24 Stunden für die Datensammlung (für mindestends fünf Minuten) nicht auf andere Grundstücke bewegen. Im Übrigen funktioniert es im Großen und Ganzen noch nach dem Modell vor 2006, wie Linden Lab im Mai 2008<ref>http://www.massively.com/2008/05/26/peering-inside-Trafficking-in-meaning/</ref> erklärt hat
* Es zählt der Traffic von allen [[avatar|Avataren]], unabhängig von deren Kontoart oder ob es sich um einen Bewohner oder einen [[bot|Bot]] handelt
* [[Mainland]] Regionen, die im Allgemeinen auf 40 Avatare beschränkt sind, können keinen Traffic über 57.600 haben, während private Regionen [[estate|Estates]] mit einem [[limit|Limit]] von 100 Avataren normalerweise nicht über 144.000 kommen, diese Höchstwerte können aber durch Avatare überschritten werden, die sich erneut auf eine Region einloggen
* Der Traffic entscheidet auch die über die "Beliebten Orte", die jede Nacht ausgewählt werden. Sie können diese sehen, wenn Sie auf den Button "Suchen" klicken und das Register "Beliebte Orte" auswählen. Sie erscheinen auch auf der [[Map|Karte]] als Icon mit dem Daumen nach oben. (Hinweis: Ab der Viewerversion 1.20 sind "Beliebte Orte" nicht mehr länger im Suchsystem enthalten.)
* Wenn Sie ein weiteres langweiliges Streitgespräch darüber beginnen wollen, ob diese Wiki-Seite, die Knowledgebase oder eine andere Informationsquelle (einschließlich verschiedener Linden Lab Mitarbeiter) richtig ist, lesen Sie bitte [http://forums.secondlife.com/showthread.php?t=310130 diesen Thread] und insbesondere diesen [http://forums.secondlife.com/showpost.php?p=2345872&postcount=67 Beitrag]<ref>http://forums.secondlife.com/showpost.php?p=2345872&postcount=67</ref>, der erneut schlüssig bewiesen hat, daß der Traffic ein Punkt pro Avatar pro Minute ist (mit Ausnahme einiger kleinen Fragen über den Zeitpunkt, wann der Mechanismus, der die Minuten ermittelt, läuft)

== Bis 2006 ==
* Ursprünglich war die Verweildauer eine feste Anzahl von Punkten für jeden Bewohner, der dardurch zugewiesen wurde, dass der Anteil der Zeit aus der Gesamtzeit ermittelt wurde, den ein Bewohner innerhalb eines Tages auf den verschiedenen Plätzen in SL verbrachte. Vorher musste ein Resident mindestends ununterbrochen 5 Minuten auf einem Grundstück bleiben, um diesem mindestends einen Trafficpunkt zu geben.
* Linden Lab hat in der Vergangenheit den 2% der Landbesitzer, die die höchste Verweildauer - im Verhältnis zu der Verweildauer, die ihre Grundstücksbesitze erreichten - eine Prämie in US$ angeboten. Im August 2004 wurden 2.308 US$ unter 36 Landbesitzern aufgeteilt. Das war in den Anfangstagen von SL wichtig für die Startfinanzierung, wenn ein Bauwerk, obwohl es beliebt war, aufgrund der sehr geringen Bevölkerungszahl wirtschaftlich nicht überlebenfähig sein konnte.
* Mitte des Jahres 2006 wurden Stipendien, die auf der Verweildauer basierten, entfernt, da das Bevölkerungswachstum ein ausreichend großes Publikum bot, um eine eher herkömmliche Wirtschaft in Second Life zu unterstützen.

== Referenzierte Artikel ==
<references />

[[Category:Text from In-world Notecards|Dwell]]
[[Category:Text from In-world Notecards|Traffic]]

User:Phillie Rhode

2009-11-03T23:02:33Z

Phillie Rhode:

User:Phillie Rhode

2009-11-03T23:01:54Z

Phillie Rhode: Created page with ' '''I am Phillie....''' I am {{Age|04|03|2007}} days old and a wandering Neko. I try to walk all the roads in SL and enjoy the fun and the silence. Translating EN <=> DE IS rel...'

About Traffic/de

2009-11-02T21:54:18Z

Phillie Rhode: moved About Traffic/de to Über Traffic: translation

#REDIRECT [[Über Traffic]]

Über Traffic

2009-11-02T21:54:18Z

Phillie Rhode: moved About Traffic/de to Über Traffic: translation

{{Help/de
|Parent=About Traffic
|LandSim=*}}
Was ist Traffic? (Verweildauer)

[[Linden Lab]] führte den "Traffic" oder die "Verweildauer" urspünglich dazu ein, um [[resident|Bewohner]] zu belohnen, die populäre Orte gebaut haben.

== Seit 2006 ==
* Im Jahr 2006 wurde der Traffic auf eine Minute umgestellt, die ein Avatar in einem Grundstück<ref>http://forums.secondlife.com/showpost.php?p=1371911&postcount=19</ref> verbringt, aber nur für Avatare, die sich innerhalb der Zeitspanne von 24 Stunden für die Datensammlung (für mindestends fünf Minuten) nicht auf andere Grundstücke bewegen. Im Übrigen funktioniert es im Großen und Ganzen noch nach dem Modell vor 2006, wie Linden Lab im Mai 2008<ref>http://www.massively.com/2008/05/26/peering-inside-Trafficking-in-meaning/</ref> erklärt hat
* Es zählt der Traffic von allen [[avatar|Avataren]], unabhängig von deren Kontoart oder ob es sich um einen Bewohner oder einen [[bot|Bot]] handelt
* [[Mainland]] Regionen, die im Allgemeinen auf 40 Avatare beschränkt sind, können keinen Traffic über 57.600 haben, während private Regionen [[estate|Estates]] mit einem [[limit|Limit]] von 100 Avataren normalerweise nicht über 144.000 kommen, diese Höchstwerte können aber durch Avatare überschritten werden, die sich erneut auf eine Region einloggen
* Der Traffic entscheidet auch die über die "Beliebten Orte", die jede Nacht ausgewählt werden. Sie können diese sehen, wenn Sie auf den Button "Suchen" klicken und das Register "Beliebte Orte" auswählen. Sie erscheinen auch auf der [[Map|Karte]] als Icon mit dem Daumen nach oben. (Hinweis: Ab der Viewerversion 1.20 sind "Beliebte Orte" nicht mehr länger im Suchsystem enthalten.)
* Wenn Sie ein weiteres langweiliges Streitgespräch darüber beginnen wollen, ob diese Wiki-Seite, die Knowledgebase oder eine andere Informationsquelle (einschließlich verschiedener Linden Lab Mitarbeiter) richtig ist, lesen Sie bitte [http://forums.secondlife.com/showthread.php?t=310130 diesen Thread] und insbesondere diesen [http://forums.secondlife.com/showpost.php?p=2345872&postcount=67 Beitrag]<ref>http://forums.secondlife.com/showpost.php?p=2345872&postcount=67</ref>, der erneut schlüssig bewiesen hat, daß der Traffic ein Punkt pro Avatar pro Minute ist (mit Ausnahme einiger kleinen Fragen über den Zeitpunkt, wann der Mechanismus, der die Minuten ermittelt, läuft)

== Bis 2006 ==
* Ursprünglich war die Verweildauer eine feste Anzahl von Punkten für jeden Bewohner, der dardurch zugewiesen wurde, dass der Anteil der Zeit aus der Gesamtzeit ermittelt wurde, den ein Bewohner innerhalb eines Tages auf den verschiedenen Plätzen in SL verbrachte. Vorher musste ein Resident mindestends ununterbrochen 5 Minuten auf einem Grundstück bleiben, um diesem mindestends einen Trafficpunkt zu geben.
* Linden Lab hat in der Vergangenheit den 2% der Landbesitzer, die die höchste Verweildauer - im Verhältnis zu der Verweildauer, die ihre Grundstücksbesitze erreichten - eine Prämie in US$ angeboten. Im August 2004 wurden 2.308 US$ unter 36 Landbesitzern aufgeteilt. Das war in den Anfangstagen von SL wichtig für die Startfinanzierung, wenn ein Bauwerk, obwohl es beliebt war, aufgrund der sehr geringen Bevölkerungszahl wirtschaftlich nicht überlebenfähig sein konnte.
* Mitte des Jahres 2006 wurden Stipendien, die auf der Verweildauer basierten, entfernt, da das Bevölkerungswachstum ein ausreichend großes Publikum bot, um eine eher herkömmliche Wirtschaft in Second Life zu unterstützen.

== References ==
<references />

[[Category:Text from In-world Notecards|Dwell]]
[[Category:Text from In-world Notecards|Traffic]]

Über Traffic

2009-11-02T21:52:36Z

Phillie Rhode: translation

{{Help/de
|Parent=About Traffic
|LandSim=*}}
Was ist Traffic? (Verweildauer)

[[Linden Lab]] führte den "Traffic" oder die "Verweildauer" urspünglich dazu ein, um [[resident|Bewohner]] zu belohnen, die populäre Orte gebaut haben.

== Seit 2006 ==
* Im Jahr 2006 wurde der Traffic auf eine Minute umgestellt, die ein Avatar in einem Grundstück<ref>http://forums.secondlife.com/showpost.php?p=1371911&postcount=19</ref> verbringt, aber nur für Avatare, die sich innerhalb der Zeitspanne von 24 Stunden für die Datensammlung (für mindestends fünf Minuten) nicht auf andere Grundstücke bewegen. Im Übrigen funktioniert es im Großen und Ganzen noch nach dem Modell vor 2006, wie Linden Lab im Mai 2008<ref>http://www.massively.com/2008/05/26/peering-inside-Trafficking-in-meaning/</ref> erklärt hat
* Es zählt der Traffic von allen [[avatar|Avataren]], unabhängig von deren Kontoart oder ob es sich um einen Bewohner oder einen [[bot|Bot]] handelt
* [[Mainland]] Regionen, die im Allgemeinen auf 40 Avatare beschränkt sind, können keinen Traffic über 57.600 haben, während private Regionen [[estate|Estates]] mit einem [[limit|Limit]] von 100 Avataren normalerweise nicht über 144.000 kommen, diese Höchstwerte können aber durch Avatare überschritten werden, die sich erneut auf eine Region einloggen
* Der Traffic entscheidet auch die über die "Beliebten Orte", die jede Nacht ausgewählt werden. Sie können diese sehen, wenn Sie auf den Button "Suchen" klicken und das Register "Beliebte Orte" auswählen. Sie erscheinen auch auf der [[Map|Karte]] als Icon mit dem Daumen nach oben. (Hinweis: Ab der Viewerversion 1.20 sind "Beliebte Orte" nicht mehr länger im Suchsystem enthalten.)
* Wenn Sie ein weiteres langweiliges Streitgespräch darüber beginnen wollen, ob diese Wiki-Seite, die Knowledgebase oder eine andere Informationsquelle (einschließlich verschiedener Linden Lab Mitarbeiter) richtig ist, lesen Sie bitte [http://forums.secondlife.com/showthread.php?t=310130 diesen Thread] und insbesondere diesen [http://forums.secondlife.com/showpost.php?p=2345872&postcount=67 Beitrag]<ref>http://forums.secondlife.com/showpost.php?p=2345872&postcount=67</ref>, der erneut schlüssig bewiesen hat, daß der Traffic ein Punkt pro Avatar pro Minute ist (mit Ausnahme einiger kleinen Fragen über den Zeitpunkt, wann der Mechanismus, der die Minuten ermittelt, läuft)

== Bis 2006 ==
* Ursprünglich war die Verweildauer eine feste Anzahl von Punkten für jeden Bewohner, der dardurch zugewiesen wurde, dass der Anteil der Zeit aus der Gesamtzeit ermittelt wurde, den ein Bewohner innerhalb eines Tages auf den verschiedenen Plätzen in SL verbrachte. Vorher musste ein Resident mindestends ununterbrochen 5 Minuten auf einem Grundstück bleiben, um diesem mindestends einen Trafficpunkt zu geben.
* Linden Lab hat in der Vergangenheit den 2% der Landbesitzer, die die höchste Verweildauer - im Verhältnis zu der Verweildauer, die ihre Grundstücksbesitze erreichten - eine Prämie in US$ angeboten. Im August 2004 wurden 2.308 US$ unter 36 Landbesitzern aufgeteilt. Das war in den Anfangstagen von SL wichtig für die Startfinanzierung, wenn ein Bauwerk, obwohl es beliebt war, aufgrund der sehr geringen Bevölkerungszahl wirtschaftlich nicht überlebenfähig sein konnte.
* Mitte des Jahres 2006 wurden Stipendien, die auf der Verweildauer basierten, entfernt, da das Bevölkerungswachstum ein ausreichend großes Publikum bot, um eine eher herkömmliche Wirtschaft in Second Life zu unterstützen.

== References ==
<references />

[[Category:Text from In-world Notecards|Dwell]]
[[Category:Text from In-world Notecards|Traffic]]

Partnerschaften

2009-11-01T12:19:49Z

Phillie Rhode: changed screenshot

{{Help/de|Parent=Partnering|Avatar=*|Community=*}}

''"Sie können im realen Leben nicht verheiratet sein? Versuchen Sie es in Second Life!"''

== Wie mache ich jemanden zu meinem Partner? ==

Second Life-Paare können jetzt ihre Beziehung öffentlich bekannt machen. Egal, ob Sie verheiratet oder einfach nur befreundet sind, Sie können in Ihrem Profil in Second Life Ihren Partner festlegen und so Ihre Beziehung dem Rest der Community bekannt geben. Das Eingehen einer Partnerschaft kostet jeden der Partner 10 L$.

# Gehen Sie auf die [http://secondlife.com/my/account/partners.php?lang=de-DE Seite "Partner"].
# Geben Sie den '''Vor- und Nachnamen Ihres Partners''' ein.
# Tippen Sie Ihr '''Angebot''' (Ihren Antrag) an Ihren gewünschten Partner ein. Das kann ein Liebesbrief, Liedtext oder etwas anderes sein, was zu Ihnen Beiden am Besten paßt.
# Klicken Sie '''Angebot abschicken'''.
#: [[File:Partner_phillie_rhode.png|640px]]

Ihr potentieller Partner wird über die Emailadresse benachrichtigt, die er mit seinem Second Life Konto benutzt. Er hat sieben Tage Zeit, zu akzeptieren und wenn er es einmal getan hat, werden Ihre Namen jeweils im Profil des anderen erscheinen.

Wenn Sie ein Angebot für eine Partnerschaft bekommen, die Sie ablehnen wollen, können Sie das ebenfalls auf der Seite "Partner" tun.

{{KBvideo|4168128}}

{{KBnote|Dieses Videotutorial zeigt noch das ''alte'' Design der Website, aber grundsätzlich funktioniert alles noch auf die gleiche Weise.}}

== Wie beende ich meine Partnerschaft? ==

Der Person, die sich "scheiden" lässt, werden 25 L$ berechnet.

# [http://secondlife.com/my/account/partners.php?lang=de-DE Gehen Sie auf die Seite "Partner"]
# Markieren Sie die Checkbox, neben der steht: '''" Ich, (Ihr Name), möchte meine Partnerschaft mit folgendem Partner auflösen: (der Name Ihres Partners)."'''
# Klicken Sie '''Auflösen'''. Ihre Partnerschaft ist aufgelöst und Ihr (jetzt) Expartner ist informiert.

== Kann ich nach einer Scheidung erneut eine Partnerschaft eingehen? ==
Wir wissen, dass Herzensangelegenheiten stürmisch sein können. Informieren Sie Ihren Partner, daß Sie wieder zurückwollen — sich übermäßig zu entschuldigen und ein bedeutungsvolles Geschenk helfen oft — und schicken Sie Ihm ein neues Angebot für eine Partnerschaft.

Wir wünschen Ihnen das Beste in Ihrem Neuanfang.

== Bringt uns das Eingehen einer Partnerschaft einen besonderen Status? ==
'''Die Anzeige der Partnerschaft erfolgt aus Eitelkeit und nur zu sozialen Zwecken''' und verändert In-world Berechtigungen, Fähigkeiten in Gruppen, Supportmöglichkeiten und so weiter ''nicht'' . Wenn Sie zum Beispiel ein Premiumkonto haben und Ihr Partner ein Basiskonto, wird dieser ''keine'' Dienste von Concierges bekommen. Wir ''können weder'' private Einzelheiten vom Konto Ihres Partners enthüllen, [[Linden_Lab_Official:Sharing_Second_Life_Accounts|''noch'' erlaubt Ihnen die Tatsache, eine Partnerschaft zu haben, es, ein Konto zu teilen]].

== Wird sich mein Nachname in Second Life ändern, wenn ich eine Partnerschaft eingehe? ==

Nein. Ihr Name bleibt derselbe.

== Kann ich herausfinden, wann ich eine Partnerschaft hatte? ==
Ihre Profile im Viewer zeigen Ihnen das nicht. Dessen ungeachtet können Sie aber diesen magischen Moment erneut erleben, wenn Sie Ihre ursprünglichen Anfragen nach der Partnerschaft, die Ihnen per Email geschickt wurden, gespeichert haben.

File:Partner phillie rhode.png

2009-11-01T12:18:20Z

Phillie Rhode:

Partnerschaften

2009-11-01T12:12:21Z

Phillie Rhode:

{{Help/de|Parent=Partnering|Avatar=*|Community=*}}

''"Sie können im realen Leben nicht verheiratet sein? Versuchen Sie es in Second Life!"''

== Wie mache ich jemanden zu meinem Partner? ==

Second Life-Paare können jetzt ihre Beziehung öffentlich bekannt machen. Egal, ob Sie verheiratet oder einfach nur befreundet sind, Sie können in Ihrem Profil in Second Life Ihren Partner festlegen und so Ihre Beziehung dem Rest der Community bekannt geben. Das Eingehen einer Partnerschaft kostet jeden der Partner 10 L$.

# Gehen Sie auf die [http://secondlife.com/my/account/partners.php?lang=de-DE Seite "Partner"].
# Geben Sie den '''Vor- und Nachnamen Ihres Partners''' ein.
# Tippen Sie Ihr '''Angebot''' (Ihren Antrag) an Ihren gewünschten Partner ein. Das kann ein Liebesbrief, Liedtext oder etwas anderes sein, was zu Ihnen Beiden am Besten paßt.
# Klicken Sie '''Angebot abschicken'''.
#: [[File:Partners_Torley_Linden.png|640px]]

Ihr potentieller Partner wird über die Emailadresse benachrichtigt, die er mit seinem Second Life Konto benutzt. Er hat sieben Tage Zeit, zu akzeptieren und wenn er es einmal getan hat, werden Ihre Namen jeweils im Profil des anderen erscheinen.

Wenn Sie ein Angebot für eine Partnerschaft bekommen, die Sie ablehnen wollen, können Sie das ebenfalls auf der Seite "Partner" tun.

{{KBvideo|4168128}}

{{KBnote|Dieses Videotutorial zeigt noch das ''alte'' Design der Website, aber grundsätzlich funktioniert alles noch auf die gleiche Weise.}}

== Wie beende ich meine Partnerschaft? ==

Der Person, die sich "scheiden" lässt, werden 25 L$ berechnet.

# [http://secondlife.com/my/account/partners.php?lang=de-DE Gehen Sie auf die Seite "Partner"]
# Markieren Sie die Checkbox, neben der steht: '''" Ich, (Ihr Name), möchte meine Partnerschaft mit folgendem Partner auflösen: (der Name Ihres Partners)."'''
# Klicken Sie '''Auflösen'''. Ihre Partnerschaft ist aufgelöst und Ihr (jetzt) Expartner ist informiert.

== Kann ich nach einer Scheidung erneut eine Partnerschaft eingehen? ==
Wir wissen, dass Herzensangelegenheiten stürmisch sein können. Informieren Sie Ihren Partner, daß Sie wieder zurückwollen — sich übermäßig zu entschuldigen und ein bedeutungsvolles Geschenk helfen oft — und schicken Sie Ihm ein neues Angebot für eine Partnerschaft.

Wir wünschen Ihnen das Beste in Ihrem Neuanfang.

== Bringt uns das Eingehen einer Partnerschaft einen besonderen Status? ==
'''Die Anzeige der Partnerschaft erfolgt aus Eitelkeit und nur zu sozialen Zwecken''' und verändert In-world Berechtigungen, Fähigkeiten in Gruppen, Supportmöglichkeiten und so weiter ''nicht'' . Wenn Sie zum Beispiel ein Premiumkonto haben und Ihr Partner ein Basiskonto, wird dieser ''keine'' Dienste von Concierges bekommen. Wir ''können weder'' private Einzelheiten vom Konto Ihres Partners enthüllen, [[Linden_Lab_Official:Sharing_Second_Life_Accounts|''noch'' erlaubt Ihnen die Tatsache, eine Partnerschaft zu haben, es, ein Konto zu teilen]].

== Wird sich mein Nachname in Second Life ändern, wenn ich eine Partnerschaft eingehe? ==

Nein. Ihr Name bleibt derselbe.

== Kann ich herausfinden, wann ich eine Partnerschaft hatte? ==
Ihre Profile im Viewer zeigen Ihnen das nicht. Dessen ungeachtet können Sie aber diesen magischen Moment erneut erleben, wenn Sie Ihre ursprünglichen Anfragen nach der Partnerschaft, die Ihnen per Email geschickt wurden, gespeichert haben.