Bug Report in Open-SIM? HowTo?

[Pius Noel]

Jetzt habe ich auch noch den Firestorm aktualisiert und einen Teleport auf einer weiteren Region installiert.

Am Viewer liegt es nicht. Aber wenn wenn ich von der Region Homes zur Region Welcome teleportierte, dann stimmt die Blickrichtung nach der Landung immer. Dasselbe gilt auch, wenn ich von der Welcome Region wieder zurück auf meine Homes Region teleportiere.

Innerhalb der Region Homes habe ich mehrere Teleports die auf Destinationen innerhalb von Homes führen. Und nur dabei hatte ich bisher das Problem. Ich kann nicht voraussagen wann es funktioniert und wann nicht.

Wenn ich einen Teleport resette, dann funktioniert es das erste Mal meistens nicht. Manchmal auch 2 oder dreimal und beim dritten oder vieten Mal funktioniert es wiederholt mehrere Male. Verlasse ich die Region und klicke den gleichen TP erneut an, dann kann es funktionieren oder auch nicht.

Bei einem meiner Teleports, bei dem ich die Blickrichtung auf ein Objekt berechne und bei der Ankunft auf einem Objekt lande, das zu Collisions führt, scheint es genau umgekehrt zu sein. Es funktioniert die ersten paar Mal und danach nicht mehr.

Ich baute auch einen TP bei dem ich vorgängig aus 16 Blickrichtungen wählen kann. Wechsle ich vor der Benutzung die eingestellte Richtung, dann funktioniert es meistens erst nach der zweiten Benutzung. Also gleiches Verhalten wie nach einem Reset.

Irgendwo scheint es ein Timing oder Caching-Problem zu geben. Ich versuche es morgen noch mit der XEngine. Dafür muss ich aber meine Konfiguration umstellen, da ich normalerweise nur noch mit der YEngine teste.

[Manfred Aabye]

Solch willkürliches verhalten hört sich nach Server Auslastung an.
Werden vielleicht irgendwelche Warnungen in den log Dateien angezeigt.
Hast du den gleichen Fehler bei osLocalTeleportAgent auch?

Wenn ich auf 2 Regionen je ein Skript laufen habe und schnell hin und her springe, dann verschluckt sich mein Server an den Avatar Assets. Liegt aber an meinem fetten Mesh Avatar.
Ich kann ansonsten keine Fehler sehen, Blickrichtung stimmt.

[Anachron]

Inkonsistentes und unvorhersehbares verhalten habe ich wie Pius auch beobachtet.
Zur Art des lookAt-Vektors: Anders als man vo der Benennung meinen könnte ist das nicht der Ortsvektor eines Punktes auf den der Avatar blicken sollte, sondern ein Richtungsvektor der Form <x,y,0> .
Da ich mich bei meinen Testversuchen von chatGPT habe beraten lassen kam die KI dabei noch mit einer zusätzlichen Eigenschaft des Vektors um die Ecke:
Dieser Richtungsvektor sollte normalisiert sein ...
Woher chatGPT diese Weisheit genommen hat, habe ich allerdings nicht feststellen können. Jedenfalls habe ich meinen LookAt-Vector bei meinen Tests von da an immer durch die Funktion llVecNorm() gejagt ... geholfen hat das allerdings auch nix.
Allgemein gebe ich die gewünschte Richtung als Kompass-Winkel vor und mein Script rechnet diesen dann über eine geeignete Funktion in einen passenden Vector um ...
Ein bischen Trigonometrie schadet dabei nie ...
Wie gesagt - manchmal gehts, manchmal dreht sich was, aber nicht so wie es sollte ... und irgendwie habe ich den Eindruck die Blickrichtung vor dem Sprung spielt dabei eine Rolle ... es bleibt kompliziert.

[Mareta Dagostino]

Dieser Richtungsvektor sollte normalisiert sein ...

Da würde ich dem Chatbot jetzt nicht zuviel OpenSim Geheimwissen unterstellen. Richtungsvektoren sind in der Mathematik üblicherweise normalisiert, und der Bot wird gewiss unzählige Mathebücher als Wissensinput bekommen haben.

Wenn ein Körper sich bewegt und man will die Richtung mit einem nicht normalisierten Richtungsvektor ändern (Skalarprodukt), dann ändert man auch die Geschwindigkeit.

[Pius Noel]

Solch willkürliches verhalten hört sich nach Server Auslastung an.
Werden vielleicht irgendwelche Warnungen in den log Dateien angezeigt.
Hast du den gleichen Fehler bei osLocalTeleportAgent auch?
[...]

Dass es an der Serverauslasrung liegt, konnte ich mir nicht wirklich vorstellen. Da ich aber lokal auf meinem PC teste, wo auch der Viewer läuft, habe ich mir in der Hetzner Cloud extra eine VM mit 3 vCPU's hochgezogen und darauf ein mini-Grid mit einer einzigen Region hochgezogen. Die Probleme sind die gleichen.

