Imprudence Viewer Voice Howto auf Deutsch

Worum geht es?

Der alternative Second Life Viewer Imprudence kommt aus Lizenzgründen bis Version 1.3.0 RC1  nicht mit den benötigten Programmbibliotheken der Firma Vivox daher, die zum Betrieb von Voice in Second Life benötigt werden. Viele aber können und wollen auf Voice in SL nicht verzichten und es ist mit ein wenig Handarbeit möglich, mit Imprudence als Viewer auch Voice wie gehabt benutzen zu können.

Dieses Howto beschreibt deren nachträgliche Installation von Voice unter Windows, da der Installer von Imprudence diese Handgriffe bis zurVersion 1.3.0 RC1 nicht vornimmt; ab Version 1.3.0 RC2 ist das im Installer eingebaut!

Voraussetzungen

Zur Installation der Dateien wird ein Archiventpacker benötigt, der mit .tar.bz2 zurecht kommen kann. 7zip kann das, wer daher nicht sicher ist, bitte zuerst diese Freeware installieren, WinRAR kann es auch.

Und los geht es!

Imprudence ist installiert, 7zip oder ein Entpacker mit vergleichbarer Funktionalität ebenfalls? Gut! Als erstes müssen per Hand die Programmteile für Voice aus dem Internet heruntergeladen werden.

Für Imprudence 1.2.x lädt man sich diese Datei herunter und für Imprudence 1.3.x diese. Danach öffnet man die Datei mit dem Entpacker, bei 7zip braucht dies zweimal, da die Datei doppelt gepackt ist.

Im Verzeichnis indra/newview/vivox-runtime/i686-win32/ des Archives dann sind die benötigten Dateien. Aus diesem Ordner kopiert/extrahiert man die folgenden Dateien, und nur wirklich diese, in den Installationsordner von Imprudence:

  • ortp.dll
  • SLVoice.exe
  • vivoxsdk.dll
  • wrap_oal.dll

Dann startet man noch Voice in den Einstellungen neu, ein Relogin ist dazu unnötig und Imprudence sollte sich nun wie gewohnt mit Voice betreiben lassen. Herzlichen Glückwunsch!

Disclaimer

Für Fehler keine Gewähr sowie für durch Fehler und/oder durch Fehlbedienung entstandene Fehler keine Haftung. Diese Anleitung wurde nach bestem Wissen und Gewissen erstellt, aber auch hier gilt nach wie vor: Hirn einschalten und wenn man sich nicht sicher ist, was man tut, lieber die Finger davon lassen und sich jemanden holen, der sich damit auskennt.

Überdies: kein in world Support jedweder Art.

Form follows function oder: Bad Sim Design at its best

Gestern gab es einen Testraid auf die Sim Stones of Silver, nachdem es eine Woche zuvor einen Testraid von denen auf uns gegeben hatte. Stones of Silver ist eigentlich ein Miniverbund aus zwei Sims, die ungefähr rollenspieltechnisch dort weitermachen, wo das alte Aretai unter Chira Mills aufgehört hatte. Außerdem wohnen da inzwischen die meisten Personen dieses alten Aretais. Dementsprechend und schon dank des Namens gut ersichtbar handelt es sich dabei um eine Wüstensim und man weiß in etwa, was einen dort erwartet.

Stones of Silver ist ein Paradebeispiel außerordentlich geschmackvoll schlechten Simdesigns, eines übertriebenen Sicherheitsbedürfnisses und eines für den Gegner absolut unfairen sowie für die Bewohner hässlichen Simdesigns. Aber was ist da los? Da ein Bild mehr als tausend Worte sagt, werfen wir doch einen Blick auf die Karte, denn das schmerzt mal so richtig schön:

Das ganze Design hier ist ein gellend lauter Schrei: "Raide mich ja nicht!"

