Aus "Arriba on Stick" wird "OpenSim on Stick"

[Leora Jacobus]

Also wenn das alles ist, was da in rot kommt...

Irgendwie bewegt sich deine Testi Tester noch im Grid. Wenn du sagst, du seist überhaupt nicht mehr eingeloggt und das kommt trotzdem alle 5-10 Minuten, dann hat dein Grid den Logout nicht mitbekommen und Testi west dort als Zombie weiter rum. Jetzt hat Testi ein Problem mit dem Objekt d2b8ab10-321e-4df1-8e38-fc61ff9975f6, was auch immer das ist, und setzt wieder auf einen "initial" Default zurück.

Kritisch sehe ich das nicht, solange da nichts sichtbares an deinem Avatar fehlt.

Das war ein Mißverständnis. Eingeloggt war sie schon nur AFK also inaktiv. Das System prüft also von sich aus alle 5-10 Minuten etwas obwohl inworld garnichts passiert. Das mit dem Objektxxx auf Default scheint Skin und Layerclothes zu betreffen. Das läßt sich mit "Appearance" zurechtrücken und passiert in anderen Grids auch, sogar in SL scheint also an Viewer und BOM zu liegen und stört mich nicht.

Was mich stört sind die dauernden Alarm- Meldungen in rot. Ich werde auf das letzte funktionierende Backup (des gesamten Ordners) zurückkgehen und vorher versuchen die jüngst erworbenen Sachen per OAR und IAR in Sicherheit zu bringen.

Aber generell könntest du dich fragen, ob ein altes Setup, das seit Jahren nicht mehr supportet wird, eine gute Arbeitsbasis ist? Vermutlich bist du da inzwischen so ziemlich die einzige, die das noch benutzt. Bei ernsthaften Problemen wirst du dann auch ziemlich alleine sein, weil niemand mehr Erfahrungswerte mit dir teilen kann. Du hast doch diverse Accounts in diversen Grids...

Ich brauche genau dieses Setup. Betrachte mich als virtuellen Prepper. *gg* Ich habe erlebt wie Metropolis unterging und wie OSGrid mal fast untergegangen ist von diversen kleineren Grids ganz zu schweigen, wo ich Läden gehabt habe. Mit anderen Worten nichts ist sicher, Nur "was Du als OAR besitzt, kannst Du getrost nach hause tragen" Aber dazu brauche ich ein "zuhause". Was nützt mir die OAR, wenn ich nicht eine Welt habe die MIR gehört, auf MEINER HD sich abspielt und in die ich sie nach Belieben laden kann?

Meine Open-Sim-Existenz ist ein komplexes System aus diversen Leoras in diversen Grids mit einem Zentrum in Craft wo ich OARs rauf- und runterladen kann und einem Heimatplaneten Oos (angeleht an den Zauberer von Oz) wo ich alles sammele, sichte und horte.. Genau das ist der Grund warum ich OS derzeit wieder viel soannender finde als SL.

Es ist ewig her, als ich die Testi Tester zum Leben erweckte, glaube sogar noch unter win7 oder gar XP?
Wie sich der gute alte Stick auf neueren Windowssystemen überhaupt noch macht, keinen Schimmer. Supporten bzw. aktualisieren tue ich das gute alte Teil auch nicht mehr.

Nööö Windows 10 kann sie! Ich habe den "OpenSim on a Stick" ja gerade installiert weil Fred Frederix Dreamworld, das ich davor benutzt habe, mit Windows 10 nicht klarkam das war im April 2020. Erinnerst Du dich? Ich verstehe völlig, daß Du das nicht mehr supportest, hoffte bloß, der Fehler würde Dir irgendwas sagen.

[Pius Noel]

Es ist kaum zu glauben, aber zuerst wollte ich hier schreiben, dass ich die "OpenSim on a Stick" nicht kenne, doch als ich dann zu meinem Erstaunen hier im Thread einen Hinweis von mir auf das kleingeschriebene Passwort von Testi Tester sah, wurde ich stutzig und wühlte in meinen Archiven, wo ich auch fündig wurde.

Ich hatte "OpenSim on a Stick" tatsächlich noch in einer oos.zip-Datei mit dem Original aus Oktober 2019 und einem Archiv meiner Installation unter Windows 10 vom Frühjahr 2020. Zuerst versuchte ich es mit dem Archiv meiner Installation und startete den Firestorm.Viewer.