In den Logs ist nichts zu sehen, das auf Probleme hinweisen könnte und auch das Hochsetzen der Debug Levels und sonstigen Debug Settings brachte keine Hinweise.

Das gleiche Verhalten habe ich auch bei osLocalTeleportAgent mit gesetztem OS_LTPAG_USELOOKAT.

Es gibt auch keinen Unterschied zwischen XEngine und YEngine.

Was den Avatar betrifft, gehört meiner ohnehin zu den Bescheidenen. Ich trage zwar auch Mesh-Kleider bleibe aber in der Regel unter einer Avatar Complexity von 15'000, Bei den letzten Tests habe ich einen vollständig zurückgesetzten Ruth Avatar genommen.

Im Moment fällt mir jetzt auch nichts mehr ein. Ich könnte noch einen Versuch unter Windows machen, aber dazu fehlt mir die passende Umgebung.

[Pius Noel]

In der Zwischenzeit habe ich mein Windows wieder mal reaktiviert OpenSim geklont und kompiliert, Config von meinem Testgrid übernommen, Gridnik und Name angepasst um Konflikte zu vermeiden und neu gestartet. User erstellt, Welcome Region erstellt, per IAR minimal Inventar von Pius mit Outfit, Test-Objekten und Scripten übernommen. Und...

Voilà, das Problem kann ich auch hier reproduzieren. Ich werde noch ein paar Tests machen und im Lauf der Woche einen Bug-Report in die Mantis stellen.

[Manfred Aabye]

Das liest sich aber merkwürdig.
Da bleibt doch nur noch ein schlecht eingestelltes OpenSim.

4 Stunden später

Und richtig, mit einer neuen Konfiguration, gibt es gar keine Fehler mehr bei mir.
https://github.com/BigManzai/OpenSim-She...Config2023

[Pius Noel]

Ich werde meine Konfiguration mal mit deiner vergleichen. Es wäre nicht das erste Mal, dass ich bei einer neuen Version eine notwendige Anpassung verpasst habe

[Manfred Aabye]

So hab mal bei mir 4 Würfel hingestellt.
Auf diesen steht die Blickrichtung.
Getestet habe ich mit Singularity, Alchemy und Firestorm.
Bei Singularity, Alchemy darf man nicht über Bandbreite 3000 gehen,
bei 6000 verschluckt sich der Viewer und stürzt ab.
Komm doch mal zu mir http://openmanniland.de:8002/ (in deine Map kopieren. Du kommst direkt auf die Welcome Region) und teste deinen Viewer,
damit kannst du diesen als Fehlerquelle schon mal ausschließen.
Die 4 oder 8 Würfel kannst du dir direkt kopieren, damit hast du etwas Tipparbeit gespart.

Meine neuen Konfigurationen habe ich gestern stellenweise radikal erneuert.

[Pius Noel]

So hab mal bei mir 4 Würfel hingestellt.
Auf diesen steht die Blickrichtung.
[...]
Die 4 oder 8 Würfel kannst du dir direkt kopieren, damit hast du etwas Tipparbeit gespart.

Meine neuen Konfigurationen habe ich gestern stellenweise radikal erneuert.

Die 4 Würfel auf OpenManniLand funktionieren auch mit meinem Viewer wunderbar. Am Viewer liegt es also nicht.

Beim Vergleich der Konfiguration mit deiner ist mir jetzt sofort aufgefallen, dass ich ubODE benutze und du BulletSim. Wenn ich die Physics Engine umstelle scheint es bei mir tatsächlich auch besser zu funktionieren.

Nach dem ersten Rezzen der Objekte mit den Teleport Scripten, nach einem Neustart des Simulators und nach einem Reset der Scripte, funktioniert der LooAt beim ersten TP aber meistens auch unter BulletSim nicht richtig. Ab dem zweiten TP ging es bei mir mit den Würfel-Scripten unter BulletSim auch immer.

Interessant finde ich noch, dass es auf einer Region mit ubODE und YEngine im OSGrid besser geht als in meinem Test-Grid, obwohl ich in der Konfiguration keine nennenswerte Unterschiede finde. Das deutet aber auch darauf hin, dass evtl. die höheren Latenzen eine Verbesserung bringen.

Die Werte in der Sektion [ClientStack.LindenUDP] habe ich aus deiner Konfiguration übernommen. Das hatte aber auch keinen Einfluss auf das Verhalten unter ubODE.

In deiner Konfiguration ist mir noch die Sektion [InterestManagement] aufgefallen. Ich kannte diese Sektion bisher überhaupt nicht und habe noch nicht versucht mit diesen Werten zu testen. Ich werde das morgen noch nachholen.