Rumms, wer sich nur ein wenig mit Sims und deren Gestaltung auskennt, der wird um diese Sim kämpferisch einen weiten Bogen machen wollen, und das aus mehreren Gründen. Der Einfachheit halber habe ich die wichtigsten Standorte nummeriert. Das Motto der Simgestaltung war sicher „Wie baue ich die ultimative Festung“ gewesen, und genau so verkorkst sieht das alles auch aus.

Nun die Kritikpunkte:

  • Es handelt sich hier um einen kleinen Verbund von zwei Sims, Silver Desert und Stones of Silver. Silver Desert ist dabei eine Homesteadsim, d.h. das Avatarmaximum ist 20, während Stones of Silver eine Fullprimsim ist. Die gelb eingezeichnete Linie kennzeichnet dabei die Simgrenze.
  • Wer sich nach Stones of Silver begeben will, der muss nach den Regeln zuerst auf Silver Desert landen. Landepunkt ist die 1 dabei, eine kleine Insel, die mit einem langen Steg zum Festland verbunden ist. Wer nun dort einen Raid anfangen will, der muss entweder im Entengang über die Brücke oder schwimmt durch den recht tiefen See an Land, sofern da nicht irgendwelche Kampffische drin schwimmen.
  • Die Verteidigungswälle sind die Positionen 5 und 6 und bestehen aus Terrain, also Erdhügeln. Das reduziert die Möglichkeit eines Splashschaden deutlich und da sich der Wall über die ganze Simbreite hinzieht, können sich die Verteidiger sehr gut darüber verteilen. Da es keine Vegetation gibt, haben sie zudem über beide Sims freies Schussfeld.
  • Der Schutzgraben zu den Mauern ist mindestens 20m breit und entsprechend tief, hinter den Mauern gibt es bewusst keine zu hohen Gebäude als Angriffsmöglichkeit für Enterhaken, an den Mauern sind noch überall Spikes befestigt und über dem Stadttor netterweise ständig Baumstämme, die man mit Schaden auf den Gegner krachen lassen kann.
  • Spätestens wenn der Tross dann an Position 2 angelangt sein sollte, wird er bereits von den Verteidigern auf ihren Wällen aus der anderen Sim heraus massiv unter Beschuss genommen. Wer sich dabei die Entfernungen auf der Karte anschaut, dem wird dabei auch eines klar: diese Leute zoomen wie die Weltmeister und wegen der Simgrenze in der Mitte funktioniert der Beschuss auf die andere Seite auch nicht immer zuverlässig, aber das gilt dann ja für beide Seiten gleich.
  • Einzig das Gebäude an Position 3 bietet ein wenig Schutz, aber auch nur solange man nicht zu sehr aus der Deckung rausgeht und von Position 6 unter Beschuss genommen wird.
  • Wer wirklich zuverlässig kämpfen will, der muss sich zu Position 4 begeben und unterliegt dann ständig dem Kreuzfeuer. Dazu kommt dann noch die Nähe zur verfluchten Simgrenze, so dass man häufiger ungewollt immer mal wieder mit den üblichen Verzögerungen die Sims wechselt, was dem Kampf auch nicht gut tut.

Was soll man also von so etwas halten? Gar nichts! Diese Festung zu knacken ist mit großem Aufwand zwar möglich, aber dafür bedarf es wirklich einer erheblichen Übermacht auf Seiten der Angreifer, und sollte jemals wer in die Festung während des Kampfes begeben, ist das sicherlich auch eine Sache, mit der sie nicht rechnen.

So aber sind diese Sims das Ergebnis eines extrem übersteigerten Sicherheitsbedürfnisses, man sieht hier „Form follows function“ nur zu überdeutlich umgesetzt und die Leute sollten sich mal wirklich ernsthaft überlegen, warum sie auf Gor unterwegs sind, wenn sie da solch einen Mist hinstellen, der nur „Geh weg!“ aussendet. Zum kontroversen Zusammenspiel gehört eben auch, dass man sich nicht zu sehr in seine Bauten einigelt, sondern potentiellen Gegnern auch durch das Simdesign eine faire Chance gibt, dass er im Fall eines Kampfes Erfolg haben kann. Das ist hier aber absolut nicht gegeben und wer SoS angreift, der ist selber schuld.