Boah... selbst "Testis Home" war im Grid Manager immer noch drin (ich benutzte die letzten 2-3 Jahre Windows nur noch selten). Was aber dann geschah war nicht so toll. Testi hat nicht geladen. Orange Wolke, ewig und die OpenSim Konsole spukte fortlaufend "[AVFACTORY]: Received texture update for..." Meldungen zusammen mit jeweils mehreren "[UPLOAD BAKED TEXTURE HANDLER]: Received baked texture ..."-Meldungen aus.

Ich versuchte einen Neustart, von allem. Diesmal war es etwas besser. Von den "Received baked texture"-Meldungen kamen nur noch fünf, aber alles war extrem langsam. Erst als ich die unsichtbare Testi von all ihren Kleidern und was sonst noch da war befreite, erschien sie Ruth-like als Avatar. Wow, das war wenigstens schon mal was.

Es dauerte danach nur noch ein paar Sekunden bis auch bei mir zum ersten Mal die rote HTTP-Fehlermeldung mit der Meldung "System.ArgumentNullException: Value cannot be null." an der Konsole auf dem Bildschirm erschienen ist.

Es schien mit den Alpha-Texturen und anderen Grafik-Artifakten noch mehr nicht in Ordnung zu sein, aber da ich als Firestorm Preview Tester unter Windows gerade nur noch eine veraltete Alpha Version verfügbar hatte, die noch recht buggy ist und meine Grafikkarte auch nicht mehr den gängigen Standards entspricht, war ich nicht sicher, ob es daran liegt.

Also, noch einen Versuch. Dieses Mal mit dem Original aus dem oos.zip von Dorena aus Oktober 2019 mit OpenSim 0.9.1.0-dev. Vor dem Start habe ich noch die Cache im Viewer gelöscht. Nach dem Start dauerte es relativ lange und noch bevor Testi sichtbar wurde poppte eine Dialog-Box mit folgender Meldung auf: "Could not put on outfit. The output folder contains no body parts or attachments". Trotzdem rezzte im Hintergrund langsam alles und nach einer Weile (wirklich mehrere Minuten) war auch Testi sichtbar in voller Montur.

Ich freute mich schon, weil ich bis dahin an der Konsole keinen Fehler mehr sah. Aber ich freute mich zu früh, die rote Medung mit dem HTTP-Fehler tauchte auch hier wieder auf. Ich war mir nicht sicher, aber ich meinte mich an diesen Fehler zu erinnern, da es einmal einen zumindest ähnlichen Fehler gab, der bei einigen (z.B. bubblesz.nl:8002) nach einem Windows Update erschienen ist.

Also packte ich alles in ein Archiv und brachte es in mein Ubuntu Linux System, wo ich es in einem Docker Container mit Mono entpackte und startete, da ich unter Linux kein Mono mehr habe. Tönt jetzt kompliziert, aber keine Angst, ist es für mich nicht

Und auch hier, wieder alles wie unter Windows. Wieder die Meldung beim ersten Start, wieder dauerte das erste Rezzen lange und wieder kam die rote Fehlermeldung an der Konsole. Das Problem mit dem Windows Update kann es also nicht sein. Aber abgesehen von dieser popeligen Fehlermeldung funktioniert es jetzt bei mir sowohl unter Windows als auch unter Linux recht gut.

An dieser Stelle war mein Hauptproblem mit dem zerschrotteten Avatar offensichtlich die Cache. Denn nach dem Leeren der Viewer-Cache dauerte es zwar zuerst recht lange bis die orange Wolke weg war, aber irgendwann war der Avatar da und es lief auch alles recht flüssig.

Ich hatte das Problem übrigens schon öfters, wenn ich mit meinen Alts in den verschiedenen Grids mit dem gleichen Outfit unterwegs war. Vor allem die Alpha-Texturen machen bei mir immer wieder Probleme. Aber ich hatte auch schon mal keine Schuhe mehr bei meinem Avatar in meinem Test-Grid, während die gleichen Schuhe im OSGrid da waren.

