Mambas oder: wat soll der Mist?

Mir ist danach mal wieder ein Fass aufzumachen, der heutige Aufreger des Tages sind dabei Mambas.

Mambas sind – wir erinnern uns – ein Stamm von Menschenfressern, die in den Dschungeln um Schendi herum leben. Es ist von ihnen nur sehr wenig bekannt, was einfach bedeutet, dass sie für Norman nur ein unwichtiges Füllmaterial bestenfalls über einige Seiten sind, dem er sonst keine weitere Beachtung schenkt, also nicht mehr und nicht weniger als ein unbedeutender Hirnfurz. Bei der Konstellation ist es anzunehmen, dass es ein Stamm Eingeborener ist, wie zum Beispiel die Yanomami im Amazonas. Mamba wird man nicht einfach so durch Feilen seiner Zähne, wie es manche Spieler gerne zelebrieren, sondern man wird als solcher geboren.

Bekannt ist, dass sie Menschen fressen, spitz angefeilte Zähne haben und auch ihre möglichen Opfer gerne in Fallen locken. Viel mehr ist es nicht.

Ja, es ist damit ohne Frage eine Rolle aus den Büchern, aber eine solche, von der so wenig bekannt ist, dass man sie quasi selbst logisch weiter entwickeln muss, damit es Sinn macht. Viele leben das Mambadasein als eine Art Kampfverband, in dem Frauen und Männer gemeinsam Städte angreifen. Tja, was soll man mit solchen Angreifern im Falle eines Siegs denn machen? Eigentlich ist es schon unmöglich, dass sie größere Städte überhaupt erfolgreich angreifen und wenn sie denn als Menschenfresser erkannt werden – aber als solche kennt man sie sicher nur begrenzt auf Gor – ist die Art des Umgangs auch sehr einfach: Tod.

Brechen können wird man sie ja kaum und wer will ständig einen Sklaven um sich herum haben, der schon Menschenfleisch aß? Alles in allem ist es so eine Rolle mal wieder, die im Lagerleben alleine und unter sich sehr wohl möglich sein kann, da ist es wie mit den Pani, aber die Interaktion mit dem Rest von Gor bis auf „Wir locken unser Opfer des Tages in die Falle und verspeisen ihn“ dürfte doch sehr begrenzt sein. Es wundert mich daher nicht, dass viele momentan wenig im normalen Spiel mit Mambas anfangen können. Meine Phantasie hält sich da jedenfalls auch arg in Grenzen, wenn sie mal wieder Städte angreifen.

Chlorreiche Ideen und anderes Zeugs, Folge I

Heute: verbieten wir doch einfach mal Voice auf Gor-Sims. Eine gute Idee, aber durch Teamspeak, Skype&Co. nicht machbar. Wer es nutzen will, der nutzt es und zieht so Vorteile im Kampf. Überprüfen kann es sowieso direkt keiner.

Daher: gut gemeint, mehr aber auch nicht.

Ohrwurm des Tages: Lalalalala!

Das habe ich heute zwar nicht gesucht, aber durch Zufall gefunden und wollte es schon lange mal wiedersehen, eine Chorszene aus dem Film „Zwei wie Pech und Schwefel“ mit Bud Spencer und Terence Hill, sogar auf Deutsch, bitte sehr. Übrigens ist die Filmmusik von deren Filmen generell sehr gut, wer da auf Youtube sucht, findet so einiges.

GgoolZ-Mo48

Idee: Despammer für Phoenix Firestorm

Wir alle kennen das doch: wer viel einkauft oder unterwegs ist, wird nach dem Betreten von Shops, meistens schon Sims mit diversem Gruscht regelrecht zugemüllt. Seien es Landmarken, Notecards, Gruppeneinladungen, man bekommt alles mögliche, immer und immer wieder und es nervt einfach nur. Lesen tue ich diese Sachen sowieso nicht mehr, sondern klicke es einfach nur noch weg.

Wieso sollte man diese Arbeit nicht den Viewer direkt für einen erledigen lassen können? Das sollte doch recht einfach machbar sein und wäre eine große Erleichterung für uns alle, so meine Idee, fast schon ein Killerfeature in meinen Augen, das das In World Erlebnis für viele stark aufwerten würde.

Also habe ich mich hingesetzt und im JIRA von Phoenix das als neue Feature-Idee für Firestorm unter dem Key #FIRE-527 eingereicht. Mal schauen, was daraus werden wird, ich bin ja gespannt…

Anleitung: wie man den Phoenix Viewer mit dem Squid-Cache betreibt

Das Problem

Wir alle kennen das doch in Second Life: man hat inzwischen Speicherplatz ohne Ende, aber aus verschiedenen Gründen kann man nach wie vor den Cache (also Zwischenspeicher) des Viewers maximal auf 1 GB einstellen und danach ist Feierabend. Dieser Speicher ist dabei auch schneller voll, als einem lieb ist und da viele von uns häufig den Cache auch bei diversen Problemen löschen, wird sein ohnehin schon geringer Nutzen nur noch mehr geschmälert, ohnehin funktioniert er auch sonst nicht besonders gut. Gerade bei den heutigen Speichermonstern sollte es ohne Problem möglich sein, z.B. 10-20 GB an Speicherplatz für Texturen einzustellen, bisher geben das alle Viewer aber nicht her.

Die Idee

Im Internet sind Proxy-Caches ein alter Hut, eine ausgereifte Technik und kostenlos verfügbar. Ein Proxy-Cache – wir benutzen hier dabei die Software Squid 2.7 – ist nichts anderes als ein zwischen dem eigenen Rechner und Internet dazwischen geschaltetes Programm, das anstelle des Viewers die Texturen herunterlädt und lokale Kopien in einer geeigneten Struktur auf der Festplatte anlegt. Ist erst einmal eine Textur lokal auf der Festplatte gespeichert, dann wird sie direkt von der Festplatte gelesen und nicht mehr erst mühselig aus dem Internet geladen.

Früher war dies übrigens schlecht möglich, seitdem aber Linden Lab als Standardtransportprotokoll für Texturen das altbekannte HTTP, mit dem auch jede Webseite arbeitet, eingeführt hat ist dies recht einfach machbar.

Die Lösung

Die aktuellen Phoenix-Viewer erlauben die direkte Angabe eines Proxy-Caches. Wer also Phoenix ohnehin nutzt, der kann dies recht einfach aktivieren, hier in dem Beispiel beschreibe ich die Installation unter Windows ab XP.

Ein Problem bei der Sache ist, dass Linden Lab für den Aufruf derselben Textur in der URL auch den Simnamen vorkommen hat. Man muss also den Squid dazu bringen, dass er für jede Textur intern dieselbe URL (Adresse) speichert, damit es auch wirklich gut funktioniert. Dafür bedarf es eines Features namens storeurl_rewrite, das nur in Squid bis Version 2.7 verfügbar ist. In aktuelleren Versionen mit einer 3 davor ist es nicht vorhanden und daher sind diese für diesen Zweck unbrauchbar. „Anleitung: wie man den Phoenix Viewer mit dem Squid-Cache betreibt“ weiterlesen