Alles in allem sind sie da auch nicht besser als die schutzsüchtigen Piraten, die es mal auf Lydius gab, das ist genau dasselbe Mindset nur in viel größerer Dimension perfektioniert!

Llkdu, Emkdu und OpenJPEG oder: was ist was und wozu braucht man es?

In allen Diskussionen um den Emerald-Client wird auch immer wieder über die Emkdu.dll diskutiert, viele wissen nicht wirklich, wozu diese gebraucht wird noch was sich hinter diesen verschiedenen Begrifflichkeiten wie OpenJPEG und Llkdu verbirgt. Ich will hier einmal das Knäuel ein wenig aufdröseln.

Die Basis von allem: JPEG2000.

Second Life basiert auf 3D-Objekten, die mit Texturen beliebigen Inhalts überzogen werden können. Da diese Texturen viel Bandbreite bei der Übertragung und auf Seiten Linden Labs dauerhaft Speicherplatz benötigen, war beim Design von Second Life eines der Ziele gewesen, einen Standard zu wählen, der möglichst viel Information bei möglichst wenig Speicherbedarf abbilden kann.

Man kennt diese Problematik bereits aus dem WWW, dort ist JPEG das verbreitetste Kodierungsverfahren für Bilder aller Art. Wichtig dabei ist, dass JPEG Bilder verlustbehaftet komprimiert, das bedeutet, es gehen je nach Qualität mehr oder weniger gut sichtbar Informationen verloren. JPEG basiert dabei auf verschiedenen Kodierungsschritten, wobei das Herz ein aus der Mathematik bekanntes Verfahren namens diskrete Cosinus-Transformation darstellt

Nun entstand JPEG aber im Jahr 1992 und seitdem blieb die Welt nicht stehen, im Laufe der Zeit entstanden bessere Verfahren als dieses. Bei der Konzeptionierung von Second Life entschied man sich für JPEG2000 als den Standard aller Bilder. JPEG2000 ist jünger als JPEG, damit technisch weiter und komprimiert Bilder besser. JPEG2000 ist rechenintensiver im Vergleich zu JPEG und basiert auf dem Verfahren der diskreten Wavelet-Transformation, zudem ist es teilweise von Softwarepatenten geschützt.

Kurz: alle Bilder, die wir in Second Life sehen, basieren auf dem Bildstandard JPEG2000. Da dieser sich bisher bis auf einige Nischenbereiche kaum durchgesetzt hat, muss der Viewer die benötigten Grundfunktionen zum De- und Kodieren dieses Standards selber mitbringen. Dies geschieht mit Hilfe einer Programmbibliothek, die die dazu benötiigten Funktionen bereitstellt.

Auftritt: OpenJPEG!

OpenJPEG ist eine Opensource-Implementierung des JPEG2000-Standards, die unter der BSD-Lizenz steht. OpenJPEG ist dabei solide programmiert, aber was die Kodierungs- und Dekodierungsgeschwindigkeit anbelangt die langsamste Variante. Dafür ist die Benutzung von OpenJPEG kostenlos und damit ist es die Standardbibliothek aller alternativen Viewer, die diese zur Darstellung von Texturen benutzen. Der Vollständigkeit halber sei erwähnt, dass es mit JasPer noch eine weitere OSS-Implementierung des Standards gibt, die im Viewer aber nie Verwendung fand.

Schneller: LLkdu!

Die industriell genutzte Standardimplementierung in C++ von JPEG2000 stammt aus dem wenig bekannten Softwarehaus Kakadu Software. Der Autor ist dabei einer der Urheber dieses Standards. KDU im Dateinamen ist dabei nichts anderes als die Abkürzung für „Kakadu“ und LL steht für Linden Lab.