Ich bin mir aber hier nicht nicht sicher, wie weit Bake on Mesh mit den diversen Problemen zu tun hat, denn allein die Masse der "Received texture update for.../Received baked texture ..."-Meldungen, die ich jetzt nach einem weiteren Start des Viewers wieder hatte, finde ich nicht normal.

Als letzter Schritt für heute versuchte ich noch manuell ein Update auf die zuletzt freigegebene OpenSimulator Version 0.9.2.2 zu machen. Dazu erstellte ich aus dem Zip-Archiv von der opensimulator.org Web-Seite ein neues Verzeichnis und kopierte alle .db- und .ini-Files sovie das Regions-Verzeichnis aus dem OOS-Verzeichnis an die richtigen Stellen im neu erstellten Verzeichnis.

Da sich die .ini-Files zu stark geändert haben, hat das leider noch nicht geklappt. ch werde morgen oder übermorgen noch versuchen die notwendigen Anpassungen zu machen und werde hier über meine Erfolge oder Misserfolge wieder berichten.

Falls es klappt, dann könnte es vielleicht doch noch zu einem Schritt in Richtung einer etwas aktuelleren Version beitragen.

Pius /

P.S. Ich muss jetzt los... Typos dürft ihr gerne behalten

[Leora Jacobus]

Danke tausendmal für die ausführliche Antwort!

Ich habe ja weit weniger Probleme als Du aber meine Version ist auch von April 2020 ... DACHTE ich. Ich glaube aber da hasbe ich sie nur heruntergeladen die Urprungs- ZIP und entpackt.

Seitdem war sie unter Windowes 10 immer recht stabil. Es ist nicht das GRID sondern die On A Stick- Version und die hat ja den Vorteil vollkommen autonom in einem eigenen Directory zu laufen. Daher kopiere ich mir regelmäßig (wie alle Backups viel zu selten!) dieses ganze DIR auf eine andere Festplatte

Heute habe ich nun mit dem von November 2023 neu begonnen (hatte inzwischen nicht viel gemacht) nachdem ich mir vorher Testis Inventar von November bis heute als IAR gesichert hatte. Der blöde Fehler mit den roten Zeilen trat aber wieder auf, anfangs nur selten, später öfter. Er lautet

Code:

2024-01-29 19:04:45,450 ERROR [BASE HTTP SERVER]: HandleRequest() threw exception
System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: source
   bei System.Linq.Enumerable.Select[TSource,TResult](IEnumerable`1 source, Func`2 selector)
   bei OpenSim.Services.UserAccountService.UserAccountService.GetUserAccounts(UUID scopeID, List`1 IDs)
   bei OpenSim.Region.CoreModules.Framework.UserManagement.UserManagementModule.GetUsersNames(String[] ids, UUID scopeID)
   bei OpenSim.Region.ClientStack.Linden.BunchOfCaps.GetDisplayNames(String request, String path, String param, IOSHttpRequest httpRequest, IOSHttpResponse httpResponse)
   bei OpenSim.Framework.Servers.HttpServer.RestStreamHandler.ProcessRequest(String path, Stream request, IOSHttpRequest httpRequest, IOSHttpResponse httpResponse)
   bei OpenSim.Framework.Servers.HttpServer.BaseStreamHandler.Handle(String path, Stream request, IOSHttpRequest httpRequest, IOSHttpResponse httpResponse)
   bei OpenSim.Framework.Servers.HttpServer.BaseHttpServer.HandleRequest(OSHttpRequest request, OSHttpResponse response)

Selbst mir als Total Doofie ist klar, daß irgend ein Wert nicht NULL sein sollte, Parametername: source.

Es scheint nichts mit BOM zu tun zu haben, eher mit GodModden. WEnn ich das mache wird er häufiger. Ich habe es mal notiert. Es erstaunt mich daß die Abstände so unregelmäßig sind und ich checke nicht so wirkllich, was es auslöst. Beobachtet habe ich diese roten Zeilen heute um: Beginn 18:16 erster Fehler um 19:04 und 19:20... nix mehr (zum Teil AFK aber inworld) ... erst wieder 20:48 - 51 - 52- 55- 56 - 58 (da hatte ich gegodmodded) - danach nix mehr bis 21:01

Ich werde mal versuchen damit zu leben und sehr viel öfter Backups machen.

[Pius Noel]

... Es ist nicht das GRID sondern die On A Stick- Version und die hat ja den Vorteil vollkommen autonom in einem eigenen Directory zu laufen....

Das ist mir schon klar. Ich denke ich habe hier die genau gleiche Version von Dorena, die du auch hast.

Im sogenannten Standalone-Betrieb ist es nur eine Frage der Konfiguration, ob OpenSimulator ein komplexes Datenbank Management System, wie MySQL oder Maria DB benötigt oder ob SQLite als einfaches Datenbaksystem verwendet wird, das die Datenbank auf mehrere Dateien verteilt direkt im OpenSim bin-Verzeichnis verwaltet.

SQLite ist weniger performant und kann deshalb recht schnell an seine Grenzen stossen. Das macht sich vor allem dann bemerkbar wenn grössere Mengen an Daten gespeichert werden müssen. Ich hatte den Eindruck, dass die Probleme bei mir zum Teil allein schon damit zusammen hingen, dass die Daten nicht schnell genug geladen wurden, so dass es beim Firestorm Viewer zu Timeouts gekommen ist. Vielleicht hat der Singularity Viewer weniger Probleme.

SQLite hat auch den Nachteil, dass keine Gruppen eingerichtet werden können. Aber das ist bei deiner Nutzung vermutlich auch kein Problem.

Es ist auch eine reine Frage der Konfiguration, ob der Standalone-Betrieb total lokal isoliert erfolgt oder ob ein Zugang zum Hypergrid ermöglicht wird. Beides hat seine Vor- und Nachteile. Schnell mal in ein Grid rüber hoppen, um sich etwas zu holen, kann ganz prachtisch sein, kann aber auch zu mehr Chaos beitragen.

[OT] Nebenbei bemerkt, habe ich für mich auch erst kürzlich die Verwendung einer Standalone-Konfiguration wieder entdeckt. Da sich meine Lebensumstände verändert haben, habe ich beschlossenen mein eigenes Test- und Bastel-Grid einzustellen und mich für meine Basteleien ganz auf meinen lokalen PC zurückzuziehen. Eine kleine Region werde ich auf OSGrid noch behalten, die wird aber nur Online sei, wenn ich sie benötige. Wo ich in Zukunft mein virtuelles Zuhause aufschlagen werde, ist noch offen.

[Klarabella Karamell]

probiert doch mal den ollen cool-viewer mit Testi...

[Leora Jacobus]

Eine technische Frage: Gibt es Maximalgrößen von OARs die dieses System noch verdaut?

[Dorena Verne]

Wäre mir neu.

[Leora Jacobus]

Verstehe ich das richtig? Egal wie groß eine OAR das System müßte sie schlucken?

Zum Beispiel eine mit so 10 000 ++ Prims inworld, die auf der Platte 2 046 596 KB KB hat?

Kommt die Datenbank da nicht an Grenzen?

[Anachron]

10.000 Prims und 2 GB sind doch keine Extremwerte ... das macht die Datenbank mit links ...

Die Frage ist auch nicht, ob SQLlite das handeln kann, sondern wie performant das dann noch ist. Im Prinzip hat SQLlite die gleichen Einschränkungen wie MySQL oder MariaDB - es wird nur ab einer gewissen Grösse immer langsamer ...

[Pius Noel]

Kurzanleitung für ein Update von "OpenSim On Stick" von OpenSim Version 0.9.1.0 Snail Dev auf OpenSim 0.9.2.2.

Vorausgesetzt, es wird kein Hypergrid benötigt und die Konfiguration der Netzwerkadressen und Ports wurden nicht verändert, dann kann die "OpenSim On Stiick" aus dem ZIP-Archiv oos.zip von Dorena ganz einfach auf den Stand der immer noch aktuellen freigegebenen OpenSim Version 0.9.2.2 aktualisiert werden.

Mit dem Befehl show version an der OpenSim Server Konsole kann sichergestellt werden, dass es sich bei der bisherigen Version um die gleiche Version wie bei mir handelt.

Code:

Region (Jasice) # show version
Version: OpenSim 0.9.1.0 Snail Dev         (SIMULATION/0.3 - SIMULATION/0.8)
Region (Jasice) #

Im Folgenden benutze ich zwei Verzeichnis-Namen: oos und opensim-0.9.2.2. oos ist das Verzeichnis mit der bisherigen Version. opensim-0.9.2.2 ist selbstredend das Verzeichnis mit der neuen Version. Im Grunde genommen sind die Namen egal. Sich könnten auch alt und neu heissen. Wichtig ist, dass sich unter diesen Verzeichnissen an oberster Stelle jeweils das Unterverzeichnis bin mit dem Programm OpenSim.exe befindet.

Schrtitt für Schritt-Anleitung

1. Sicherheits-Kopie des Verzeichnisses oos erstellen.

2. Von der OpenSimulator Home Page die Zip Datei mit den Binaries von OpenSim 0.9.2.2 herunterladen.

3. Die heruntergeladene Datei opensim-0.9.2.2.zip entzippen.

4. Das entzippte Verzeichnis opensim-0.9.2.2 neben das Verzeichnis oos verschieben.
Achtung: manchmal befindet sich das gewünschte Verzeichnis im enzippten Verzeichnis mit dem gleichen Namen.

5. Im bereitgestellten Verzeichnis opensim-0.9.2.2 an oberster Stelle ausser dem Verzeichnis bin alle Dateien und Verzeichnisse löschen. bin muss vollständig erhalten bleiben.

6. Anschliessend nachstehende Dateien aus oos in die entsprechenden Verzeichnisse in opensim-0.9.2.2 kopieren. Dateien, die im Zielverzeichnis bereits vorhanden sind, müssen überschrieben werden.

1. Datei oos\read me.TXT nach opensim-0.9.2.2\ kopieren.
2. Datei oos\bin\Regions\Regions.ini nach opensim-0.9.2.2\bin\Regions\ kopieren.
3. Datei oos\bin\config-include\StandaloneCommon.ini nach opensim-0.9.2.2\bin\config-include\ kopieren.
4. Alle .db-Dateien aus oos\bin\ nach opensim-0.9.2.2\bin\ kopieren (ausgenommen opensim-nunit.db).

Das ist eigentlich schon alles (ich hoffe, dass ich nichts wichiges vergessen habe). Jetzt kann OpenSim.exe aus dem Verzeichnis opensim-0.9.2.2\bin\ gestartet werden. Ich empfehle einen ausgiebigen Test zu machen und dann ggf. die Verzeichnisnamen zu ändern. Die Sicherungs-Kopie der alten Version würde ich noch eine Weile behalten.

Aber aufgepasst, da die Grundkonfiguration in der Distribution der neuen Version an die neuen Möglichkeiten angepasst wurde, gibt es kleinere Unterschiede. Aufgefallen ist mir:

1. Die Script Engine ist neu YEngine. Falls notwendig, könnte XEngine in der OpenSim.ini wieder zugeschaltet werden.

2. Das MapImageModule ist nicht mehr Warp3DImageModule, das schönere Map-Images produzierte, aber mehr Resourcen benötigte. Auch Warp3DImageModule könnte in der OpenSim.ini wieder zugeschaltet werden, falls schönere Map-Images eine Rolle spielen.

3. Windlight (in OpenSim Ligtshare genannt) wurde mit OpenSim 0.9.2.x entfernt. Es können immer noch Einstellungen über Scripte vorgenommen werden. Mir ist jetzt aufgefallen, dass diese aber bei jedem Neustart verloren gehen, da in den SQLite Datenbanken keine Möglichkeit zur Speicherung vorgesehen ist.

Ansonsten ist mir nichts negativ aufgefallen. Bei mir läuft es viel performanter und ich hatte auch nach langem intensivem Testen keinen einzigen Fehler oder sonstige abnormale Fehlermeldungen in den Logs.

In dieser Konfiguration werden nur die StandaloneCommon.ini und die Regions.ini angepasst. Alle anderen .ini-Files werden, wie von der OpenSim-Distribution geliefert, belassen. Sie könnten bei Bedarf jederzeit angepasst werden.

Ursprünglich wollte ich eine Konfiguration bereitstellen in der alle benötigten Parameter am Anfang der OpenSim.ini definiert werden können. Damit andere auch noch verstehen können was da passiert und somit möglichst nahe an den gewohnten Stadards zu bleiben, habe ich aber darauf verzichtet. Wer weiss, vielleicht wird das ein Projekt für den nächsten Winter .

Pius /