Diese Implementierung des JPEG2000-Standards ist dabei um Längen schneller arbeitend als OpenJPEG, dafür aber kein Opensource und zum Einsatz in Software ist eine saftige Lizenzgebühr fällig. Linden Lab liefert seinen Viewer standardmäßig mit Kakadu als Bibliothek aus, und das Ergebnis macht sich in spürbar schnelleren Ladezeiten der Texturen bemerkbar.

Noch schneller: Emkdu!

Einer der Entwickler von Emerald, Phox Modularsystems, lizenzierte bei Kakadu ebenfalls deren Bibliothek in einer neueren Variante als Linden Lab das tat und baute darum seine eigene Variante namens Emkdu.dll. Die Lizenz zur nicht kommerziellen Nutzung der Bibliothek kostet dabei im Jahr 250 US$, und es machte sich in einer nochmals leicht schnelleren Geschwindigkeit beim Laden der Texturen bemerkbar.

Er baute in die Bibliothek dann auch eine Funktion ein, die den Dateipfad samt Windows-Titel vom Emerald-Viewer in den Metadaten der Avatartextur versteckten, das ist inzwischen nicht mehr der Fall, aber war auch der Anstoß für viel Kritik.

Fazit

Emerald funktioniert bisher mit Emkdu, Llkdu und OpenJPEG, ansonsten jeder Viewer zumindest mit Llkdu oder OpenJPEG. Die Bibliotheken sind dabei beliebig austauschbar; wer z.B. im Verzeichnis von Emerald die emkdu.dll löscht und den Viewer neu startet, dann nutzt der die noch vorhandene openjpeg.dll und gut ist es.

Wer wirklich auf der sicheren Seite sein will, der sollte momentan nur OpenJPEG oder LLkdu nutzen bis die Turbulenzen um Emerald geklärt sind.

Mehr Spaß mit Emerald

Linden Lab hat sich in world mit den Entwicklern von Emerald getroffen und denen gesagt, was nun getan werden muss, damit Emerald nicht bald geblockt wird. Die Liste der Änderungswünsche von Seiten LLs scheint dabei lang zu sein und wird in Bälde veröffentlicht, sobald sie sich darüber klar sind, wie das umgesetzt werden könnte. Bisher ist Emerald nicht gesperrt, der Zugriff weiter erlaubt und Emerald hat nun zwei Wochen, daran zu arbeiten.

Einige Details am Rande sind dabei bereits interessant:

  • LL will, dass emkdu.dll nicht mehr verbreitet wird und sie geben dem als Zeichen von Good Will erst einmal nach. Ebenso hat Linden Lab etwas gegen die Benutzung von llkdu.dll im Emerald an sich. Zukünftige Versionen von Emerald werden also out of the box wohl nur noch OpenJPEG benutzen.
  • Es kann sein, dass in den nächsten Tagen der Zugriff aufs Grid mit einigen älteren Emerald-Versionen gesperrt wird. Dies würde jedoch erst dann geschehen, wenn auf der Seite von Emerald neuere Versionen als Ersatz angeboten werden.

Ich höre die nächsten Schreie und Gerüchte der Marke „Emerald ist gesperrt, waaah!“  jetzt schon, wenn diese Sperrungen älterer Versionen erst einmal aktiv sind. Wir sollten uns alle besser warm anziehen!

Rolle rückwärts

Wie man bei Zasta lesen kann, hat Lydius seinen Prätor wieder. Dafür ist die Person, die der Prätor als Stein des Anstoßes nahm um zu gehen, inzwischen nicht mehr in Lydius tätig und auch kein Owner mehr. Überdies laut Profil nun eine neue Gruppe suchend.

Solange alle nun daraus lernen, so dass so etwas so schnell nicht mehr vorkommt, hat es dann wohl mehr Gutes als Schlechtes gehabt.